>>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 <[email protected]> wrote on 07/09/2020 02:21:03 PM: > From: Steve Smith <[email protected]> > To: [email protected] > Date: 07/09/2020 02:21 PM > Subject: [EXTERNAL] Re: IFG0EX0B to increase secondary allocation > Sent by: IBM Mainframe Discussion List <[email protected]> > > 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. <[email protected]> > 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 [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
