|
Repeat this mantra "API's are my friend". Study the following: http://publib.boulder.ibm.com/pubs/html/as400/v4r5/ic2924/info/apis/wm1.htm Especially the list object locks api. If you have never done a list API before study the following, very carefully: http://publib.boulder.ibm.com/pubs/html/as400/v4r5/ic2924/info/apis/concept.htm Especially the 'User space format for list apis' and the 'API error reporting'. There is an optional part of OS/400 which will put the library QSYSINC on your system. There are many /copy members for API's in here. You can change certain job streams, or if you want to get really fancy, add a physical file before read trigger to IIM to check and process locks. You probably won't be real popular - performance wise. Not that I am against triggers in general, but checking for locks can be somewhat intensive. Rob Berendt ================== A smart person learns from their mistakes, but a wise person learns from OTHER peoples mistakes. MacWheel99@aol.com Sent by: To: MIDRANGE-L@midrange.com (AS400 & family discussion group) owner-midrange-l@mi cc: drange.com Subject: WRKOBJLCK automated API ? 06/05/01 10:13 AM Please respond to MIDRANGE-L From Al Macintyre, still writing in RPG/400 but occasionally embedded SQL This is not urgent, more like brain storming. I have some software to modify, to enhance what it is doing in the form of features, new data capturing, less hassles for users & so forth, and one worrysome situation is risk of conflict updating a heavily used file. I would like my next modifications to handle that situation more gracefully. What happens today is that there is lock up because two people are trying to update the same file at the same time, and the end user messages are not friendly informative. At best we are told that some other unspecified user is updating a record in a specific file that this one needs, & usually does not give a clue as to which one, & when it does it gives record # of the file, when our users think of the data by item # order # etc., and then manual usage of WRKOBJLCK to locate who that is can be a royal pain. Finally we figure out who is the blocking program, and get that out of the way, then there is the issue of which of IBM's many responses is the least harmful to the original project ... I usually take GO getin continue if it was JOBQ & Retry if it was interactive, but tell all my helpers to use Go because far too often they have done Retry on JOBQ after a bomb on say transaction 500 & it retries all 500 transactions resulting in duplicate postings. I imagine there must be some AS/400 network & other places with examples of source code to reduce this kind of hassle for the end users. For the interactive user, before trying to update some file that MIGHT have some conflict, I would want code from RPG program to detect whether or not that record is locked, then send user a better phrased message, including what response code to take after resolving the case of who is blocking access. For the batch job in this scenario, what I ideally would like to end up with is. 1. Program wants to update a file with a record key, but in addition to the error message being IIML01 file it should include ITEM MASTER FILE which is how the users identify it, and it should also say which item # it is trying to update, in addition to wherever the system gets the record # which apparently is the only way to communicate through WRKOBJLCK. 2. Perhaps the program that wants to update a locked record calls a secondary program to handle the conflict, let's call it MSGAIDIIM if the conflict is with the IIM file, sending parameters identifying what item is to be updated & for what purpose. The users might like to know the purpose so they can decide whether to bypass this update or if it is essential to get it done. 3. MSGAIDIIM program would a. unless this is the first iteration, check whether the end users had sent a certain GO message meaning, return control to the calling program with instructions to bypass that update. b. check whether access to that item is still blocked & if not, return control to the calling program with instructions to retry the update c. use some API (is there one?) to identify from WRKOBJLCK or some other LCK command precisely what program job etc. is blocking access to the desired item # record. d. only in the first iteration, create the message place that will be checked in later iterations to see if the end users sent the GO AROUND instruction. e. craft & send a message saying in effect that the calling program / user / job needs to update item master item # for what purpose but the blocking program / user / job needs to get out of the way first can some users please arrange this, or do whatever to send the GO AROUND instruction how this message should be sent to the user who owns the batch job that got stuck this message should be sent to the user of the job doing the blocking this message should be sent to certain computer department personnel or the work stations in the computer department the logic needs to avoid duplicates, like if the same user is on more than one list if we write such software then user or work station no longer exists on our system, the program needs to send a message to QSECOFR or QSYSMSG what message was tried to be sent by MSGAIDIIM to user or work station that no longer exists so that current computer department personnel know to make adjustments f if no response to first message there needs to be some loop & wait some reasonable time period - perhaps loop on "a & b" more rapidly than on sending message again, especially if the job doing the blocking changes. Again, my need here is not urgent. It is more that I am brainstorming some ideas. 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 +--- +--- | 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-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
