36-400 History How (was S/ 36 stuff on the AS/400)

schmuel@bigfoot.com writes:

> 1) History File on 36 was so simple and straightforward for OCL logging..
>       Is there a comparable way to log OCL statements in the AS/400 ?

Steven

This stuff is also a good review for me, because I do not know it as well as 
I oughta.

This is my second of several replies via midrange-L to your interests.
The S/36 had a variety of logging.
The AS/400 has a variety of logging.
It is organized under different names but pretty much all the same stuff can 
be done.
Simple is in the minds of the people who are experienced in figuring it out.
To a 400 person, the 36 logging might seem strange & alien & weird.

You recall that on the 36 there was a MAIN CONSOLE which you could hot key to 
to get at all SYSTEM messages of a possible problem or error nature, while we 
also had SUB CONSOLES which you could hot key to from the work session that 
"controlled" a printer, to find out any messages with alignment relevance or 
forms changes.

On the 400 these type messages are sent to DSPMSG QSYSOPR which any user from 
any location can get to via a variety of means.  Such as your first sign on 
that owns your own message queue can get to this via F6.  Some messages about 
user objects you can also get to from screens associated with those objects.

You may recall on the 36 there was a record of all jobs starting & stopping 
even when you were not doing any logging.  I called it the EJOB report.  You 
can get at something very similar on the 400.  From command line do DSPLOG & 
then not press enter but F4 & change the beginning date to *BEGIN & leave 
other defaults intact & press enter.  

You are looking at EJOB/400 (the 400 people have another name for this of 
course) ... basically all the stuff that got done successfully, either people 
signing on & off the system, people forgetting their passwords then 
remembering them, printer problems that got resolved Ok, what all got saved 
in a backup, what happened in the last automated cleanup, automated tasks, 
stuff that ran off the JOBQ ... any line that looks the least bit interesting 
... put cursor on it & F1 for more information than the summary line is 
telling you. 

A useful command is WRKUSRJOB then F4 & do *ALL
Well in fact there are many useful commands, but this is getting you at ALL 
user jobs that are in the system - JOBQ interactive, finished but left 
something on OUTQ & of couse you can do filters to just show what's waiting 
in JOBQ to run, who left reports ... you can also get at this with WRKOUTQ & 
other ways ... but this is a way to identify the individual JOBs of users & 
what was on JOBQ so that then you can go into the detail on a specific job 
either from here or elsewhere.

WRKACTJOB only gets you at jobs that are running on 400 right now, not those 
waiting in JOBQ or those that have ended leaving stuff on OUTQ.

If you know the # identification of a specific job, which you can get from 
DSPLOG or WRKUSRJOB or various other places, then you can DSPJOB that 
particular job & from the main screen take option 10 then do F10 & you are 
looking at the history captured on that job.  You can put cursor on an 
interesting line & F1 for more infor.

Within the software for a job, or within the rules for a sign on session, or 
by the user who is running it when inter active, the logging rules for the 
history for a job can be altered to gather more detail than normal..

Find the *JOBD Job Description for your session & scroll to the LOG settings 
& put F1 on each to study what is there.  You should be seeing THREE values

Message Logging Level
Message Severity Level
Message Text Level

This should be vaguely familiar to a 36 person - there is something similar 
here to say AUTO RESPONSE on the 36

Message Logging (element 1 of the 3) can have values 0-4
This controls the KIND of IBM messages written to job log
Higher number means more messages
Lower number means less messages
0 means no messages whatsoever
1 means only the messages sent external message queue 

for example ... user running a job & it says this got done & that got done 
... whatever the user might have seen when the job was running, that's what 
goes into the log at setting 1

2 adds logged lines that sent messages that the user might not have seen

in other words a lot of 400 functioning is by software sending messages to 
other software & at level 2 you get to see that traffic also

3 adds anything that got CL logged whether it sent a message or not
In CL you have a LOG command that can turn of & off logging - default is *NO
The specific command is LOGCLPGM ... you might want to get that on a command 
line & F4 F1 it for more clarification on where you can use it

4 logs the max

Message Severity (element 2 of 3) can have levels 0-99

You may have noticed in looking at various error messages on the 400 that 
there are levels of severity
00 informational only
10 warning of potential problem
the numbers go up with whether error can be recovered without aborting job
or perhaps this is not a problem with a job but a problem with the sub system 
or entire system

You use this value to say which of these messages are to be kept in the 
JOBLOG after the job ends ... while a job is active, DSPJOB that job option 
10 & F10 gets you to a lot more information, generally, than what you find in 
its JOBLOG (if any) on spool after the job is done.

If you set this at 00 that means you want EVERYTHING in the JOBLOG because 
what is kept is that severity level & anything higher.

Message Text Level (element 3)
can have *NOLIST *MSG *SECLVL

now when you sign off, the default (F4 on SIGNOFF to see what I mean) is 
*NOLIST which means that if there was any JobLog on this session, please 
erase it unless there was a severe problem that the user might have been 
oblivious to, or you can do SIGNOFF *LIST which means to capture to spool the 
full detail of whatever is in your on-line joblog right now, as constrained 
by the 3 settings I just mentioned & tried to explain with some examples

*NOLIST means (at element 3) nothing to spool with normal end-job or ONLY if 
abnormal end-job send anything to spool
*MSG means only send first level text to job log spool
*SECLVL means also include 2nd level

I believe that if you are going to do a Job Log deliberately, having *SECLVL 
transalates to productivity to the personnel trying to figure it out, unless 
you are one of those rare birds who have memorized what every error message 
means without having to look it up

Any time you see a message in 400, you can cursor on it & F1
the initial message is your level 1 detail
what the F1 is accessing is level 2

Lets suppose you have some problem & you have a particular job that you want 
to crank up the history logging on to help you diagnose the problem & then 
when the problem has been solved, you don't want abnormal logging on it any 
more.

There are several ways you can do this.

CHGJOB & F4 gets you into the rules for the session you currently signed on 
as ... you can crank up the history logging on what you doing right now, then 
when you sign off / on again it will return to your *JOBD defaults.

I have messed with the *JOBD rules so that a particular JOBQ has higher 
logging ... so jobs that we have some suspicions about can go on the higher 
logging JOBQ.

I am not too enthused on telling my users to CHGJOB since there is a lot of 
stuff in there I do not want them exploring & accidentally messing up.

Rather, a better solution would be some menu option to run some program I 
have written that takes care of these setting adjustments for the user, to 
use IF to find current log rules then either crank up or crank down.  I have 
not actually done this yet.  If you are interested in setting up something 
like this, the place to start would be the WORK MANAGEMENT MANUAL and the CL 
MANUAL.

Lots of other manuals available from IBM & the trade press.
This is also covered by the education offered for people just starting out on 
a 400
The topic of that education is SYSTEM OPERATOR
This does also get mentioned in some programmer/400 classes & others

As an old experienced 36 man, I thought I did not need any System Operator 
classes, but I found the programmer classes did not go into enough detail on 
this & the system administrator classes were like PhD/400 when I was only 
ready for kindergarten/400, so I went to System Operator class to fill in the 
gaps in my know how 

The kind of data that comes from this logging is generally understandable 
only to a programmer who is familiar with the software that is executing, and 
some of the innards of 400 architecture.  Thus, I suggest you spend some time 
exploring some joblogs to get comfortable with what they look like, before 
you try to use one to resolve a crisis situation.

There is also some stuff conceptually similar to history logging goals but 
not to be confused with it ... I am giving you here some names by which to 
look up or ask about if you interested.

DEBUGGING PROGRAMS

ISDB supports CL & RPG/400 but not ILE
DBG supports ILE

STRISDB PGM(lib/pgm) INVPGM(*CMD) CMD(CALL PGM(lib/pgm) PARM(list them)

with this we can control where the program starts & stops & what values are 
fed into the program's variables & work areas ... so the program starts & 
takes our values & runs a bit & then we can interrogate values, so it is like 
using a microscope into history logging inside just one program

We cannot change the program logic

I hope my post has been illuminating for you.
I may later select another of your questions for an in depth reply like this 
one

Have you had any formal 400 education, other than the books?

I think the best investment of your time & employer money is this midrange 
dot com continuing education place & also get subscription to some trade 
press & hang out at their web site, and you gotta go to some education/400, 
whether from IBM, or Common, or Technical conference, or what the trade press 
sponsors.  Then USE the stuff you learned, so you get proficient in 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
+---