Re: INV901C -- BPCS-L

Al at Tim PC
____________________________________________

-----Original Message-----
From: Dennis Munro <DMunro@badgerminingcorp.com>


>AS/400 V4R2M0, 6.0.02 plF, full c/s, Mar '98 cum.
AS/436 V4R3M0 mm BPCS 405 CD not up to date yet on our Y2K fixes
>
>Ran month end last night and one of the job logs generated lists program
>INV901C that had a problem.  WRKOBJ shows the program in BPCSO & BPCSPTF
>libraries.
>
>Dennis Munro
>Badger Mining Corporation

You really have several problems, 2 of which I will address.
1. What the heck is going on here & how do I find out?
2. How do we prevent this mess from happening again in the future?

GO CMDREF gets you to an IBM tool to cross reference which objects call what
other objects for what purposes.  Be selective in criteria to avoid getting
a door stop printout that is unmanageable.
Running this in 405 CD for INV90* *LIBL library list *PRINT *PGM shows that
INV900 has a collection of INV901 INV902 INV903 INV904 INV905 steps & SYS
ingredients which collectively update file IIM ILI ILN ITH IWI IWM  IW1 RCM
RTP RTX SSH SSD SSM YCI YTH ZPA & some work objects, but I know, from
modifying the name of the file that goes off-line so that it is individually
labeled where it came from & for which fiscal EOM, that this is also writing
to whichever media ... tape, diskette, etc. so you might have a file that
needs to be moved to tape before next month EOM obliterates it ... Is
anything missing from your inventory history, and is your sales history
correct?

We have found that some EOM update jobs are so intrusive in their access
across a vast spectrum of files, that to be safe, we need to take the
computing environment back 20 years & enforce a dedicated restricted system
in which the ONLY stuff that is running is EOM.  An early step of
End-of-Month is to prevent other users from signing on until EOM is done ...
vary off sections of the network ... also we do not want stuff running from
various JOBQ or scheduler areas, so they also need to be shut down.  Then
when the EOM job stream is the only thing going, it is safe for it to be
going.  Some EOM steps can be run on-line or JOBQ while some must be JOBQ
... resist temptation to try to run some on-line & others off JOBQ at the
same time ... let them all go JOBQ ... resist temptation for person doing
EOM to go to another session to do something that seems innocent.

I have WRKMBRPDM off of a BPCS User Menu with all sorts of CALL QCMD & APIs
programming tools so compiled stuff is in the desired library list, but if I
start INV901 running then go here to work on some modifications my sign-on
bombs because BPCS Menu cannot even get to some standard files due to EOM
locking them up, thus if I was on a BPCS Menu first, I figure that might be
conflicting with EOM running from a different session.

Ideally we need SSA to make an improvement in the state of BPCS art.  There
should be a programming standard.
if program-any-scenario cannot continue because of a conflict for access to
some other user activity, then the job should stop with a meaningful message
to the system message queue, and the person who launched the job should get
a message "Waiting on response to QSYSOPR" or whatever, like we get when
CST900 blows up the spool file.  We do get some such message in the INV900
stream to remind us to have the magnetic media ready, when it is too late to
say "oops ... we took that idiotic default by mistake."

____________________________________________

Al Macintyre
Central Industries of Indiana, Inc.
www.cen-elec.com


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