Re: Confirming problem

Some 405 CD "solutions" may not be applicable.

Make sure that it really is hung ... we sometimes have people who do not 
recognize error messages, who press enter when they get one, causing the 
default response which is often the worst response.  You might want to look 
at job log on problem user session & enhance your picture with CHGJOB F10 2nd 
screen 4 0 *SECLVL *YES on LOGCLPGM.  If you want joblog after user "normal" 
signoff, you have to get them to SIGNOFF *LIST.

I have had several phone conversations with end users about their latest 
problem in which I am reading to them off of their job log "When you got this 
error message & took such & such response." their reaction is often having no 
memory of having any such error message & asking where I am seeing that 
information, which tells me that they may well be ignoring the error messages 
& forcing the default.

I do not know if this is still the case but there are some PC interfaces to 
the 400 that can best be described as corrupt because they chop off the error 
message line at the bottom so the end user does not even see this information.

When we have recurring problems with some work stations, sometimes we change 
the work station address on the AS/400 & the problem goes away ... there is 
some data structure or work files or members out there based on the name of 
that work station that are causing problems & their identification has 
escaped us.  Be sure that you do not have a case of an improperly connected 
PC that got a name like QPDAV0000# with 2 or more concurrent users of the 
identical address except for the last digit.

As we figure out where work stuff is stored, we run periodic lists of 
contents to see if there is debris from past crashes that needs cleaning up.

I assume you know about the option to reset a corrupted work station batch 
off of SYS menu 23.

We have found that it is suicide to be billing some orders at the same time 
as shipping some more of the same orders.  In fact we want everyone to stay 
out of any updating of orders that are involved in billing.  To this end 
there is an effort to intercommunicate between shipping personnel & 
accounting personnel so that during the billing process, shipping stays off 
the system.  This is easy in 405 CD because Billing only takes a few minutes, 
while I understand that on V6 the same software takes several hours to run.

It might be possible to find out if someone was updating the same order that 
was in shipping.  We have occasionally had a problem where the order was in 
shipping, then someone in customer service needed to change the order & they 
got a warning message & did not understand the message & they overrode it & 
ended up messing up shipping.  We have a 3rd party customer order change 
history that helps trace this sort of thing.

You might check if the one that hung was doing anything differently than the 
4-5 that went fine.  Like we sometimes ship inventory that production control 
has not yet reported making, so the shipping process has to drive something 
negative.

When a user shipping session is aborted for any reason, some other work 
station address can pick up the slack.  Also with ORD590 I think it is, you 
can reprint whatever shipping documents were missed the first time around.

I recently had a thread about excess members & excess logicals in which Roger 
Wolf provided a wonderful solution.  Several files manage to accumulate 
massive numbers of obsolete members.  EC* & BB* included.

Customer Orders start in EC* files.
Shipping Story gets into ES* files & BB* & ITH
Billing in turn populates RAR & S* files

If something is abnormally terminated, there may be more than one place that 
needs fixing in the data base.

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


+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---