$GETJPI - terminal

[Willem Grooters]

Environment:

$ pascal/ver
HP Pascal Alpha V5.9-95 on OpenVMS Alpha V7.3-2

Given this code snipplet:

ItemList[0].Buflen := SIZEOF G_Currterminal.BODY) ;
ItemList[0].ItmCod := JPI$_TERMINAL ;
ItemList[0].Buffer := IADDRESS (G_CurrTerminal.BODY);
ItemList[0].RetLenAdr := IADDRESS (RetLenTrm) ;

ItemList[4].Terminator := 0 ;

Retstat := $GETJPIW (,,,ItemList,,,) ;

in which G_CurrTerminal is defined as:

G_CurrTerminal : VARYING [8] OF CHAR ;

If run from a process when logged in, the terminal will be returned as (for example) OPA0: in G_CurrTerminal.body, and (since not specified) 0 in G_CurrTerminal.LENGTH. This is taken care of later on.

however, in a subprocess (SPAWN and then run the program), G_CurrTermninal is returned empty (all inprintables). My expectation would be the same as teh parent process.

If this is normal behaviour, how would I get the terminal the process is attached to (apart from referring bto SYS$OUTPUT, which may have been redefined) ?

[Steven Schweda]

http://h71000.www7.hp.com/doc/732FINAL/4527/4527pro_004.html

JPI$_TERMINAL

Returns, for interactive users, the process's login terminal name as acharacter string. Because the terminal name can include up
to 8characters, the buffer length field in the item descriptor shouldspecify at least 8 bytes. Trailing zeros are written to the
outputbuffer if necessary.

[The sub-ideal whatever-to-HTML conversion is
not my fault.]

Note: "interactive".

If I were looking for a terminal, I'd
probably ask about SYS$COMMAND. Otherwise, I
suppose that one could try to climb up the
ladder of parent processes, looking for a
better answer.

[Steven Schweda]

Not proof, but suggestive:

alp $ show logical sys$command
"SYS$COMMAND" = "_ALP$RTA2:" (LNM$PROCESS_TABLE)

alp $ spawn show logical sys$command
%DCL-S-SPAWNED, process SMS_47505 spawned
%DCL-S-ATTACHED, terminal now attached to process SMS_47505
"SYS$COMMAND" = "_ALP$RTA2:" (LNM$PROCESS_TABLE)
%DCL-S-RETURNED, control returned to process _RTA2:

alp $ write sys$output f$getjpi( "", "terminal")
RTA2:

alp $ spawn write sys$output f$getjpi( "", "terminal")
%DCL-S-SPAWNED, process SMS_30276 spawned
%DCL-S-ATTACHED, terminal now attached to process SMS_30276

%DCL-S-RETURNED, control returned to process _RTA2:

[John Gillings · Accepted solution]

Willem,

As Steven's SPAWN command shows, JPI$_TERMINAL is only defined for the owner of the terminal (ie: the parent process).

It's not necessary to walk the process tree, JPI$_MASTER_PID will take you directly to the top.

You need the equivalent of the DCL:

F$GETJPI(F$GETJPI("","MASTER_PID"),"TERMINAL")

This will work for all processes, including the master itself. Try:

$ WRITE SYS$OUTPUT F$GETJPI(F$GETJPI("","MASTER_PID"),"TERMINAL")
$ SPAWN WRITE SYS$OUTPUT F$GETJPI(F$GETJPI("","MASTER_PID"),"TERMINAL")
$ SPAWN SPAWN WRITE SYS$OUTPUT F$GETJPI(F$GETJPI("","MASTER_PID"),"TERMINAL")
$ SPAWN SPAWN SPAWN WRITE SYS$OUTPUT F$GETJPI(F$GETJPI("","MASTER_PID"),"TERMINAL")

etc...

[John Gillings]

oh, and I just noticed as I hit "SUBMIT"...

your code:

>Retstat := $GETJPIW (,,,ItemList,,,) ;

Although the IOSB is documented as "optional", a prudent programmer will never omit it. The return status will only tell you if you have a syntactically correct call. It will not tell you the result of the $GETJPI query.

See $ HELP SYSTEM $GETJPI ARGUMENTS

[Hoff]

What task might you be resolving here, beyond the obvious discussion of retrieving the name behind SYS$COMMAND?

I've been at this OpenVMS coding at least a year or two, and recently discovered I blew a case of this when I was using SMG$, and missed an error sequence.

This whole area is fraught with oddities, FWIW, and the best course depends highly on the particular application requirement(s) in play here. More than a few applications have (or have had) incorrect decisions around the particular capabilities of the device target, for instance.

[Willem Grooters]

Steven/John,
That would do the trick, I'll use GETJPI(JPI$K_PARENT_PID) and get the right data from there - including usage (and handling) of IOSB.
Hoff:
The program is used to change the process environment: UIC, username and privilege masks, as if the user logs in; a requirement in the way the whole environment is set up. As a result, the terminal will no longer be accessabale unsless it's ACL is changed. I found code that uses $CHANGE_ACL for this, but the only reference I could find on this service was it is obsolete, and an alternate should be used to do this. I used the alternative ;)

FYI: The original is a program, written over 10 years ago, of which the source is lost. By reverse-engineering we could develop code that was functionally equivalent - but due to time constraints, not all possibilities were covered - and usage of the functionality in a SPWANed process was one of them.

[Willem Grooters]

HAs been implemented and it works. Drawback: On return, the terminal protection is not fit for that user. But that's another story.