Re: Hung Invoices -- BPCS-L

From Al Macintyre with BPCS 405 CD on AS/400 mixed mode
Some stuff is version specific so reminding the community what version of 
BPCS you are on may be constructive & perhaps even mention which application 
modules you using.
I hope you find some of my comments to be helpful.

http://archive.midrange.com/bpcs-l/index.htm
BPCS_L archives go back several years & comes with a search engine ... I just 
mentioning in case that is not what you mean by reviewing past digests.

Today we live in a reality in which many users connect to BPCS via PCs which 
are notoriously subject to going down in the middle of access to BPCS far 
more so than twinax connections.  This means that some work can be corrupted. 
 Sometimes the users communicate with MIS in sufficient detail that we can 
fix damage from a disruption.  Sometimes not.  This means that past 
interruptions can create "hung batches" of data that are like time bombs 
waiting to cause trouble the next time someone running the same kind of work 
from that session address.

We recently added a query/400 to list all the data in the WORK member of FLT, 
sequenced by work station & date, so that we could clean up one particular 
kind of time bomb, that we call "orphan batches."  I suspect there is some 
similar kind of scenario in the data stream into billing.  I just have not 
reverse engineered it yet.

We wrote query/400 to list all current orders that are in the IN USE status 
for customer orders and purchase orders.  We run that report periodically ... 
it is in a string of jobs involved in our weekly reorg for example.  It is an 
MIS responsibility in the evening after everyone gone for the day, to use 
STRDFU with relevant logical to take out of in use anything from the day's 
mishaps, except our rate of mishap in this department is such that we can 
trust our users to report this kind of mishap so a weekly check sufices.

I figured out where it is in work station members that BPCS stores the status 
of batches in progress & wrote a collection of programs that IBM dump object 
to *OUTFILE then RPG program to print them in a chart with control break on 
application with *** marking at side when pattern changes, then I use SYS993 
to decipher what the differences imply & add clues to my RPG program in 
essence illuminating session addresses needing adjustment by application.  It 
is also a good review which users are on which JOBQ since we want some 
applications to be sharing the same single threaded JOBQ.

Be sure to check all the stuff on the BPCS reorg menu ... option 23 from SYS 
menu, in concert with relevant documentation on the correct sequence to run 
this stuff.  We copied many of these to our own SYSC menu for reorg in the 
sequence we use, and to FXS menu for fixes like SYS993C and SYS013C.  I have 
not seen any BPCS reports on lists of messed up stuff & have written quite a 
few of my own, as have several users with access to query/400 definitions.

In fact we have a huge volume of queries that list various different kinds of 
suspicious circumstances such as customer orders with no price, orders whose 
price disagrees with the master list price, orders whose price is less than 
standard cost plus 15%, all items that have a negative cost ingredient, so I 
am now working on a BPCS file list that for each file gives statistics from 
an IBM *OUTFILE then uses SQL to get some counts of contents in various 
categories.  My end goal is one report that lists all current problems in 
need of clean up.

You are talking about fields that should be at a particular value on the eve 
of billing.  Some values might not be correct because some previous step has 
not yet been taken to a proper conclusion & for us to be doing some kind of 
forcing of data ready for a step might corrupt what is supposed to be done at 
that prior step.  We found it constructive to get at charts of what the 
status codes mean in customer & shop orders for reference by people 
developing query/400 reports & general troubleshooting & also 400 to CA 
spread sheets.

My feeling is that when there is a problem with BPCS data getting corrupted, 
if we develop programs to force the data to be correct, there will be a 
temptation to never fix the problem that is getting the data corrupted in the 
first place.  There are times that that is exactly what the company wants.  
Just make sure management is aware that this is what we are doing ... letting 
data be trashed, and having some fix-it programs repair damage, without 
resolving what continues to cause damage.

In any listing of orders suspected of being corrupted, it might be useful to 
include what TYPE of order is involved, so for example one of the categories 
of orders we have managed to mess up is how we do resupply orders.  We know 
exactly how we have managed to mess them up & it is a management decision to 
continue to do so & use certain fix-it programs to clean up the mess we 
continue to create ... I just have not yet got a round TUIT on writing all of 
those programs.  But that leaves various other messed up orders in other 
categories & there was one category that I got approval a few weeks ago to 
just wipe them out, but we only wiped out the orders that were bad within one 
category.

Some pointers on query/400.  We have given access to the creation of query 
definitions to our general users who sometimes not appreciate some nuances of 
this language & how OS/400 runs queries.

1. The logical that you use in the query definitions only tells the query 
what physical file to use.  Depending on your selection & sort criteria, the 
query optimizer of OS/400 will use the best logical it can find in a 
reasonable time period to execute your query efficiently.  Depending on 
complexity of your data, OS/400 will not take all day about it, making best 
guess in which your logical will be included as a suggestion.  Thus it is 
imperative to do selection criteria that excludes records not relevant to 
your query & not depend on the logical's definition to do that for you.

2. You need to be particularly careful in matching files.  The example I 
often use for my people ... suppose you have a query of shop floor efficiency 
over FLT labor history transactions & you link to CEM to get employee name on 
the report & let's suppose some employee is no longer working for us & has 
been purged from the file, the labor reported by that person will not appear 
on your report because only what you have matched is to be listed.  No match, 
no data on query.

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

>  From:    cmassoglia@voyager.net

>  We have a number of invoices which appear to be hung.  From looking in
>  the BPCS Midrange-L digest, we found the following:
>  
>  Check all the following fields, if you have plenty of orders that do
>  not show up for billing then the cause could be in a load shared for
>  all these orders. Check also the loads for the orders.
>  
>   ECH record:
>      HINUSE field should be blank.
>  
>   BBH record:
>      1) BHID field (Record ID) should be in BH status.
>      2) BHDOCN field(Document Number) should be blank.
>      3) BHWSID (Workstation ID) should be blank.
>  
>   BBL record.
>      1) BLID (Record Status) should be BL.
>      2) BSTAT field (Invoice Status) should be blank.
>      3) BLLOAD (Load Number) should be the correct load number that the
>  order is currently attached to.
>      5) BLSTS3 (Ready for Ship Confirm)field should have a value of 0.
>      6) The BLSTS4 (Ready for Invoicing) field should have a value of 1.
>      7) BLWSID (Workstation ID) field should be blank.
>  
>   LLM Record :
>      LMSTAT (Load Status) should have a value of 3.
>  
>   LLH Record :
>      LHSTAT (Load Status) should have a value of 3.
>  
>   LLX Record:
>      LXSTAT (Load Staus) should have a value of 3.
>  
>  Is there a way we can just write a program to fix records using logic
>  as shown above or should we only attempt to fix the invoices records
>  we know are hung?  Also, is there a report we can run to provide us a
>  list of the invoices which appear to be hung?
>  
>  Thanks in advance.


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