Re: OSS Server, send message to HOMETERM

On 2 Mrz., 16:12, Keith *** <kdic...@xxxxxxxxxxx> wrote:
wbreidbach wrote:
On 2 Mrz., 10:59, Keith *** <kdic...@xxxxxxxxxxx> wrote:

William, Lin wrote:

On Feb 28, 12:26 pm, MicroTech <Henry.KO.Nor...@xxxxxxxxx> wrote:

Hello William!

HOMETERM specifies the name of the process’ “home terminal,” and by
default (unless redirected), I/O for STDIN/OUT/ERR will all go via
that same file.

In your code, assuming everything else is OK, the text string will
indeed be sent as a message to (not from ;) the $receive queue for the
process you specified. An fprint() return value of zero tells me that
the process read zero bytes from $receive: the return value is the
number of bytes actually transferred to the application (not the
number of bytes written to the process), which will be zero if the
process reads zero bytes).

So you should check your “hometerm” process—from what you describe, it
looks as if it calls READ() or READUPDATE() on $receive with a read-
count of zero (which will just take the request off the queue and drop
it in the bit bucket).

Your $abcd “hometerm process” has to be pretty sophisticated, in order
to deal with all I/O types (READ, WRITE, and WRITEREAD), and to handle
possible prompts (such as from Inspect)… Why have you “rolled your
own”? Why not use VHS?

Cheers,

Henry Norman
MicroTech Consultinghttp://groups.google.com/group/MicroTech_Software

I'm sorry that didn't mention it, $ABCD is autually a VHS
process....   I've figured out another method of sending message to
hometerm, that's use PROCESS_GETINFO_ to get home terminal and then
open /write /close message to it.

And I tried the test again, below is the result.

source code--
   //test
   int fresult;
   char strResult[100];
   fresult = fprintf(stderr, "MYPROG, Standard err output Test");
   sprintf(strResult, "stderr result = %d", fresult);
   generateHomeTermEvent(strResult); //send message to home terminal

   fresult = fprintf(stdout, "MYPROG, Standard output Test");
   sprintf(strResult, "stdout result = %d", fresult);
   generateHomeTermEvent(strResult);

message get from VHSL--
01:53:01 $Y575    stderr result = -1
01:53:01 $Y575    stdout result = 28

Anyway, If we can find out a more simple way of sending message to
HOMETERM, I would like to try...

Thanks.

So is this code is running in a Pathway OSS serverclass for which you did NOT specify a value for STDERR or STDOUT?  If so, this result seems at odds with the description in the Pathway manual for configuring serverclasses.  That manual says for both STDERR and STDOUT that if you do not specify a value for the attribute, a null string is sent.  Yet your results seem to show that stderr is unusable while stdout works.  Are you certain that no STDOUT attibute was defined for the serverclass?  Do an PATHCOM INFO SERVER <name of your serverclass> to check to see whether an STDOUT from some earlier serverclass definition got carried over to this serverclass.

I did a little searching in the manuals, and perhaps the intended way to do what you seem to want to do is to use the OSSTTY utility, which is documented in the Open System Services Programmer's Guide, chapter 7 in the version I looked at.  The short description is that OSSTTY is a Guardian program that can accept OSS opens and pass through the data streams to certain kinds of Guardian files.  Using it to redirect stdout and stderr to a VHS process is specifically mentioned, which seems to be what you want to do..  For example, if the OSSTTY program were started with process name $X and term $ABCD, you would use it by configuring the Pathway serverclass to define STDERR as /G/X/#stderr then when you wrote to stderr from the Pathway server, the data would go to the OSSTTY process, then to the VHS process.  Look at the documentation I mentioned for a complete description of how to use it.

I don't know what special things OSSTTY has to do to accept OSS opens.  I don't even know why something special has to be done to allow a Guardian process to accept an OSS open, but free mixing was not implemented when OSS was first implemented.  I'm sure there is some technical reason; I just don't know what it is.

I imagine that, in principle, VHS could be modified to accept OSS opens as well as Guardian opens (since OSSTTY, a Guardian process can accept OSS opens), but I see no documentation that says VHS has been changed to do so..  OSSTTY can be used to redirect to places other than VHS, so maybe they decided to do the extra work just once, in OSSTTY, rather than there and in VHS.- Zitierten Text ausblenden -

- Zitierten Text anzeigen -

Probably OSSTTY is the solution, we had problems without OSSTTY with
an OSS batchjob started via netbatch a while ago.

I just tried the following
 mxci >2/G/homex          where $HOMEX is a Guardian process acting as
a hometerminal

but the result is: 2/G/homex:  cannot create          and of course
mxci does not start up.

Maybe it is the same problem writing to VHS, we do not use VHS so I
cannot try.

Regards

Wolfgang

Did you make a typo in the above?  I assume you meant the redirection to be:

   mxci 2>/G/homex

That is, the 2 goes before the > rather than after when you are redirecting stderr.

And I seem to recall that in some circumstances, Guardian process names longer than 4 characters after the $ are a problem, though I don't remember exactly why.  So it might have been better to shorten $HOMEX to $HOMX or something similar.

Given the documentation about OSSTTY, I wouldn't expect those changes to make it work, unless $HOMX were a process running OSSTTY, but it can't hurt to try it to see what happens.- Zitierten Text ausblenden -

- Zitierten Text anzeigen -

.

Loading