Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!ucbvax!MBUNIX.MITRE.ORG!jcmorris
From: jcmorris@MBUNIX.MITRE.ORG ("Joseph C. Morris")
Newsgroups: comp.protocols.ibm
Subject: Re: Problem with JES2 proclibs
Message-ID: <8907310120.AA10274@jade.berkeley.edu>
Date: 28 Jul 89 20:37:57 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: "Joseph C. Morris" <jcmorris@MBUNIX.MITRE.ORG>
Organization: The Internet
Lines: 22

In a recent article cook@bdofed writes:
>
>       Occasionally when a proc has been updated in or added to one of the
>proclibs, batch jobs encounter problems accessing the proc. The job either
>gets the old copy of the proc, or, in the case of a new proc, gets the error
>message "I/O ERROR READING PROCLIB".

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.  The
existence of the secondary extents might be masked if you have a routine
degassing procedure which releases vacated secondary extents.

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.

It's been a few years since I've worked with MVS, but I do recall having the
same symptoms as you are seeing.  Good luck.