Dennis Schaffer wrote:
If you're talking about CA's VM:Batch, code executing on a worker machine
(i.e. the customer application) can issue the "VMBATCH SERVICE STACK $USER"
to place on the program stack the userid of the submitting job.
In my case it is IBM VM Batch, not the CA product. Regardless, it's not
the userid of the submitting job I need. That is already available as
the "jobowner" parm passed to DGROOLY EXEC.
What I need is the ALTID value used by the submitter.
When the ALTID is specified on a BATCH SUBMIT command, the jobowner (as
far as VM Batch is concerned) is still the ID submitting the job. That
ALTID value is not passed to DGROOLY, so DGROOLY has to resort to other
means of obtaining it:
A more generic solution is the following rexx code which will obtain the
same information by perusing z/VM's VMDBK control block:
if substr(userid,1,6) = 'VMBAT0' then do
numeric digits 12
parse value diag(8,'CP LOCATE VMDBK ' userid) ,
with . '15'x . $vmdbk .
$addr = x2d($vmdbk) + x2d('5F0')
$addr = insert('.8',d2x($addr,8),8)
parse value diag(8,'CP D HT'$ADDR) with ,
. . . . . . $userids .
userid=strip(substr($userids,2,8))
end
The problem I see with this is the use of a privileged command. CP
LOCATE is not generally available for all users. Of course a mod could
make it available, but that sort of breaks the "no mods" philosophy.
I like the LCLQRY approach... even my 'brute force' approach is growing
on me.... :-)
Don
