Re: WRKOBJLCK automated API ?

Thanks Joe

I am working with BPCS 405 CD.
I have notified SSA of bugs that I have found.
In some cases I have identified for them a specific program, a specific chunk 
of code, what specifically is wrong with it, then stated that the same 
program has a few thousand other places with the same fatal flaw, without me 
enumerating them all.
Invariably SSA has said this is the way the software is supposed to work & if 
they were to change it, it would mess things up for other users.
Thus, I conclude that the tech support person in each of these instances did 
not understand what I was trying to communicate, and was giving me a standard 
answer.  My duty was done, and I had to get on with the best I could with the 
reality.

Overall I consider BPCS 405 CD to be a very stable ERP but it is not perfect.

I believe that good programming practice is such that:
1. Program determines we need access to such & such a record.
Program obtains the neccessary information, provided it is not locked out.
2. Program disengages lock on record until user ready for update.
so that the program only needs access to the record for miliseconds.
3. Interactive program sends information to user screen related to that 
record.
4. Program compares data now in record with fields to be updated.
5. 99.99 % of the time data is identical & no further reconciliation needed
6. When a difference in iterim, then additional logic needed for that 
scenario.

I suspect that some BPCS software, which as I am sure you are aware was 
written by SSA with help of AS/Set to work on HP Unix & Win NT in addtion to 
the 400, instead follows practice of

1. Program determines we need access to such & such a record.
2. Interactive program sends information to user screen related to that 
record.
3. Program retains lock on that record until user is finished doing their 
thing

We have found in WRKOBJLCK cases that
the hung program needs access to such & such a record
that record is locked by such & such a user update program
the user of that work station has gotten distracted & left their program in 
the middle of an INV100 or INV500 or ORD590 or other update process in which 
the lock on some record ends at the moment we ask that person to F12 back out 
of the screen they are on, or get the screen finished & move on to the next 
item or order or whatever.

I do not consider that it is possible practical for me to rewrite all the bad 
code I am finding.  

There is a systemic problem in BPCS 405 CD with fields that are far too large 
being multiplied, so that with simple numbers you get ONE TIMES ZERO EQUALS 
MINUS DECIMAL TWO or some such variation, at rate of about one such hit a 
week, which is probably more disturbing to management than this hassle with 
conflicting access to records, which is an every other day hassle.  I have 
found several programs that have this incorrect multiplication problem & the 
second one I analysed has literally hundreds if not thousands of locations in 
the source code where it is doing the same risk.  I got the first one fixed 
... the billing program is not doing this any more ... I never did get the 
cost rollups fixed.

There are programs that only need to access the actual routings (type 1 
including work center detail) not all the additional description lines we use 
to describe the steps involved in manufacturing the product, but SSA insists 
on having these programs access lines irrelevant to those programs (I have 
such modified some of these programs to use the smaller logicals) generating 
humogous wasted page size reports (I also modified that to avoid spool file 
blow up) that we have to kill after the program runs because digging into 
50,000 page reports to find the 2 pages we are interested in is just 
unmanageable.  I now run a modified report on the eve of one of these big 
update runs, showing the reality of what we are interested in.

Yesterday one person was trying to key in some transactions & kept bouncing 
up against another person in INV100 item master maintenance of item 4014 who 
had been called away from their work station, so that it was locking that 
item.

We have not modified INV100, but I am working on modifying the program that 
happened to be the one dong the bouncing yesterday & I just thought that in 
my next round of modifications, perhaps I can have it do a better job of 
coping with this scenario.

The software that I am working on is the SFC600 610 SFC620 series embedded in 
the JIT600 610 JIT620 series that handle labor ticket input.  My 
modifications are intended to reduce the amount of redundant keying needed, 
make it easier for us to catch transcription problems, improve the quality of 
the edit reports the users have at their disposal, block selected things that 
BPCS does that our company does not want, such as substituting which shop 
order gets updated when it is scrap that pushes the total work product over 
the ceiling of what was requested, and address issues that cause this process 
to to have conflicts in the first place.

Every conflict that I have studied has the kind of good programming practice 
that I stated at the top of this post in the SFC6* series point that fails, 
while it is the other program, the one doing the blocking, that is written in 
a bad way.  The problem is that it is not consistently one bad program doing 
the blocking, and the points in those other programs are not consistently one 
place.

Fixing this is an enormous task, so I was brainstroming some intermediate 
work around.

Al Macintyre

> Subj:  RE: WRKOBJLCK automated API ?
>  From:    joepluta@PlutaBrothers.com (Joe Pluta)
>  
>  Mac, there's a bigger issue here.  Why in the world is a record locked for
>  anything more than a few milliseconds (the time to read and update the
>  record)?  There are two perfectly good alternate architectures for data
>  access - busy flags and image checking - neither of which lock the record
>  for any appreciable length of time, and so never run into the situation you
>  are facing.
>  
>  Joe

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---