Re: IWI and ILI Imbalances

[MacWheel99@xxxxxxx]

From Al Macintyre BPCS 405 CD mixed mode OS/400 V4R3

I doubt that I am being as helpful as you want, but perhaps you will get some 
ideas from this.

As I understand BPCS jobs running in batch or interactive, there is no 
difference in what gets updated, or what flags get set with respect to the 
BPCS data base.  The difference is in how messages are communicated to the 
user & the precise flow of the CL.  However, because some code is supposedly 
duplicated in the interactive vs. batch sections, and because it is 
perpetually updated by BMRs, there is a risk of something in one place that 
should be in both places ... what we call a bug.

I have had occasion to stick my nose in some of the BPCS code & found what I 
thought to be bugs & reported them to SSA & sometimes they agree with my 
diagnosis & sometimes not.

At Central Industries, our problem is a combination of not getting a Round 
TUIT on obtaining all the BPCS manuals that we know about & not getting a 
Round TUIT on reading all the BPCS manuals that we have purchased & having 
turnover of personnel in which the newbies are taught how to do the job by 
oldies who forget that we created an in-house manual just for shipping how to 
do the job step by step to take care of every possible eventuality & as new 
scenarios are discovered, the manual is supposed to be updated appropriately 
with all copies of the manual updated in the correct ISO style.

Our operators are supposed to post interactively.  The reason we do not want 
them doing batch is that we have workers who are not sufficiently technically 
literate to realize that when you send a job to JOBQ the time it will take to 
execute might be anywhere from seconds to hours, depending on what else is in 
the JOBQ.

We are at risk of people sending stuff to JOBQ, then ASSUMING that their jobs 
got done instantaneously, then taking the NEXT step, then the job actually 
runs from the JOBQ out of sequence.

Another problem with JOBQ used by folks at the bottom of the technical 
computer literacy ladder is if there is a conflict for access to some record. 
 If you are interactive, the on-line job stops & there is an error message, 
and the user involved never remembers what to do, or how to interpret the 
summary, or that there is second level help text, but at least they know the 
job hung & they call for help from one of our more technically literate 
individuals, who calls for help from someone higher on that ladder, and we 
get the job to a satisfactory conclusion not long after it actually halted.

I was over-ruled on the notion of adding a section to our user manual on what 
to do if you get an error message, so that the instructions would be 
formatted in a consistent manner, with an index tab whose existance might be 
easier to remember.

When a job hangs on the JOBQ it can hang for hours before someone notices it, 
then the person who copes with the problem might not resolve it in a data 
base friendly manner or be able to communicate effectively with the owner of 
the job what the possible consequences were of this task being abnormally 
terminated.

There has been talk about creating a separate JOBQ to be called QSHIPPING 
then changing the work station defaults of all the devices in the shipping 
departments to default to this JOBQ intended for the exclusive use of the 
shipping department.  That would solve the problem of folks in shipping 
departments sending stuff to JOBQ that normally executes in a matter of 
seconds but several times a month gets behind a collection of jobs that in 
aggregate will take an hour or more.  

It will not solve it for folks who help out the shipping department using 
display stations outside that department, or resolve error message recovery.

I was overruled on having pages added to the user manual instructing in the 
use of WRKSBMJOB or WRKUSRJOB to verify your JOBQ job got to satisfactory 
conclusion before starting next job.

We have added to our BPCS USER Menus for individuals with no command line 
authority some of the IBM commands that tell them about their work that are 
not on the BPCS Pop-Up Menu.

We have modified appearance of our Shipping Documents & any time further 
modification desired, there are a number of ways that we can do testing to 
find out if latest mod is quite right, before actually implementing it.

>  From:    klvanhorn@lozier.com

>  You're right it came from the PO Number entered in order entry, then
>  populated TCOM when we shipped the order in ORD570.  Our B transactions are
>  the result of ORD570 not INV500, but the result is the PO Number is in 
TCOM.
>  
>  I am still grasping at straws here, but is it possible we have some
>  parameters set wrong or the program is timing out with only the ILI being
>  posted and not the IWI???
>  
>  Our operators are supposed to post in batch... by posting interactive could
>  that cause the posting to abort before posting to IWI/IIM?  Could some 
other
>  process interfere with a interactive job but not effect a batch job?
>  
>  Does someone with more of a techie background know the answer?
>  
>  Thanks,
>  
>  Kent

Al Macintyre  ©¿©
http://www.cen-elec.com MIS Manager Programmer & Computer Janitor
+---
| 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
+---