RE: joblog outq management (was AW: Hiding spoolfiles from outq x )

Thanks for your useful tips, but color me a bit inexperienced & frustrated.

I can see how this might work for a CL program that I am working with when 
the error is an IBM OS/400 error, but I have a bunch of BPCS scenarios where 
that is not the case, that perhaps someone can point me in a good direction 
to resolve.  

99% of the time when I have investigated "bombs" they turn out to be BPCS 
gave a perfectly valid error message like "You cannot update this item # 
right now because a specifically named user or display station session has it 
locked for update." for which there is a very logical reaction, but the user 
sees this and panics.

Usually in this circumstance there is very little I can do to prevent the 
panic, but there are cases where I think I can reduce the probability of 
confusion.

I have a bug I am tracing right now in one program where there are a BUNCH of 
places where it can call this particular error message, and at least one of 
them is calling it for the wrong combination of circumstances, so I need to 
identify right spot & substitute correct error message.

There is another program I want to study & not yet got around to it.
During an update, it says something to the effect "Conflict accessing this 
particular file for update" and has a bunch of choices in which the least 
worst is G (go on to the next step) and the next worst is R (rerun the whole 
job stream & duplicate a thousand inventory transactions) & my collegues 
usually try G first (because I asked that they do that) then if it fails 
again (on a different item) they try R next (because it appears to work & 
then 15 minutes later when it happens again at the same point, they think it 
is a different point & they take an R again) & DSPLOG just shows the R not 
the G.  I just found out they were doing the G & it not in DSPLOG & I had 
asked that no matter what action taken, the input batch be quarantined until 
the audit trail reports checked, and I do not think they doing that 
religiously.
Eventually what I want to do is locate where in the RPG program this error 
message is coming from & see if I can make it more explicit - what record - 
what conflict - and also if there is some alternative to G & R that will 
retry ONLY that update after getting the other user out of the way.

Anyhow what I want is
1. JOBLOG that includes BPCS error messages, whether interactive to bottom of 
screen (Program Message Que) or JOBQ why the thing "failed", neither of which 
considered to be an IBM error, for those jobs that entirely too often either 
fail or invite inappropriate co-worker action.
2. Some kind of MONMSG in the CL that is looking for BPCS error message in 
the called RPG, so I only get JOBLOG captured on the failures for thos jobs 
with very rare failures.

In other words, one of my challenges is that the CL calls an RPG & the error 
is in the RPG, not in the CL, so I don't want to be trapping JOB LOGs when 
there is no BPCS error.  As far as IBM is concerned there is no error when 
BPCS says there is an error, because in this circumstance the application is 
"working" the application did not bomb.

Users Generating new Shop Orders almost every day.  About twice a month, one 
particular user at one particular work station "bombs" with no details to me. 
 I now have that setup so that if they SIGNOFF *LIST after the "bomb" I can 
get full details, but they never do & I am never there when it happens.  Now 
they say "Sorry Al we forgot you wanted that - we will try to remember next 
time." which is an improvement over "Al, when are you going to fix this 
nuisance."

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)

-----Original Message----- from Chris Bipes
What we added to the error processing is the command "DSPJOBLOG
OUTPUT(*PRINT)" if an error hit our general trap routine.  Also include a
DMPJOB and SNDNETMSG to your IS programming staff to include the
job/user/number.  Now you got all the info trapped to work with.  The user
never gets those annoying CPF messages and your programmers get the
necessary info to find/re-create/fix the error.

Christopher K. Bipes      mailto:ChrisB@Cross-Check.com
Operations & Network Mgr  mailto:Chris_Bipes@Yahoo.com
CrossCheck, Inc.          http://www.cross-check.com
6119 State Farm Drive     Phone: 707 586-0551 x 1102
Rohnert Park CA  94928    Fax: 707 586-1884

-----Original Message----- from Al Macintyre
From: MacWheel99@aol.com 

We have applications that try to do their own error resolution.
Ideally we want errors recovered in a graceful way that will not burden the 
end users with having to be MIS experts to cope with error messages.
This means that IBM 400 OS does not recognize as a problem worthy of a job 
log, a problem that the application saw but perhaps did not handle as 
gracefully as we MIS would desire, so we need to give the task a human 
helping hand to ensure the generation of a joblog.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)


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