Re: Checking a JOBQ to see if there are jobs waiting -- MIDRANGE-L

From Alister Wm Macintyre (Al Mac)

Pryce

I do not have such a solution but am also interested in finding one & I think 
there are several points of possible attack.

The problems as I see them are:
1. We have several JOBQ jobs that have performance problems that a programmer 
might be able to re-write a little bit & make them go more efficiently, but 
they have to be called to the attention of the programmers.
2. The more that things run smoothly, the less that we are paying attention 
to what is in JOBQ or anything being sent to QSYSOPR, so that when something 
gets hung in JOBQ, there is a risk that it will be there for a while & no one 
notice.
3. End users sometimes need to know when their JOBQ jobs are finished before 
going on to later steps & when their stuff does not end as rapidly as they 
are accustomed to, they need some easy option to check up on what is holding 
up their work.

MAPICS used to have a NEVER ENDING PROGRAM to handle Security.  This might no 
longer be the case ... I have not touched MAPICS for many years & my last 
exposure was on S/36.
Perhaps generic 400 users need a NEVER ENDING PROGRAM to help manage JOBQ 
performance.
This NEP would be one of the pre-start jobs & then ENDSBS would bring it to a 
close.

The program might be running in its own dedicated JOBQ or other area that no 
other software should ever be put.  It would check on some stuff, then go 
into a wait state for some predetermined time period, then do the same 
checking, perpetual loop.

What it would do is analyse JOBQ information ... any BATCH job that is now 
ACTIVE that came from JOBQ, excluding itself & any IBM Q-system-stuff ... 

Is it in RUN status, or some kind of WAIT state ... 
Is it a temporary wait or a problem needing human attention?
If human attention is needed ... send some message.

How LONG has it been ACTIVE?  Is it above some reasonableness thresh hold?
If yes, send information about this JOB to some OUTQ or MSGQ where we store 
such diagnostics.

If this NEP goes back to sleep & then when it wakes up again, if the story 
has not changed since the last time, then a more severe message might be sent.

DSPJOB shows start point & end point of all jobs on the system ... when 
someone signs on, signs off, information about something that ran on JOBQ.  
While this data will not go to an *OUTFILE, it can go to *PRINT then from 
there to *DATA file, and we can also use filters when running it, to only 
look for certain combinations of hits.

We might be able to extract information from DSPJOB about the average 
statistics of JOBQ jobs ... how long does each typically take to run.  Get a 
chart of expectations by name of main program title.  Programmers sort chart 
to identify what takes longest time to run, then ask which of these seem 
unreasonable & in need of polishing.  End users get copy of this info.  I 
have altered some menu options ... at very end of description line is #.## 
representing an estimate in Hours & Minutes how long this task normally takes 
to execute.

We also have monster queries, in terms of the sizes of the files being 
extracted against, and the complexity of what the queries are doing.  In 
theory such queries are candidates for a HLL replacement, but I have the 
usual growing backlog of software development, that even when I know we have 
such scenarios, I am not going to get a round TUIT to fix them any time soon.

Although you are using a single threaded JOBQ because of dependencies, does 
EVERYTHING have to go through that same thread?  Can you put selected tasks, 
such as queries that just print reports, on a different JOBQ?

Perhaps part of the answer is to look at the JOBD that queries use, and lower 
the RUN priority, so that they eat just a little less of system resources 
while executing.  However, I have several general performance tinkering tasks 
to do before I mess in this area.

The JOBD, that a JOBQ runs in, can be tinkered with to capture JOBLOG but you 
not want to clutter your system with an excess of these.

Each evening after backup, I go through our WRKOUTQ to locate JOBLOGS from 
user activity & I move them to their own OUTQ for review, then I clear the 
OUTQ of all other system JOBLOGS which averages well over a hundred of them 
every evening. This is a bit tedious, but it is consuming too much disk space 
if I do not do it regularly.  I also tinker occasionally with GO CLEANUP.

If you need something to send a message to a USER who happens to be a 
programmer, give some thought to eventual personnel turn-over.  None of us 
will be working for our employers for all infinity.  We certainly do not want 
to leave something that will crash the moment we no longer have a valid 
profile, that will leave a bad taste in peoples memories about us.  Create a 
new message Q other than what is already going to IBM Q's, that has a generic 
name like QOURINFO & have symptomology sent to that Q, then programmers have 
access to it & periodically check on what info is there.

While a job is still ACTIVE, you can use WRKACTJOB against it using F4 
filters to restrict all what you get to see.  I would love to have some 
version that excludes all the Q-system-stuff from this picture & just show 
what our users are doing.

You can also use WRKUSRJOB *ALL users to see all the stuff that is in JOBQ 
from all users waiting to run.  While you are looking for something to 
identify the odd job that is taking excessively long to run & thus needs 
programmer review, my more common need is an easy way for end users to look 
at what all is waiting in JOBQ to execute, where they are in the Q, and what 
is holding up the parade right now.

This continuing education leads to some internal discussion & I suggest that 
certain jobs could use a lower priority, so that they only start running when 
nothing else is in the JOBQ, and programmer studies what tasks are safe to 
put in their own separate JOBQ.

I hope that several of my ideas connect with some enthusiasm by you as 
something worth trying out.

>  From:    jonesp@quinn-group.com (Pryce Jones)
>  
>  Hi People,
>  After searching through the archives and not getting anywhere I wonder if I
>  can throw a problem passed you to see what we can come up with.
>  Problem: We have one jobq where loads of jobs are sent to and normally this
>  is fine for what we require. However, on occasion, the job that is running
>  from the jobq (we only allow one as there are dependencies) has either
>  stopped because of a msg (and the operations team have not spotted it) or
>  the job is running very slow and taking up all resources (perhaps a monster
>  query is running), etc, etc .... you get the idea - it is not something 
that
>  we can normally forsee and program around. What I am looking to do is
>  something like throwing a "wrkjobq qbatch" to spool, doing a cpysplf to a
>  temp file and then retrieving the number of records. If over 2 then there
>  could be a problem so send msg to Me (not ops!). This is a "dirty" option
>  and there are a couple of prblems even with this solution. Has any one done
>  similar. :)
>  Thanx,
>  Pryce.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

+---
| 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
+---