|
Suppose you connected to the 400 via a PC and there is a power outage while you in the middle of some accounting update. You hypothetical user have no idea what the proper recovery process is. When the power back on again, you ignore the fact that you had this disruption, sign on again to a new work session and restart the same job, in which prior to the power outage, some work was in fact done, and BPCS has a data structure, and work members in various files named after your work session, containing evidence of partially done work, which you then are doing over again, resulting in some work done more than once.
Let's suppose it was not a power outage, just some glitch requiring the PC to be rebooted, or arrangement of stuff under the desk so that an accidental kick can nudge the power plug. From the perspective of the end user, it appears to them that they are able to abnormally terminate a BPCS update job, then restart that same job, and it seems to go to an Ok conclusion, but some work got done in duplicate, that is not immediately obvious to that user.
Since they not know any problem, they may not make an effort to capture extra joblogs of their activity.
There can also be problems, if someone other than the billing person, is in midst of update of the files associated with billing, then their connection gets broken. Remember that in this scenario, WKRACTJOB will not show you DSC jobs that are entangled. You need to use WRKSBSJOB QINTER.
So what is the correct response? Well first, people need to remember what BPCS task they were running when they got disconnected, and they need to know enough about naming conventions to know which is an inquiry, simple report, or an update program, and if update, what are the kinds of problems that can result from THAT update program getting disrupted, such as risk of duplicate postings, some in use flag, hung batch, and so forth.
We have a query that lists which customer orders currently have their in use flag on, and a second that does this for RMAs (member RETURN). We know how to fix onsies with DFU. However, there is a step in shipping in which they select the customer to be shipped, then get list of orders for that customer, and then pick which of those to be shipped, and if the shipping PC goes down right at the point where they select customer, then 100% of the orders on that customer are in use. We get everyone off of all BPCS tasks which can update BPCS, then we run a program that does a mass update of all customer orders to not be in use.
SYS993 is needed to reset certain tasks such as BIL500 when the end user was in the middle of a series of steps, and they get disrupted, and need to restart. SYS993 is found on the reset menu of SYS which we copied to our menu FXS for miscelaneous fixes because we not want many people able to mess with other stuff on the SYS menus. Note that SYS993 needs to be run when the victim is at a menu, and we also need to do the in use fix.
SYS993 vanilla is SYS / 23 /21 ours is FIXS / 50 Also of relevance is SYS / 4In addition, there are flags in BBL related to how far the process got before it bombed. We added a few logicals to simplify the task of making repairs to the disrupted work in process.
We use GO CMDLCK when it is an ordinary case of a conflict with another user, other than the in use flag, to find out who is updating the same file, which we know from error message on bottom of screen, F1 there, or check the user's joblog while they still signed on.
GO CMDLCK option 8 ECL If you get a blank screen, F6 then F5 scroll to locate activity of other than an inquiry (read only) naturelock column with *SHRUPD means the person is running a program which can update the file To the left of the *SHRUPD you have column showing work station of person who is currently running something that is updating customer orders
There can be an in use flag if someone else is updateing a customer order at same time as different user trying to bill earlier shipments on that order. BPCS tells the ORD500 person that the order is in the invoicing state, which means it got shipped but not yet billed, and there is a way for the ORD500 person to take a command to force access to update the order anyway, which messes up the billing.
We have a process I call pre-billing, in which we run various reports driven by what's in BBL file to review what is about to be invoiced, to support any last minute corrections. We have learned what can be corrected at that point, and what can not.
This topic is one of several we have added details about how to resolve in our FIXOOPS document added to the BPCSDOC collection, because when there is a long time between one instance of a problem and the next instance, there is a tendency to forget some of the nuances of what needs fixing.
Hi Everyone, I have a BPCS Version 405 site that somehow manages to get duplicate invoice numbers on occasion - there is no relation I can see between the invoices ie they are for different customers, different items, different quantities etc etc. Is it possible that two users have accessed the invoicing process at the same time to grab the same invoice number from the data structure? Regards, Kylea White Technical Consultant KAZ Technology Services Switch: +61 8 6212 0100 Fax: +61 8 9225 6748 Email kylea.white@xxxxxxxxxxxxx Web www.focalsystems.com.au A KAZ Technology Services Company - visit our website at http://www.kaz-group.com -- This is the SSA's BPCS ERP System (BPCS-L) mailing list To post a message email: BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/bpcs-l or email: BPCS-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/bpcs-l. Delivered-To: macwheel99@xxxxxxxxxxx
- Al Macintyre http://www.ryze.com/go/Al9Mac BPCS/400 Computer Janitor ... see http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.
midrange.com
