Re: "Record in use" message & resulting mess

from MacWheel99@aol.com (Al)

Zzbpcs@aol.com (Jim) writes:

> However, I was refering to an RPG error stating, "record cannot be updated 
>  because it is still locked by another user" ( the original posting spoke 
of 
>  F1 for help then F10 for job log in order to see who locked the 
>  record...)

We have a recurring problem with JIT620.

For example Thurs Jan-18 there were 3 different users trying to do update 
batches at the SAME time ON-LINE.  Some of the items involved were quite 
common to our current production, so that odds favored a conflict.

I have given up trying to get my users to run batch jobs on JOBQ.  If they 
were all running there & using same JOBQ then there would have been no 
conflict & the tasks would have got done a whole lot sooner, however my 
people who find stuff hung on JOBQ & respond are no more skilled at doing it 
right than end users.  I suspect they need the on-line batch to take a break 
from keying another JIT600 batch which is a certain hassle.

They get an error message.  They do not check the details.  They take the 
default.
They get another error message. Ditto ditto ditto, then when taking a random 
answer cannot get them out of the error condition repeat they come ask some 
MIS person for help.  We do the cursor on error condition, F1 F10 locate lock 
details, go to that work station to check story there, may find easy 
solution, or whatever.

What I have found from analysing these messes is that as the labor tickets 
are updated, there is some flag saying to the software "this labor got done 
through the system" but there is no such flag for the inventory side, so that 
if the process gets some distance, then hangs on conflict & user does a 
retry, it can retry a string of programs ... labor does not get posted twice, 
but multi-issue inventory gets reposted, for however many hundreds of labor 
tickets are in the batch, then the process gets to the same point of the 
previous hang, because the problem is that user in next cubicle in the middle 
of INV500 transaction on some item & is away from desk, and because end user 
not understand message, they take an "R" again thinking rhey retrying one 
transaction, and in reality retrying a string of programs each posting 
hundreds of transactions, and we get the inventory in triplicate now.

It is a fair statement that we have a dual need here.
End user training how to cope when get an error message.
Modification to try to do a better job of idiot proofing the process.

Areas I want to explore.

I know that I cannot totally prevent this scenario, I will just settle for 
have it happen less offten, have less chaos, be easier to fix the damage.

Insert some flag or file existance in JIT620 SFC620 to prevent more than one 
person doing this at the same time, since 90% of our 620 crashes are 
triggered by this scenario.

Error Messages & what default hits when they just press enter & what would we 
prefer to happen in that circumstance?

MONMSG that includes MSG to QSYSOPR and/oror a specific message queue for 
specific problems, so that after a mess has been created, someone knows in a 
timely manner that a mess has been created.

We have supplemented 610 with queries that list what is in the work station 
batch file not yet posted, for the purpose of expediting verification 
correctly keyed in ... vanilla 610 is aimed at someone who understands 
production control & is showing them what will happen if this is posted, but 
we have some clerical people who just need to see they did not do a typo.

I need to add to those queries with audit trail of items fueling inventory 
transactions so that if we have a batch of 2,000 inventory multi-issue 
updates that got done 5 times instead of 1 time, the person doing the 
negative reversals has a list prepared to help get that job done.

Look in the update code to see if there is any place to insert an "I'm done" 
flag to prevent duplicate inventory postings like is now done with the labor 
side.

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