cook@bdofed.UUCP (b) (07/27/89)
This article probably constitutes misuse of this news group (apologies) but it is the only forum of IBM systems programmers that I have access to. Is there a more appropriate news group that perhaps I am not getting in my feed? On to the subject at hand. I am a systems programmer responsible for a 4381 running MVS/SP and JES2 1.3.6 . For a long time we have been experiencing a problem with JES2 that no one has been able to explain or solve. 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". The only way we know of to straighten this problem out is to stop JES2 and hot start it. This is not a great thing to be doing in the middle of the day!! ISC have carried this problem all the way to the JES2 development team without any success. Does anyone have any ideas or suggestions? Here are some details that may aid the diagnosis: We run the following OEM products; ACF2, TLMS and FDR/ABR (being replaced by DFHSM!). The JES2 proc is; //JES2 PROC MEMBER=JES2PARM,ALTMEM=JES2PARM //IEFPROC EXEC PGM=HASJES20,DPRTY=(15,15),TIME=1440,PERFORM=9 //PROC00 DD DSN=SYS1.EBE.PROCLIB,DISP=SHR,DCB=BLKSIZE=20000 // DD DSN=SYS1.PROCLIB,DISP=SHR // DD DSN=OKPROD.PROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 // DD DSN=OKPROD.MSPROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 // DD DSN=PROD.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE007 // DD DSN=TEST.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE005 //HASPPARM DD DSN=SYS1.JESPARMS(&MEMBER),DISP=SHR,FREE=CLOSE //ALTPARM DD DSN=SYS1.PARMLIB(&ALTMEM),DISP=SHR,FREE=CLOSE //HASPLIST DD DDNAME=IEFRDER All of the proclibs are PRIMARY allocation only. Their blocksizes are (in order) 3120, 3120, 3120, 3120, 6160, 6160. Any help in this matter would be appreciated. Trevor Cook attcan!bdofed!cook (416) 394-7181
cook@bdofed.UUCP (b) (07/27/89)
This article probably constitutes misuse of this news group (apologies) but it is the only forum of IBM systems programmers that I have access to. Is there a more appropriate news group that perhaps I am not getting in my feed? On to the subject at hand. I am a systems programmer responsible for a 4381 running MVS/SP and JES2 1.3.6 . For a long time we have been experiencing a problem with JES2 that no one has been able to explain or solve. 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". The only way we know of to straighten this problem out is to stop JES2 and hot start it. This is not a great thing to be doing in the middle of the day!! ISC have carried this problem all the way to the JES2 development team without any success. Does anyone have any ideas or suggestions? Here are some details that may aid the diagnosis: We run the following OEM products; ACF2, TLMS and FDR/ABR (being replaced by DFHSM!). The JES2 proc is; //JES2 PROC MEMBER=JES2PARM,ALTMEM=JES2PARM //IEFPROC EXEC PGM=HASJES20,DPRTY=(15,15),TIME=1440,PERFORM=9 //PROC00 DD DSN=SYS1.EBE.PROCLIB,DISP=SHR,DCB=BLKSIZE=20000 // DD DSN=SYS1.PROCLIB,DISP=SHR // DD DSN=OKPROD.PROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 // DD DSN=OKPROD.MSPROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 // DD DSN=PROD.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE007 // DD DSN=TEST.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE005 //HASPPARM DD DSN=SYS1.JESPARMS(&MEMBER),DISP=SHR,FREE=CLOSE //ALTPARM DD DSN=SYS1.PARMLIB(&ALTMEM),DISP=SHR,FREE=CLOSE //HASPLIST DD DDNAME=IEFRDER All of the proclibs are PRIMARY allocation only. Their blocksizes are (in order) 3120, 3120, 3120, 3120, 6160, 6160. Any help in this matter would be appreciated. Trevor Cook attcan!bdofed!cook (416) 394-7181
" Maynard) (07/28/89)
In article <129@bdofed.UUCP> cook@bdofed.UUCP (b) 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". This looks like an extent being added to the library in the middle... except that your primary allocation only rules that out. >The only way we know of to straighten this problem out is to stop JES2 and >hot start it. This is not a great thing to be doing in the middle of the >day!! ISC have carried this problem all the way to the JES2 development team >without any success. Does anyone have any ideas or suggestions? Actually, issuing $PJES2,ABEND and then restarting it, isn't that disruptive if your JES2 starts up reasonably quickly. The only effect that users will notice is that their SUBMITs and LOGONswill take a bit longer. >//PROC00 DD DSN=SYS1.EBE.PROCLIB,DISP=SHR,DCB=BLKSIZE=20000 >// DD DSN=SYS1.PROCLIB,DISP=SHR >// DD DSN=OKPROD.PROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 >// DD DSN=OKPROD.MSPROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 >// DD DSN=PROD.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE007 >// DD DSN=TEST.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE005 >All of the proclibs are PRIMARY allocation only. Their blocksizes are (in >order) 3120, 3120, 3120, 3120, 6160, 6160. Looks like you've done everything right here...what's in SYS1.EBE.PROCLIB? Hopefully, not much. You might run the BLKSIZE parameter on the first card up to 20480, just to take better advantage of the pages allocated to the buffers, but that's a nit. Good question. Has me stumped. I guess you've APARed it... -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- internet: jay@splut.conmicro.com | "He's T*d, Jim."-Richard "Bones" Sexton
' Maynard) (07/28/89)
In article <129@bdofed.UUCP> cook@bdofed.UUCP (b) 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". This looks like an extent being added to the library in the middle... except that your primary allocation only rules that out. >The only way we know of to straighten this problem out is to stop JES2 and >hot start it. This is not a great thing to be doing in the middle of the >day!! ISC have carried this problem all the way to the JES2 development team >without any success. Does anyone have any ideas or suggestions? Actually, issuing $PJES2,ABEND and then restarting it, isn't that disruptive if your JES2 starts up reasonably quickly. The only effect that users will notice is that their SUBMITs and LOGONswill take a bit longer. >//PROC00 DD DSN=SYS1.EBE.PROCLIB,DISP=SHR,DCB=BLKSIZE=20000 >// DD DSN=SYS1.PROCLIB,DISP=SHR >// DD DSN=OKPROD.PROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 >// DD DSN=OKPROD.MSPROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 >// DD DSN=PROD.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE007 >// DD DSN=TEST.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE005 >All of the proclibs are PRIMARY allocation only. Their blocksizes are (in >order) 3120, 3120, 3120, 3120, 6160, 6160. Looks like you've done everything right here...what's in SYS1.EBE.PROCLIB? Hopefully, not much. You might run the BLKSIZE parameter on the first card up to 20480, just to take better advantage of the pages allocated to the buffers, but that's a nit. Good question. Has me stumped. I guess you've APARed it... -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- internet: jay@splut.conmicro.com | "He's T*d, Jim."-Richard "Bones" Sexton
jbeard@quintus.UUCP (Jeff Beard) (07/28/89)
Last time I looked, concatenated data sets should be of the same BLOCKSIZE, OR equal LRECL with the largest BLOCKSIZE being first in the list of concatenation.
X040BK@TAMVM1.BITNET (Butch Kemper) (07/28/89)
The problem is caused by the dataset going into a new extent that wasn't
present when the datasets were opened. The circumvention is to:
1. Allocate the datasets so there are only primary allocations
and no secondary allocations.
2. When the dataset get full, quiesce JES2 so that no jobs are
going through JCL conversion and then compress the proclib.
Butch
Computing Services Center X040BK@TAMVM1.BITNET
Texas A&M University X040BK@TAMVM1.TAMU.EDU
College Station, Tx 77843-3142 409/845-4215jcmorris@mbunix.mitre.org (Joseph C. Morris) (07/29/89)
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.
jcmorris@MBUNIX.MITRE.ORG ("Joseph C. Morris") (07/29/89)
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.
X040BK@TAMVM1.BITNET (Butch Kemper) (07/29/89)
I had some problems sending my original reply and I don't know if it
made it through. So here it is again:
The problem is caused by the dataset going into a new extent that wasn't
present when the datasets were opened. The circumvention is to:
1. Allocate the datasets so there are only primary allocations
and no secondary allocations.
2. When the dataset get full, quiesce JES2 so that no jobs are
going through JCL conversion and then compress the proclib.
Butch
Computing Services Center X040BK@TAMVM1.BITNET
Texas A&M University X040BK@TAMVM1.TAMU.EDU
College Station, Tx 77843-3142 409/845-4215bdb@becker.UUCP (Bruce Becker) (07/30/89)
In article <8907271812.AA19235@jade.berkeley.edu> b <mailrus!jarvis.csri.toronto.edu!utgpu!attcan!bdofed!cook@TUT.CIS.OHIO-ST> writes: | [...] |The JES2 proc is; | |//JES2 PROC MEMBER=JES2PARM,ALTMEM=JES2PARM |//IEFPROC EXEC PGM=HASJES20,DPRTY=(15,15),TIME=1440,PERFORM=9 |//PROC00 DD DSN=SYS1.EBE.PROCLIB,DISP=SHR,DCB=BLKSIZE=20000 |// DD DSN=SYS1.PROCLIB,DISP=SHR |// DD DSN=OKPROD.PROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 |// DD DSN=OKPROD.MSPROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 |// DD DSN=PROD.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE007 |// DD DSN=TEST.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE005 | [...] |All of the proclibs are PRIMARY allocation only. Their blocksizes are (in |order) 3120, 3120, 3120, 3120, 6160, 6160. I think you should be saying "DCB=BUFLEN=20000" on the //PROC00 line. Changing the BLKSIZE will indeed cause i/o errors since the read will expect 20000 bytes but will only get 3120 whenever a SYS1.EBE.PROCLIB block is accessed. Cheers, -- __ Bruce Becker Toronto, Ont. w \cc/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/\/-e BitNet: BECKER@HUMBER.BITNET _< >_ "Mistah Kaldis, he T*d" - A Popsicle Now
bdb@becker.UUCP (Bruce Becker) (07/30/89)
In article <8907271812.AA19235@jade.berkeley.edu> b <mailrus!jarvis.csri.toronto.edu!utgpu!attcan!bdofed!cook@TUT.CIS.OHIO-S writes: | [...] |The JES2 proc is; | |//JES2 PROC MEMBER=JES2PARM,ALTMEM=JES2PARM |//IEFPROC EXEC PGM=HASJES20,DPRTY=(15,15),TIME=1440,PERFORM=9 |//PROC00 DD DSN=SYS1.EBE.PROCLIB,DISP=SHR,DCB=BLKSIZE=20000 |// DD DSN=SYS1.PROCLIB,DISP=SHR |// DD DSN=OKPROD.PROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 |// DD DSN=OKPROD.MSPROC,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE013 |// DD DSN=PROD.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE007 |// DD DSN=TEST.PROCLIB,DISP=SHR,UNIT=SYSDA,VOL=SER=EBE005 | [...] |All of the proclibs are PRIMARY allocation only. Their blocksizes are (in |order) 3120, 3120, 3120, 3120, 6160, 6160. I think you should be saying "DCB=BUFLEN=20000" on the //PROC00 line. Changing the BLKSIZE will indeed cause i/o errors since the read will expect 20000 bytes but will only get 3120 whenever a SYS1.EBE.PROCLIB block is accessed. Cheers, -- __ Bruce Becker Toronto, Ont. w \cc/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/\/-e BitNet: BECKER@HUMBER.BITNET _< >_ "Mistah Kaldis, he T*d" - A Popsicle Now
LDW@USCMVSA.BITNET (Leonard D Woren) (07/31/89)
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
<LDW@USCMVSA.BITNET> <LDW@MVSA.USC.EDU>
University of Southern CaliforniaLDW@USCMVSA.BITNET (Leonard D Woren) (07/31/89)
My brain was out of order when I sent my previous reply. Here's what
it should have said:
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 your namejbeard@quintus.UUCP (Jeff Beard) (07/31/89)
>If SPACE is on the DD, the secondary allocation in the DSCB is ignored, >regardless of whether it's 0 I'm not sure of this with current levels of JES/ MVS, however, back with MVS/SP an prior systems, DSCB with zero secondary space can NEVER be extended. Original DD allocations like SPACE=(Quantum,(Pri,Sec,1)), allow subsequent JCL overrides of SPACE=(Quantum,(Pri,Sec,NN)), while DSCBs with secondarys of zero will ignore the JCL override attempt. I concur that the symptoms match that of a new extent being taken when updated, and not seen when referenced. This is a behavior that reflects the underpinning OS/360 PCP/MFT/MVT origins of the system.
jbeard@quintus.UUCP (Jeff Beard) (07/31/89)
>If SPACE is on the DD, the secondary allocation in the DSCB is ignored, >regardless of whether it's 0 I'm not sure of this with current levels of JES/ MVS, however, back with MVS/SP an prior systems, DSCB with zero secondary space can NEVER be extended. Original DD allocations like SPACE=(Quantum,(Pri,Sec,1)), allow subsequent JCL overrides of SPACE=(Quantum,(Pri,Sec,NN)), while DSCBs with secondarys of zero will ignore the JCL override attempt. I concur that the symptoms match that of a new extent being taken when updated, and not seen when referenced. This is a behavior that reflects the underpinning OS/360 PCP/MFT/MVT origins of the system.
dandrews@rtmvax.UUCP (David Andrews) (08/05/89)
From article <2792@splut.conmicro.com>, by jay@splut.conmicro.com (Jay "you
ignorant splut!" Maynard):
> Actually, issuing $PJES2,ABEND and then restarting it, isn't that
> disruptive if your JES2 starts up reasonably quickly. The only effect
> that users will notice is that their SUBMITs and LOGONswill take a bit
> longer.
Unfortunately, there are some products (e.g. INTERACT) which do cross-memory
stuff into the JES2 address space and get really confused when JES2 bounces.
You have to bounce INTERACT, too.
And just WHERE in the Usenet is there an MVS newsgroup?
- Davedandrews@rtmvax.UUCP (David Andrews) (08/05/89)
From article <2792@splut.conmicro.com>, by jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard): > Actually, issuing $PJES2,ABEND and then restarting it, isn't that > disruptive if your JES2 starts up reasonably quickly. The only effect > that users will notice is that their SUBMITs and LOGONswill take a bit > longer. Unfortunately, there are some products (e.g. INTERACT) which do cross-memory stuff into the JES2 address space and get really confused when JES2 bounces. You have to bounce INTERACT, too. And just WHERE in the Usenet is there an MVS newsgroup? - Dave