Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!USCMVSA.BITNET!LDW From: LDW@USCMVSA.BITNET (Leonard D Woren) Newsgroups: comp.protocols.ibm Subject: Re: Problem with JES2 proclibs Message-ID: <8907310402.AA11042@jade.berkeley.edu> Date: 31 Jul 89 03:57:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Leonard D Woren Organization: The Internet Lines: 30 I think a more appropriate list for this problem is JES2-L. To subscribe, send mail to LISTSERV@NDUVM1.BITNET with a message body of: sub JES2-L to LISTSERV@NDSUVM1.BITNET There are a lot of JES2 experts on that list. > Are you sure that there are no secondary allocations? The symptoms you > describe match what would occur if the replacement of a member caused the > library to go into secondary allocation. Since the DEB is built at OPEN > time (meaning JES startup) any extents created later will be beyond the > legal limits enforced by the DEB as seen by JES. This would be consistent > with your reported symptoms since they go away if you restart JES. > > You can test this by setting the secondary extent size (DS1SCALO, I think) > to zero; this will cause an abend of any task which runs past the end of > the primary allocation. Well, not quite. If a job has SPACE=(xxx,(..,nn)) on the DD statement, and another extent is needed, one of type xxx and size nn will be obtained. If SPACE is on the DD, the secondary allocation in the DSCB is ignored, regardless of whether it's 0. JES2 will close and re-open the proclib if you switch proclib dd's by submitting a job with /*JOBPARM P=PROCnn, where nn is different than the last one used by the converter. This is rather simpler than restarting JES2. Leonard D. Woren Senior MVS Systems Programmer University of Southern California