Re: S213 Abend Backing Up 530RES Using z/OS FDR
On Friday, 02/01/2008 at 02:03 EST, Chip Davis [EMAIL PROTECTED] wrote: Oh man, I *HATE* it when that happens... :-) Dennis, I commend your courage and candor. We've all been there, and sometimes managed to slink away unnoticed with an only slightly flattened forehead. Just think of all the valuable insight we all gained about VM VTOC records from your problem... ;- And on the positive side, it had an effect on some designs we have on the drawing board; something that almost slipped by unnoticed. My thanks to Dennis for preventing some future CP abends! (You all owe Dennis an adult beverage.) Alan Altmark z/VM Development IBM Endicott
Re: S213 Abend Backing Up 530RES Using z/OS FDR
I thought I'd provide an update and closure to this S213 abend issue. The solution was actually pretty embarrassing. The solution was to vary the device offline/online to the correct z/OS system. I had recognized the need to vary the device offline/online before I even solicited input from the community. However, my backup job was redirecte d to a different z/OS system from the one where the varies occurred. So, there was no problem with the z/VM sysres volume which was built by t he installation process. Probable user error. Thanks to all of you for your input. Dennis On Thu, 17 Jan 2008 00:28:09 -0600, Dennis Schaffer [EMAIL PROTECTED] wrote: Hi, I'm installing z/VM (v5.3) in a previously z/OS-only shop. Because ther e is no existing VM, I'm doing a first-level installation and I'm also using the FTP server method. The installation, while slow, has completed successf ully and I'm able to IPL the newly-installed system. Thanks, IBM, for allowi ng me to bypass all those tapes. I don't yet have access to any tape drives under VM so I'm depending on z/OS to backup my newly-installed volumes, 530RES, 530PAG and 530SPL. However, I experience S213-04 abends (can't find SYS1.VTOC on the volume ) attempting to backup these volumes using Innovation's FDR under z/OS. z /VM was shutdown and I varied the volumes offline/online to z/OS following t he first failure, hoping that might correct the problem. I've used the sam e product/technique many times before in a past life and I know the proces s works. I suspect the installation process (whether its something inherent to v5 .3 or something unique to the FTP server install process, I'm not sure) is not initializing these volumes with the dummy VTOC required by z/OS. I di d not override the default volume format option of the installation. I suspect I need to run ICKDSF CPVOLUME FORMAT (or CPFMTXA FORMAT) again st cyl 0 on each of these volumes (first documenting and resbuilding the allocation maps) and then run SALIPL to rewrite the Loader IPL text on 530RES. Be aware that I'll more than likely be doing this against a run ning system without a backup (I'll probably try to DDR MAINT 123/124/125 to another volume, for a small amount of insurance). I think that's what I need to do but I want to run it past the community because I don't want to go through that multi-day installation again. D oes this sound reasonable? Can you think of any other reason I'd be experiencing this error? Thanks in advance for your assistance. Dennis Schaffer = ===
Re: S213 Abend Backing Up 530RES Using z/OS FDR
Oh man, I *HATE* it when that happens... :-) Dennis, I commend your courage and candor. We've all been there, and sometimes managed to slink away unnoticed with an only slightly flattened forehead. Just think of all the valuable insight we all gained about VM VTOC records from your problem... ;- -Chip- On 2/1/08 04:12 Dennis_Schaffer said: I thought I'd provide an update and closure to this S213 abend issue. The solution was actually pretty embarrassing. The solution was to vary the device offline/online to the correct z/OS system. I had recognized the need to vary the device offline/online before I even solicited input from the community. However, my backup job was redirected to a different z/OS system from the one where the varies occurred. So, there was no problem with the z/VM sysres volume which was built by the installation process. Probable user error. Thanks to all of you for your input. Dennis On Thu, 17 Jan 2008 00:28:09 -0600, Dennis Schaffer [EMAIL PROTECTED] wrote: Hi, I'm installing z/VM (v5.3) in a previously z/OS-only shop. Because there is no existing VM, I'm doing a first-level installation and I'm also using the FTP server method. The installation, while slow, has completed successfully and I'm able to IPL the newly-installed system. Thanks, IBM, for allowing me to bypass all those tapes. I don't yet have access to any tape drives under VM so I'm depending on z/OS to backup my newly-installed volumes, 530RES, 530PAG and 530SPL. However, I experience S213-04 abends (can't find SYS1.VTOC on the volume) attempting to backup these volumes using Innovation's FDR under z/OS. z/VM was shutdown and I varied the volumes offline/online to z/OS following the first failure, hoping that might correct the problem. I've used the same product/technique many times before in a past life and I know the process works. I suspect the installation process (whether its something inherent to v5.3 or something unique to the FTP server install process, I'm not sure) is not initializing these volumes with the dummy VTOC required by z/OS. I did not override the default volume format option of the installation. I suspect I need to run ICKDSF CPVOLUME FORMAT (or CPFMTXA FORMAT) against cyl 0 on each of these volumes (first documenting and resbuilding the allocation maps) and then run SALIPL to rewrite the Loader IPL text on 530RES. Be aware that I'll more than likely be doing this against a running system without a backup (I'll probably try to DDR MAINT 123/124/125 to another volume, for a small amount of insurance). I think that's what I need to do but I want to run it past the community because I don't want to go through that multi-day installation again. Does this sound reasonable? Can you think of any other reason I'd be experiencing this error? Thanks in advance for your assistance. Dennis Schaffer
Re: S213 Abend Backing Up 530RES Using z/OS FDR
I sent Dale a TYPE of two cyl 0 head 0 (one of z/VM 5.3 and one of an ICKDSF CPVOL-ed Tdisk) 2008/1/18, Dale R. Smith [EMAIL PROTECTED]: The VTOC should start right after the volume label. The first record in the VTOC should be the FMT4 (Format-4) DSCB record. The second record in the VTOC should be the FMT5 (Format-5) DSCB record. Here is a pointer to the layout of the Format-4 DSCB: http://publibz.boulder.ibm.com/cgi- bin/bookmgr/BOOKS/dgt2s330/1.1.1.5? SHELF=ez2zo10f.bksDT=20050617115137CASE= Layout for the Format-5 DSCB: http://publibz.boulder.ibm.com/cgi- bin/bookmgr/BOOKS/dgt2s330/1.1.1.6?SHELF=ez2zo10f.bksDT=20050617 115137 Unfortunately, I don't have access to a VM system currently, or I would take a look myself. Kris, if you want to email me the the output of DDR TYPE, I'm willing to take a look at it and try to decipher it! :-) -- Dale R. Smith Duct tape is like the Force, it has a dark side, it has a light side, and it holds the universe together. - Carl Zwanig On Fri, 18 Jan 2008 17:17:32 +0200, Kris Buelens [EMAIL PROTECTED] wrote: DDR TYPE of cyl 0, track0 is still a lot of data. One should know which fields to display. 2008/1/18, Dale R. Smith [EMAIL PROTECTED]: IIRC, ICKDSF CPVOLUME FORMAT is supposed to set the FMT5 DSCB in the VTOC for a volume to indicate that there is no free space on the volume. The FMT4 DSCB should contain the size of the volume. I'm not sure what DITTO is looking at, but z/OS should be using the FMT5 DSCB. What does a DDR TYPE of cylinder 0, track 0 show? -- Dale R. Smith -- Kris Buelens, IBM Belgium, VM customer support
Re: S213 Abend Backing Up 530RES Using z/OS FDR
Thanks Kris! I was wrong about the location of the Format-4 DSCB, it doesn't always follow immediately after the volume label record. The volume label record is always the third record on cylinder 0 track 0. Th e volume label record has a pointer to the first record in the VTOC, (which is always a Format-4 record). The Format-5 record is always the next record after the Format-4 record. Here is part of the volume label recor d from Kris's z/VM 5.3 install: (I'm posting from the web interface, which doesn't allow very long lines, so I'm only posting parts of the DDR TYPE output.) CYL HD 00 REC 003 COUNT 03 04 0050 4 0004 KEY LENGTH 0 E5D6D3F1*VOL1 00080 0050 DATA LENGTH 0 E5D6D3F1 E5E3C5F5 F3D9F000 0005 *VOL1VTE53R0. The DATA portion of the label starts with VOL1, then the 6 character volser, (VTE53R), a one byte security code, (0 - xF0), and a five byte pointer to the first record in the VTOC, (Format-4), in CCHHR format. This label says the VTOC starts in cylinder 0, track 0, record 5 . Here is part of the Format-4 DSCB, (record 5): CYL HD 00 REC 005 COUNT 05 2C 0060 00044 002C KEY LENGTH 0 04040404 04040404 04040404 04040404 00096 0060 DATA LENGTH 0 F400 0005 0001 0D0B 000F The KEY area actually contains 44 bytes of x'04' and the first byte of th e DATA area is x'F4', which indicates that this is a Format-4 DSCB record. The x'0D0B' is the number of cylinders, (3339), and x'000F' is the number of tracks per cylinder, (15). Here is part of the Format-5 DSCB, (record 6): CYL HD 00 REC 006 COUNT 06 2C 0060 00044 002C KEY LENGTH 0 05050505 0001 00096 0060 DATA LENGTH 0 F500 The x'05050505' in the KEY area indicates that this is a Format-5 DSCB. Immediately following the key identifier, the x'0001' is the first free track available, (relative to the beginning of the volume). The x'' after that is the number of free cylinders in the extent, in this case zero. The x'00' after that is the number of additional free tracks, also zero. Other free extents would follow this one, (there are none). This Format-5 DSCB indicates that there is NO free space on this volume, which is what z/OS would believe also. Kris's CPVOL formatted T-Disk is very similar to what is above, except that the volser is TESTRS and it is only 10, (x'0A'), cylinders in size! (If anybody wants to see the data from the formatted T-Disk, let me know and I will post it.) It looks to me like the VM install volumes are formatted correctly and that ICKDSF CPVOLUME also formats them correctly, (Format-5 DSCB shows no free cylinders/tracks available). My guess is that DITTO may be looking for Format-1 and Format-3 DSCBs, (they describe space used by allocated datasets), and not finding any on a VM volume, it is a assuming that the entire volume is free. z/OS will not allocate a dataset on a properly formatted VM volume, regardless of what DITTO shows. -- Dale R. Smith Always acknowledge a fault. This will throw those in authority off their guard and give you an opportunity to commit more. - Mark Twain On Mon, 21 Jan 2008 16:35:57 +0200, Kris Buelens [EMAIL PROTECTED] wrote: I sent Dale a TYPE of two cyl 0 head 0 (one of z/VM 5.3 and one of an ICKDSF CPVOL-ed Tdisk) -- Kris Buelens, IBM Belgium, VM customer support =
Re: S213 Abend Backing Up 530RES Using z/OS FDR
On Monday, 01/21/2008 at 10:02 EST, Dale R. Smith [EMAIL PROTECTED] wrote: The x'05050505' in the KEY area indicates that this is a Format-5 DSCB. Immediately following the key identifier, the x'0001' is the first free track available, (relative to the beginning of the volume). The x'' after that is the number of free cylinders in the extent, in this case zero. The x'00' after that is the number of additional free tracks, also zero. Other free extents would follow this one, (there are none). This Format-5 DSCB indicates that there is NO free space on this volume, which is what z/OS would believe also. Your observations match mine from last Friday http://listserv.uark.edu/scripts/wa.exe?A2=ind0801L=ibmvmT=0P=32477 My guess is that DITTO may be looking for Format-1 and Format-3 DSCBs, (they describe space used by allocated datasets), and not finding any on a VM volume, it is a assuming that the entire volume is free. z/OS will not allocate a dataset on a properly formatted VM volume, regardless of what DITTO shows. (whew!) I'm glad its a DITTO bug. It explains why my playing with the Format-5 DSCB didn't affect what DITTO reported. I looked up the S213-04: It is because a format *1* DSCB cannot be found. I was confusing the lack of a dataset called SYS1.VTOC with the lack of a VTOC. Tricksy, it is! Alan Altmark z/VM Development IBM Endicott
Re: S213 Abend Backing Up 530RES Using z/OS FDR
IIRC, ICKDSF CPVOLUME FORMAT is supposed to set the FMT5 DSCB in the VTOC for a volume to indicate that there is no free space on the volume. The FMT4 DSCB should contain the size of the volume. I'm not sure what DITTO is looking at, but z/OS should be using the FMT5 DSCB. What does a DDR TYPE of cylinder 0, track 0 show? -- Dale R. Smith There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened. - Douglas Adams On Fri, 18 Jan 2008 09:35:10 +0200, Kris Buelens [EMAIL PROTECTED] wrote: Same here (for a VM resident) DITTO/ESA for VM DVT - Display VTOC Line 1 of 2 Unit 0130 VFRRES 3390 with 3339 cyls, 15 trks/cyl, 58786 bytes/trk --- Data Set Name ---Ext Begin-endReltrk, 1...5...10...15...20...25...30. seq Cyl-hd Cyl-hd numtrks *** VTOC EXTENT *** 0 0 0 0 0 0,1 *** FREE EXTENT *** 0 0 1 3338 14 1,50084 *** This volume is currently 0 % full with 50084 tracks available Maybe MVS is looking at some other field to find out if there still is free space 2008/1/18, Alan Altmark [EMAIL PROTECTED]: On Thursday, 01/17/2008 at 09:42 EST, Kris Buelens [EMAIL PROTECTED] wrote: VM doesn't use VTOCs to describe disk contents; the CP directory tel ls which cylinders are allocated as minidisks, and the CP allocation map tell s CP which cylinders to use for PAGE, SPOOL, etc. After a CPFMTXA FORMAT, I used DITTO to look at the VTOC that *is* on the volume: --- Data Set Name --- sorted by NAME - Ext Begin-end Reltrk, 1...5...10...15...20...25...30...35...40 seq Cyl-hd Cyl-hd numtrks *** VTOC EXTENT *** 0 0 0 0 0 0,1 *** FREE EXTENT *** 0 0 1 4 14 1,74 *** This volume is currently 1 percent full with 74 tracks available I had always thought that a full VTOC was written by DSF so that MVS would not attempt to allocate space on a CP-owned volume. It is a 5 c yl 3390. Alan Altmark z/VM Development IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: S213 Abend Backing Up 530RES Using z/OS FDR
Dale, I hope I don't lose your interest; it will be sometime next week before I can get that information because (1 I can't IPL it due to bad HMC-SE connectivity which occurred last night; the processor is in another city and (2 it will be next week before we get network connectivity for the LPAR defined so I can ftp the data. However, I do plan to DDR cyl 0 to a print file before and after reformat so I can perhaps pursue what caused this to happen. I have a PMR open w/ IB M and they don't seem terribly interested so far; I'm hoping a little evide nce will pique their interest. If I get time after we birth some penguins, I may even try to recreate the problem with a second level reinstallation. It looks like the INSTDVD processing which I think introduced this problem is common between first- and second- levels. Thanks for your help.
Re: S213 Abend Backing Up 530RES Using z/OS FDR
I had the same problem at my shop a few months ago - new z/VM 5.3 implementation backing up with FDR on z/OS. The problem is a missing dummy VTOC on cylinder 0 that FDR depends on - S213 abend if it doesn't find it. You must format cylinder 0 using CPFMTXA. Just make sure you run an ALLOCATE after the format to redefine all your CP areas. ...Nick. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Schaffer Sent: Thursday, January 17, 2008 1:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: S213 Abend Backing Up 530RES Using z/OS FDR Hi, I'm installing z/VM (v5.3) in a previously z/OS-only shop. Because there= is no existing VM, I'm doing a first-level installation and I'm also using t= he FTP server method. The installation, while slow, has completed successfu= lly and I'm able to IPL the newly-installed system. Thanks, IBM, for allowin= g me to bypass all those tapes. I don't yet have access to any tape drives under VM so I'm depending on z= /OS to backup my newly-installed volumes, 530RES, 530PAG and 530SPL. However, I experience S213-04 abends (can't find SYS1.VTOC on the volume)= attempting to backup these volumes using Innovation's FDR under z/OS. z/= VM was shutdown and I varied the volumes offline/online to z/OS following th= e first failure, hoping that might correct the problem. I've used the same= product/technique many times before in a past life and I know the process= works. I suspect the installation process (whether its something inherent to v5.= 3 or something unique to the FTP server install process, I'm not sure) is n= ot initializing these volumes with the dummy VTOC required by z/OS. I did= not override the default volume format option of the installation. I suspect I need to run ICKDSF CPVOLUME FORMAT (or CPFMTXA FORMAT) agains= t cyl 0 on each of these volumes (first documenting and resbuilding the allocation maps) and then run SALIPL to rewrite the Loader IPL text on 530RES. Be aware that I'll more than likely be doing this against a runn= ing system without a backup (I'll probably try to DDR MAINT 123/124/125 to another volume, for a small amount of insurance). I think that's what I need to do but I want to run it past the community because I don't want to go through that multi-day installation again. Do= es this sound reasonable? Can you think of any other reason I'd be experiencing this error? Thanks in advance for your assistance. Dennis Schaffer This email is intended for the recipient only. If you are not the intended recipient please disregard, and do not use the information for any purpose.
Re: S213 Abend Backing Up 530RES Using z/OS FDR
The VTOC should start right after the volume label. The first record in the VTOC should be the FMT4 (Format-4) DSCB record. The second record in the VTOC should be the FMT5 (Format-5) DSCB record. Here is a pointer to the layout of the Format-4 DSCB: http://publibz.boulder.ibm.com/cgi- bin/bookmgr/BOOKS/dgt2s330/1.1.1.5? SHELF=ez2zo10f.bksDT=20050617115137CASE= Layout for the Format-5 DSCB: http://publibz.boulder.ibm.com/cgi- bin/bookmgr/BOOKS/dgt2s330/1.1.1.6?SHELF=ez2zo10f.bksDT=20050617 115137 Unfortunately, I don't have access to a VM system currently, or I would take a look myself. Kris, if you want to email me the the output of DDR TYPE, I'm willing to take a look at it and try to decipher it! :-) -- Dale R. Smith Duct tape is like the Force, it has a dark side, it has a light side, and it holds the universe together. - Carl Zwanig On Fri, 18 Jan 2008 17:17:32 +0200, Kris Buelens [EMAIL PROTECTED] wrote: DDR TYPE of cyl 0, track0 is still a lot of data. One should know which fields to display. 2008/1/18, Dale R. Smith [EMAIL PROTECTED]: IIRC, ICKDSF CPVOLUME FORMAT is supposed to set the FMT5 DSCB in the VTOC for a volume to indicate that there is no free space on the volume. The FMT4 DSCB should contain the size of the volume. I'm not sure what DITTO is looking at, but z/OS should be using the FMT5 DSCB. What does a DDR TYPE of cylinder 0, track 0 show? -- Dale R. Smith
Re: S213 Abend Backing Up 530RES Using z/OS FDR
Way back when IBM first started putting dummy VTOCs on devices used by VM and ACP, I pointed out that relying on a Format 5 DSCB that said there was no space was not the correct way to do it. It needs an F1 DSCB that allocates all available space instead. In those days, relying on the F5 alone could have led to real trouble. Whenever the O/S DASD allocation routines, looked at a VTOC, they turned on the DOS VTOC bit, known also as the Damaged VTOC bit, which was used to indicate that the allocation routines were working on the volume. If, for some reason, that bit were already on when the routines started, they first built a new F5 by starting with everything free and processing the F1 and F3 DSCBs to re-allocate the space that was in use. No F1 meant that all space was free. It looks like nothing has really changed. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Thursday, January 17, 2008 11:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: S213 Abend Backing Up 530RES Using z/OS FDR Same here (for a VM resident) DITTO/ESA for VM DVT - Display VTOC Line 1 of 2 Unit 0130 VFRRES 3390 with 3339 cyls, 15 trks/cyl, 58786 bytes/trk --- Data Set Name ---Ext Begin-endReltrk, 1...5...10...15...20...25...30. seq Cyl-hd Cyl-hd numtrks *** VTOC EXTENT *** 0 0 0 0 0 0,1 *** FREE EXTENT *** 0 0 1 3338 14 1,50084 *** This volume is currently 0 % full with 50084 tracks available Maybe MVS is looking at some other field to find out if there still is free space 2008/1/18, Alan Altmark [EMAIL PROTECTED]: On Thursday, 01/17/2008 at 09:42 EST, Kris Buelens [EMAIL PROTECTED] wrote: VM doesn't use VTOCs to describe disk contents; the CP directory tells which cylinders are allocated as minidisks, and the CP allocation map tells CP which cylinders to use for PAGE, SPOOL, etc. After a CPFMTXA FORMAT, I used DITTO to look at the VTOC that *is* on the volume: --- Data Set Name --- sorted by NAME - Ext Begin-endReltrk, 1...5...10...15...20...25...30...35...40 seq Cyl-hd Cyl-hd numtrks *** VTOC EXTENT *** 0 0 0 0 0 0,1 *** FREE EXTENT *** 0 0 1 4 14 1,74 *** This volume is currently 1 percent full with 74 tracks available I had always thought that a full VTOC was written by DSF so that MVS would not attempt to allocate space on a CP-owned volume. It is a 5 cyl 3390. Alan Altmark z/VM Development IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: S213 Abend Backing Up 530RES Using z/OS FDR
DDR TYPE of cyl 0, track0 is still a lot of data. One should know which fields to display. 2008/1/18, Dale R. Smith [EMAIL PROTECTED]: IIRC, ICKDSF CPVOLUME FORMAT is supposed to set the FMT5 DSCB in the VTOC for a volume to indicate that there is no free space on the volume. The FMT4 DSCB should contain the size of the volume. I'm not sure what DITTO is looking at, but z/OS should be using the FMT5 DSCB. What does a DDR TYPE of cylinder 0, track 0 show? -- Dale R. Smith There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened. - Douglas Adams On Fri, 18 Jan 2008 09:35:10 +0200, Kris Buelens [EMAIL PROTECTED] wrote: Same here (for a VM resident) DITTO/ESA for VM DVT - Display VTOC Line 1 of 2 Unit 0130 VFRRES 3390 with 3339 cyls, 15 trks/cyl, 58786 bytes/trk --- Data Set Name ---Ext Begin-endReltrk, 1...5...10...15...20...25...30. seq Cyl-hd Cyl-hd numtrks *** VTOC EXTENT *** 0 0 0 0 0 0,1 *** FREE EXTENT *** 0 0 1 3338 14 1,50084 *** This volume is currently 0 % full with 50084 tracks available Maybe MVS is looking at some other field to find out if there still is free space 2008/1/18, Alan Altmark [EMAIL PROTECTED]: On Thursday, 01/17/2008 at 09:42 EST, Kris Buelens [EMAIL PROTECTED] wrote: VM doesn't use VTOCs to describe disk contents; the CP directory tel ls which cylinders are allocated as minidisks, and the CP allocation map tell s CP which cylinders to use for PAGE, SPOOL, etc. After a CPFMTXA FORMAT, I used DITTO to look at the VTOC that *is* on the volume: --- Data Set Name --- sorted by NAME - Ext Begin-end Reltrk, 1...5...10...15...20...25...30...35...40 seq Cyl-hd Cyl-hd numtrks *** VTOC EXTENT *** 0 0 0 0 0 0,1 *** FREE EXTENT *** 0 0 1 4 14 1,74 *** This volume is currently 1 percent full with 74 tracks available I had always thought that a full VTOC was written by DSF so that MVS would not attempt to allocate space on a CP-owned volume. It is a 5 c yl 3390. Alan Altmark z/VM Development IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support -- Kris Buelens, IBM Belgium, VM customer support
Re: S213 Abend Backing Up 530RES Using z/OS FDR
On Friday, 01/18/2008 at 10:49 EST, Said, Nick [EMAIL PROTECTED] wrote: I had the same problem at my shop a few months ago - new z/VM 5.3 implementation backing up with FDR on z/OS. The problem is a missing dummy VTOC on cylinder 0 that FDR depends on - S213 abend if it doesn't find it. You must format cylinder 0 using CPFMTXA. Just make sure you run an ALLOCATE after the format to redefine all your CP areas. The VTOC is located on cyl 0. The record number is a 5-byte number starting at +0x0B in the label. In the example I posted, the VTOC is on record 5: RECORD 3 (a VOL1 label) KEY 4 E5D6D3F1 *VOL1 * DATA80 E5D6D3F1 E3C5E2E3 C5D9F000 0005 *VOL1TESTER0.* 0010 00404040 40404040 40404040 *. * 0020 40404040 40404040 4000 C3D7 * .CP* 0030 E5D6D340 40404040 40404040 40404040 *VOL * 0040 40404040 40404040 40404040 40404040 * * RECORD 5 - This looks like a good type 4 DSCB KEY 44 04040404 04040404 04040404 04040404 0010 04040404 04040404 04040404 04040404 0020 04040404 04040404 04040404 DATA96 F400 0005 0001 DSCB type = 0xF4 = 4 max CCHHR of DSCB entry = 5 # VTOC extents = 0x01 = 1 0010 0005 000FE5A2 0030 322D SMS status = 0x00 = Non-system managed volume # alt cyls = 0x00 = 0 # cyls = 0x0005 = 5 # trks/cyl = 0x000F = 15 Trk length = 0xE5A2 = 58786 Flags = 0x30 = 0011 ...1 ... = # alt cyls is valid ..1. ... = ? Not defined DSCBs per track = 0x32 = 50 PDS dir blocks per track = 0x2D = 45 0020 0030 0040 0050 RECORD 6 - This looks like a type 5 DSCB KEY 44 05050505 0001 key = 0x05050505 relative addr of 1st avail trk = 0x0001 # UNused cyls = 0x = 0 # add'l unused trks = 0x00 = 0 0010 0020 DATA96 F500 DSCB type = 0xF5 = 5 0010 0020 0030 0040 0050 Repeating the DITTO VTOC listing: Unit 0111 VOLSER TESTER 3390 with 5 cyls, 15 trks/cyl, 58786 bytes/trk --- Data Set Name --- sorted by NAME - Ext Begin-endReltrk, 1...5...10...15...20...25...30...35...40 seq Cyl-hd Cyl-hd numtrks *** VTOC EXTENT *** 0 0 0 0 0 0,1 *** FREE EXTENT *** 0 0 1 4 14 1,74 *** This volume is currently 1 percent full with 74 tracks available I agree that that the DSCB-4 says the VTOC consists of only one track starting on track 0 of cyl 0, head 0. I have no idea how it decided from the DSCB-5 shown above that the rest of the volume was available. I even changed the 0x0001 to 0x in the DSCB-5 and it says the same thing. I wonder what the DSCB-5 looks like on an MVS volume that is completely full? Maybe DITTO is wrong? Alan Altmark z/VM Development IBM Endicott
Re: S213 Abend Backing Up 530RES Using z/OS FDR
Before trying to fix (if required) the packs of your new VM system, use ICKDSK CPVOL FORMAT on a spare pack and see if FDR likes that better. Because, I'd think that when the z/VM 5.3 disks were created at IBM, the same ICKDSF was being used. I also suppose that the process to create the INSTDVD DVD has simply physically read these install packs and stored them as binary files on some server that burned a DVD. A z/VM on tape would be similar, but here DDR would have been used to create a physical copy. As for emailing a DDR TYPE of a cylinder 0: sorry, I'm at home now, no VM here. 2008/1/18, Schuh, Richard [EMAIL PROTECTED]: Way back when IBM first started putting dummy VTOCs on devices used by VM and ACP, I pointed out that relying on a Format 5 DSCB that said there was no space was not the correct way to do it. It needs an F1 DSCB that allocates all available space instead. In those days, relying on the F5 alone could have led to real trouble. Whenever the O/S DASD allocation routines, looked at a VTOC, they turned on the DOS VTOC bit, known also as the Damaged VTOC bit, which was used to indicate that the allocation routines were working on the volume. If, for some reason, that bit were already on when the routines started, they first built a new F5 by starting with everything free and processing the F1 and F3 DSCBs to re-allocate the space that was in use. No F1 meant that all space was free. It looks like nothing has really changed. Regards, Richard Schuh -- Kris Buelens, IBM Belgium, VM customer support
Re: S213 Abend Backing Up 530RES Using z/OS FDR
Dennis, This appears to be a problem with FDR. I have used it to backup various VM DASD for over 20 years. I suggest you contact Innovation. Jim This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: S213 Abend Backing Up 530RES Using z/OS FDR
VM doesn't use VTOCs to describe disk contents; the CP directory tells which cylinders are allocated as minidisks, and the CP allocation map tells CP which cylinders to use for PAGE, SPOOL, etc. I'll send you a document with some extra information about this subject. The FTP based installation shouldn't have anything to do with your FDR problem. The fact that CP can IPL fine means all is OK. You should tell FDR -I don't know how- that it should take some physical based backup, or has it a VM-format parameter? 2008/1/17, Dennis Schaffer [EMAIL PROTECTED]: Hi, I'm installing z/VM (v5.3) in a previously z/OS-only shop. Because there is no existing VM, I'm doing a first-level installation and I'm also using t he FTP server method. The installation, while slow, has completed successfu lly and I'm able to IPL the newly-installed system. Thanks, IBM, for allowin g me to bypass all those tapes. I don't yet have access to any tape drives under VM so I'm depending on z /OS to backup my newly-installed volumes, 530RES, 530PAG and 530SPL. However, I experience S213-04 abends (can't find SYS1.VTOC on the volume) attempting to backup these volumes using Innovation's FDR under z/OS. z/ VM was shutdown and I varied the volumes offline/online to z/OS following th e first failure, hoping that might correct the problem. I've used the same product/technique many times before in a past life and I know the process works. I suspect the installation process (whether its something inherent to v5. 3 or something unique to the FTP server install process, I'm not sure) is n ot initializing these volumes with the dummy VTOC required by z/OS. I did not override the default volume format option of the installation. I suspect I need to run ICKDSF CPVOLUME FORMAT (or CPFMTXA FORMAT) agains t cyl 0 on each of these volumes (first documenting and resbuilding the allocation maps) and then run SALIPL to rewrite the Loader IPL text on 530RES. Be aware that I'll more than likely be doing this against a runn ing system without a backup (I'll probably try to DDR MAINT 123/124/125 to another volume, for a small amount of insurance). I think that's what I need to do but I want to run it past the community because I don't want to go through that multi-day installation again. Do es this sound reasonable? Can you think of any other reason I'd be experiencing this error? Thanks in advance for your assistance. Dennis Schaffer -- Kris Buelens, IBM Belgium, VM customer support
Re: S213 Abend Backing Up 530RES Using z/OS FDR
I use FDR to backup my current z/VM 510 system. However, you need to make sure you are using FDR and not FDRABR. Here is part of the JCL I use to backup the z/VM system. //VMDUMP EXEC PGM=FDR,REGION=0M, //PARM='DUMP TYPE=FDR' //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSINDD DUMMY //DISK1DD UNIT=DISK,DISP=OLD,VOL=SER=510RES //TAPE1DD UNIT=MEDIA3E,DSN=BACKUP.V510RES,DISP=(,KEEP), // VOL=(,RETAIN),LABEL=1,RETPD=DA. //DISK2DD UNIT=DISK,DISP=OLD,VOL=SER=510W01 //TAPE2DD UNIT=MEDIA3E,DSN=BACKUP.V510W01,DISP=(,KEEP), // VOL=REF=*.TAPE1,LABEL=2 Etc for other z/VM volumes William L. Boyer Senior Systems Programmer ViPS, Inc. One West Pennsylvania Avenue Baltimore, MD 21204 Office: 410.832.8300 ext. 8419 Fax: 410.832.8329 This message is confidential, intended only for the named recipient(s) and may contain information that is privileged or exempt from disclosure under applicable law. If you are not the intended recipient(s), you are notified that the dissemination, distribution, or copying of this message is strictly prohibited. If you receive this message in error or are not the named recipient(s), please notify the sender at either the fax address or telephone number above and delete this message. Thank you. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Schaffer Sent: Thursday, January 17, 2008 1:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: S213 Abend Backing Up 530RES Using z/OS FDR Hi, I'm installing z/VM (v5.3) in a previously z/OS-only shop. Because there is no existing VM, I'm doing a first-level installation and I'm also using the FTP server method. The installation, while slow, has completed successfully and I'm able to IPL the newly-installed system. Thanks, IBM, for allowing me to bypass all those tapes. I don't yet have access to any tape drives under VM so I'm depending on z/OS to backup my newly-installed volumes, 530RES, 530PAG and 530SPL. However, I experience S213-04 abends (can't find SYS1.VTOC on the volume) attempting to backup these volumes using Innovation's FDR under z/OS. z/VM was shutdown and I varied the volumes offline/online to z/OS following the first failure, hoping that might correct the problem. I've used the same product/technique many times before in a past life and I know the process works. I suspect the installation process (whether its something inherent to v5.3 or something unique to the FTP server install process, I'm not sure) is not initializing these volumes with the dummy VTOC required by z/OS. I did not override the default volume format option of the installation. I suspect I need to run ICKDSF CPVOLUME FORMAT (or CPFMTXA FORMAT) against cyl 0 on each of these volumes (first documenting and resbuilding the allocation maps) and then run SALIPL to rewrite the Loader IPL text on 530RES. Be aware that I'll more than likely be doing this against a running system without a backup (I'll probably try to DDR MAINT 123/124/125 to another volume, for a small amount of insurance). I think that's what I need to do but I want to run it past the community because I don't want to go through that multi-day installation again. Does this sound reasonable? Can you think of any other reason I'd be experiencing this error? Thanks in advance for your assistance. Dennis Schaffer
Re: S213 Abend Backing Up 530RES Using z/OS FDR
We use dfdss from z/OS to backup all our z/VM packs and you must have a special parm in the job to do that. The parms (sysin) looks like this: DUMP TRACKS(0,0,3338,14) INDDNAME(DASD) OUTDDNAME(TAPE) ADMIN - CPVOLUME CANCELERROR The admin and cpvolume are a must. Don't know it this helps Mace From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Thursday, January 17, 2008 9:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: S213 Abend Backing Up 530RES Using z/OS FDR VM doesn't use VTOCs to describe disk contents; the CP directory tells which cylinders are allocated as minidisks, and the CP allocation map tells CP which cylinders to use for PAGE, SPOOL, etc. I'll send you a document with some extra information about this subject. The FTP based installation shouldn't have anything to do with your FDR problem. The fact that CP can IPL fine means all is OK. You should tell FDR -I don't know how- that it should take some physical based backup, or has it a VM-format parameter? 2008/1/17, Dennis Schaffer [EMAIL PROTECTED]: Hi, I'm installing z/VM (v5.3) in a previously z/OS-only shop. Because there is no existing VM, I'm doing a first-level installation and I'm also using t he FTP server method. The installation, while slow, has completed successfu lly and I'm able to IPL the newly-installed system. Thanks, IBM, for allowin g me to bypass all those tapes. I don't yet have access to any tape drives under VM so I'm depending on z /OS to backup my newly-installed volumes, 530RES, 530PAG and 530SPL. However, I experience S213-04 abends (can't find SYS1.VTOC on the volume) attempting to backup these volumes using Innovation's FDR under z/OS. z/ VM was shutdown and I varied the volumes offline/online to z/OS following th e first failure, hoping that might correct the problem. I've used the same product/technique many times before in a past life and I know the process works. I suspect the installation process (whether its something inherent to v5. 3 or something unique to the FTP server install process, I'm not sure) is n ot initializing these volumes with the dummy VTOC required by z/OS. I did not override the default volume format option of the installation. I suspect I need to run ICKDSF CPVOLUME FORMAT (or CPFMTXA FORMAT) agains t cyl 0 on each of these volumes (first documenting and resbuilding the allocation maps) and then run SALIPL to rewrite the Loader IPL text on 530RES. Be aware that I'll more than likely be doing this against a runn ing system without a backup (I'll probably try to DDR MAINT 123/124/125 to another volume, for a small amount of insurance). I think that's what I need to do but I want to run it past the community because I don't want to go through that multi-day installation again. Do es this sound reasonable? Can you think of any other reason I'd be experiencing this error? Thanks in advance for your assistance. Dennis Schaffer -- Kris Buelens, IBM Belgium, VM customer support - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: S213 Abend Backing Up 530RES Using z/OS FDR
What is the iec143I message that accompanies it?? Mace -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Schaffer Sent: Thursday, January 17, 2008 11:22 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: S213 Abend Backing Up 530RES Using z/OS FDR I just attempted to use DFDSS to dump 530RES using the syntax suggested b= y Larry and I got another S213 abend for SYS1.VTOC. I think the problem is= with the volume and not the dumping software. What do you think of my original suggestion (CPFMTXA FORMAT cyl 0, followed by SALIPL to reload the IPL text) for correcting the problem? Thanks, Dennis On Thu, 17 Jan 2008 09:59:43 -0500, Macioce, Larry [EMAIL PROTECTED] wrote: We use dfdss from z/OS to backup all our z/VM packs and you must have a special parm in the job to do that. The parms (sysin) looks like this: DUMP TRACKS(0,0,3338,14) INDDNAME(DASD) OUTDDNAME(TAPE) ADMIN - CPVOLUME CANCELERROR The admin and cpvolume are a must. = = Don't know it this helps Mace From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Thursday, January 17, 2008 9:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: S213 Abend Backing Up 530RES Using z/OS FDR VM doesn't use VTOCs to describe disk contents; the CP directory tells which cylinders are allocated as minidisks, and the CP allocation map tells CP which cylinders to use for PAGE, SPOOL, etc. I'll send you a document with some extra information about this subject. The FTP based installation shouldn't have anything to do with your FDR problem. The fact that CP can IPL fine means all is OK. You should tell FDR -I don't know how- that it should take some physical based backup, or has it a VM-format parameter? 2008/1/17, Dennis Schaffer [EMAIL PROTECTED]: Hi, I'm installing z/VM (v5.3) in a previously z/OS-only shop. Because there is no existing VM, I'm doing a first-level installation and I'm also using t he FTP server method. The installation, while slow, has completed successfu lly and I'm able to IPL the newly-installed system. Thanks, IBM, for allowin g me to bypass all those tapes. I don't yet have access to any tape drives under VM so I'm depending on z /OS to backup my newly-installed volumes, 530RES, 530PAG and 530SPL. However, I experience S213-04 abends (can't find SYS1.VTOC on the volume) attempting to backup these volumes using Innovation's FDR under z/OS. z/ VM was shutdown and I varied the volumes offline/online to z/OS following th e first failure, hoping that might correct the problem. I've used the same product/technique many times before in a past life and I know the process works. I suspect the installation process (whether its something inherent to v5. 3 or something unique to the FTP server install process, I'm not sure) is n ot initializing these volumes with the dummy VTOC required by z/OS. I did not override the default volume format option of the installation. I suspect I need to run ICKDSF CPVOLUME FORMAT (or CPFMTXA FORMAT) agains t cyl 0 on each of these volumes (first documenting and resbuilding the allocation maps) and then run SALIPL to rewrite the Loader IPL text on 530RES. Be aware that I'll more than likely be doing this against a runn ing system without a backup (I'll probably try to DDR MAINT 123/124/125 to = another volume, for a small amount of insurance). I think that's what I need to do but I want to run it past the community because I don't want to go through that multi-day installation again. Do es this sound reasonable? Can you think of any other reason I'd be experiencing this error? Thanks in advance for your assistance. Dennis Schaffer -- Kris Buelens, IBM Belgium, VM customer support - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: S213 Abend Backing Up 530RES Using z/OS FDR
I just attempted to use DFDSS to dump 530RES using the syntax suggested b y Larry and I got another S213 abend for SYS1.VTOC. I think the problem is with the volume and not the dumping software. What do you think of my original suggestion (CPFMTXA FORMAT cyl 0, followed by SALIPL to reload the IPL text) for correcting the problem? Thanks, Dennis On Thu, 17 Jan 2008 09:59:43 -0500, Macioce, Larry [EMAIL PROTECTED] wrote: We use dfdss from z/OS to backup all our z/VM packs and you must have a special parm in the job to do that. The parms (sysin) looks like this: DUMP TRACKS(0,0,3338,14) INDDNAME(DASD) OUTDDNAME(TAPE) ADMIN - CPVOLUME CANCELERROR The admin and cpvolume are a must. Don't know it this helps Mace From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Thursday, January 17, 2008 9:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: S213 Abend Backing Up 530RES Using z/OS FDR VM doesn't use VTOCs to describe disk contents; the CP directory tells which cylinders are allocated as minidisks, and the CP allocation map tells CP which cylinders to use for PAGE, SPOOL, etc. I'll send you a document with some extra information about this subject. The FTP based installation shouldn't have anything to do with your FDR problem. The fact that CP can IPL fine means all is OK. You should tell FDR -I don't know how- that it should take some physical based backup, or has it a VM-format parameter? 2008/1/17, Dennis Schaffer [EMAIL PROTECTED]: Hi, I'm installing z/VM (v5.3) in a previously z/OS-only shop. Because there is no existing VM, I'm doing a first-level installation and I'm also using t he FTP server method. The installation, while slow, has completed successfu lly and I'm able to IPL the newly-installed system. Thanks, IBM, for allowin g me to bypass all those tapes. I don't yet have access to any tape drives under VM so I'm depending on z /OS to backup my newly-installed volumes, 530RES, 530PAG and 530SPL. However, I experience S213-04 abends (can't find SYS1.VTOC on the volume) attempting to backup these volumes using Innovation's FDR under z/OS. z/ VM was shutdown and I varied the volumes offline/online to z/OS following th e first failure, hoping that might correct the problem. I've used the same product/technique many times before in a past life and I know the process works. I suspect the installation process (whether its something inherent to v5. 3 or something unique to the FTP server install process, I'm not sure) is n ot initializing these volumes with the dummy VTOC required by z/OS. I did not override the default volume format option of the installation. I suspect I need to run ICKDSF CPVOLUME FORMAT (or CPFMTXA FORMAT) agains t cyl 0 on each of these volumes (first documenting and resbuilding the allocation maps) and then run SALIPL to rewrite the Loader IPL text on 530RES. Be aware that I'll more than likely be doing this against a runn ing system without a backup (I'll probably try to DDR MAINT 123/124/125 to another volume, for a small amount of insurance). I think that's what I need to do but I want to run it past the community because I don't want to go through that multi-day installation again. Do es this sound reasonable? Can you think of any other reason I'd be experiencing this error? Thanks in advance for your assistance. Dennis Schaffer -- Kris Buelens, IBM Belgium, VM customer support - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: S213 Abend Backing Up 530RES Using z/OS FDR
I would try that. We use DFDSS to dump too. I recall that there were some vols that had a problem. I think it was 3390-9's that had been ddr's of 3's at one point in their life. Hard to remember though. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Schaffer Sent: Thursday, January 17, 2008 8:22 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] S213 Abend Backing Up 530RES Using z/OS FDR I just attempted to use DFDSS to dump 530RES using the syntax suggested b= y Larry and I got another S213 abend for SYS1.VTOC. I think the problem is= with the volume and not the dumping software. What do you think of my original suggestion (CPFMTXA FORMAT cyl 0, followed by SALIPL to reload the IPL text) for correcting the problem? Thanks, Dennis On Thu, 17 Jan 2008 09:59:43 -0500, Macioce, Larry [EMAIL PROTECTED] wrote: We use dfdss from z/OS to backup all our z/VM packs and you must have a special parm in the job to do that. The parms (sysin) looks like this: DUMP TRACKS(0,0,3338,14) INDDNAME(DASD) OUTDDNAME(TAPE) ADMIN - CPVOLUME CANCELERROR The admin and cpvolume are a must. = = Don't know it this helps Mace From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Thursday, January 17, 2008 9:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: S213 Abend Backing Up 530RES Using z/OS FDR VM doesn't use VTOCs to describe disk contents; the CP directory tells which cylinders are allocated as minidisks, and the CP allocation map tells CP which cylinders to use for PAGE, SPOOL, etc. I'll send you a document with some extra information about this subject. The FTP based installation shouldn't have anything to do with your FDR problem. The fact that CP can IPL fine means all is OK. You should tell FDR -I don't know how- that it should take some physical based backup, or has it a VM-format parameter? 2008/1/17, Dennis Schaffer [EMAIL PROTECTED]: Hi, I'm installing z/VM (v5.3) in a previously z/OS-only shop. Because there is no existing VM, I'm doing a first-level installation and I'm also using t he FTP server method. The installation, while slow, has completed successfu lly and I'm able to IPL the newly-installed system. Thanks, IBM, for allowin g me to bypass all those tapes. I don't yet have access to any tape drives under VM so I'm depending on z /OS to backup my newly-installed volumes, 530RES, 530PAG and 530SPL. However, I experience S213-04 abends (can't find SYS1.VTOC on the volume) attempting to backup these volumes using Innovation's FDR under z/OS. z/ VM was shutdown and I varied the volumes offline/online to z/OS following th e first failure, hoping that might correct the problem. I've used the same product/technique many times before in a past life and I know the process works. I suspect the installation process (whether its something inherent to v5. 3 or something unique to the FTP server install process, I'm not sure) is n ot initializing these volumes with the dummy VTOC required by z/OS. I did not override the default volume format option of the installation. I suspect I need to run ICKDSF CPVOLUME FORMAT (or CPFMTXA FORMAT) agains t cyl 0 on each of these volumes (first documenting and resbuilding the allocation maps) and then run SALIPL to rewrite the Loader IPL text on 530RES. Be aware that I'll more than likely be doing this against a runn ing system without a backup (I'll probably try to DDR MAINT 123/124/125 to = another volume, for a small amount of insurance). I think that's what I need to do but I want to run it past the community because I don't want to go through that multi-day installation again. Do es this sound reasonable? Can you think of any other reason I'd be experiencing this error? Thanks in advance for your assistance. Dennis Schaffer -- Kris Buelens, IBM Belgium, VM customer support - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient
Re: S213 Abend Backing Up 530RES Using z/OS FDR
A few years ago, we migrated to a new datacenter. The first step was to copy the VM DASD to a bunker box - a SHARK facility that could be sync'd with a counterpart at the new site. The storage management group was going to handle the move from MVS. To make a long story short, after trying three different utilities and opening sev 1 PMRs against all of them because of this or similar problems, I was asked (at the last minute 16:30, Thursday with the move scheduled for 08:00 Saturday) if I could somehow do the move from VM. I created a one pack VM system that could be used to DDR COPY the disks while the real system was down. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Schaffer Sent: Thursday, January 17, 2008 8:22 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: S213 Abend Backing Up 530RES Using z/OS FDR I just attempted to use DFDSS to dump 530RES using the syntax suggested b= y Larry and I got another S213 abend for SYS1.VTOC. I think the problem is= with the volume and not the dumping software. What do you think of my original suggestion (CPFMTXA FORMAT cyl 0, followed by SALIPL to reload the IPL text) for correcting the problem? Thanks, Dennis On Thu, 17 Jan 2008 09:59:43 -0500, Macioce, Larry [EMAIL PROTECTED] wrote: We use dfdss from z/OS to backup all our z/VM packs and you must have a special parm in the job to do that. The parms (sysin) looks like this: DUMP TRACKS(0,0,3338,14) INDDNAME(DASD) OUTDDNAME(TAPE) ADMIN - CPVOLUME CANCELERROR The admin and cpvolume are a must. = = Don't know it this helps Mace From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Thursday, January 17, 2008 9:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: S213 Abend Backing Up 530RES Using z/OS FDR VM doesn't use VTOCs to describe disk contents; the CP directory tells which cylinders are allocated as minidisks, and the CP allocation map tells CP which cylinders to use for PAGE, SPOOL, etc. I'll send you a document with some extra information about this subject. The FTP based installation shouldn't have anything to do with your FDR problem. The fact that CP can IPL fine means all is OK. You should tell FDR -I don't know how- that it should take some physical based backup, or has it a VM-format parameter? 2008/1/17, Dennis Schaffer [EMAIL PROTECTED]: Hi, I'm installing z/VM (v5.3) in a previously z/OS-only shop. Because there is no existing VM, I'm doing a first-level installation and I'm also using t he FTP server method. The installation, while slow, has completed successfu lly and I'm able to IPL the newly-installed system. Thanks, IBM, for allowin g me to bypass all those tapes. I don't yet have access to any tape drives under VM so I'm depending on z /OS to backup my newly-installed volumes, 530RES, 530PAG and 530SPL. However, I experience S213-04 abends (can't find SYS1.VTOC on the volume) attempting to backup these volumes using Innovation's FDR under z/OS. z/ VM was shutdown and I varied the volumes offline/online to z/OS following th e first failure, hoping that might correct the problem. I've used the same product/technique many times before in a past life and I know the process works. I suspect the installation process (whether its something inherent to v5. 3 or something unique to the FTP server install process, I'm not sure) is n ot initializing these volumes with the dummy VTOC required by z/OS. I did not override the default volume format option of the installation. I suspect I need to run ICKDSF CPVOLUME FORMAT (or CPFMTXA FORMAT) agains t cyl 0 on each of these volumes (first documenting and resbuilding the allocation maps) and then run SALIPL to rewrite the Loader IPL text on 530RES. Be aware that I'll more than likely be doing this against a runn ing system without a backup (I'll probably try to DDR MAINT 123/124/125 to = another volume, for a small amount of insurance). I think that's what I need to do but I want to run it past the community because I don't want to go through that multi-day installation again. Do es this sound reasonable? Can you think of any other reason I'd be experiencing this error? Thanks in advance for your assistance. Dennis Schaffer -- Kris Buelens, IBM Belgium, VM customer support
Re: S213 Abend Backing Up 530RES Using z/OS FDR
Dennis--If I remember correctly, you'll also have to be able to do a DIRECTXA to reload the directory. I think there is a pointer on cyl 0 that points to the current system directory even tho the DRCT allocated area is somewhere else. I may be wrong, but just in case Jim Dennis Schaffer wrote: I just attempted to use DFDSS to dump 530RES using the syntax suggested b= y=20 Larry and I got another S213 abend for SYS1.VTOC. I think the problem is= =20 with the volume and not the dumping software. What do you think of my original suggestion (CPFMTXA FORMAT cyl 0,=20 followed by SALIPL to reload the IPL text) for correcting the problem? Thanks, Dennis -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: S213 Abend Backing Up 530RES Using z/OS FDR
Yes indeed: There are two hex values for DRCT (maybe not exact): X'40' inactive DRCT cylinder; X'C0' active DRCT cylinder. ICKDSF ALLOCATE writes X'40' for DRCT, and CP won't find an active DRCT anymore. 2008/1/17, Jim Bohnsack [EMAIL PROTECTED]: Dennis--If I remember correctly, you'll also have to be able to do a DIRECTXA to reload the directory. I think there is a pointer on cyl 0 that points to the current system directory even tho the DRCT allocated area is somewhere else. I may be wrong, but just in case Jim Dennis Schaffer wrote: I just attempted to use DFDSS to dump 530RES using the syntax suggested b= y=20 Larry and I got another S213 abend for SYS1.VTOC. I think the problem is= =20 with the volume and not the dumping software. What do you think of my original suggestion (CPFMTXA FORMAT cyl 0,=20 followed by SALIPL to reload the IPL text) for correcting the problem? Thanks, Dennis -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED] -- Kris Buelens, IBM Belgium, VM customer support
Re: S213 Abend Backing Up 530RES Using z/OS FDR
On Thursday, 01/17/2008 at 09:42 EST, Kris Buelens [EMAIL PROTECTED] wrote: VM doesn't use VTOCs to describe disk contents; the CP directory tells which cylinders are allocated as minidisks, and the CP allocation map tells CP which cylinders to use for PAGE, SPOOL, etc. After a CPFMTXA FORMAT, I used DITTO to look at the VTOC that *is* on the volume: --- Data Set Name --- sorted by NAME - Ext Begin-endReltrk, 1...5...10...15...20...25...30...35...40 seq Cyl-hd Cyl-hd numtrks *** VTOC EXTENT *** 0 0 0 0 0 0,1 *** FREE EXTENT *** 0 0 1 4 14 1,74 *** This volume is currently 1 percent full with 74 tracks available I had always thought that a full VTOC was written by DSF so that MVS would not attempt to allocate space on a CP-owned volume. It is a 5 cyl 3390. Alan Altmark z/VM Development IBM Endicott
Re: S213 Abend Backing Up 530RES Using z/OS FDR
Same here (for a VM resident) DITTO/ESA for VM DVT - Display VTOC Line 1 of 2 Unit 0130 VFRRES 3390 with 3339 cyls, 15 trks/cyl, 58786 bytes/trk --- Data Set Name ---Ext Begin-endReltrk, 1...5...10...15...20...25...30. seq Cyl-hd Cyl-hd numtrks *** VTOC EXTENT *** 0 0 0 0 0 0,1 *** FREE EXTENT *** 0 0 1 3338 14 1,50084 *** This volume is currently 0 % full with 50084 tracks available Maybe MVS is looking at some other field to find out if there still is free space 2008/1/18, Alan Altmark [EMAIL PROTECTED]: On Thursday, 01/17/2008 at 09:42 EST, Kris Buelens [EMAIL PROTECTED] wrote: VM doesn't use VTOCs to describe disk contents; the CP directory tells which cylinders are allocated as minidisks, and the CP allocation map tells CP which cylinders to use for PAGE, SPOOL, etc. After a CPFMTXA FORMAT, I used DITTO to look at the VTOC that *is* on the volume: --- Data Set Name --- sorted by NAME - Ext Begin-endReltrk, 1...5...10...15...20...25...30...35...40 seq Cyl-hd Cyl-hd numtrks *** VTOC EXTENT *** 0 0 0 0 0 0,1 *** FREE EXTENT *** 0 0 1 4 14 1,74 *** This volume is currently 1 percent full with 74 tracks available I had always thought that a full VTOC was written by DSF so that MVS would not attempt to allocate space on a CP-owned volume. It is a 5 cyl 3390. Alan Altmark z/VM Development IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
