Re: ENQ trap for dynamic allocation
In 1673718699-1278445011-cardhu_decombobulator_blackberry.rim.net-10409900...@bda026.bisx.prod.on.blackberry, on 07/06/2010 at 07:37 PM, Ted MacNEIL eamacn...@yahoo.ca said: RACF already has hooks in OPEN, Nonsense! -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
In 1266114502-1278510036-cardhu_decombobulator_blackberry.rim.net-4418546...@bda026.bisx.prod.on.blackberry, on 07/07/2010 at 01:41 PM, Ted MacNEIL eamacn...@yahoo.ca said: My point was that ENQ would have to be redesigned in order to use RACF. Your point was incorrect. There is no need for ENQ to use RACF. The whole issue is that nothing stops you from coding DISP=OLD on a dataset that you have no permissions to open. Then why the nonsense about modifying ENQ? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
In listserv%201007060939362842.0...@bama.ua.edu, on 07/06/2010 at 09:39 AM, Paul Gilmartin paulgboul...@aim.com said: JES3 is likely different, perhaps not because of RACF. JES3 has a serialization mechanism that uses both DSN and volser. If you don't propogate SYSDSN then you solve the problem for similarly named dataset on different systems. I don't know of anything in JES3 that would help when it's the same dataset or on the same system. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
John Hooper jhoo...@foodlion.com wrote in message news:listserv%201007071639213340.0...@bama.ua.edu... I have looked at the exits and I don't see two things that I would have to have to recover from SYSDSN ENQ failures. First, I can't see a way to get control on and ENQ failure and secondly, even if I could, I could not see a way to redrive the original ENQ request for SYSDSN. Also, all of the ENQ exits seem to indicate that a wait is not allowed. A WTOR or STIMER does that if you want to wait a bit and retry. Also, there seems to be discussion about my possible solution to remove RACF read access. It is true that ENQ and RACF have no connection. It is just likely that a DD statement in JCL or a utility control statement will at least eventually open the file even though the ENQ might have already been satisfied. A security failure will reduce the likelyhood that the programmer will just follow the old adage if at first you don't succeed, resubmit the job and hope for a miracle. It also looks like the most common approach to prevent development access from interfering with production process is to isolate production data from development. Is that the consensus? Thanks. Well no, the original problem is a production job wanting a data set that is held by a development job. Apparently both may/need use the same data and you cannot separate them. If you could, you can also deny the development job any access to the data set in the current environment. A simple solution is to use JCL allocation: the system issues the contention message, the automation tool traps it checks the situation and cancels the development job. Kees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Tue, 6 Jul 2010 19:37:15 +, Ted MacNEIL eamacn...@yahoo.ca wrote: I wonder if IBM would consider changing that? Don't ask me; ask them. Of course, a new interface would have to be designed. RACF already has hooks in OPEN, they would have to put one in ENQ. No, Ted, RACF would not put one in ENQ. RACF does not have any hooks anywhere. System resource managers decide which functions need security, and implement appropriate calls ( via RACROUTE or callable services) to SAF in order to implement their security needs. Even before SAF, it was still the responsibility of the resource manager to call RACF, via the older macros. Other security products certainly did, and may still, hook into the system to provide their functions, but it does not work that way with RACF and never has. We believe that the resource owner, who understands the design of their code, should decide what needs security, and where it is appropriate to provide it. So, if the designers of ENQ feel it is appropriate to provide this security function, they will do so. At most what we in RACF would do is consult with them about how to implement their call, or possibly implement a change in the SAF interfaces if they need some kind of processing we don't already provide. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
No, Ted, RACF would not put one in ENQ. RACF does not have any hooks anywhere. Sorry for my imprecision. My point was that ENQ would have to be redesigned in order to use RACF. And, it probably not be trivial. I was more concerned about the result, if needed, than the actual implementation details. The whole issue is that nothing stops you from coding DISP=OLD on a dataset that you have no permissions to open. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Perhaps I'm missing something here, but couldn't this be nicely done in IEFDB401? Some code would be necessary to rattle through the dynamic allocation parameter list, but on an allocation request, find the DSN (if present) and DISP (if present) and then, do the actual ENQ on SYSDSN (whatever). If you get it, DEQ and proceed, otherwise use the logic you presently have. Lance - Original Message - From: John Hooper jhoo...@foodlion.com Newsgroups: bit.listserv.ibm-main Sent: Tuesday, July 06, 2010 7:55 AM Subject: Re: ENQ trap for dynamic allocation This thread has had some interesting comments. I agree that in todays world it is a terrible idea to develop your own screening or front-end code to provide functionality. The ENQ front-end was done 15 years ago and has served us well. It has allowed us to sort-of have our cake and eat it too. Our requirement was to prevent test jobs from adversely affecting production jobs. This was in the days of a single LPAR and using the security system to prevent all access was not deemed to be a good idea. I accept the fact that this facility will be retired. I do have a question. What do most shops do to prevent this condition? I see three options. I hope there are more. One - I think CA-MIM can address this problem. Is that true? Two - Totally physically isolate development from production and do not allow them to even see production files. Three - Use the security system to not even allow READ access. Again - how do you address this issue? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Perhaps I'm missing something here, but couldn't this be nicely done in IEFDB401? Some code would be necessary to rattle through the dynamic allocation parameter list, but on an allocation request, find the DSN (if present) and DISP (if present) and then, do the actual ENQ on SYSDSN (whatever). If you get it, DEQ and proceed, otherwise use the logic you presently have. Testing can I get the resource by obtaining and then releasing it doesn't do anything productive, but it DOES drive up resource contention and overhead. The problem with any such approach is that the state of the resource is quite likely to be different the moment you release it, so a subsequent attempt to obtain it would block anyway. There IS a conditional form of ENQ you can use if you don't want to become trapped in amber while some paleolithic production job runs all day. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
- Original Message - From: Chris Craddock crashlu...@gmail.com Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 07, 2010 10:12 AM Subject: Re: ENQ trap for dynamic allocation Perhaps I'm missing something here, but couldn't this be nicely done in IEFDB401? Some code would be necessary to rattle through the dynamic allocation parameter list, but on an allocation request, find the DSN (if present) and DISP (if present) and then, do the actual ENQ on SYSDSN (whatever). If you get it, DEQ and proceed, otherwise use the logic you presently have. Testing can I get the resource by obtaining and then releasing it doesn't do anything productive, but it DOES drive up resource contention and overhead. The problem with any such approach is that the state of the resource is quite likely to be different the moment you release it, so a subsequent attempt to obtain it would block anyway. There IS a conditional form of ENQ you can use if you don't want to become trapped in amber while some paleolithic production job runs all day. Well, yes. But the OP has an existing ENQ screen, and existing logic and an expectation that this continue. If I were in his situation, IEFDB401 is where I would look. I did look at PC screening once, and it was scary. So, given the situation at hand, is there a better place to look than IEFDB401? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Wed, 7 Jul 2010 11:30:08 -0600, kopplin kopp...@earthlink.net wrote: Well, yes. But the OP has an existing ENQ screen, and existing logic and an expectation that this continue. If I were in his situation, IEFDB401 is where I would look. I did look at PC screening once, and it was scary. So, given the situation at hand, is there a better place to look than IEFDB401? Yes - covered early in the thread along with a pointer to the manual. GRS exits. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
I have looked at the exits and I don't see two things that I would have to have to recover from SYSDSN ENQ failures. First, I can't see a way to get control on and ENQ failure and secondly, even if I could, I could not see a way to redrive the original ENQ request for SYSDSN. Also, all of the ENQ exits seem to indicate that a wait is not allowed. A WTOR or STIMER does that if you want to wait a bit and retry. Also, there seems to be discussion about my possible solution to remove RACF read access. It is true that ENQ and RACF have no connection. It is just likely that a DD statement in JCL or a utility control statement will at least eventually open the file even though the ENQ might have already been satisfied. A security failure will reduce the likelyhood that the programmer will just follow the old adage if at first you don't succeed, resubmit the job and hope for a miracle. It also looks like the most common approach to prevent development access from interfering with production process is to isolate production data from development. Is that the consensus? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
- Original Message - From: Mark Zelden mzel...@flash.net Newsgroups: bit.listserv.ibm-main Sent: Wednesday, July 07, 2010 2:32 PM Subject: Re: ENQ trap for dynamic allocation On Wed, 7 Jul 2010 11:30:08 -0600, kopplin kopp...@earthlink.net wrote: Well, yes. But the OP has an existing ENQ screen, and existing logic and an expectation that this continue. If I were in his situation, IEFDB401 is where I would look. I did look at PC screening once, and it was scary. So, given the situation at hand, is there a better place to look than IEFDB401? Yes - covered early in the thread along with a pointer to the manual. GRS exits. Mark It looks like we have different definitions of better. We run a GRS exit (for Bronzeplex) written when we had a lot more Systems Programming horsepower than we do today. Given the same (Priceplex) situation today, I would swear up and down that MIM is an absolute requirement. From a business perspective, I really do think that's true. Things are obviously changing. Given a No money, code something up situation I would work a dynamic allocation front-end with GRS Exit as a distant second choice. But that's a personal pucker factor at play. Mileage varies, there's more than one way to skin a cat etc. Lance -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
This thread has had some interesting comments. I agree that in todays world it is a terrible idea to develop your own screening or front-end code to provide functionality. The ENQ front-end was done 15 years ago and has served us well. It has allowed us to sort-of have our cake and eat it too. Our requirement was to prevent test jobs from adversely affecting production jobs. This was in the days of a single LPAR and using the security system to prevent all access was not deemed to be a good idea. I accept the fact that this facility will be retired. I do have a question. What do most shops do to prevent this condition? I see three options. I hope there are more. One - I think CA-MIM can address this problem. Is that true? Two - Totally physically isolate development from production and do not allow them to even see production files. Three - Use the security system to not even allow READ access. Again - how do you address this issue? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
We allow test jobs to READ some production (non HIPAA) data. And it is known that they will be CANCELed if they need to be or get in production's way. If a test job causes a production job to go down, it is written up and the programmer gets a talking to. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Hooper Sent: Tuesday, July 06, 2010 8:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ENQ trap for dynamic allocation This thread has had some interesting comments. I agree that in todays world it is a terrible idea to develop your own screening or front-end code to provide functionality. The ENQ front-end was done 15 years ago and has served us well. It has allowed us to sort-of have our cake and eat it too. Our requirement was to prevent test jobs from adversely affecting production jobs. This was in the days of a single LPAR and using the security system to prevent all access was not deemed to be a good idea. I accept the fact that this facility will be retired. I do have a question. What do most shops do to prevent this condition? I see three options. I hope there are more. One - I think CA-MIM can address this problem. Is that true? Two - Totally physically isolate development from production and do not allow them to even see production files. Three - Use the security system to not even allow READ access. Again - how do you address this issue? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
John Hooper jhoo...@foodlion.com wrote in message news:listserv%201007060855033012.0...@bama.ua.edu... This thread has had some interesting comments. I agree that in todays world it is a terrible idea to develop your own screening or front-end code to provide functionality. The ENQ front-end was done 15 years ago and has served us well. It has allowed us to sort-of have our cake and eat it too. Our requirement was to prevent test jobs from adversely affecting production jobs. This was in the days of a single LPAR and using the security system to prevent all access was not deemed to be a good idea. I accept the fact that this facility will be retired. I do have a question. What do most shops do to prevent this condition? I see three options. I hope there are more. One - I think CA-MIM can address this problem. Is that true? Two - Totally physically isolate development from production and do not allow them to even see production files. Three - Use the security system to not even allow READ access. Again - how do you address this issue? I'd like to bring up another view on the original problem, a production job doing a dynamic allocation of a datasets that is in use. Actually the base problem is, that the a dynamic allocation *request* can generate both a *yes* and a *no* answer. Often applications don't realize the latter and don't cater for it. We had similar situations lately and then the job owners started blaming everybody else, including our backup- and other dasd maintenance jobs for breaking their application flow. Where in fact this is an application error for assuming that it will always get the requested datasets. After explaining this extensively to the development departement, together with written evidence from the IBM manuals on how to use dynamic allocation, they were convinced of their shortcommings. This will not immediately help you in your 15 years ago established situation, but might provide another solution path. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Tue, 6 Jul 2010 08:55:03 -0500, John Hooper wrote: ... I do have a question. What do most shops do to prevent this condition? I see three options. I hope there are more. One - I think CA-MIM can address this problem. Is that true? Two - Totally physically isolate development from production and do not allow them to even see production files. Three - Use the security system to not even allow READ access. Again - how do you address this issue? (One) CA-MIM can prevent propagation of ENQs to other systems. Our site exploits this for ISPF profile data sets to permit concurrent LOGONs. (Three) scarcely helps. RACF does not intervene against ENQs. If a job contains //N DD DISP=OLD,DSN=SYS1.LINKLIB, JES2 will bring it to an initiator where it will wait until all other ENQs of SYS1.LINKLIB are freed. JES3 is likely different, perhaps not because of RACF. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
The dynamic allocation issue that we suffer from is primarily IDCAMS. Some of the functions that do not use the FILE parameter allocate the affected file with dynamic allocation. There are other utilities such as DFDSS (ADRDSSU) that also get involved at least with ENQ testing. These may or may not use the program call interface to ENQ. The point is that if a batch job uses JCL to allocate a file and has a conflict then it issues a waiting for dataset message but does not fail. Other dataset conflicts especially those using dynamic allocation are not so lucky. I would like to blame the developers but they are also victims. One other side effect is without this facility sloppy scheduling will now cause failures. An improperly scheduled production job may cause another to fail. Someone will have to scour syslogs to find those jobs. With the front-end one job would just wait a little bit. This facility has saved thousands of failures over the years. I assume others have had similar issues and either use data isolation or a 2x4 over the head approach. It might be worth a SHARE requirement to provide an exit point to address this problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Tue, 6 Jul 2010 09:46:59 -0500, John Hooper wrote: will now cause failures. An improperly scheduled production job may cause another to fail. Someone will have to scour syslogs to find those jobs. With the front-end one job would just wait a little bit. This facility has saved thousands of failures over the years. I assume others have had similar issues and either use data isolation or a 2x4 over the head approach. It might be worth a SHARE requirement to provide an exit point to address this problem. At present, use of S99WTDSN is restricted to APF authorized jobs. A finer granularity of control by RACF, allowing certain jobs to use S99WTDSN with certain DSNAMEs might provide relief. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Perhaps what is needed is a new PARMLIB specification in the ALLOCnn member. Perhaps similar to the SDSN_WAIT parameter. Perhaps called DYN_DSN_WAIT(YES|NO). Which would specify whether a DYNALLOC of an in use dataset should WAIT until the DSN is freed or not. Now, I know that this can lead to a deadly embrace where JOB A allocates DSN A in JCL with DISP=OLD while job B allocated DSN B in JCL. Job A then tries to DYNALLOC B and waits. Job B tries the same and wait, which causes a deadlock. So another parameter of DYN_DSN_WAIT_TIME could be specified so that after the specific period of time the DYNALLOC fails as it does today. Or IBM could try to write a deadlock detection routine which would fail the second DYNALLOC with a potential deadlock failure code. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Hooper Sent: Tuesday, July 06, 2010 9:47 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ENQ trap for dynamic allocation The dynamic allocation issue that we suffer from is primarily IDCAMS. Some of the functions that do not use the FILE parameter allocate the affected file with dynamic allocation. There are other utilities such as DFDSS (ADRDSSU) that also get involved at least with ENQ testing. These may or may not use the program call interface to ENQ. The point is that if a batch job uses JCL to allocate a file and has a conflict then it issues a waiting for dataset message but does not fail. Other dataset conflicts especially those using dynamic allocation are not so lucky. I would like to blame the developers but they are also victims. One other side effect is without this facility sloppy scheduling will now cause failures. An improperly scheduled production job may cause another to fail. Someone will have to scour syslogs to find those jobs. With the front-end one job would just wait a little bit. This facility has saved thousands of failures over the years. I assume others have had similar issues and either use data isolation or a 2x4 over the head approach. It might be worth a SHARE requirement to provide an exit point to address this problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Tuesday, July 06, 2010 9:57 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ENQ trap for dynamic allocation On Tue, 6 Jul 2010 09:46:59 -0500, John Hooper wrote: will now cause failures. An improperly scheduled production job may cause another to fail. Someone will have to scour syslogs to find those jobs. With the front-end one job would just wait a little bit. This facility has saved thousands of failures over the years. I assume others have had similar issues and either use data isolation or a 2x4 over the head approach. It might be worth a SHARE requirement to provide an exit point to address this problem. At present, use of S99WTDSN is restricted to APF authorized jobs. A finer granularity of control by RACF, allowing certain jobs to use S99WTDSN with certain DSNAMEs might provide relief. -- gil But would require that it be used. IDCAMS does not use it, but could because IDCAMS is APF authorized. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Paul Gilmartin paulgboul...@aim.com wrote in message news:listserv%201007060957004521.0...@bama.ua.edu... On Tue, 6 Jul 2010 09:46:59 -0500, John Hooper wrote: will now cause failures. An improperly scheduled production job may cause another to fail. Someone will have to scour syslogs to find those jobs. With the front-end one job would just wait a little bit. This facility has saved thousands of failures over the years. I assume others have had similar issues and either use data isolation or a 2x4 over the head approach. It might be worth a SHARE requirement to provide an exit point to address this problem. At present, use of S99WTDSN is restricted to APF authorized jobs. And that is a good thing, isn't it? You don't want everybody to create deadlocks, only APF programmers. There are 2 options: 1 Retry the allocation at some interval, for some period. SAS has the ability for this in the FILENAME/LIBNAME statement. Dynalloc coders have it too of course. 2 Return to JCL allocation. This will very much clear up the situation: -The programmer does not have to worry about allocation, when the program runs, it *has* the dataset. -Jobs will simply wait and produce message for the operator, who can then determine who is waiting and who is holding and what to do with the situaition. The messages can also be trapped by your automation tool, which can then do the determination and consequent actions. Kees. A finer granularity of control by RACF, allowing certain jobs to use S99WTDSN with certain DSNAMEs might provide relief. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PC Screening (Was: ENQ trap for dynamic allocation)
In its initial release, TMON/MVS front-ended the first load module involved in GETMAIN/FREEMAIN after all validation and common entry logic (SVC, PC, branch-entry, etc.) had been processed. The reason was to detect and identify orphan pieces of virtual storage in CSA/ECSA/SQA/ESQA. This function was added to the product before IBM put the same logic into the operating system, so it might not still be in there. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bob Shannon Sent: Monday, July 05, 2010 3:38 PM To: IBM-MAIN@bama.ua.edu Subject: Re: PC Screening (Was: ENQ trap for dynamic allocation) I don't know why anyone would hook Getmain, but frontending PCs is pretty common. I suspect a large shop such as yours has vendor products that already do it. ENQ has provided exit points so that frontending is unnecessary. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
I was once granted access to, and crashability of, a totally isolated test system to test my sensitive supervisor state, key 0 code. I managed to cause JES2 on the test system to crash just after it had done a hardware reserve to its checkpoint data set, which, of course, was also shared by the production system. Thus I caused a lengthy non-optimal situation on the production system. My point is to examine every possible link between the two allegedly physically isolated systems with a high-powered magnifying glass and as a criminal trial lawyer would think; i.e., assume that the two systems have at least one link that you haven't found yet, guilty until proven innocent etc. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Hooper Sent: Tuesday, July 06, 2010 8:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ENQ trap for dynamic allocation ...Totally physically isolate development from production and do not allow them to even see production files. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Tue, 6 Jul 2010 17:07:27 +0200, Vernooij, CP - SPLXM wrote: At present, use of S99WTDSN is restricted to APF authorized jobs. And that is a good thing, isn't it? You don't want everybody to create deadlocks, only APF programmers. APF programmers are responsible for setting timers and breaking deadlocks. -Jobs will simply wait and produce message for the operator, who can then determine who is waiting and who is holding and what to do with the situaition. The messages can also be trapped by your automation tool, which can then do the determination and consequent actions. Deadlocks can be detected simply by inspecting the GRS queue for cycles. So, a modest proposal: allow unauthorized programs to use S99WTDSN, but fail the allocation immediately if it would create a cycle in the GRS queue. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Three - Use the security system to not even allow READ access. Even with absolutely no access, I can (accident or design) still issue an exclusive on a dataset. As long as I don't open it, I can still specify DISP=OLD. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Tuesday, July 06, 2010 2:03 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ENQ trap for dynamic allocation Three - Use the security system to not even allow READ access. Even with absolutely no access, I can (accident or design) still issue an exclusive on a dataset. As long as I don't open it, I can still specify DISP=OLD. I wonder if IBM would consider changing that? Of course, there could be a case where a program, via APF, could access a dataset which the RACF id of the job would normally not have access to. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Even with absolutely no access, I can (accident or design) still issue an exclusive on a dataset. As long as I don't open it, I can still specify DISP=OLD. I wonder if IBM would consider changing that? Of course, there could be a case where a program, via APF, could access a dataset which the RACF id of the job would normally not have access to. Unlikely. If one omits the disposition it defaults to NEW which requires an exclusive enqueue. I've seen a lot of systems hungup because of this. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
I wonder if IBM would consider changing that? Don't ask me; ask them. Of course, a new interface would have to be designed. RACF already has hooks in OPEN, they would have to put one in ENQ. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Tuesday, July 06, 2010 2:37 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ENQ trap for dynamic allocation I wonder if IBM would consider changing that? Don't ask me; ask them. Of course, a new interface would have to be designed. RACF already has hooks in OPEN, they would have to put one in ENQ. Or in allocation. Why allocatate that which you cannot open? Like having a beer at the desk. grin -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Or in allocation. Why allocatate that which you cannot open? Becaus it's easy? - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
At 9:39 AM -0500 on 07/06/2010, Paul Gilmartin wrote about Re: ENQ trap for dynamic allocation: (Three) scarcely helps. RACF does not intervene against ENQs. If a job contains //N DD DISP=OLD,DSN=SYS1.LINKLIB, JES2 will bring it to an initiator where it will wait until all other ENQs of SYS1.LINKLIB are freed. This need to wait brings up one of my Hot Button design flaws with ENQ. There is no way for an Exclusive ENQ to be converted to a Shared ENQ. Due to this design flaw, a multi-step job that has DISP=OLD in step 1 and DISP=SHR in subsequent steps owns an exclusive ENQ until the last step ends instead of having the subsequent steps having a Shared ENQ once step 1 ends (and allowing other DISP=SHR jobs to run). Since I own the EXC ENQ and there is a queue of SHR ENQs waiting for me to release the EXC ENQ, I see no reason why the EXC entry can not be altered to a SHR and to then drive the code to run the queue to release the holds on the SHR requests until a queued EXC request is encountered. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
At 10:00 AM -0500 on 07/06/2010, McKown, John wrote about Re: ENQ trap for dynamic allocation: Perhaps what is needed is a new PARMLIB specification in the ALLOCnn member. Perhaps similar to the SDSN_WAIT parameter. Perhaps called DYN_DSN_WAIT(YES|NO). Which would specify whether a DYNALLOC of an in use dataset should WAIT until the DSN is freed or not. Now, I know that this can lead to a deadly embrace where JOB A allocates DSN A in JCL with DISP=OLD while job B allocated DSN B in JCL. Job A then tries to DYNALLOC B and waits. Job B tries the same and wait, which causes a deadlock. So another parameter of DYN_DSN_WAIT_TIME could be specified so that after the specific period of time the DYNALLOC fails as it does today. Or IBM could try to write a deadlock detection routine which would fail the second DYNALLOC with a potential deadlock failure code. Even worse, due to the design flaw in ENQ that does not allow an EXC ENQ to be converted into a SHR ENQ, you have the situation that so long as any step in a Job Stream has DISP=OLD, the EXC ENQ is held until the last step that uses the data set has completed (even though that step has DISP=SHR coded). Thus I can run into this situation even though the owning step (and all subsequent steps) only want/need a SHR ENQ due to a prior completed step having needed a EXC ENQ. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
the EXC ENQ is held until the last step that uses the data set has completed I always thought it was until the end of the job. Thus the need for FREE=CLOSE. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Source: http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.i bm.zos.r9.ieab600/xdddisp.htm DISP and ENQ: Before starting the first step of a job, the initiator requests control of all of the data sets in that job by issuing an ENQ for each of them, using the value specified for DISP to determine the kind of ENQ issued. The initiator issues the ENQ for each data set at the highest level required for that data set by any step of the job. For example, if all steps of the job request shared control of a specific data set (DISP=SHR) then the ENQ for that data set is requested as SHR. If, on the other hand, any step of the job requests exclusive control of a specific data set (DISP=NEW, DISP=MOD, or DISP=OLD), then the ENQ for that data set is requested EXCL. The ENQ for each dataset is released at the end of the last step of the job referencing it. Since ENQs cannot be downgraded from EXCL to SHR, if one step needs the ENQ EXCL and a following step only needs it SHR, the ENQ is still issued as EXCL and held until the end of the last step which references that data set, at which point the ENQ is released entirely. HTH, Greg Shirey Ben E. Keith Company -Original Message- Sent: Tuesday, July 06, 2010 3:18 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ENQ trap for dynamic allocation the EXC ENQ is held until the last step that uses the data set has completed I always thought it was until the end of the job. Thus the need for FREE=CLOSE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
held until the end of the last step which references that data set, at which point the ENQ is released entirely. I'll take your (and the manual's) word for it. But, we did some tests (circa 1985), where we would add and IEFBR14 with a disp=old, to a multi-hour job, and try to access the dataset in question. No joy. But, this was back with ACF2, and many mods (pre-XA). I can't even ask the SYSPROG who helped me, for verification. He's beyond retirement. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PC Screening (Was: ENQ trap for dynamic allocation)
On 4 July 2010 04:03, Edward Jaffe edja...@phoenixsoftware.com wrote: If IBM chooses to provide no equivalent function to SVC screening for PCs, then proceeds to change numerous services to use PCs instead of SVCs, and then complains because software that used to intercept SVC calls with SVC screening now uses unintended programing interfaces to intercept the equivalent PC calls, what can I really say about that? I just don't have much sympathy... Two small points... SVC Screening was not something IBM implemented either to keep customers happy in general, or as a a counter to customers' often voiced need for continued source code availability. Rather, SVC Screening was implemented around 1980 in support of the short-lived IBM product VSPC (Virtual Storage Personal Computing), which, to some extent like CICS, attempted to run multiple users and their programs in a single address space. To keep one user from interfering with another, it was essential to be able to capture all or at least dangerous SVCs and treat them in a local manor. That customers and ISVs used this facility for all kinds of things almost as soon as it came along is hardly surprising. One could well argue that these uses were customers' and ISVs' own attempts to use a programming interface rather than the myriad non-standard schemes that had been in use from the beginning. In this light, IBM's failure to provide a general PC Screening interface has brought about the current situation. Peter Relson suggests, though doesn't exactly say, that screening of SVCs like ENQ is not a programming interface. But SVC Screening itself *is* a programming interface -- a very poorly documented one to be sure, but described in the mainstream manuals -- and the relevant TCB fields are clearly marked PI in the IKJTCB mapping macro and the control blocks book. Certainly not all SVC parameter lists are PIs, but some are documented as such, and it's a plausible argument that any generated by a published IBM macro such as ENQ are de facto a PI, since the MF=E and MF=L forms often require explicit and knowledgeable manipulation of them. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PC Screening (Was: ENQ trap for dynamic allocation)
You have to add at least one more likely choice to that list O Lack of resources IBM has a finite amount of developer and testing folks time which can be used to ship new feature and function in a release. IBM hw/sw planners and others drive requirements inside IBM. We customers through Marketing Requirements and user group (SHARE, COMMON, Guide/SHARE Europe, IDUG, etc.) Requirements raise them. I assume decisions are made and resources assigned based on priorities to add value to the platform, support key IBM hw/sw, reduce support costs both for IBM and the customer and I imagine a myriad of other factors. While PC Screening and PCUPDTE seem logical and useful I have never heard this raised as a requirement in discussions with IBM. It may well be on the drawing board unfinished or unimplemented. Maybe there are good reasons it was not done in the first place. Perhaps the perception that the security and stability of Program Call would be better if no one hooked code in this way. As a customer I don't want anyone hooking ENQ, GETMAIN or the PC equivalents it just complicates upgrades, creates problems, and complicates debugging of problems. As a customer in the trenches stability, availability, security, reliability, functionality are keystones and cost is king. Ease of use is rising concern even for the uber techies or perhaps because of an expected shortage someday. If I put together a top list of requirements for IBM and ISV's I doubt this would make the list. So the big iron geek in me can agree that of course it should be done and should have been done years ago but the customer focused side says hold up there a minute what don't I get while they are off doing this? I would prefer IBM do more work to eliminate the need for use of unsupported dynamic hook and patch points used by ISVs so they can get off those unintended interfaces and into new, stable, robust, documented exit points. A generalized PC hooking facility seems like an invitation to more of what customers want to see go away. What do you think? Best Regards, Sam Knutson, GEICO System z HW/SW/Automation Team Leader mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shane Ginnane Sent: Sunday, July 04, 2010 5:05 AM To: IBM-MAIN@bama.ua.edu Subject: Re: PC Screening (Was: ENQ trap for dynamic allocation) Peter Relson wrote: But I will point out that we have been making concerted efforts to get ISVs to share with us their use of unintended interfaces. Then Ed Jaffe wrote: Whether by oversight, laziness, perceived difficulty of implementation, or whatever, IBM implemented no equivalent programming interface for PC calls. PC call intercepts, if needed, must always be done at a system level using unintended interfaces. Doesn't sound like IBMs concerted efforts are working too well. Knowing Ed, he would have been in there batting hard for this and is obviously pissed off with the response so far. I'm always for more openness - it's up to IBM to provide the interfaces IMHO. Shane ... This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PC Screening (Was: ENQ trap for dynamic allocation)
As a customer I don't want anyone hooking ENQ, GETMAIN or the PC equivalents it just complicates upgrades, creates problems, and complicates debugging of problems. I don't know why anyone would hook Getmain, but frontending PCs is pretty common. I suspect a large shop such as yours has vendor products that already do it. ENQ has provided exit points so that frontending is unnecessary. A generalized PC hooking facility seems like an invitation to more of what customers want to see go away IBM has never standardized a way to frontend or hook SVCs, but many vendors have figured out how to do it without stepping on each other. When work is moved from SVCs to PCs, vendors need to hook the PCs to provide equivalent function. If vendors stop hooking PCs, the vendor product goes away. Probably not good for either the customer or the vendor. Bob Shannon Rocket Software rchives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PC Screening (Was: ENQ trap for dynamic allocation)
Thanks Bob, nicely put. Covers my attitude pretty well. As for Sams contention, I'd much rather everybody had a (published) API to use rather than try to dig around and write their own. A lot of that skillset (and knowledge) seems to be disappearing - given some of the threads here over recent times, that seems a lot more of an exposure than using a legitimate hook. Shane ... On Tue, Jul 6th, 2010 at 6:38 AM, Bob Shannon wrote: A generalized PC hooking facility seems like an invitation to more of what customers want to see go away IBM has never standardized a way to frontend or hook SVCs, but many vendors have figured out how to do it without stepping on each other. When work is moved from SVCs to PCs, vendors need to hook the PCs to provide equivalent function. If vendors stop hooking PCs, the vendor product goes away. Probably not good for either the customer or the vendor. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PC Screening (Was: ENQ trap for dynamic allocation)
IBM provides a programming interface for intercepting SVC calls called SVC screening. I agree. And it is documented that the purpose of SVC screening is to do authorization checking. Front-ending SVCs is also provided (SVCUPDTE) but that does not mean that you are able to assume that a particular caller is using an SVC to invoke a particular interface. The abuse of SVC screening and (more often) SVCUPDTE are frequent causes of customer outages. Front-ending PCs will never be supported. If you can make a case for an exit out of particular PCs, then make it. MIM did. And that is why GRS has exits.. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
PC Screening (Was: ENQ trap for dynamic allocation)
Peter Relson wrote: This whole thread is exactly why it is important to code your applications to programming interfaces. Intercepting, front-ending, whatever: you are only asking for trouble. IBM provides a programming interface for intercepting SVC calls called SVC screening. This facility has been used by a great many ISVs--including Phoenix--to intercept SVC calls in a way that limits the intercept to a a subset of SVCs for a single, targeted TCB. Whether by oversight, laziness, perceived difficulty of implementation, or whatever, IBM implemented no equivalent programming interface for PC calls. PC call intercepts, if needed, must always be done at a system level using unintended interfaces. It should be obvious, but I will clarify for those that might not be privileged code programmers, that intercepting PC calls using these unintended interfaces is considerably more difficult to implement than SVC screening and, because the intercept must be at a system level, programming errors here are several orders of magnitude more likely to expose the system to instability than similar programming errors in SVC screening routines. If IBM chooses to provide no equivalent function to SVC screening for PCs, then proceeds to change numerous services to use PCs instead of SVCs, and then complains because software that used to intercept SVC calls with SVC screening now uses unintended programing interfaces to intercept the equivalent PC calls, what can I really say about that? I just don't have much sympathy... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PC Screening (Was: ENQ trap for dynamic allocation)
Peter Relson wrote: But I will point out that we have been making concerted efforts to get ISVs to share with us their use of unintended interfaces. Then Ed Jaffe wrote: Whether by oversight, laziness, perceived difficulty of implementation, or whatever, IBM implemented no equivalent programming interface for PC calls. PC call intercepts, if needed, must always be done at a system level using unintended interfaces. Doesn't sound like IBMs concerted efforts are working too well. Knowing Ed, he would have been in there batting hard for this and is obviously pissed off with the response so far. I'm always for more openness - it's up to IBM to provide the interfaces IMHO. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Just pointing out the obvious: This whole thread is exactly why it is important to code your applications to programming interfaces. Intercepting, front-ending, whatever: you are only asking for trouble. But I will point out that we have been making concerted efforts to get ISVs to share with us their use of unintended interfaces. We typically feel free to change, as needed, things that are not documented programming interfaces. When we (incompatibly) change documented programming interfaces, we try to get that changed noted in the migration publications for a release. When we know something unintended is being done, we factor that into our design process. It might or might not change our mind on what we need to do, but it does enable us to alert the application owner of the need to change (rather than relying on their happening to find out). Has anyone identified to IBM the exact need of this application? It is not to intercept all ENQs. Yet by intercepting all ENQs, you might be adversely affecting the entire system. In all likelihood, even if the requirement were accepted, it would not be implemented by the time you initiallly needed it. But if it is implemented later, you would be able to exploit that change and get out of the dangerous game you are playing (assuming that you really do want your application to keep working). As with any requirement, the more users it will benefit, the more likely it is that it will be accepted and implemented. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Sat, 2010-07-03 at 20:54 -0400, Peter Relson wrote: snip Has anyone identified to IBM the exact need of this application? It is not to intercept all ENQs. Yet by intercepting all ENQs, you might be adversely affecting the entire system. In all likelihood, even if the requirement were accepted, it would not be implemented by the time you initiallly needed it. But if it is implemented later, you would be able to exploit that change and get out of the dangerous game you are playing (assuming that you really do want your application to keep working). As with any requirement, the more users it will benefit, the more likely it is that it will be accepted and implemented. Peter Relson z/OS Core Technology Design The OP indicated that it was to allow a retry of ENQs to SYSDSN for dataset in use similar to what is done by the initiator, but by unauthorized (nonAPF) callers to DYNALLOC. APF callers to DYNALLOC can use S99WTDSN to wait if the dataset is in use. The OP said that their front end would go to normal ENQ but if the QNAME was SYSDSN and the RC from normal ENQ was 4, the front end would wait a bit and automatically retry the ENQ. Something about allowing test jobs to access prod datasets but not cause problems to prod jobs using IDCAMS to delete and redefine some datasets (VSAM?). To me, a most weird requirement. -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
It still works for certain things, but to be honest, I haven't needed to use it since DFSMS and ISPF added the support for renaming an in use data set in OS/390 R10. -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ On Fri, 2 Jul 2010 08:48:37 +1000, Shane Ginnane ibm-m...@tpg.com.au wrote: Hadn't picked up on that - thanks for the heads up Mark. Don't use it much any more, but it still comes (came) in handy for unusual circumstances. Shane ... On Fri, Jul 2nd, 2010 at 2:53 AM, Mark Zelden wrote: This change also broke some tools like the popular BYPASSNQ from Gilbert St. Flour (CBT File 183). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Fri, 2 Jul 2010 07:38:49 -0500, Mark Zelden wrote: It still works for certain things, but to be honest, I haven't needed to use it since DFSMS and ISPF added the support for renaming an in use data set in OS/390 R10. Isn't this just an automated mechanism for zapping the VTOC? The integrity protection remains carbon-based (graphite on Post-IT), and the programmer must know, somehow, that the other jobs holding ENQs refer to irrelevant volsers, or intend _never_ to modify the extents. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Fri, 2 Jul 2010 09:24:41 -0500, Paul Gilmartin paulgboul...@aim.com wrote: On Fri, 2 Jul 2010 07:38:49 -0500, Mark Zelden wrote: It still works for certain things, but to be honest, I haven't needed to use it since DFSMS and ISPF added the support for renaming an in use data set in OS/390 R10. Isn't this just an automated mechanism for zapping the VTOC? The integrity protection remains carbon-based (graphite on Post-IT), and the programmer must know, somehow, that the other jobs holding ENQs refer to irrelevant volsers, or intend _never_ to modify the extents. I don't know exactly what CAMLST does under the covers, but I doubt it has anything to do with zapping the VTOC (which you can't do safely without disabling the VTOCIX first if one exists). The data set can't be SMS managed though. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2S361/2.6.3.4?SHELF=DGT2BK91DT=20100120144526CASE= Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
I want to thank all of the respondents to this question. I was tied up and could not respond yesterday. It seems certain that IBM changed the call to ENQ in 1.10 so my old SVC filter won't work. It also seems that the efford to front-end the PC routine would be risky at best especially when I will age out in a couple of years. That leaves commercial software or data segregation. One is unlikely in view of the economic situation that we and most shops face. The other will be political with many unhappy developers who will lose easy access to production data. Unless someone can come up with another alternative I will accept my fate and go fight for money or data segregation. Again, thanks all. John Hooper -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
As someone else previously suggested, look at the GRS exit points IBM provides. They were created so that vendors don't need to frontend the SVCs or PCs. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Reading this thread, and Mark's link to the DFSMS advanced functions manual, it seems that it is necessary to code a program using the CAMLST macro to do renames of datasets that are enqueued, and that it must be executed access to the appropriate resource. Correct? Would I be correct in thinking that IBM has not supplied a utility that does this? Has anyone yet coded such a program? We have been using BYPASSNQ as part of our SYSRES clone process. The VOLSER of the HFS files that reside on the SYSRES is part of the name, so after we do a volume copy, we rename the HFS files on the new SYSRES. If BYPASSNQ is no longer going to work when we get off z/OS 1.9 we will need to change something in our process. Jeff Holst Fiserv Dublin, OH -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Fri, 2 Jul 2010 13:41:44 -0500, Jeff Holst jeff.ho...@fiserv.com wrote: Reading this thread, and Mark's link to the DFSMS advanced functions manual, it seems that it is necessary to code a program using the CAMLST macro to do renames of datasets that are enqueued, and that it must be executed access to the appropriate resource. Correct? Would I be correct in thinking that IBM has not supplied a utility that does this? Hi Jeff, It's mentioned in the doc I posted in one paragraph: PDF. IBM has written a utility - ISPF/PDF.The thing is, this has never been documented in the ISPF manuals nor ISPF help that I know of. If you attempt rename a data set that is ENQed / in use from an ISPF 3.4 volser list (not a catalog list) and have the proper RACF authority, you see this message: DATA SET NAME IS IN USE BUT YOU HAVE AUTHORITY TO OVERRIDE THIS TEST *** Then when you hit enter, you get confirmation panel like this: Rename Data Set In Use Command === Data Set Name . : some_data_set_name Volume . . . . : vv The system detected that a data set with the above name is in use (possibly on another system) but it cannot determine whether it is the data set you wish to rename. If it is the same data set and any program has it open, renaming it could cause serious system and data integrity problems. You have the extra security authority to rename the data set even though its name is in use. Refer to the DFSMS documentation on the RENAME macro for further information. Instructions: Press ENTER to override data set name protection and rename the data set. Enter CANCEL or EXIT to cancel the rename request. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Fri, 2 Jul 2010 13:41:44 -0500, Jeff Holst jeff.ho...@fiserv.com wrote: We have been using BYPASSNQ as part of our SYSRES clone process. The VOLSER of the HFS files that reside on the SYSRES is part of the name, so after we do a volume copy, we rename the HFS files on the new SYSRES. If BYPASSNQ is no longer going to work when we get off z/OS 1.9 we will need to change something in our process. I'm sure you can figure out alternatives, but here are perhaps some (not knowing a lot of details). Keep the HFS data sets off the sysres (like we had to do when they were required to be SMS controlled) and logically copy, or logically copy from a maintenance version to the target set you are creating with the proper name. Or just manually rename via ISPF 3.4 after your full volume copy. You will have to change your process for zFS anyway should you decide to finally migrate your sysres unix file systems. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ENQ trap for dynamic allocation
Fifteen years ago I wrote a facility that front-ends the ENQ SVC. It traps all ENQ requests and if SYSDSN ENQ comes back with a return code of 4 it examines the environment, issues console messages, and usually waits a minute and tries ENQ again. Thus a test job reading a production file would not cause a production job to fail but would keep trying and give the console operator a chance to cancel the test job or wait for it to finish. This facility is designed especially to eliminate the following messages: IKJ56225I DATA SET MYTEST.TEST.ENQ.FILE ALREADY IN USE, TRY LATER IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER Anyway, it works fine under z/OS 1.9 but doesn’t work under z/OS 1.11. Apparently dynamic allocation (or IDCAMS) has changed and does not call SVC 56 to see if the dataset is allocated or else the ENQ parameter list has changed radically. This routine don’t seem to get a chance to trap the SYSDSN ENQ request. In attempting to debug the routine I found that all SVC 56 effectively does is make a PC to the GRS address space. I am afraid that dynamic allocation is doing the PC without the SVC. I think there is a CA product that could replace this function but this home- grown facility has been free and I work for a frugal company. Does anyone know if I am correct in my assumption that dynamic allocation has changed? Does anyone have any idea of how to front-end the program call to GRS? Is the program call (PC) facility documented anywhere? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Thu, 1 Jul 2010 09:18:46 -0500 John Hooper jhoo...@foodlion.com wrote: :Fifteen years ago I wrote a facility that front-ends the ENQ SVC. It traps all :ENQ requests and if SYSDSN ENQ comes back with a return code of 4 it :examines the environment, issues console messages, and usually waits a :minute and tries ENQ again. Thus a test job reading a production file would :not cause a production job to fail but would keep trying and give the console :operator a chance to cancel the test job or wait for it to finish. :This facility is designed especially to eliminate the following messages: :IKJ56225I DATA SET MYTEST.TEST.ENQ.FILE ALREADY IN USE, TRY LATER :IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER :Anyway, it works fine under z/OS 1.9 but doesnt work under z/OS 1.11. :Apparently dynamic allocation (or IDCAMS) has changed and does not call SVC :56 to see if the dataset is allocated or else the ENQ parameter list has :changed radically. This routine dont seem to get a chance to trap the :SYSDSN ENQ request. In attempting to debug the routine I found that all SVC :56 effectively does is make a PC to the GRS address space. I am afraid that :dynamic allocation is doing the PC without the SVC. :I think there is a CA product that could replace this function but this home- :grown facility has been free and I work for a frugal company. :Does anyone know if I am correct in my assumption that dynamic allocation :has changed? Does anyone have any idea of how to front-end the program :call to GRS? Is the program call (PC) facility documented anywhere? Well, you could change your frontend to display what it is seeing - that will tell you if you are being bypassed. But, at any rate - what does doesnt work mean - what is different? -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
As far as I know, there is no mechanism provided by IBM for hooking a PC. Ch. 10 of the Pops manual discusses the mechanism used to process a PC and a PR. Ch. 5 discusses the translation and look-up mechanisms involved. There are a lot of ISV products in the market that do front-end PCs...but it ain't somethng to be done without a lot of thought. And, it ain't for the novice, part-time coder to attempt. --Dave Day -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dave Day Sent: Thursday, July 01, 2010 10:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ENQ trap for dynamic allocation As far as I know, there is no mechanism provided by IBM for hooking a PC. Ch. 10 of the Pops manual discusses the mechanism used to process a PC and a PR. Ch. 5 discusses the translation and look-up mechanisms involved. There are a lot of ISV products in the market that do front-end PCs...but it ain't somethng to be done without a lot of thought. And, it ain't for the novice, part-time coder to attempt. --Dave Day I would also say it is not really even for an expert, company employee, to do either. Who's going to maintain it when the developer goes to the great data center in the sky? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
It is likely that the enqueue is now either being done by ENQ LINKAGE=SYSTEM or by ISGENQ - both forms will *not* issue the old enqueue SVC. Do NOT attempt to front-end the GRS PC - this would be *very* dangerous. The GRS execution environment can be extremely complex with various cross-memory links and various locks held (I spent 18 months in the bowels of GRS and have the grey hairs and nervous twitches to mark that experience). The normal GRS installation exits are also not going to be of much use either as I believe that prohibit any WAIT processing (eg WTOR). My suggestion is to examine why the IKJ* messages are being issued and see if you can top-and-tail the production jobs with a process that will wait for the resources rather than just fail. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Hooper Sent: 01 July 2010 15:19 To: IBM-MAIN@bama.ua.edu Subject: ENQ trap for dynamic allocation Fifteen years ago I wrote a facility that front-ends the ENQ SVC. It traps all ENQ requests and if SYSDSN ENQ comes back with a return code of 4 it examines the environment, issues console messages, and usually waits a minute and tries ENQ again. Thus a test job reading a production file would not cause a production job to fail but would keep trying and give the console operator a chance to cancel the test job or wait for it to finish. This facility is designed especially to eliminate the following messages: IKJ56225I DATA SET MYTEST.TEST.ENQ.FILE ALREADY IN USE, TRY LATER IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER Anyway, it works fine under z/OS 1.9 but doesn't work under z/OS 1.11. Apparently dynamic allocation (or IDCAMS) has changed and does not call SVC 56 to see if the dataset is allocated or else the ENQ parameter list has changed radically. This routine don't seem to get a chance to trap the SYSDSN ENQ request. In attempting to debug the routine I found that all SVC 56 effectively does is make a PC to the GRS address space. I am afraid that dynamic allocation is doing the PC without the SVC. I think there is a CA product that could replace this function but this home- grown facility has been free and I work for a frugal company. Does anyone know if I am correct in my assumption that dynamic allocation has changed? Does anyone have any idea of how to front-end the program call to GRS? Is the program call (PC) facility documented anywhere? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
On Thu, 1 Jul 2010 09:18:46 -0500, John Hooper jhoo...@foodlion.com wrote: Fifteen years ago I wrote a facility that front-ends the ENQ SVC. It traps all ENQ requests and if SYSDSN ENQ comes back with a return code of 4 it examines the environment, issues console messages, and usually waits a minute and tries ENQ again. Thus a test job reading a production file would not cause a production job to fail but would keep trying and give the console operator a chance to cancel the test job or wait for it to finish. This facility is designed especially to eliminate the following messages: IKJ56225I DATA SET MYTEST.TEST.ENQ.FILE ALREADY IN USE, TRY LATER IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER Anyway, it works fine under z/OS 1.9 but doesnt work under z/OS 1.11. This actually was changed in z/OS 1.10, so it wouldn't work on that OS either.This change also broke some tools like the popular BYPASSNQ from Gilbert St. Flour (CBT File 183). Here is a note that I have from an IBMer with more detail: In z/OS R10, the Allocation component changed to use LINKAGE=SYSTEM for all ENQs to provide better performance and efficiency. Some of those ENQs were changed back to LINKAGE=SVC via APAR OA29286, however SYSDSN ENQ was not. Moreover, there are no plans to change the SYSDSN ENQ back to LINKAGE=SVC. (Also, we may choose to revert those changed linkages in OA29286 back to LINKAGE=SYSTEM in a future release.) Programs that rely upon SVC screening for finding and changing ENQs should be using GRS exits some text deleted For information on GRS exits, see the MVS Installation Exits documentation. Relying upon SVCs for ENQs is not supported and would be exposed to this type of internal change if and when it occurred. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Hadn't picked up on that - thanks for the heads up Mark. Don't use it much any more, but it still comes (came) in handy for unusual circumstances. Shane ... On Fri, Jul 2nd, 2010 at 2:53 AM, Mark Zelden wrote: This change also broke some tools like the popular BYPASSNQ from Gilbert St. Flour (CBT File 183). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
