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 <shai.h...@gmail.com> 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 <mike.a.sch...@gmail.com>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 <shai.h...@gmail.com> wrote: >> > ---------- Forwarded message ---------- >> > From: Shai Hess <mfnetd...@mfnetdisk.com> >> > Date: Sun, Jul 8, 2012 at 8:08 PM >> > Subject: New code MFNetDIsk and ISPF 3.4 and file deletes >> > To: shai.h...@gmail.com >> > >> > >> > ** >> > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > > -- > Thank. > God bless you, > Shai > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
