Re: Buttoning up a public emulation session

["James H H Lampert" <jamesl@xxxxxxxxxxx>]

A simple solution! No exit programs; no new subsystems; 
it's all done in the application code.
It's truly amazing what can happen after a good night's 
sleep, and after looking at other people's suggestions. It 
came to me as I was pulling up the V4R2 softcopy CD, to 
look up the TELNET exit programs and see if that approach 
would work.
This will only work for situations where the emulator is 
locked into an auto-login, and the user profile is locked 
into an application, but for this situation, those are the 
givens.
Premise 1: You can do a GRTOBJAUT to a signed-on device if 
you're the one signed on to it (but ONLY if you're the one 
signed on to it, because of locks).
Premise 2: All signed-on terminal sessions have the device 
name as their job name. Therefore, a CL program can get 
the device name just by doing a RTVJOBA for the job name.
Premise 3: If your working privileged accounts have 
QSYSOPR as a group profile, then they have the run of the 
system, EXCEPT for those devices QSYSOPR is locked out of, 
even if you've got the system value set to restrict 
QSECOFR access.
Thus, all you have to do is have the application's startup 
CL, running under *OWNER authority, retrieve the device 
name, and if it's in the "public" device name series, do a 
series of GRTOBJAUTs on the *DEVD to lock all but the 
public account out. For *DEVDs that already exist, that 
will likely only repeat what had already been done before; 
for those that have been freshly AUTOCFGed into existence, 
it will achieve the "lockout" status before the 
application screen even comes up.
Absurdly simple idea, really; I wish I knew why it took me 
so long to come up with it.
--
JHHL