Re: Finding Current Subsystem

On 19-Mar-2015 09:24 -0500, rob@xxxxxxxxx wrote:

On 19-Mar-2015 08:46 -0500, Gary Thompson wrote:

On 19-Mar-2015 08:36 -0500, Diego Kesselman wrote:

On 2015-03-19 7:30 GMT-06:00 Rich Loeber wrote:

I think I'm having a brain cramp. Is there an easy way in a CL
program to find out what subsystem the program is currently
running in? I would have thought it would be available from
RTVJOBA, but no dice. I also looked at the values returned from
the QUSLJOB API but I don't see it there either.

Suggestions?

Maybe you can perform DSPJOBLOG with output and look for the data
you need

Good suggestion Diego:

*...+....1....+. [..]..4....+....5....+....6....+....7....+...[..]
5770SS1 V7R1M0[..] Display Job [..]
Job name . . [..]GTHOMPSON1 User . . . . . . : GTH[..]
Job descripti[..]BASIS2 Library . . . . . : SWI[..]
MSGID TYPE[..]SEV DATE TIME FROM PGM [..]
CPF1124 Info[..]00 03/19/15 05:55:10.338312 QWTPIIPP [..]
[..] Message . . . . : Job 171331/GTHOMPSO[..]
[..] 05:55:10 in subsystem QINTER in QSYS.[..]
[..] 05:55:10.

Sorry, this is going to come off harsh. I really mean it with love
though.

God save me from people that are so API phobic that believe every
solution is to generate a spool file, copy it to disk, and analyze
that!
Really, parsing out a substring that can shift positions in the line
based on how long the job name and/or user are, or what version of
the OS you are running, or... is easier than learning something new?

Effective screen-scraping is appropriately discouraged.

However, access to the data shown by Gary [generated as _spooled_ output], is not solely restricted to that which was presented. There is of course, both the Receive Message (RCVMSG) and the Display Job Log (DSPJOBLOG) with support to an Output File (OUTFILE). Just as the Message Data (MSGDTA) parameter is available using RCVMSG to obtain the _structured data_ [that was defined with the Format (FMT) of the Add Message Description (ADDMSGD)], the same is available from the QMHMDT field of the Record Format QMHPFT of the database output file produced for a DSPJOBLOG request.

If one can depend-upon, that neither a Routing Program nor an Initial Program has deleted the messages, then the following CLP provides an example of how the message data can be retrieved from the msg CPF1124 and msg CPI1125 that are sent successively in batch [or just the former in interactive] job initiation\startup. Rather than picking any specific component of the MsgDta [though parsed\stored for possible reference as an example], the data is just retrieved [from the *EXTernal message queue] and the message(s) get re-sent to the previous program within the job message queue:


dcl &mky *char 4
dcl &mid *char 7
dcl &mdl *dec (05 00)
dcl &mdt *char 250
dcl &jtp *char 1
dcl &sbs *char 20
rcvmsg pgmq(*ext) msgtype(*first) wait(0) rmv(*no) +
msgq(*pgmq) keyvar(&mky) msgid(&mid) +
msgdta(&mdt) msgdtalen(&mdl)
if (&mid *eq 'CPF1124') then(do)
chgvar &sbs %sst(&mdt 59 20) /* qualified SBS name */
sndpgmmsg msgid(&mid) msgdta(&mdt) topgmq(*prv) +
msgtype(*info) msgf(qcpfmsg)
enddo
rtvjoba type(&jtp)
if (&jtp *eq '0') then(do)
rcvmsg pgmq(*ext) msgtype(*next) wait(0) rmv(*no) +
msgq(*pgmq) msgid(&mid) +
msgdta(&mdt) msgkey(&mky)
if (&mid *eq 'CPI1125') then(do)
sndpgmmsg msgid(&mid) msgdta(&mdt) topgmq(*prv) +
msgtype(*info) msgf(qcpfmsg)
enddo
enddo