Re: Pick confirm looping -- BPCS-L

from Al Macintyre

I have previously had my knuckles smacked by people on this list for talking 
about oops that can be made by end users doing DFU on BPCS files, and other 
similar activities, and by managers at work for suggesting that there is 
anything wrong with that practice, but here goes again.

Ditto with respect to how we cope when hardware goes down.

You have someone doing BPCS work from a PC & it goes down.
We have had this happen with twinax, but for every one instance of twinax 
device going down in middle of a BPCS job, we have thousands of instances 
with a PC.

Often when a user has a problem & along comes someone to help them, the 
helper gets far from the whole story of what is relevant to cleaning up the 
mess.  I think this is human nature in the current state of art of business 
computer user understanding.

Some BPCS tasks are much more messed up by device downage than others & I 
have made certain suggestions, not heeded, with respect to which tasks 
perhaps should not be habitually done on a PC precisely because of this high 
risk.

The work that the device was doing has the potential to be corrupted & in 
need of repairs, but often the only stuff that is done is the minimum to let 
the end user get back into the work they were doing, and no serious tracking 
of these instances & what chaos might have been caused to the files.
In fact it may be simpler to clean up messes & not sweat what caused them.

Humans sometimes make mistakes & in my experience we are more likely to make 
mistakes when correcting past mistakes because we are doing something that we 
not normally practiced at doing.  The company figures out the best way to do 
various BPCS things & this is documented somehow, then some users discover 
ways they can do things that we had previously determined that we should not 
be doing, but our documentation does not say DO NOT DO THIS, DO NOT DO THAT, 
it says "Here is how to do the job."  

So there periodically needs to be some kind of audit to find out if people 
are not doing according to the rules, then have someone evaluate what the 
consequences are of that.

The BBL gets its information from other files & if those other files manage 
to get corrupted, then this corrupts other places if not rapidly caught.

The fact remains that you have one file with duplicate records.
There may be more.
You need to locate & destroy before it mushrooms like a computer virus.
A secondary goal is to gather evidence that would help you figure out what 
caused it so as to stop it happening again in the future.

>  From:    sas@toto.co.id (SAS)
>  
>  Hi all ...
>  we have already check on BBL file and we found some duplicate data ( group
>  by bord , bline and bseq ), but we saw some strange data :  same order
>  number , same order line , same sequence BUT different item number ???  
does
>  anyone have experience about that situation ??? how could that happen ? how
>  could there are duplicate on BBL ???
>  Your attentions are much appreciated .
>  Thank you
>  Regards ,
>  SAS

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

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