Re: IEC143I 213-30
This is not true Ted, as we have discussed before. In fact, the symptom in the title of this thread is the result of IBM closing that exposure. Ted MacNEIL eamacn...@yahoo.ca 12/6/2009 9:46 PM Oh? Even with GRS in place? Because we are doing this. There are potential corruption issues when two people are editing members on different swystems. Both read the same offsets. Whoever saves wins! - Too busy driving to stop for gas! -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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: IEC143I 213-30
You can't share them for update, as you have discovered. I would suggest you take this to your sysprogs and tell them you have a requirement they need them to satisfy, and you could even suggest that Sysplex is one solution. If they don't listen, take it to management. Frank Swarbrick frank.swarbr...@efirstbank.com 12/4/2009 7:51 PM On 12/4/2009 at 2:17 PM, in message 2121472874-1259961467-cardhu_decombobulator_blackberry.rim.net-17612826...@bda4 8.bisx.prod.on.blackberry, Ted MacNEIL eamacn...@yahoo.ca wrote: Exactly my point. Someone asked me why I said we didn't want to use PDSE to solve my issue and I said because we can't share them well, because we're not in a Sysplex. You can't share regular PDS datasets either. Oh? Even with GRS in place? Because we are doing this. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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: IEC143I 213-30
On Mon, 7 Dec 2009 09:31:47 -0500, Scott Rowe wrote: This is not true Ted, as we have discussed before. In fact, the symptom in the title of this thread is the result of IBM closing that exposure. Depends. Ted MacNEIL 12/6/2009 9:46 PM Oh? Even with GRS in place? Because we are doing this. There are potential corruption issues when two people are editing members on different swystems. Both read the same offsets. Whoever saves wins! In more detail, last guy to save wins; first guy's changes are lost. Some might consider this corruption. But directory integrity is maintained. -- 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: IEC143I 213-30
I don't believe that's true, Gil. It doesn't make sense given the changes that were made to the logic, and I can't create it here. Do you have a test case that shows this? Paul Gilmartin paulgboul...@aim.com 12/7/2009 9:39 AM On Mon, 7 Dec 2009 09:31:47 -0500, Scott Rowe wrote: This is not true Ted, as we have discussed before. In fact, the symptom in the title of this thread is the result of IBM closing that exposure. Depends. Ted MacNEIL 12/6/2009 9:46 PM Oh? Even with GRS in place? Because we are doing this. There are potential corruption issues when two people are editing members on different swystems. Both read the same offsets. Whoever saves wins! In more detail, last guy to save wins; first guy's changes are lost. Some might consider this corruption. But directory integrity is maintained. -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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: IEC143I 213-30
On Mon, 7 Dec 2009 09:53:26 -0500, Scott Rowe wrote: I don't believe that's true, Gil. It doesn't make sense given the changes that were made to the logic, and I can't create it here. Do you have a test case that shows this? I believe SPFEDIT mostly protects you. To show the problem you'd need to have: o DSNTYPE=PDS o DISP=SHR o Update by a process other than ISPF EDIT, and which doesn't respect the SPFEDIT ENQ. I'll grant this is unlikely; I'd prefer not to try to create it. Perhaps Ted is thinking of something in addition. Paul Gilmartin 9:39 AM On Mon, 7 Dec 2009 09:31:47 -0500, Scott Rowe wrote: This is not true Ted, as we have discussed before. In fact, the symptom in the title of this thread is the result of IBM closing that exposure. Depends. Ted MacNEIL 12/6/2009 9:46 PM Oh? Even with GRS in place? Because we are doing this. There are potential corruption issues when two people are editing members on different swystems. Both read the same offsets. Whoever saves wins! In more detail, last guy to save wins; first guy's changes are lost. Some might consider this corruption. But directory integrity is maintained. -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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: IEC143I 213-30
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, December 07, 2009 9:40 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEC143I 213-30 On Mon, 7 Dec 2009 09:53:26 -0500, Scott Rowe wrote: I don't believe that's true, Gil. It doesn't make sense given the changes that were made to the logic, and I can't create it here. Do you have a test case that shows this? I believe SPFEDIT mostly protects you. To show the problem you'd need to have: o DSNTYPE=PDS o DISP=SHR o Update by a process other than ISPF EDIT, and which doesn't respect the SPFEDIT ENQ. I'll grant this is unlikely; I'd prefer not to try to create it. Perhaps Ted is thinking of something in addition. SNIP I've not been following this thread closely. But it seems that about this time last year I started dealing with a related issue. So if this is not germane to your discussions, just ignore it. Meanwhile, I had found an ABEND that happens when two tasks are trying to do STOW at the same time. In my situation, this was a race (or timing dependant) condition and it could be done within a single LPAR between two address spaces (and I think I was even able to get it within the same address space). I did this under z/OS V1R9. Since we did things to prevent it, I would have to break the code to recreate under z/OS V1R10/11. During design, we concluded that we had to use the ISPF EDIT ENQUEUE. But during testing we found that if you are doing a STOW for member X while another task is attempting member Y at the same time, the ISPF EDIT ENQUEUE does not protect the directory from a simultaneous update situation, only from two tasks using the same member. In order to prevent this ABEND situation, we decided to use an ENQUEUE for the directory updates. The ENQUEUE actually protects from the problem within one address space or across two -- and only between uses of the product (which is still underdevelopment) since the ENQUEUE we came up with is private. The STOW situation I ran into did not require a member write, only that you wish to update the directory entry. In my case, attempting to add the ISPF stats caused the ABEND. And because of race (or timing as you prefer) conditions I was getting two STOWs being done at the same time to the same directory. The system detected this and the arbitrary second updater got the ABEND. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- 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: IEC143I 213-30
Yes, the 213-13 abend is the solution, if you try to open a DCB for output when there is already an output DCB open for a PDS, it will cause the abend. I cannot see how corruption can occur if you can't have two DCBs open for output at the same time. The ENQ is only to avoid getting the abend. Thompson, Steve steve_thomp...@stercomm.com 12/7/2009 11:30 AM -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, December 07, 2009 9:40 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEC143I 213-30 On Mon, 7 Dec 2009 09:53:26 -0500, Scott Rowe wrote: I don't believe that's true, Gil. It doesn't make sense given the changes that were made to the logic, and I can't create it here. Do you have a test case that shows this? I believe SPFEDIT mostly protects you. To show the problem you'd need to have: o DSNTYPE=PDS o DISP=SHR o Update by a process other than ISPF EDIT, and which doesn't respect the SPFEDIT ENQ. I'll grant this is unlikely; I'd prefer not to try to create it. Perhaps Ted is thinking of something in addition. SNIP I've not been following this thread closely. But it seems that about this time last year I started dealing with a related issue. So if this is not germane to your discussions, just ignore it. Meanwhile, I had found an ABEND that happens when two tasks are trying to do STOW at the same time. In my situation, this was a race (or timing dependant) condition and it could be done within a single LPAR between two address spaces (and I think I was even able to get it within the same address space). I did this under z/OS V1R9. Since we did things to prevent it, I would have to break the code to recreate under z/OS V1R10/11. During design, we concluded that we had to use the ISPF EDIT ENQUEUE. But during testing we found that if you are doing a STOW for member X while another task is attempting member Y at the same time, the ISPF EDIT ENQUEUE does not protect the directory from a simultaneous update situation, only from two tasks using the same member. In order to prevent this ABEND situation, we decided to use an ENQUEUE for the directory updates. The ENQUEUE actually protects from the problem within one address space or across two -- and only between uses of the product (which is still underdevelopment) since the ENQUEUE we came up with is private. The STOW situation I ran into did not require a member write, only that you wish to update the directory entry. In my case, attempting to add the ISPF stats caused the ABEND. And because of race (or timing as you prefer) conditions I was getting two STOWs being done at the same time to the same directory. The system detected this and the arbitrary second updater got the ABEND. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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: IEC143I 213-30
This is not true Ted, as we have discussed before. In fact, the symptom in the title of this thread is the result of IBM closing that exposure. I thought it was only fixed in a SYSPLEX environment. I have not worked in a non-SYSPLEX world for over 15 years, so I have not shared either kind of partitioned dataset outside that boundary in that same period of time. - Too busy driving to stop for gas! -- 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: IEC143I 213-30
In more detail, last guy to save wins; first guy's changes are lost. That's what I meant. Some might consider this corruption. But directory integrity is maintained. Data integrity is what I meant. - Too busy driving to stop for gas! -- 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: IEC143I 213-30
I'll grant this is unlikely; I'd prefer not to try to create it. Perhaps Ted is thinking of something in addition. The last time I saw it was in a hmegrown source management system -- not using ISPF services. - Too busy driving to stop for gas! -- 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: IEC143I 213-30
In 2121472874-1259961467-cardhu_decombobulator_blackberry.rim.net-17612826...@bda488.bisx.prod.on.blackberry, on 12/04/2009 at 09:17 PM, Ted MacNEIL eamacn...@yahoo.ca said: You can't share regular PDS datasets either. Of course you can. Whether or not you know how to do it safely, others do. -- 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: IEC143I 213-30
In 45d79eacefba9b428e3d400e924d36b902d16...@iwdubcormsg007.sci.local, on 12/07/2009 at 11:30 AM, Thompson, Steve steve_thomp...@stercomm.com said: Meanwhile, I had found an ABEND that happens when two tasks are trying to do STOW at the same time. That's because you didn't have proper serialization. You need to do the ENQ (RESERVE) before the OPEN and the DEQ after the CLOSE. BPAM does not support multiple concurrent opens of the same PDS for output. During design, we concluded that we had to use the ISPF EDIT ENQUEUE. Which ENQ? ISPF uses one to serialize the member and one to serialize the data set; you need to use both. -- 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: IEC143I 213-30
At 21:17 + on 12/04/2009, Ted MacNEIL wrote about Re: IEC143I 213-30: Exactly my point. Someone asked me why I said we didn't want to use PDSE to solve my issue and I said because we can't share them well, because we're not in a Sysplex. You can't share regular PDS datasets either. I think you can since, I think, a RESERVE is issued against the DRIVE during the update. -- 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: IEC143I 213-30
I think you can since, I think, a RESERVE is issued against the DRIVE during the update. Only during update. If two people are editing and do saves at different times then there is a potential for corruption. - Too busy driving to stop for gas! -- 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: IEC143I 213-30
On 12/4/2009 at 2:17 PM, in message 2121472874-1259961467-cardhu_decombobulator_blackberry.rim.net-17612826...@bda4 8.bisx.prod.on.blackberry, Ted MacNEIL eamacn...@yahoo.ca wrote: Exactly my point. Someone asked me why I said we didn't want to use PDSE to solve my issue and I said because we can't share them well, because we're not in a Sysplex. You can't share regular PDS datasets either. Oh? Even with GRS in place? Because we are doing this. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
Oh? Even with GRS in place? Because we are doing this. There are potential corruption issues when two people are editing members on different swystems. Both read the same offsets. Whoever saves wins! - Too busy driving to stop for gas! -- 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: IEC143I 213-30
In 4b17e85d.6f0f.008...@efirstbank.com, on 12/03/2009 at 04:33 PM, Frank Swarbrick frank.swarbr...@efirstbank.com said: So you are saying that there is no point doing the two step process I mention because it will have the file enqueued for the life of the job no matter what, if DISP=OLD is specified? Not quite; the Initiator will release it at the end of the last step that has a DD statement for it. So if you can arrange to do all of your work in a few short steps at the beginning, you can let other jobs use it after that. -- 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: IEC143I 213-30
I'm not the sysprog, so I may not have all of the details, but if I remember correctly these are the issues: We have PDSESHARING(NORMAL) in our IGDSMSxx member, rather than PDSESHARING(EXTENDED). From http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.idad400/pdsesh3.htm In a multiple-system environment, the system programmer uses PDSESHARING(EXTENDED) to share PDSEs at the member level. A system programmer must specify PDSESHARING(EXTENDED) in the IGDSMSxx member in the SYS1.PARMLIB on each system in the sysplex. Every system that is sharing a PDSE must be a member of the sysplex and have the sysplex coupling facility (XCF) active. We don't have the sysplex, so we're stuck with PDSESHARING(NORMAL). This causes problems when one system has a PDSE open and a second system opens it and tries to update it. Take for example the following scenario, which I just tested. On system 1 I open a PDSE with ISPF VIEW. On system 2 I open the same PDSE with ISPF EDIT. On system 2 I open a member in that PDSE and attempt to save it. I get the following error: IEC143I 213-70,IGG0191B,FJS,APPPROG,ISP11523,0469,TSO001,FJS.APPL.COBOL This means 70 OPEN detected a cross-system share conflict for the PDSE. This issue does not occur when I do the same exact thing with a PDS. Anyway, systems has given us the direction to not use PDSEs. (Well, we can use them for our own personal datasets, but at our own risk.) Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 12/3/2009 at 9:50 PM, in message 002101ca749d$5fda4cf0$e6f71...@foggybottom, George Fogg gf...@nwlink.com wrote: I believe the OP mentioned GRS in shared dasd environment and having problems with PDSEs. I for one would like to know what the problems were. George Fogg -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tony B. Sent: Thursday, December 03, 2009 6:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEC143I 213-30 Sorry I lost track of most of the interim suggestions toward this thread. Did anyone suggest using a PDSE as the target library? Years ago I cobbled together a poor man's scheduling system that used a single PDSE as a repository of members that each nightly batch job would add, as they completed with CC5. Hundreds of jobs updated this PDSE over the course of the evening, resulting in thousands of members having been written. . Sorry if I've restated someone else's post. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Thursday, December 03, 2009 5:34 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEC143I 213-30 On 12/3/2009 at 6:39 AM, in message 20091203184630.1fe42f58...@smtp.patriot.net, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 4b1662c2.6f0f.008...@efirstbank.com, on 12/02/2009 at 12:51 PM, Frank Swarbrick frank.swarbr...@efirstbank.com said: So perhaps a combination of the two is in order. Write to a temporary PDS during the translate and then use DISP=OLD on the copy from the temp PDS in to the actual PDS. The Initiator does the DISP=OLD ENQ at the beginning of the job. So you are saying that there is no point doing the two step process I mention because it will have the file enqueued for the life of the job no matter what, if DISP=OLD is specified? Hmm, oh well. Thanks for the info. The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
Thanks for clarifying. On 12/4/2009 at 8:14 AM, in message 20091204154243.c72fef58...@smtp.patriot.net, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 4b17e85d.6f0f.008...@efirstbank.com, on 12/03/2009 at 04:33 PM, Frank Swarbrick frank.swarbr...@efirstbank.com said: So you are saying that there is no point doing the two step process I mention because it will have the file enqueued for the life of the job no matter what, if DISP=OLD is specified? Not quite; the Initiator will release it at the end of the last step that has a DD statement for it. So if you can arrange to do all of your work in a few short steps at the beginning, you can let other jobs use it after that. The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
On Fri, 4 Dec 2009 12:01:29 -0700, Frank Swarbrick wrote: I'm not the sysprog, so I may not have all of the details, but if I remember correctly these are the issues: We have PDSESHARING(NORMAL) in our IGDSMSxx member, rather than PDSESHARING(EXTENDED). From http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.idad400/pdsesh3.htm In a multiple-system environment, the system programmer uses PDSESHARING(EXTENDED) to share PDSEs at the member level. A system programmer must specify PDSESHARING(EXTENDED) in the IGDSMSxx member in the SYS1.PARMLIB on each system in the sysplex. Every system that is sharing a PDSE must be a member of the sysplex and have the sysplex coupling facility (XCF) active. We don't have the sysplex, so we're stuck with PDSESHARING(NORMAL). This causes problems when one system has a PDSE open and a second system opens it and tries to update it. Take for example the following scenario, which I just tested. This has been discussed several times. Please search the archives. You can not share a PDSE outside of a Sysplex. If you are not in a Sysplex, you can not share a PDSE with another system. If you do so, you can expect the PDSE to break. You quoted the reference. Every system that is sharing a PDSE must be a member of the sysplex and have the sysplex coupling facility (XCF) active. -- Tom Marchant -- 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: IEC143I 213-30
On 12/4/2009 at 12:34 PM, in message listserv%200912041334504828.0...@bama.ua.edu, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Fri, 4 Dec 2009 12:01:29 -0700, Frank Swarbrick wrote: I'm not the sysprog, so I may not have all of the details, but if I remember correctly these are the issues: We have PDSESHARING(NORMAL) in our IGDSMSxx member, rather than PDSESHARING(EXTENDED). From http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.z os.r9.idad400/pdsesh3.htm In a multiple-system environment, the system programmer uses PDSESHARING(EXTENDED) to share PDSEs at the member level. A system programmer must specify PDSESHARING(EXTENDED) in the IGDSMSxx member in the SYS1.PARMLIB on each system in the sysplex. Every system that is sharing a PDSE must be a member of the sysplex and have the sysplex coupling facility (XCF) active. We don't have the sysplex, so we're stuck with PDSESHARING(NORMAL). This causes problems when one system has a PDSE open and a second system opens it and tries to update it. Take for example the following scenario, which I just tested. This has been discussed several times. Please search the archives. You can not share a PDSE outside of a Sysplex. If you are not in a Sysplex, you can not share a PDSE with another system. If you do so, you can expect the PDSE to break. You quoted the reference. Every system that is sharing a PDSE must be a member of the sysplex and have the sysplex coupling facility (XCF) active. Exactly my point. Someone asked me why I said we didn't want to use PDSE to solve my issue and I said because we can't share them well, because we're not in a Sysplex. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
Exactly my point. Someone asked me why I said we didn't want to use PDSE to solve my issue and I said because we can't share them well, because we're not in a Sysplex. You can't share regular PDS datasets either. - Too busy driving to stop for gas! -- 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: IEC143I 213-30
Yes, Ted, I think he's figured that out. Frank, as I've mentioned before, I really think you guys need to re-visit the Sysplex question again. There is really no reason to not be running at least a base Sysplex, it should vastly improve things there. IIRC, you are running GRS in ring mode without a Base Sysplex, which is a really poor performer. There are many benefits and zero cost in changing to a base Sysplex from there. Ted MacNEIL eamacn...@yahoo.ca 12/4/2009 4:17 PM Exactly my point. Someone asked me why I said we didn't want to use PDSE to solve my issue and I said because we can't share them well, because we're not in a Sysplex. You can't share regular PDS datasets either. - Too busy driving to stop for gas! -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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: IEC143I 213-30
I think so to, but it is not my decision to make. Perhaps one of our sysprogs will read this and get that discussion restarted amongst themselves. I have tried to nudge them in that direction in the past, but nothing has come of it. -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 12/4/2009 at 2:47 PM, in message 4b193d17.8489.00d...@joann.com, Scott Rowe scott.r...@joann.com wrote: Yes, Ted, I think he's figured that out. Frank, as I've mentioned before, I really think you guys need to re-visit the Sysplex question again. There is really no reason to not be running at least a base Sysplex, it should vastly improve things there. IIRC, you are running GRS in ring mode without a Base Sysplex, which is a really poor performer. There are many benefits and zero cost in changing to a base Sysplex from there. Ted MacNEIL eamacn...@yahoo.ca 12/4/2009 4:17 PM Exactly my point. Someone asked me why I said we didn't want to use PDSE to solve my issue and I said because we can't share them well, because we're not in a Sysplex. You can't share regular PDS datasets either. - Too busy driving to stop for gas! -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
In 4b1662c2.6f0f.008...@efirstbank.com, on 12/02/2009 at 12:51 PM, Frank Swarbrick frank.swarbr...@efirstbank.com said: So perhaps a combination of the two is in order. Write to a temporary PDS during the translate and then use DISP=OLD on the copy from the temp PDS in to the actual PDS. The Initiator does the DISP=OLD ENQ at the beginning of the job. -- 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: IEC143I 213-30
On 12/3/2009 at 6:39 AM, in message 20091203184630.1fe42f58...@smtp.patriot.net, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 4b1662c2.6f0f.008...@efirstbank.com, on 12/02/2009 at 12:51 PM, Frank Swarbrick frank.swarbr...@efirstbank.com said: So perhaps a combination of the two is in order. Write to a temporary PDS during the translate and then use DISP=OLD on the copy from the temp PDS in to the actual PDS. The Initiator does the DISP=OLD ENQ at the beginning of the job. So you are saying that there is no point doing the two step process I mention because it will have the file enqueued for the life of the job no matter what, if DISP=OLD is specified? Hmm, oh well. Thanks for the info. -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
Sorry I lost track of most of the interim suggestions toward this thread. Did anyone suggest using a PDSE as the target library? Years ago I cobbled together a poor man's scheduling system that used a single PDSE as a repository of members that each nightly batch job would add, as they completed with CC5. Hundreds of jobs updated this PDSE over the course of the evening, resulting in thousands of members having been written. . Sorry if I've restated someone else's post. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Thursday, December 03, 2009 5:34 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEC143I 213-30 On 12/3/2009 at 6:39 AM, in message 20091203184630.1fe42f58...@smtp.patriot.net, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 4b1662c2.6f0f.008...@efirstbank.com, on 12/02/2009 at 12:51 PM, Frank Swarbrick frank.swarbr...@efirstbank.com said: So perhaps a combination of the two is in order. Write to a temporary PDS during the translate and then use DISP=OLD on the copy from the temp PDS in to the actual PDS. The Initiator does the DISP=OLD ENQ at the beginning of the job. So you are saying that there is no point doing the two step process I mention because it will have the file enqueued for the life of the job no matter what, if DISP=OLD is specified? Hmm, oh well. Thanks for the info. -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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 ___ No viruses found in this incoming message Scanned by iolo AntiVirus 1.5.8.3 http://www.iolo.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: IEC143I 213-30
I believe the OP mentioned GRS in shared dasd environment and having problems with PDSEs. I for one would like to know what the problems were. George Fogg -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tony B. Sent: Thursday, December 03, 2009 6:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEC143I 213-30 Sorry I lost track of most of the interim suggestions toward this thread. Did anyone suggest using a PDSE as the target library? Years ago I cobbled together a poor man's scheduling system that used a single PDSE as a repository of members that each nightly batch job would add, as they completed with CC5. Hundreds of jobs updated this PDSE over the course of the evening, resulting in thousands of members having been written. . Sorry if I've restated someone else's post. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Thursday, December 03, 2009 5:34 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEC143I 213-30 On 12/3/2009 at 6:39 AM, in message 20091203184630.1fe42f58...@smtp.patriot.net, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 4b1662c2.6f0f.008...@efirstbank.com, on 12/02/2009 at 12:51 PM, Frank Swarbrick frank.swarbr...@efirstbank.com said: So perhaps a combination of the two is in order. Write to a temporary PDS during the translate and then use DISP=OLD on the copy from the temp PDS in to the actual PDS. The Initiator does the DISP=OLD ENQ at the beginning of the job. So you are saying that there is no point doing the two step process I mention because it will have the file enqueued for the life of the job no matter what, if DISP=OLD is specified? Hmm, oh well. Thanks for the info. -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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 ___ No viruses found in this incoming message Scanned by iolo AntiVirus 1.5.8.3 http://www.iolo.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: IEC143I 213-30
I think that using a later copy step works because the time window involved is shorter and so collisions, two programs having the same PDS open for output with DISP=SHR, would be less likely but could still occur. I have seen that abend happen for link-edit steps. Using DISP=OLD will solve this problem since the job would no longer be updating a dataset allocated with DISP=SHR. Note that the elapsed time for the jobs will increase because the allocation will be held from the start of the job until the end of the step that allocates the dataset with DISP=OLD. Bill On Tue, 1 Dec 2009 12:04:48 -0700, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: A later step in the same job? Does this solve the issue because the copy uses different serialization than the actual creating of the DBRM member? I'll give it a shot. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 12/1/2009 at 11:58 AM, in message 6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com, Don Leahy don.le...@leacom.ca wrote: This is a perennial problem. Our local solution was to allocate DBRMLIB to a temporary data set. //DBRMLIB DD DSN=DBRMLB(MR),DISP=(,PASS), // UNIT=SYSDA,SPACE=(TRK,(15,5,5)), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160) A later step copies the DBRM to a permanent library. On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: For our conversion from VSE to z/OS we have a mass compile process that runs many compiles at the same time. This has been fine up until when we added DB2 compiles in to the mix. Now we are getting things like the following for every second or third compile: 11.02.22 JOB05118 IEC143I 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM 02) 30 An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is already open for output to the data set. The data set might be on the same system or on another system that is sharing the volume. Access was not serialized before the attempt to open the data set. I am guessing that job 2 is trying to add a member to SYS3.DSN910.DBRMLIB.DATA at the same time that job 1 is trying to do the same thing (though a different member). Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Why does the link-edit step seem to not have a similar issue? Is it just that the link-edit step completes so quickly that only one job has the PDS open at one time? Or does the link-edit (binder; whatever) have some special stuff that allows it do deal with this situation? Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 -- 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: IEC143I 213-30
Good point. Our process is working by coincidence. Time to took for a better approach. Thanks. On Wed, Dec 2, 2009 at 05:23, Big Iron billlalo...@rocketmail.com wrote: I think that using a later copy step works because the time window involved is shorter and so collisions, two programs having the same PDS open for output with DISP=SHR, would be less likely but could still occur. I have seen that abend happen for link-edit steps. Using DISP=OLD will solve this problem since the job would no longer be updating a dataset allocated with DISP=SHR. Note that the elapsed time for the jobs will increase because the allocation will be held from the start of the job until the end of the step that allocates the dataset with DISP=OLD. Bill On Tue, 1 Dec 2009 12:04:48 -0700, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: A later step in the same job? Does this solve the issue because the copy uses different serialization than the actual creating of the DBRM member? I'll give it a shot. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 12/1/2009 at 11:58 AM, in message 6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com, Don Leahy don.le...@leacom.ca wrote: This is a perennial problem. Our local solution was to allocate DBRMLIB to a temporary data set. //DBRMLIB DD DSN=DBRMLB(MR),DISP=(,PASS), // UNIT=SYSDA,SPACE=(TRK,(15,5,5)), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160) A later step copies the DBRM to a permanent library. On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: For our conversion from VSE to z/OS we have a mass compile process that runs many compiles at the same time. This has been fine up until when we added DB2 compiles in to the mix. Now we are getting things like the following for every second or third compile: 11.02.22 JOB05118 IEC143I 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM 02) 30 An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is already open for output to the data set. The data set might be on the same system or on another system that is sharing the volume. Access was not serialized before the attempt to open the data set. I am guessing that job 2 is trying to add a member to SYS3.DSN910.DBRMLIB.DATA at the same time that job 1 is trying to do the same thing (though a different member). Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Why does the link-edit step seem to not have a similar issue? Is it just that the link-edit step completes so quickly that only one job has the PDS open at one time? Or does the link-edit (binder; whatever) have some special stuff that allows it do deal with this situation? Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 -- 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: IEC143I 213-30
In 4b14fd2e.6f0f.008...@efirstbank.com, on 12/01/2009 at 11:25 AM, Frank Swarbrick frank.swarbr...@efirstbank.com said: Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Yes. Why does the link-edit step seem to not have a similar issue? It does an exclusive RESERVE prior to the OPEN. -- 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: IEC143I 213-30
I believe the Binder uses ISPF-style enqueues to allow OPEN for output with SHR access without any problems. When needing updates with SHR and utilities that do not support ISPF-style enqueues, our approach has been to change the job step to invoke a front-end program that gets the required SPFEDIT enqueue, invokes the utility, and when the utility returns control drop the enqueue. That way the job may wait, but only for the time when someone else actually has the dataset enqueued for open for output. JC Ewing On 12/02/2009 09:42 AM, Don Leahy wrote: Good point. Our process is working by coincidence. Time to took for a better approach. Thanks. On Wed, Dec 2, 2009 at 05:23, Big Iron billlalo...@rocketmail.com wrote: I think that using a later copy step works because the time window involved is shorter and so collisions, two programs having the same PDS open for output with DISP=SHR, would be less likely but could still occur. I have seen that abend happen for link-edit steps. Using DISP=OLD will solve this problem since the job would no longer be updating a dataset allocated with DISP=SHR. Note that the elapsed time for the jobs will increase because the allocation will be held from the start of the job until the end of the step that allocates the dataset with DISP=OLD. Bill On Tue, 1 Dec 2009 12:04:48 -0700, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: A later step in the same job? Does this solve the issue because the copy uses different serialization than the actual creating of the DBRM member? I'll give it a shot. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 12/1/2009 at 11:58 AM, in message 6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com, Don Leahy don.le...@leacom.ca wrote: This is a perennial problem. Our local solution was to allocate DBRMLIB to a temporary data set. //DBRMLIB DD DSN=DBRMLB(MR),DISP=(,PASS), // UNIT=SYSDA,SPACE=(TRK,(15,5,5)), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160) A later step copies the DBRM to a permanent library. On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: For our conversion from VSE to z/OS we have a mass compile process that runs many compiles at the same time. This has been fine up until when we added DB2 compiles in to the mix. Now we are getting things like the following for every second or third compile: 11.02.22 JOB05118 IEC143I 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM 02) 30 An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is already open for output to the data set. The data set might be on the same system or on another system that is sharing the volume. Access was not serialized before the attempt to open the data set. I am guessing that job 2 is trying to add a member to SYS3.DSN910.DBRMLIB.DATA at the same time that job 1 is trying to do the same thing (though a different member). Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Why does the link-edit step seem to not have a similar issue? Is it just that the link-edit step completes so quickly that only one job has the PDS open at one time? Or does the link-edit (binder; whatever) have some special stuff that allows it do deal with this situation? Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 -- Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org -- 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: IEC143I 213-30
So perhaps a combination of the two is in order. Write to a temporary PDS during the translate and then use DISP=OLD on the copy from the temp PDS in to the actual PDS. Yet another frustating issue in going to z/OS. Oy. Thanks for the ideas. Frank On 12/2/2009 at 3:23 AM, in message listserv%200912020423410867.0...@bama.ua.edu, Big Iron billlalo...@rocketmail.com wrote: I think that using a later copy step works because the time window involved is shorter and so collisions, two programs having the same PDS open for output with DISP=SHR, would be less likely but could still occur. I have seen that abend happen for link-edit steps. Using DISP=OLD will solve this problem since the job would no longer be updating a dataset allocated with DISP=SHR. Note that the elapsed time for the jobs will increase because the allocation will be held from the start of the job until the end of the step that allocates the dataset with DISP=OLD. Bill On Tue, 1 Dec 2009 12:04:48 -0700, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: A later step in the same job? Does this solve the issue because the copy uses different serialization than the actual creating of the DBRM member? I'll give it a shot. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 12/1/2009 at 11:58 AM, in message 6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com, Don Leahy don.le...@leacom.ca wrote: This is a perennial problem. Our local solution was to allocate DBRMLIB to a temporary data set. //DBRMLIB DD DSN=DBRMLB(MR),DISP=(,PASS), // UNIT=SYSDA,SPACE=(TRK,(15,5,5)), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160) A later step copies the DBRM to a permanent library. On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: For our conversion from VSE to z/OS we have a mass compile process that runs many compiles at the same time. This has been fine up until when we added DB2 compiles in to the mix. Now we are getting things like the following for every second or third compile: 11.02.22 JOB05118 IEC143I 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM 02) 30 An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is already open for output to the data set. The data set might be on the same system or on another system that is sharing the volume. Access was not serialized before the attempt to open the data set. I am guessing that job 2 is trying to add a member to SYS3.DSN910.DBRMLIB.DATA at the same time that job 1 is trying to do the same thing (though a different member). Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Why does the link-edit step seem to not have a similar issue? Is it just that the link-edit step completes so quickly that only one job has the PDS open at one time? Or does the link-edit (binder; whatever) have some special stuff that allows it do deal with this situation? Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 -- 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 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
Does IEBCOPY use the same enqueue strategy as the Binder? On Wed, Dec 2, 2009 at 14:29, Joel C. Ewing jcew...@acm.org wrote: I believe the Binder uses ISPF-style enqueues to allow OPEN for output with SHR access without any problems. When needing updates with SHR and utilities that do not support ISPF-style enqueues, our approach has been to change the job step to invoke a front-end program that gets the required SPFEDIT enqueue, invokes the utility, and when the utility returns control drop the enqueue. That way the job may wait, but only for the time when someone else actually has the dataset enqueued for open for output. JC Ewing On 12/02/2009 09:42 AM, Don Leahy wrote: Good point. Our process is working by coincidence. Time to took for a better approach. Thanks. On Wed, Dec 2, 2009 at 05:23, Big Iron billlalo...@rocketmail.com wrote: I think that using a later copy step works because the time window involved is shorter and so collisions, two programs having the same PDS open for output with DISP=SHR, would be less likely but could still occur. I have seen that abend happen for link-edit steps. Using DISP=OLD will solve this problem since the job would no longer be updating a dataset allocated with DISP=SHR. Note that the elapsed time for the jobs will increase because the allocation will be held from the start of the job until the end of the step that allocates the dataset with DISP=OLD. Bill On Tue, 1 Dec 2009 12:04:48 -0700, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: A later step in the same job? Does this solve the issue because the copy uses different serialization than the actual creating of the DBRM member? I'll give it a shot. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 12/1/2009 at 11:58 AM, in message 6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com, Don Leahy don.le...@leacom.ca wrote: This is a perennial problem. Our local solution was to allocate DBRMLIB to a temporary data set. //DBRMLIB DD DSN=DBRMLB(MR),DISP=(,PASS), // UNIT=SYSDA,SPACE=(TRK,(15,5,5)), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160) A later step copies the DBRM to a permanent library. On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: For our conversion from VSE to z/OS we have a mass compile process that runs many compiles at the same time. This has been fine up until when we added DB2 compiles in to the mix. Now we are getting things like the following for every second or third compile: 11.02.22 JOB05118 IEC143I 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM 02) 30 An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is already open for output to the data set. The data set might be on the same system or on another system that is sharing the volume. Access was not serialized before the attempt to open the data set. I am guessing that job 2 is trying to add a member to SYS3.DSN910.DBRMLIB.DATA at the same time that job 1 is trying to do the same thing (though a different member). Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Why does the link-edit step seem to not have a similar issue? Is it just that the link-edit step completes so quickly that only one job has the PDS open at one time? Or does the link-edit (binder; whatever) have some special stuff that allows it do deal with this situation? Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 -- Joel C. Ewing, Fort Smith, AR jremoveccapsew...@acm.org -- 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: IEC143I 213-30
On Wed, 2 Dec 2009 12:51:15 -0700, Frank Swarbrick wrote: So perhaps a combination of the two is in order. Write to a temporary PDS during the translate and then use DISP=OLD on the copy from the temp PDS in to the actual PDS. Yet another frustating issue in going to z/OS. Oy. It's even worse than you've learned so far. If you use static (JCL DD DISP=OLD) allocation, the exclusive ENQ will be obtained at job initiation and persist through the last step that mentions the data set, regardless whether SHR or OLD. If you attempt dynamic allocation and the data set is in use, the allocation will fail unless you ask to wait for DSN, which will fail unless you're APF-authorized. -- 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: IEC143I 213-30
On Wed, 2 Dec 2009 15:21:03 -0500, Don Leahy wrote: Does IEBCOPY use the same enqueue strategy as the Binder? I believe IEBCOPY's strategy is, It's your foot and your gun ... Use DISP=OLD if you care. On Wed, Dec 2, 2009 at 14:29, Joel C. Ewing wrote: I believe the Binder uses ISPF-style enqueues to allow OPEN for output with SHR access without any problems. When needing updates with SHR and Historically, I believe it would be more proper to say that ISPF uses Linkage editor style ENQs. Binder ENQs on SYSIEWLP. ISPF, for RECFM=U ENQs on SYSIEWLP (and SPFEDIT?) For other RECFM only on SPFEDIT. utilities that do not support ISPF-style enqueues, our approach has been to change the job step to invoke a front-end program that gets the required SPFEDIT enqueue, invokes the utility, and when the utility returns control drop the enqueue. That way the job may wait, but only for the time when someone else actually has the dataset enqueued for open for output. How practical is it to use ISPF itself as the front-end program? I'm trying to envision ATTACHing the utility from inside ISPF and redirecting the output to LMPUT/LMCOPY. But that's UNIX-think; I can't see how to make it work in the z/OS environment without a temporary data set. BTW, I tried: /bin/cp /some/file //'DATA.SET.NAME(MEMBER)' It gets an exclusive ENQ on SYSDSN 'DATA.SET.NAME'. That's probably CRTL or LE behavior. NFS server uses ISPF-style ENQ and generates ISPF-style timestamps in the directory (but wrong during leap years), but I don't believe it runs ISPF proper. -- 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: IEC143I 213-30
On 12/1/2009 at 2:46 PM, in message 20091202171512.5d106f58...@smtp.patriot.net, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 4b14fd2e.6f0f.008...@efirstbank.com, on 12/01/2009 at 11:25 AM, Frank Swarbrick frank.swarbr...@efirstbank.com said: Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Yes. Why does the link-edit step seem to not have a similar issue? It does an exclusive RESERVE prior to the OPEN. Thanks. Would be nice if DB2 did this as well. Oh well. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
2009/12/2 Paul Gilmartin paulgboul...@aim.com: BTW, I tried: /bin/cp /some/file //'DATA.SET.NAME(MEMBER)' It gets an exclusive ENQ on SYSDSN 'DATA.SET.NAME'. That's probably CRTL or LE behavior. Um, isn't that just a side effect of the DYNALLOC it doubtless does for the dataset? If you don't want that ENQ, you have to be APF authorized, iirc. NFS server uses ISPF-style ENQ and generates ISPF-style timestamps in the directory (but wrong during leap years), but I don't believe it runs ISPF proper. No authorization needed to ENQ on the ISPF name. 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: IEC143I 213-30
At 15:33 -0600 on 12/02/2009, Paul Gilmartin wrote about Re: IEC143I 213-30: It's even worse than you've learned so far. If you use static (JCL DD DISP=OLD) allocation, the exclusive ENQ will be obtained at job initiation and persist through the last step that mentions the data set, regardless whether SHR or OLD. This is because the ENQ support has no way of altering a owned EXCLUSIVE ENQ to a SHARED one (you can only [try to] change from SHARED to EXCLUSIVE). It would be easy to do since all that is needed is to put the share request at the top of the waiting queue and do the DEQ processing. The task now has a SHARED ENQ and all the tasks waiting for the Exclusive ENQ to get released would fire off. With that capability Job Initiation would be able to issue an early DISP=OLD DEQ in lieu of its current need to wait for the last step referencing the dataset. -- 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
IEC143I 213-30
For our conversion from VSE to z/OS we have a mass compile process that runs many compiles at the same time. This has been fine up until when we added DB2 compiles in to the mix. Now we are getting things like the following for every second or third compile: 11.02.22 JOB05118 IEC143I 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM02) 30 An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is already open for output to the data set. The data set might be on the same system or on another system that is sharing the volume. Access was not serialized before the attempt to open the data set. I am guessing that job 2 is trying to add a member to SYS3.DSN910.DBRMLIB.DATA at the same time that job 1 is trying to do the same thing (though a different member). Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Why does the link-edit step seem to not have a similar issue? Is it just that the link-edit step completes so quickly that only one job has the PDS open at one time? Or does the link-edit (binder; whatever) have some special stuff that allows it do deal with this situation? Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
Make your DBRM lib PDS-E, and that problem goes away. Linkedit issues a GRS enqueue SYSIEWLP to serialize the updates. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Tuesday, December 01, 2009 1:26 PM To: IBM-MAIN@bama.ua.edu Subject: IEC143I 213-30 For our conversion from VSE to z/OS we have a mass compile process that runs many compiles at the same time. This has been fine up until when we added DB2 compiles in to the mix. Now we are getting things like the following for every second or third compile: 11.02.22 JOB05118 IEC143I 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA( EXAM02) 30 An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is already open for output to the data set. The data set might be on the same system or on another system that is sharing the volume. Access was not serialized before the attempt to open the data set. I am guessing that job 2 is trying to add a member to SYS3.DSN910.DBRMLIB.DATA at the same time that job 1 is trying to do the same thing (though a different member). Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Why does the link-edit step seem to not have a similar issue? Is it just that the link-edit step completes so quickly that only one job has the PDS open at one time? Or does the link-edit (binder; whatever) have some special stuff that allows it do deal with this situation? Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: IEC143I 213-30
This is a perennial problem. Our local solution was to allocate DBRMLIB to a temporary data set. //DBRMLIB DD DSN=DBRMLB(MR),DISP=(,PASS), // UNIT=SYSDA,SPACE=(TRK,(15,5,5)), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160) A later step copies the DBRM to a permanent library. On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: For our conversion from VSE to z/OS we have a mass compile process that runs many compiles at the same time. This has been fine up until when we added DB2 compiles in to the mix. Now we are getting things like the following for every second or third compile: 11.02.22 JOB05118 IEC143I 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM02) 30 An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is already open for output to the data set. The data set might be on the same system or on another system that is sharing the volume. Access was not serialized before the attempt to open the data set. I am guessing that job 2 is trying to add a member to SYS3.DSN910.DBRMLIB.DATA at the same time that job 1 is trying to do the same thing (though a different member). Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Why does the link-edit step seem to not have a similar issue? Is it just that the link-edit step completes so quickly that only one job has the PDS open at one time? Or does the link-edit (binder; whatever) have some special stuff that allows it do deal with this situation? Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
Wouldn't that be nice... We aren't in a Sysplex, but we do use GRS for shared DASD, so PDSEs are a no go. (We've tried. Too many problems.) Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 12/1/2009 at 11:27 AM, in message a90766b5039c59409110c92d47216f59044cc...@s1flokydce2k322.dm0001.info53.com, Jousma, David david.jou...@53.com wrote: Make your DBRM lib PDS-E, and that problem goes away. Linkedit issues a GRS enqueue SYSIEWLP to serialize the updates. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Tuesday, December 01, 2009 1:26 PM To: IBM-MAIN@bama.ua.edu Subject: IEC143I 213-30 For our conversion from VSE to z/OS we have a mass compile process that runs many compiles at the same time. This has been fine up until when we added DB2 compiles in to the mix. Now we are getting things like the following for every second or third compile: 11.02.22 JOB05118 IEC143I 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA( EXAM02) 30 An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is already open for output to the data set. The data set might be on the same system or on another system that is sharing the volume. Access was not serialized before the attempt to open the data set. I am guessing that job 2 is trying to add a member to SYS3.DSN910.DBRMLIB.DATA at the same time that job 1 is trying to do the same thing (though a different member). Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Why does the link-edit step seem to not have a similar issue? Is it just that the link-edit step completes so quickly that only one job has the PDS open at one time? Or does the link-edit (binder; whatever) have some special stuff that allows it do deal with this situation? Thanks, Frank The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
A later step in the same job? Does this solve the issue because the copy uses different serialization than the actual creating of the DBRM member? I'll give it a shot. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 12/1/2009 at 11:58 AM, in message 6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com, Don Leahy don.le...@leacom.ca wrote: This is a perennial problem. Our local solution was to allocate DBRMLIB to a temporary data set. //DBRMLIB DD DSN=DBRMLB(MR),DISP=(,PASS), // UNIT=SYSDA,SPACE=(TRK,(15,5,5)), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160) A later step copies the DBRM to a permanent library. On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: For our conversion from VSE to z/OS we have a mass compile process that runs many compiles at the same time. This has been fine up until when we added DB2 compiles in to the mix. Now we are getting things like the following for every second or third compile: 11.02.22 JOB05118 IEC143I 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM 02) 30 An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is already open for output to the data set. The data set might be on the same system or on another system that is sharing the volume. Access was not serialized before the attempt to open the data set. I am guessing that job 2 is trying to add a member to SYS3.DSN910.DBRMLIB.DATA at the same time that job 1 is trying to do the same thing (though a different member). Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Why does the link-edit step seem to not have a similar issue? Is it just that the link-edit step completes so quickly that only one job has the PDS open at one time? Or does the link-edit (binder; whatever) have some special stuff that allows it do deal with this situation? Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
I am not sure why it works, we did not do any extensive testing but I do know that we haven't had any problems for a long time. We use ICEGENER to do the copying. Caveat: we rarely have more than 2 compiles running at the same time (small shop), so your mileage may vary. On Tue, Dec 1, 2009 at 14:04, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: A later step in the same job? Does this solve the issue because the copy uses different serialization than the actual creating of the DBRM member? I'll give it a shot. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 12/1/2009 at 11:58 AM, in message 6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com, Don Leahy don.le...@leacom.ca wrote: This is a perennial problem. Our local solution was to allocate DBRMLIB to a temporary data set. //DBRMLIB DD DSN=DBRMLB(MR),DISP=(,PASS), // UNIT=SYSDA,SPACE=(TRK,(15,5,5)), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160) A later step copies the DBRM to a permanent library. On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: For our conversion from VSE to z/OS we have a mass compile process that runs many compiles at the same time. This has been fine up until when we added DB2 compiles in to the mix. Now we are getting things like the following for every second or third compile: 11.02.22 JOB05118 IEC143I 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM 02) 30 An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is already open for output to the data set. The data set might be on the same system or on another system that is sharing the volume. Access was not serialized before the attempt to open the data set. I am guessing that job 2 is trying to add a member to SYS3.DSN910.DBRMLIB.DATA at the same time that job 1 is trying to do the same thing (though a different member). Obviously one solution is to single thread the compiles. But I'd rather not if I don't have to. Any other solutions? If I changed to DISP=OLD would this eliminate the issue by making job 2 wait until job 1 is done with the PDS? Why does the link-edit step seem to not have a similar issue? Is it just that the link-edit step completes so quickly that only one job has the PDS open at one time? Or does the link-edit (binder; whatever) have some special stuff that allows it do deal with this situation? Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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: IEC143I 213-30
On Tue, 1 Dec 2009 14:46:09 -0500, Don Leahy wrote: I am not sure why it works, we did not do any extensive testing but I do know that we haven't had any problems for a long time. We use ICEGENER to do the copying. Caveat: we rarely have more than 2 compiles running at the same time (small shop), so your mileage may vary. Sounds risky to me. A safe technique I use is LMCOPY (but ICEGENER may be smart enough to use the same ENQ as ISPF). Or, allocate DRMLIB to a Unix directory. On Tue, Dec 1, 2009 at 14:04, Frank Swarbrick wrote: A later step in the same job? Does this solve the issue because the copy uses different serialization than the actual creating of the DBRM member? On 12/1/2009 at 11:58 AM, in message 6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com, Don Leahy wrote: This is a perennial problem. Our local solution was to allocate DBRMLIB to a temporary data set. //DBRMLIB DD DSN=DBRMLB(MR),DISP=(,PASS), // UNIT=SYSDA,SPACE=(TRK,(15,5,5)), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160) A later step copies the DBRM to a permanent library. -- 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
