Find the date a drive was initialized?

[C Nipper]

I work on a govn't system that swaps drives constantly and we use a proprietary suite of tools for copying disks. Any disk that is copied using this suite maintains it's original modified date on dir/full, so there's no way to tell when the disk was made using dir/full.

Is there any way to tell when a disk was initialized? Is there another way to tell when a disk (i suppose volume would be more accurate) was created?

Thank you for any help you can give.

[Jan van den Ende · Accepted solution]

C,

to begin with:

WELCOME to the VMS ITRC Forum.

I am not sure how I should read your question.

The answer to the literal title question is simple:
the CREATION DATE of the 000000.DIR (and/or the various .SYS files) on the volume are the date/time of the INIT command.

But if the disk was created by a BACKUP/IMAGE with the disk as output device (and without the /NOINIT qualifier), then the data (including dates) of the original saveset is used, and there is no way (at least, that _I_ know of) to tell when that was done.

Barring special psychic powers, whatever those "proprietary tools" are doing with the relevant device dates, is for those that know those tools to tell.

Proost.

Have one on me.

jpe

[C Nipper]

Thanks for the quick response. I'll check with them (they work in the same cube farm as me) about what it's using as it's copy procedure and respond back.

[Hoff]

There are certainly ways to implement what you want here, particularly given this unspecified suite of tools.

Depending on the architecture, these can be subtle, or something akin to an ACE can be added to key structures.

I'm familiar with a number of replication schemes and related issues, including OpenVMS I64 and its GPT-level structures. Depending on the specific local requirements, there are various mechanisms and schemes that can be utilized.

The typical approach used by replication tools is block-oriented (for reasons of EFI and otherwise), and this most definitely does not have a replication date. Particularly with typical GPT hackery these tools often perform.

I've posted up an intro (and pointers) to the GPT over at http://64.223.189.234/node/112 -- the other volume-level structure involved here ("above" the GPT) is the ODS Storage Control Block (SCB), then whatever the application might choose to apply on top of (or into) the system-level volume structures; GPT or ACL-level mechanisms, in the FAT partition, etc.

And it occurs to me that if this is OpenVMS I64 system disk, the FAT partition likely contains the date details as the usual means to replicate disks preserves these structures. When the system disk is instantiated via standard tools and mechanisms, EFI$CP writes the FAT structures, including dates.

I haven't yet posted up particular details of the FAT-level implementation present within OpenVMS I64 and EFI, but it's familiar turf and certainly worth an article or three.

Stephen Hoffman
HoffmanLabs LLC

[John Gillings]

C,

I'm not entirely sure which date you really want? That of the original volume before it was copied? Or, the date the target volume was initialized, before dumping the replicated data on it? I suspect you want the latter.

Hunting around the physical blocks at the beginning of the disk, I've found a field that looks like a date stamp at about the right time (ie: shortly before the creation date of INDEXF.SYS & friends on an unreplicated disk). Depending on how your tools replicate the disk, this date might be a more accurate reflection of when the physical disk was initialised than the directory dates. Very crude DCL to pull it out:

$ IF p1.EQS."" THEN INQUIRE p1 "Device"
$ f=F$PARSE("[000000]INDEXF.SYS",p1)
$ OPEN/READ/SHARE IN 'F'
$ READ IN BLK1
$ READ IN BLK2
$ CLOSE IN
$ INITDATE[32,32]=F$CVUI(%X200,32,BLK2)
$ INITDATE[0,32]=F$CVUI(%X220,32,BLK2)
$ WRITE SYS$OUTPUT F$FAO("!%D",F$CVUI(32,32,F$FAO("!AD",8,INITDATE)))
$ EXIT

Note, I found this by examining the hex dump for numbers that looked like a VMS date at about the right time. I've sanity checked it on a few disks and it looks reasonable. A more rigourous approach would be to cross check it against the source code, or the IDSM.

[Hein van den Heuvel]

John wrote... Note, I found this by examining the hex dump for numbers that looked like a VMS date at about the right time. I've sanity checked it on a few disks and it looks reasonable. A more rigourous approach would be to cross check it against the source code, or the IDSM.

That's the HOME BLOCK you are looking at.

It's actually documented in the
"VMS File System internals"
Table 2-15
and Figure 2-19
"Layout of the First Extent of the Index File"

Also on the system:
$ pipe libr/extr=hm2def/out=sys$output sys$Library:sys$lib_c.tlb | searc sys$pipe date
unsigned __int64 hm2$q_credate; /* volume creation date */
unsigned __int64 hm2$q_revdate; /* volume revision date */
unsigned __int64 hm2$q_copydate; /* volume copy date */
$ pipe libr/extr=$hm2def/out=sys$output sys$Library:lib.mlb | searc sys$pipe date
$EQU HM2$Q_CREDATE 60
$EQU HM2$Q_REVDATE 88
$EQU HM2$Q_COPYDATE 146

So I think your code is off by 4 bytes.
That x220 should be x1E0.
I would write it as 60*8 myself.

I don't think there is an F$GETDVI for this.

Cheers,
Hein van den Heuvel

[John Gillings]

Hein,

>So I think your code is off by 4 bytes.
>That x220 should be x1E0.

Thanks, you are, of course correct, and thanks for confirming the fields and giving them names. I was confusing myself with little endian and reading dumps right to left. The low longword should have been the previous line! Since the low 32 bits of a time value only represents a bit over 7 minutes, it doesn't make a whole lot of difference where those bits come from, the result was still well within reason! ;-)

>I would write it as 60*8 myself

Yes, I originally wrote it as %X40*8 based on the DUMP display, but changed it to the constant hoping to reduce the confusion of a mixed radix expression!

From the disks I've looked at, it appears REVDATE and COPYDATE may be latent.

[Hoff]

The home block moved with GPT disks; all home blocks are now alternate home blocks, and the primary home block is no longer required nor necessarily present.

[Dean McGorrill]

Interesting, I ran your prodecure john on
a newly created stripeset on a hsz70..

$ @diskdate;-1 $1$dkc204
8-NOV-2000 17:15:27.63
$ @diskdate; $1$dkc204
8-NOV-2000 17:08:38.40

..the second one was with x1e0. I'm not
sure where time 8-nov-2000 came from,
as vms doesn' see the real disks. not
that it matters, curious.

[Hein van den Heuvel]

Dean, in my expereince it is failrly common to pick up the remnants of an old file structure in a newly created HSZ/HSG logical unit. Even with stiping and raid-5 and such. The home block is simply block 2, and repeated several times more.
To satisfy your curiosity do a DUMP/BLOC=(STA=2,COU=1) device:
Look for the last few lines from byte 466 onwards (x1CC) there should be readily readable text in 12 byte space filled chunks:
- Structure Name
- Volume Name
- Owner Name
and the clincher
- "DECFILE11B"

Hein.