Especially when the VTOCIX is broken. This is real hardware without your software, so the bug still existed as of last year.
On Mon, Jul 9, 2012 at 12:55 AM, shai hess <[email protected]> wrote: > This error is timing error. > Chance are small for regular disks. > For many files delete in the time of DSLIST 3.4 your chance to failed is > high. > > > > On Mon, Jul 9, 2012 at 8:19 AM, Mike Schwab <[email protected]> wrote: > >> Yes. As recently as last year, we went to display the files on the >> full volume with TSO ISPF 3.4 and it hung. We were concerned on >> getting the problem volume fixed and not determining the error. >> >> On Sun, Jul 8, 2012 at 10:34 PM, shai hess <[email protected]> wrote: >> > HI, >> > After cancel the userid IBMUSER the DSLIST of the disk work fine. >> > In other words, the IO loop was DSLIST problem and not the index vtoc of >> > vtoc or any file inside the disk. >> > The solution is to change code in DSLIST which will verify that if the >> old >> > VIER index vtoc data was changed, then the DSLIST must end the DSLIST >> with >> > warning message or better to redo the DSLIST from the beginning until >> > success. If DSLIST redo will fail N times then it may be index vtoc error >> > and just send warning message and exit. >> > Sure you can not run in loop forever the IO chain of checking why record >> > DSCB1 become zero and expect miracle to return the file back to the disk. >> > >> > On Sun, Jul 8, 2012 at 10:09 PM, Mike Schwab <[email protected] >> >wrote: >> > >> >> Over the last 12 years, we have certain volumes with large number of >> >> small datasets that are frequently created and deleted. Sometimes the >> >> VTOC Index would get corrupted, all allocations to that group would >> >> get assigned to that volume, then all allocation would blow because >> >> that volume was full, and the LPAR would run slow. DASDMAP when run >> >> on that volume would all but hang the entire LPAR until you got the >> >> DASDMAP cancelled. We are running z/OS 1.11 and 1.13 and I know it >> >> last happened on z/OS 1.11 or 1.10. >> >> >> >> Did disable new, Migrate to other level 0 volumes, then the ICKDSF >> >> BUILDOS and ICKDSF BUILDIX to fix the index on that volume. >> >> >> >> On Sun, Jul 8, 2012 at 12:14 PM, shai hess <[email protected]> wrote: >> >> > ---------- Forwarded message ---------- >> >> > From: Shai Hess <[email protected]> >> >> > Date: Sun, Jul 8, 2012 at 8:08 PM >> >> > Subject: New code MFNetDIsk and ISPF 3.4 and file deletes >> >> > To: [email protected] >> >> > >> >> > >> >> > ** >> >> > HI, >> >> > >> >> <deleted> >> >> > I attach case which was very interesting to me and it may be IBM bug >> >> or >> >> > maybe this was IBM solution to deal with the problem. >> >> > >> >> > The case: >> >> > I run few jobs (CHK4K) which run on device 300 volser MPC000 which is >> >> > MFNetDisk emulated 3390 device. >> >> > The jobs created temporary files and start to create many IO to this >> >> > device. >> >> > Then I run ISPF 3.4 DSLIST to display the content of the disk 300 >> >> (MPC000). >> >> > Before the DSLIST ended, I cancel the jobs quickly and I find out >> that >> >> > the DSLIST run in loop using 3 IO chain endless. >> >> > So, I start GTF and I find out the reason. >> >> > The user is IBMUSER which run ISPF 3.4 DSLIST with VOLSER parameter >> >> MPC000. >> >> > The GTF shows that the DSLIST check if the disk support index vtoc >> if >> >> yes >> >> > it read ( IO CHAIN 1) the VIER record from the index vtoc which >> contained >> >> > all the DSN in the disk. and it use it until the end of the DSLIST. >> >> > >> >> > As you can see 2 temporary files SYS12390.xx( IO CHAIN 1) exists in >> the >> >> > disk which were created by CHK4K. >> >> > The CCHHR of DSCB1 of the SYS0 files from the VIER are 0001-0000-0E >> and >> >> > 0001-0000-0F. >> >> > >> >> > The VIER in our index vtoc is in CC-HH-R=0001-000A-05. >> >> > >> >> > After canceling the jobs CHK4K, the VIER block was updated. The 2 >> >> temporary >> >> > files (IO CHAIN 2) was deleted from the VIER. >> >> > Also the VTOC update the dscb 1 of the 2 files in the VTOC to all >> zeros >> >> (I >> >> > did not add it) and update more index vtoc other blocks (like free >> >> space). >> >> > >> >> > DSLIST ran by IBMUSER eventually read the VIER and find out the >> SYS012390 >> >> > is not exist anymore but it was exist before when DSLIST start to run >> and >> >> > keep the VIER. This is good action because it verify if something >> >> changed. >> >> > So it try to read the DSCB1 with the CCHHR from the old VIER record >> which >> >> > was read before the SYS012390 was deleted (CCHHR=1-0-E and 1-0-F). >> >> > The bug is that DSLIST read the VIER and if it find that the SYS0 >> files >> >> are >> >> > not exist it must return indication that files was changed or >> whatever. >> >> > But DSLIST start to run in uncotroled loop the IO CHAIN of reading >> the >> >> > DSCB4 from the vtoc, verify that the index vtoc active. If it active >> >> > it read the VIER and verify that SYS0 is there. If it is there or not >> >> there >> >> > it read the LOCATION of DSCB1 of the SYS0 and find that it is empty >> and >> >> > contained all zeros. >> >> > When it find out that DSCB1 zero it run again the same records which >> is >> >> > read DSCB4, READ VIER, READ the DSCB1 and it continue forever until I >> >> > canel my userid. >> >> > So, I checked it without index vtoc and it run OK. Why, because in >> this >> >> > case it read the DSCB1 only for DSLIST and it does not contained the >> VIER >> >> > of all the files and its DSCB1 CCHHR. >> >> > >> >> > DSLIST run without reserved or without ENQ to VTOC (DSLIST is heavy >> >> utility >> >> > so it run without ENQ or RESERVE) so this can happen. >> >> > Maybe this problem was fixed by IBM but it was intersthing to me. I >> test >> >> it >> >> > with ZOS 1.10 with the help of one of my user. >> >> <deleted> >> >> -- >> >> Mike A Schwab, Springfield IL USA >> >> Where do Forest Rangers go to get away from it all? >> >> >> >> ---------------------------------------------------------------------- >> >> For IBM-MAIN subscribe / signoff / archive access instructions, >> >> send email to [email protected] with the message: INFO IBM-MAIN >> >> >> > >> > >> > >> > -- >> > Thank. >> > God bless you, >> > Shai >> > >> > ---------------------------------------------------------------------- >> > For IBM-MAIN subscribe / signoff / archive access instructions, >> > send email to [email protected] with the message: INFO IBM-MAIN >> >> >> >> -- >> Mike A Schwab, Springfield IL USA >> Where do Forest Rangers go to get away from it all? >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > > > -- > Thank. > God bless you, > Shai > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
