Re: IFG0EX0B to increase secondary allocation
I want to say - Sri - Thank You for your above and beyond help on ALL the list’s. Your mentor would be very proud indeed! Big shoes to fill and you have done an amazing job! Best Regards, Doug Shupe Stay Safe >> On Jul 9, 2020, at 18:29, Sri h Kolusu wrote: > >> >>> But where did this undocumented flag that you're now setting come from > and how does it relate to JFCNWRIT? > > Steve, > > Looks like you skipped over "There's a long discussion of RDJFCB in > DFSMSdfp Advanced Services." > > If you read the "Reading and Modifying a Job File Control Block (RDJFCB > Macro)" section in the DFSMSdfp Advanced Services manual you would find the > recommendation. > > Here is the link for V2R3 pdf > > https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc236861/$file/idas300_v2r3.pdf > > The Tip is documented on Page 255 under the "Reading and Modifying a Job > File Control Block (RDJFCB Macro)" section > > OP wanted to get his IFG0EX0B exit working and I just helped to debug and > make it work. > > Thanks, > Kolusu > DFSORT Development > IBM Corporation > > IBM Mainframe Discussion List wrote on > 07/09/2020 02:21:03 PM: > >> From: Steve Smith >> To: IBM-MAIN@LISTSERV.UA.EDU >> Date: 07/09/2020 02:21 PM >> Subject: [EXTERNAL] Re: IFG0EX0B to increase secondary allocation >> Sent by: IBM Mainframe Discussion List >> >> I don't follow. I understand the JFCNWRIT flag, as it's documented. I >> don't know why you would set it in the first place if you don't have a > good >> reason for it. But where did this undocumented flag that you're now >> setting come from and how does it relate to JFCNWRIT? >> >> sas >> >> >>> On Thu, Jul 9, 2020 at 1:40 PM PINION, RICHARD W. >> >>> wrote: >>> I'd like to take this opportunity to thank Sri Kolusu, of IBM, for > taking >>> the time >>> to help with the open exit IFG0EX0B, in regards to IEBGENER/ICEGENER > and >>> DF/SORT. >>> He has spent the last few days researching and testing. >>> He came up with a solution, and the exit is now working with >>> IEBGENER/ICEGENER >>> and DF/SORT. Below is the solution he came up with. >>> "And the reason as to why the increased secondary quantity in the 3.4 > is >>> because you haven't forced the modified JFCB writeback into the DSCB >>> There's a long discussion of RDJFCB in DFSMSdfp Advanced Services. >>> Tip: If you set the bit JFCNWRIT in the JFCBTSDM field to 1 before you >>> issue the OPEN macro instruction, the JFCB is not written back at the >>> conclusion of open processing. OPEN TYPE=J normally moves your > program's >>> modified copy of the JFCB, to replace the system copy. To ensure that > this >>> move is done, your program must set bit zero of the JFCBMASK+4 field to > 1. >>> IBM recommends not setting on JFCNWRIT. >>> So I would add the flag to set jfcbmask+4 bit 0 to 1 when the secondary >>> gets modified. >>> Here is the modified code at label STSQTY (in blue color) >>> STSQTY EQU * STORE SECONDARY QTY >>> STCM RODD,7,JFCBSQTY >>> OI JFCBMASK+4,X'80'REQUEST JFCB WRITEBACK >>> LA RINCODE,MODJFCB JFCB MODIFIED >>> RETSQTY EQU * RETURN FROM SQTY >>> BR RET RETURN " >>> Confidentiality notice: >>> This e-mail message, including any attachments, may contain legally >>> privileged and/or confidential information. If you are not the intended >>> recipient(s), or the employee or agent responsible for delivery of this >>> message to the intended recipient(s), you are hereby notified that any >>> dissemination, distribution, or copying of this e-mail message is > strictly >>> prohibited. If you have received this message in error, please > immediately >>> notify the sender and delete this e-mail message from your computer. >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IFG0EX0B to increase secondary allocation
Well, actually I have read that section, although some time ago. I am very surprised to see that Richard Pinion's post was a direct quote from there! Sorry for assuming it So I still have the same question, I just don't hope much for an answer, as it would presumably have to be answered by whoever wrote that part of the manual. That sentence about "must set bit zero of the JFCBMASK+4 field to 1" is a non-sequitur in the middle of the discussion of JFCNWRIT. Again, I'm familiar with JFCNWRIT (and the fact it has a negative name, which is bad form). I have programs that set that when I don't want write-back, and I leave it when I do. I must have overlooked that part about the random bit in JFCBMASK before, but it sure isn't explained. sas On Thu, Jul 9, 2020 at 6:29 PM Sri h Kolusu wrote: > >>But where did this undocumented flag that you're now setting come from > and how does it relate to JFCNWRIT? > > Steve, > > Looks like you skipped over "There's a long discussion of RDJFCB in > DFSMSdfp Advanced Services." > > If you read the "Reading and Modifying a Job File Control Block (RDJFCB > Macro)" section in the DFSMSdfp Advanced Services manual you would find the > recommendation. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IFG0EX0B to increase secondary allocation
>>But where did this undocumented flag that you're now setting come from and how does it relate to JFCNWRIT? Steve, Looks like you skipped over "There's a long discussion of RDJFCB in DFSMSdfp Advanced Services." If you read the "Reading and Modifying a Job File Control Block (RDJFCB Macro)" section in the DFSMSdfp Advanced Services manual you would find the recommendation. Here is the link for V2R3 pdf https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc236861/$file/idas300_v2r3.pdf The Tip is documented on Page 255 under the "Reading and Modifying a Job File Control Block (RDJFCB Macro)" section OP wanted to get his IFG0EX0B exit working and I just helped to debug and make it work. Thanks, Kolusu DFSORT Development IBM Corporation IBM Mainframe Discussion List wrote on 07/09/2020 02:21:03 PM: > From: Steve Smith > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 07/09/2020 02:21 PM > Subject: [EXTERNAL] Re: IFG0EX0B to increase secondary allocation > Sent by: IBM Mainframe Discussion List > > I don't follow. I understand the JFCNWRIT flag, as it's documented. I > don't know why you would set it in the first place if you don't have a good > reason for it. But where did this undocumented flag that you're now > setting come from and how does it relate to JFCNWRIT? > > sas > > > On Thu, Jul 9, 2020 at 1:40 PM PINION, RICHARD W. > wrote: > > > I'd like to take this opportunity to thank Sri Kolusu, of IBM, for taking > > the time > > to help with the open exit IFG0EX0B, in regards to IEBGENER/ICEGENER and > > DF/SORT. > > He has spent the last few days researching and testing. > > > > He came up with a solution, and the exit is now working with > > IEBGENER/ICEGENER > > and DF/SORT. Below is the solution he came up with. > > > > "And the reason as to why the increased secondary quantity in the 3.4 is > > because you haven't forced the modified JFCB writeback into the DSCB > > > > There's a long discussion of RDJFCB in DFSMSdfp Advanced Services. > > > > Tip: If you set the bit JFCNWRIT in the JFCBTSDM field to 1 before you > > issue the OPEN macro instruction, the JFCB is not written back at the > > conclusion of open processing. OPEN TYPE=J normally moves your program's > > modified copy of the JFCB, to replace the system copy. To ensure that this > > move is done, your program must set bit zero of the JFCBMASK+4 field to 1. > > IBM recommends not setting on JFCNWRIT. > > > > So I would add the flag to set jfcbmask+4 bit 0 to 1 when the secondary > > gets modified. > > > > Here is the modified code at label STSQTY (in blue color) > > > > STSQTY EQU * STORE SECONDARY QTY > >STCM RODD,7,JFCBSQTY > >OI JFCBMASK+4,X'80'REQUEST JFCB WRITEBACK > >LA RINCODE,MODJFCB JFCB MODIFIED > >RETSQTY EQU * RETURN FROM SQTY > >BR RET RETURN " > > > > Confidentiality notice: > > This e-mail message, including any attachments, may contain legally > > privileged and/or confidential information. If you are not the intended > > recipient(s), or the employee or agent responsible for delivery of this > > message to the intended recipient(s), you are hereby notified that any > > dissemination, distribution, or copying of this e-mail message is strictly > > prohibited. If you have received this message in error, please immediately > > notify the sender and delete this e-mail message from your computer. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IFG0EX0B to increase secondary allocation
That's what I got from Sri. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Smith Sent: Thursday, July 9, 2020 5:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IFG0EX0B to increase secondary allocation [External Email. Exercise caution when clicking links or opening attachments.] I don't follow. I understand the JFCNWRIT flag, as it's documented. I don't know why you would set it in the first place if you don't have a good reason for it. But where did this undocumented flag that you're now setting come from and how does it relate to JFCNWRIT? sas On Thu, Jul 9, 2020 at 1:40 PM PINION, RICHARD W. wrote: > I'd like to take this opportunity to thank Sri Kolusu, of IBM, for > taking the time to help with the open exit IFG0EX0B, in regards to > IEBGENER/ICEGENER and DF/SORT. > He has spent the last few days researching and testing. > > He came up with a solution, and the exit is now working with > IEBGENER/ICEGENER and DF/SORT. Below is the solution he came up with. > > "And the reason as to why the increased secondary quantity in the 3.4 > is because you haven't forced the modified JFCB writeback into the > DSCB > > There's a long discussion of RDJFCB in DFSMSdfp Advanced Services. > > Tip: If you set the bit JFCNWRIT in the JFCBTSDM field to 1 before you > issue the OPEN macro instruction, the JFCB is not written back at the > conclusion of open processing. OPEN TYPE=J normally moves your > program's modified copy of the JFCB, to replace the system copy. To > ensure that this move is done, your program must set bit zero of the > JFCBMASK+4 field to 1. > IBM recommends not setting on JFCNWRIT. > > So I would add the flag to set jfcbmask+4 bit 0 to 1 when the > secondary gets modified. > > Here is the modified code at label STSQTY (in blue color) > > STSQTY EQU * STORE SECONDARY QTY >STCM RODD,7,JFCBSQTY >OI JFCBMASK+4,X'80'REQUEST JFCB WRITEBACK >LA RINCODE,MODJFCB JFCB MODIFIED >RETSQTY EQU * RETURN FROM SQTY >BR RET RETURN " > > Confidentiality notice: > This e-mail message, including any attachments, may contain legally > privileged and/or confidential information. If you are not the > intended recipient(s), or the employee or agent responsible for > delivery of this message to the intended recipient(s), you are hereby > notified that any dissemination, distribution, or copying of this > e-mail message is strictly prohibited. If you have received this > message in error, please immediately notify the sender and delete this e-mail > message from your computer. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IFG0EX0B to increase secondary allocation
I don't follow. I understand the JFCNWRIT flag, as it's documented. I don't know why you would set it in the first place if you don't have a good reason for it. But where did this undocumented flag that you're now setting come from and how does it relate to JFCNWRIT? sas On Thu, Jul 9, 2020 at 1:40 PM PINION, RICHARD W. wrote: > I'd like to take this opportunity to thank Sri Kolusu, of IBM, for taking > the time > to help with the open exit IFG0EX0B, in regards to IEBGENER/ICEGENER and > DF/SORT. > He has spent the last few days researching and testing. > > He came up with a solution, and the exit is now working with > IEBGENER/ICEGENER > and DF/SORT. Below is the solution he came up with. > > "And the reason as to why the increased secondary quantity in the 3.4 is > because you haven't forced the modified JFCB writeback into the DSCB > > There's a long discussion of RDJFCB in DFSMSdfp Advanced Services. > > Tip: If you set the bit JFCNWRIT in the JFCBTSDM field to 1 before you > issue the OPEN macro instruction, the JFCB is not written back at the > conclusion of open processing. OPEN TYPE=J normally moves your program's > modified copy of the JFCB, to replace the system copy. To ensure that this > move is done, your program must set bit zero of the JFCBMASK+4 field to 1. > IBM recommends not setting on JFCNWRIT. > > So I would add the flag to set jfcbmask+4 bit 0 to 1 when the secondary > gets modified. > > Here is the modified code at label STSQTY (in blue color) > > STSQTY EQU * STORE SECONDARY QTY >STCM RODD,7,JFCBSQTY >OI JFCBMASK+4,X'80'REQUEST JFCB WRITEBACK >LA RINCODE,MODJFCB JFCB MODIFIED >RETSQTY EQU * RETURN FROM SQTY >BR RET RETURN " > > Confidentiality notice: > This e-mail message, including any attachments, may contain legally > privileged and/or confidential information. If you are not the intended > recipient(s), or the employee or agent responsible for delivery of this > message to the intended recipient(s), you are hereby notified that any > dissemination, distribution, or copying of this e-mail message is strictly > prohibited. If you have received this message in error, please immediately > notify the sender and delete this e-mail message from your computer. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IFG0EX0B to increase secondary allocation
I'd like to take this opportunity to thank Sri Kolusu, of IBM, for taking the time to help with the open exit IFG0EX0B, in regards to IEBGENER/ICEGENER and DF/SORT. He has spent the last few days researching and testing. He came up with a solution, and the exit is now working with IEBGENER/ICEGENER and DF/SORT. Below is the solution he came up with. "And the reason as to why the increased secondary quantity in the 3.4 is because you haven't forced the modified JFCB writeback into the DSCB There's a long discussion of RDJFCB in DFSMSdfp Advanced Services. Tip: If you set the bit JFCNWRIT in the JFCBTSDM field to 1 before you issue the OPEN macro instruction, the JFCB is not written back at the conclusion of open processing. OPEN TYPE=J normally moves your program's modified copy of the JFCB, to replace the system copy. To ensure that this move is done, your program must set bit zero of the JFCBMASK+4 field to 1. IBM recommends not setting on JFCNWRIT. So I would add the flag to set jfcbmask+4 bit 0 to 1 when the secondary gets modified. Here is the modified code at label STSQTY (in blue color) STSQTY EQU * STORE SECONDARY QTY STCM RODD,7,JFCBSQTY OI JFCBMASK+4,X'80'REQUEST JFCB WRITEBACK LA RINCODE,MODJFCB JFCB MODIFIED RETSQTY EQU * RETURN FROM SQTY BR RET RETURN " Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
