Need help understanding DISP-SHR in OCL

[ebbhitch]

Well, I had this issue yesterday and my programmer could not understand why this solution was necessary, but it worked. I'd really like to be able to understand it, as well as get him an explanation. A job is kicked off in the QUSRWRK subsystem for the sole purpose of running: STRS36PRC PRC(ACSUP1). The OCL for ACSUP1 is:

// LOAD ACSUP1 // FILE NAME-ACSDATA // FILE NAME-ACCTMAST,DISP-SHR // RUN * ACSUP3 ACSUP4

ACSUP1 reads through the ACSDATA file and applies the necessary changes to the appropriate accounts. ACSUP3 and 4 are both reports that also have the identical line referring to ACSDATA. What I found was that the job would run the first program and then hang waiting for exclusive access to ACSDATA. [No other programs access this file in the entire system] The solution was to add ',DISP-SHR' to each procedure for ACSDATA. Since the one procedure calls Program 1, then OCL 2 for Program 2, then OCL 3 for Program 3, but all are under the same user... Why would it wait for itself to give itself access to a file it just used? My programmer had said something like when the last record is read on a file, the locks are released. But if that's the case, then it really doesn't make sense here. Any guidance would be hugely appreciated!! Thank you!

[efnkay]

Re:Need help understanding DISP-SHR in OCL

Wow...Strictly from distant memories. Why you have to explicitly DISP-SHR on ACSDATA may be a S/36 environment default or perhaps S/36 procedure attribute that could be changed? Anyway...I would add that any record locks are released only by an update, unlock, next read, closing the file, or ending-program w/LR on. I don't believe commitment-control exists for S/36...But I don't know for sure. My guess is that a "member" lock or exclusive-file-access is obtained for the S/36 file unless DISP-SHR is specified. Which is of course necessary for any in-line procedure calls that use the same file. Because the lock lives until the calling procedure ends. It's been too long since my S/36 Model-D era...So I don't know if DISP-SHR would allow another separately running procedure/program call to access and/or update the same file...But that may not be of any concern since you already established ACSDATA exclusive use to the ACSUP1 procedure. Anyway...No questions about "POP" ok...??? :-)

[ebbhitch]

Re:Need help understanding DISP-SHR in OCL

efnkay wrote:

Wow...Strictly from distant memories. Why you have to explicitly DISP-SHR on ACSDATA may be a S/36 environment default or perhaps S/36 procedure attribute that could be changed? Anyway...I would add that any record locks are released only by an update, unlock, next read, closing the file, or ending-program w/LR on. I don't believe commitment-control exists for S/36...But I don't know for sure.

I'm flailing my way through learning this system. It's a custom written software in RPG II for S/36 environment. I've had some RPG IV classes, but our programmer only knows S/36 and only RPG II and, due to other circumstances, can't teach it to me.. so I'm trying my best, but wishing I didn't have to.

My guess is that a "member" lock or exclusive-file-access is obtained for the S/36 file unless DISP-SHR is specified. Which is of course necessary for any in-line procedure calls that use the same file. Because the lock lives until the calling procedure ends.

If that's the case, that would certainly explain this situation! Since the program ACSUP1 was done, but the procedure ACSUP1 still was running to call the procedure ACSUP3, you're saying it wouldn't have released the member for ACSDATA. Is that (member locks living until the end of the calling procedure not just the last record read) just a guess or is that a fact? (Just checking before I bring that back to my programmer, as it doesn't line up with what he seemed to understand) Thank you!

[efnkay]

Re:Need help understanding DISP-SHR in OCL

I feel your pain. Yeah the member lock is essentially a file lock if there is only one data member in the physical file. (That member-lock terminology is more specific to non-S/36 environment AS/400 jargon.) By the apparent behavior of subsequent procedure calls hanging until you applied DISP-SHR...It's a good indication that the file access was dedicated to ACSUP1 without the DISP-SHR. This type of lock however would be used maybe during an end-of-day jobstream where you explicitly don't want anything else touching that file during a night-batch job for example. Don't feel bad. Sometimes fate puts you on a wonderful and modern machine...But the legacy software still being used takes the wonderful right out of it. It gets better. Maybe you can influence your company to convert to native environment from S/36 but the overall cost and effort may be a deterent unless you can piggy-back the effort along with some other huge, all encompassing, software upgrade. Good Luck just the same!

[ebbhitch]

Re:Need help understanding DISP-SHR in OCL

efnkay wrote:

I feel your pain. Yeah the member lock is essentially a file lock if there is only one data member in the physical file. (That member-lock terminology is more specific to non-S/36 environment AS/400 jargon.) By the apparent behavior of subsequent procedure calls hanging until you applied DISP-SHR...It's a good indication that the file access was dedicated to ACSUP1 without the DISP-SHR. This type of lock however would be used maybe during an end-of-day jobstream where you explicitly don't want anything else touching that file during a night-batch job for example.

Do you know if there might be an "official" place this explanation or definition would be provided? I believe you, but my programmer has a (hugely irritating) habit of immediately dismissing information I research and bring to him because it's not something he's heard of (holding back a rant here) If I say that I asked a forum and someone told me this, he might dismiss it anyway. But if I find him a webpage or official IBM doc with the details or even generic statements, he might not be able dismiss it up front. I have been trying Google searches, but I guess my problem is that beyond "DISP-SHR", I'm not sure what words to add to narrow the results correctly... the issue did lock a member, but is there a more appropriate phrase for the S/36 environment? Is DISP-SHR only used in S/36 or is it in Native as well [which would get me more results that wouldn't be accurate for this situation...]

Maybe you can influence your company to convert to native environment from S/36

Well actually it's been a easily one discussion on my part as to why we should/need to consider a conversion, but the implementation has been very slow. Mostly due to very few hands and being a small business that has lasted on the principle "if it ain't broke.." even when that means they waste LOTS of time on manual efforts.. We bought a software tool to help the conversion. We have another programmer who only gives us some part time hours outside his other job and the original thought was that he and I would work together so I could learn during the process. Ultimately the scheduling just didn't make any sense, so he's running with it on his own and I'll learn by seeing the results and having him tell me the process he's applying. So after three years, I can finally say we have the creation of External Data Definitions in progress!! So many ideas of what to do.. and this will be just a huge jump in the right direction!