Re: show message on line 24 -- MIDRANGE-L

Leif

Here are a few things I do, which may be helpful for you to consider.

Various software packages come with message id systems.

We can add another similar object that has our own internal message ids & use 
in our modifications, so that the message ids for the software packages are 
left intact to avoid complications during upgrades from the software vendor.

Perhaps we should use a message id collection for implemented modifications & 
a separate one for software development & testing & troubleshooting work.

Although IBM SND this or that MSG usually wants a MSG ID, we can have a dummy 
one that gets repopulated with different text within the body of the CL.

I have a long running string of programs called from a CL, in which I 
periodically tinker with some components & I want to know how long the 
components take before & after my tinkering to see if my effort has been 
productive, or if I should back out the idea I tried.  My ultimate goal is to 
help the whole sucker move along in less time.  The CL program periodically 
has an ordinary SNDMSG to the QSYSOPR or to a message queue I have especially 
setup for this kind of tinkering.

Related to this is where there seems to be a recurring user inquiry.  "When 
was the last time we ran job ABC & what settings were used when we did it?"   
Well if that question is going to come up a lot, let's change the CL for job 
ABC to send a start & completion message to a special message queue for ABC 
with whatever the settings are & give the users a menu option that DSPMSG 
that message queue.

QSYSOPR is useful when the goal of the string of programs is some popular 
report ... my users have choice of generating another copy, knowing it will 
take 15 minutes or so to obtain, or look at QSYSOPR to see what co-worker was 
the last person to run it, and make an extra copy off their spool file, since 
we have given most of our users spool file special authority to get at each 
other's reports.

Unfortunately some of our CL programs break, due to circumstances I cannot 
fathom.  I suspect some action taken by user, or some combination of data 
going through one of the programs in the string.  I do not want to be 
creating detailed joblogs everytime we run jobs that only intermittently 
fail, because I do not have the time to be studying excess job logs, but also 
I have been unable to train my users .... if ANYTHING goes crazy in your sign 
on session, sign off with *LIST, or use the menu option I provided you which 
does SIGNOFF *LIST.

You do not need to be a programmer to understand a CL string of programs that 
goes to a special message queue ... outer program menu option thus & so by 
user-X will next load program-Y ... there is a whole string of these & then 
BANG it fails, so now we know what program it failed at.  We can also look at 
message queue for tasks that ran to a satisfactory conclusion.  With proper 
automated GO CLEANUP we do not store this stuff in perpetuity.

CHGJOB F10 2nd screen can alter what goes to JOBQ such as LOG CL *YES so that 
when the CL calls this or that program, that goes into the log.  I am 
thinking that is the sort of information I would like on bottom of screen if 
job is running interactively, but a long running CL should be in batch mode, 
which is why I like the approach of send message to user message queue - they 
get it whether interactive or batch.  Some of this stuff I can send duplicate 
messages - keep user informed on what is going on & also send to a history 
queue for analysis by MIS & system helpers.

One thing I want is ease of turning this sort of thing on & off.

Programs A B C D E F G H I J etc. are reasonably stable right now & I want to 
be focusing my efforts on programs L M N Q which are in trouble, so throw 
some flag somewhere which programs will be doing this detailed logging 
history message queue, without having to recompile all CLs involved.

An advantage with that might be ... A user is in trouble, a job is in 
trouble, it is not one we expected to be in trouble.  Go to menu option & 
throw the switch on that job - we want it to start detailed logging of this 
nature.  

Now right now someone could go to that job, if it is active & CHGJOB F10 2nd 
screen LOG 4 0 *SECLVL LOGCLPGM *YES but if it is an interactive job & the 
end user does an ordinary signoff when done, as is the case in 95% of our 
crises, then all that evidence gets erased.

I would love to have something in CHGJOB that says "I don't care if the end 
user selects ordinary sign off ... I want OS/400 to treat end of THIS job as 
if it was SIGNOFF *LIST because the end users just do not understand this 
nuance."

I am looking for something in which a CL program might periodically check a 
data area associated with name of that program to see if the history tracking 
flag is on or not & if it is, send these progress messages.  If the job was 
running when the flag was thrown, we would only get the progress reports for 
what it tried after someone discovered it was in trouble.

But this would be a big help with our most frequent crash.
We have this job in which it is updating inventory based on labor 
transactions.
It gets hung because of a conflict to access some record.
So we locate the other user & get them out of the way.
Then we should take the option to CONTINUE, but I have been unable to train 
my co-workers to NOT take RETRY because what often happens is the CL program 
reruns a string of update programs meaning that a bunch of inventory 
transactions get posted a second time.
Now MONMSG can help with some of this, but we still need human intervention 
to get the other user out of the way, and then tell the main program to 
continue.

Well, until I can train co-workers NOT to take RETRY loop, what is needed at 
this point is to inform the inventory management ... something went wrong 
with so & so's batch of JIT620 on this date & time, so you need to check the 
inventory transactions from that batch in case some of them were doubled up.

>  From:    leif@leif.org (Leif Svalgaard)

>  what I'm doing is executing a long running CL program
>  that does a lot of stuff. Every so often I want a progress message
>  to appear on line 24 (where the user would normally look for
>  it)

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