Oops JOBQ perceptions -- MIDRANGE-L

I have some trainee dumb questions here since I not often get into this area 
& I just love to push the envelope of what I know how to program, provided 
the educational detour won't take long to sink into my brain.

You know how, if you add message queue QSYSMSG it automatically captures 
copies of the most serious stuff on QSYSOPR, are there any other "magical" 
message queues like that, which we only know about if we been to the right 
IBM class or studied the right manual?  QUPSMSGQ in System Value.

Well I added a message queue to receive confirmations that we did in fact run 
some regularly scheduled stuff with what settings.  So far I only adjusted 
the CL for one job & discovered in my testing that there were some holes in 
what I thought I knew about  some basics.

After the CL verifies prompt criteria, but before actually doing anything 
like launching itself into JOBQ or doing the job interactively, SNDPGMMSG to 
my new message queue with a bunch of info that seems to be working fine in my 
testing.

At completion time of the actual run, not interactive ends because JOBQ was 
launched, I have a completion message in which I was hoping to have more 
variables still populated not needing any refresh.

          **********************************
          ***  Al's dumb questions *****
          **********************************

1) If I put stuff in QTEMP before launching JOBQ, then I sign off, does the 
batch job have access to that QTEMP story like it has access to what was in 
the LDA when I launched it, or is any QTEMP access by a batch job totally 
independent of the interactive job that created the job?

2) When I define a bunch of variables based on some prompt screen, then 
launch same CL to JOBQ, bypassing the uniquely interactive portions of the 
work in the next run, does the job lose all variables, and only have access 
to what's in data areas with respect to work station or user, unless the 
SBMJOB passes some specific parameters.  Thus, if I want to add a variable to 
what is remembered, while interactive is running, populate *LDA or data area 
with it, then when JOBQ portion is running, extract that *LDA area back into 
the variable.  OCL/36 had a pass *ALL but that was just IBM's numbered 
parameters, without CL flexibility in naming what *ALL is.

3) I would like the completed batch job to communicate 
"I'm job 06884 running on QBATCH3 and I was called by 06840" 
so by elimination I can see what got hung up some place
& if it was only QBATCH2 that got hung.

It is not unusual for us to fill the JOBQ with some scheduled jobs that are 
identical except for facility then later question whether one particular 
facility had all its stuff go to a satisfactory conclusion.  Also I am often 
on several concurrent interactive sessions running various tasks in which 
they can end up on different JOBQ, based on the programming & other factors.

I can capture RTVJOBA NBR(&JOBNBR) and other values and stick that some place 
for JOBQ later match up, but I was wondering

3-A ) Does a batch job have a native RTV info on whatever launched me, 
perhaps API like QSP-JOBQ? (I am a novice in API & not yet a programmer of 
ILE REXX or UIM)

If we DSPJOB for a completed job#, Job Status Attributes second screen shows 
me that Batch Job# 060884 was submitted by Interactive Job# 060840 ... could 
the batch job 060884, while it was running, get at this info identifying its 
060840 parent?

3-B ) Right around the point that an interactive job does a submit batch job, 
can it retrieve the identity of the job just launched ... actually BPCS 405 
CD does not do a simple SBMJOB, it calls a program to do the launch with 
access to some other esoteric stuff.  I was thinking something like this 
format

OVRJOBINFO     SAVE(&BATCHINFO)     WHERE(&BATCHWHAT)
Whatever the software is that launches to JOBQ from interactive
RTVJOBINFO    for whatever variables were specified in last OVRJOBINFO

in which in this example &BATCHINFO would contain the data I later saw on Job 
Status attributes of the completed batch job, and &BATCHWHAT would contain 
which JOBQ it was sent to.

4) Initially I had adjusted placement of pieces of story so it looks nice in 
DSPMSG how I usually view messages, then later when I did DSPMSG QNITEHIST F4 
F10 & look at some of this in *PRINT & *PRINTWRAP it did not look quite as 
nice, although the big picture was more readable checking off all the right 
steps did in fact run to a conclusion, than scrolling DSPMSG on-line, for the 
one CL I messed with so far.  

I see how to list INFO (severity 80) only.
Is there a way to list COMPLETION (severity 00) only?
Other than a separate message queue for each.

          ********************************************************************

I got into this interest because of the inability of existing job trails to 
tell when was the last time we did job X, what settings were used, which 
facilities, was it a full run or a limited run, was it in the right 
environment, normal or simulated ... the values on the prompt screen.

I wear many hats in my job & one of them is some stuff that should be a no 
brainer ... a variation of MRP CAP CST update runs with a slightly different 
formula each nite of the week ... it seems like I may have missed a step or 
run one wrong ... there is no way to tell ... I may have been so engrossed in 
solving some programming puzzle that I missed the basics in one of my other 
nitely jobs.

Also there is the recurring question "Al when was the last time we did ...." 
& I answer I THINK I did that a week last Thursday.

I just plan to do this for the most critical jobs that need to be done very 
regularly.

Alister William Macintyre 
Computer Data Janitor etc. @ http://www.cen-elec.com 

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---