|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.