On Mon, 9 Dec 2013 13:54:16 -0700, Lizette Koehler <stars...@mindspring.com> wrote:
>Only if you can place the PROCLIB data set completely on the original TTRs. >I do not believe this has changed. > >You can use dynamic Proclibs (see $TPROCLIB) which are not bothered by the >same issues as the ones in the JCL of JES2 or Master JCL > >If the Proclib is in the JES2 startup JCL then JES2 reads all of the members >and places the TTRs in storage. Definitely not true. How would you ever add or change a PROC with the system up without bouncing JES2? Do you think something notifies JES2 of the change? If so, try a simple test by changing a PROC from another non sharing system (if you can). The new (updated) PROC will be found just fine. > If you move the proclib dataset, JES2 tries >to read the TTR location of the member of proclib and if it is not there you >get the JES2 I/O ERROR ON PROCLIB message. > The extents (DEB) of PROCLIB data set itself is the issue, not the TTR of the member(s). BTW, code was added a very long time ago to automatically close / reopen the PROCLIB after the HASPxxx I/O error message. The problem is that you can have many converter subtasks and they all must have the concatenation closed / opened. Hence the "PROC99" / flooding "trick" was born. Earlier I posted that I thought that "the trick" might not even work when a PROCLIB was re-allocated / renamed on the same volume. It's been a long time since I thought about this so I had to think about it a bit. There is nothing special about JES2 "keeping track of extents", the problem is just what I wrote above - there are potentially many converter subtasks to deal with and each one knows about the extents in the PROCxx concatenation. $DPCEDEF will tell you how many converter tasks you have. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ >You can refresh the proclib TTRs by opening and closing a different PROCxx >jcl statement in the JES2 Startup proc. > >Lizette > > > >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of R.S. >> Sent: Monday, December 09, 2013 12:48 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: JES2 Proclibs >> >> W dniu 2013-12-09 17:14, Lizette Koehler pisze: >> > Once JES2 is up, it has read the TTR information about the members in >> > PROCLIB and will not be bothered by the removal, compress or move of a >> > PROCLIB dataset. However, doing this could produce JES2 I/O ERROR >> > message reading the PROCLIB members. >> I dare to disagree. >> You can add/change/remove proclib members anytime you want. Proclib is >read at >> submit time. >> >> > But JES2 does not have an enqueue on the dataset after it is read into >> > memory >> No enqueue - that's true. >> >> I'm not sure about OP's question, but my faulty memory tells me it's just >matter of >> PDS delete/rename and creation. >> >> >> -- >> Radoslaw Skorupka >> Lodz, Poland >> >> >> > >---------------------------------------------------------------------- >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
