Re: Checking a DASD label
DDR is easy:
/* check a DASD label */
arg vaddr .
'PIPE',
'LITERAL SYSPRINT CONS',
'| LITERAL PROMPTS OFF',
'| LITERAL INPUT' vaddr 'DASD',
'| LITERAL TYPE 0 TO 0',
'| INSTORE REVERSE',
'| OUTSTORE',
'| > LABEL CHECK A'
'PIPE',
'CMS DDR LABEL CHECK A',
'| TAKE 1',
'| LOCATE /HCPDDR696I/',
'| SPECS W5',
'| VAR dasd_label'
IF symbol('dasd_label')<>'VAR'
THEN say vaddr 'is not a DASD'
ELSE say 'DASD label='dasd_label
Brian Nielsen
On Tue, 12 Dec 2006 09:22:33 +0100, Colin Allinson
<[EMAIL PROTECTED]> wrote:
>I am linking to a fullpack minidisk and, in preparation for a copy, I wa
nt
>to check the label on the source disk is what it should be.
>
>In our environment the label could have changed since the DASD was
>attached to the system so Q DASD DETAILS or looking at the RDEV block
>won't help.
>
>If the DASD has a standard CP/OS label then accessing it as a minidisk
>will get the information I require - but it is possible that some DASD
>might have only minimal labels. I have not found one to try yet but I
>don't think ACCESS will work for these.
>
>The only way I can think of is to physically read the first track of the
>disk and process it. Any ideas on the best way to do this? DDR seems a b
it
>unweildy in terms of getting the output into an EXEC/PIPE for processing
.
>
>My current code caters for most situations but I would like to build a
>comprehensive solution.
>
>Thanks in advance,
>
>Colin Allinson
>Amadeus Data Processing
Re: Checking a DASD label
On 12/12/06, Kris Buelens <[EMAIL PROTECTED]> wrote: >> If you only want the disk label, there is the DEVTYPE command. Kris, Brilliant - that is just what I needed. Now implemented and working. ** Why didn't I know about that - DUH!! ** Mind you, the question has been helpful because I have learnt a lot from Rob about the PIPELINES RUNTIME LIBRARY and other ways of doing things. Thanks Colin Allinson Amadeus Data Processing
Re: Checking a DASD label
If you only want the disk label, there is the DEVTYPE command. Kris, IBM Belgium, VM customer support Colin Allinson <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System 2006-12-12 09:22 Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Checking a DASD label I am linking to a fullpack minidisk and, in preparation for a copy, I want to check the label on the source disk is what it should be. In our environment the label could have changed since the DASD was attached to the system so Q DASD DETAILS or looking at the RDEV block won't help. If the DASD has a standard CP/OS label then accessing it as a minidisk will get the information I require - but it is possible that some DASD might have only minimal labels. I have not found one to try yet but I don't think ACCESS will work for these. The only way I can think of is to physically read the first track of the disk and process it. Any ideas on the best way to do this? DDR seems a bit unweildy in terms of getting the output into an EXEC/PIPE for processing. My current code caters for most situations but I would like to build a comprehensive solution. Thanks in advance, Colin Allinson Amadeus Data Processing
Re: Checking a DASD label
On 12/12/06, Rob van der Heij <[EMAIL PROTECTED]> wrote: >> Oh, you mean you still run the 10-year old plumbing? Tssj... ;-) Yes, we are still in the dark ages here - but I think this might give me an excuse to leap into the future. ;-) Do you have a link to the Marist page to get the download and install instructions. Thanks Colin
Re: Checking a DASD label
On 12/12/06, Colin Allinson <[EMAIL PROTECTED]> wrote: Sounds just what I need - but it does not work for me. I guess this is part of the alternate PIPES package? Oh, you mean you still run the 10-year old plumbing? Tssj... ;-) Yes, trackread was added back in 2001. You would need to pick up a version of the CMS Pipelines Runtime Library from the Pipelines page at Marist. Obviously you can keep it just on the users where you need that new function. Rob
Re: Checking a DASD label
On 12/12/06, Rob van der Heij <[EMAIL PROTECTED]> wrote: >> How 'bout trackread? Sounds just what I need - but it does not work for me. I guess this is part of the alternate PIPES package? Colin Allinson Amadeus Data Processing
Re: Checking a DASD label
On 12/12/06, Rob van der Heij <[EMAIL PROTECTED]> wrote: How 'bout trackread? Oh, yes... there also is 'trackwrite' that will take the tracks from trackread. You may find that easier to automate than driving DDR from input files, but that's up to you. Rob
Re: Checking a DASD label
On 12/12/06, Colin Allinson <[EMAIL PROTECTED]> wrote: I am linking to a fullpack minidisk and, in preparation for a copy, I want to check the label on the source disk is what it should be. How 'bout trackread? (below, 123 is the virtual address of my disk). The locate will select R03 (which holds the label). pipe trackread 123 0 0 | trackdeblock |locate 5.1 x03|fmtdump | cons The output of that is 03040050 E5D6D3F1 E5D6D3F1*VOL1VOL1* 0010 F3F1F0D9 C5E2F000 0005 *310RES0.* 0020 00404040 40404040 40404040 40404040*. * 0030 40404040 4000 C3D7 E5D6D340* .CPVOL * 0040 00010140 40404040 40404040 40404040*... * 0050 40404040 40404040 40404040 ** The first 8 byte is the CKD header. The x'04' says that there is a 4-byte key, and the next x'0050' says there is 80 byte data following the header. For CP volumes you will find the key VOL1 and the data start with VOL1 again. So if you're only looking for CP disks you might simply check for R03 to have the entire first 16 byte, and take the next 6 as your volser. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Checking a DASD label
I am linking to a fullpack minidisk and, in preparation for a copy, I want to check the label on the source disk is what it should be. In our environment the label could have changed since the DASD was attached to the system so Q DASD DETAILS or looking at the RDEV block won't help. If the DASD has a standard CP/OS label then accessing it as a minidisk will get the information I require - but it is possible that some DASD might have only minimal labels. I have not found one to try yet but I don't think ACCESS will work for these. The only way I can think of is to physically read the first track of the disk and process it. Any ideas on the best way to do this? DDR seems a bit unweildy in terms of getting the output into an EXEC/PIPE for processing. My current code caters for most situations but I would like to build a comprehensive solution. Thanks in advance, Colin Allinson Amadeus Data Processing
