I'm trying to set up for a large scale move of data from an Alphaserver to a remote newer Integrity; we need to do a bulk move (at a scheduled time) much faster than the intervening networks will allow. The total transfer will be around 4 terabytes but is able to be stored in savesets (or raw data, TBD) on those 300GB disks. We do not have tapes for these systems.

I connected a tabletop shelf of U320 Universal 300GB disks in a cabinet to the KZPEA controller in the Alpha, (HP V8.4), initialized them as ODS5 with default settings, created several test backups to different disks, shut down and moved the disks to our test Integrity box here (same model and SCSI controller as will be added to the real system). The Integrity is running VSI V8.4-2L1, SCSI controller IDs as LSI Logic 1030 U320, and is an HP branded and supported card.

The disks will not mount normally on the integrity; it reports them as offline. I can mount them /foreign, and I can read them (dumping blocks) in that state, but doing a normal mount fails. No errors reported.

We can set up a NAS device instead, stage the backups and ZIP them then transfer to SAN and reverse that on the other end; that is more time and steps, though it is our alternative (just moving one server to the other's site is not possible, and we don't have shadow licenses at either end to use that option, even if the SCSI problem didn't kill it).

I could swear I read about similar behavior in the past but haven't found reference to it (which may mean it was in the mass of data HPe is taking offline). Any thoughts on why this is happening and if theres a way to use the disks is appreciated. I _know_ these universal disks worked on older RX servers in the same shelves but those were built on the servers.

On 2021-12-22 02:28:12 +0000, Rich Jordan said:

> I'm trying to set up for a large scale move of data from an Alphaserver
> to a remote newer Integrity; we need to do a bulk move (at a scheduled
> time) much faster than the intervening networks will allow. The total
> transfer will be around 4 terabytes but is able to be stored in
> savesets (or raw data, TBD) on those 300GB disks...

INIT /ERASE /GPT /SYSTEM /STRUCT=5 [...] the disks on OpenVMS Alpha
(with adequate max files and headers set, as the INIT defaults are
~always bad), re-populate the disk contents, and try the transfer again.

Or just shovel the stuff over onto some SSD-based laptop (zip "-V" with
current zip 3.0 and unzip 6.0) and transfer that over to the new
network, as four terabytes of storage is dinky by present-day storage
standards. Or if the local laptops are as dinky as the OpenVMS Alpha
data, scrounge an external SSD or HDD and use that for the transfer.

--
Pure Personal Opinion | HoffmanLabs LLC

On Tuesday, December 21, 2021 at 9:54:59 PM UTC-5, Stephen Hoffman wrote:
> On 2021-12-22 02:28:12 +0000, Rich Jordan said:
>
> > I'm trying to set up for a large scale move of data from an Alphaserver
> > to a remote newer Integrity; we need to do a bulk move (at a scheduled
> > time) much faster than the intervening networks will allow. The total
> > transfer will be around 4 terabytes but is able to be stored in
> > savesets (or raw data, TBD) on those 300GB disks...
>
> INIT /ERASE /GPT /SYSTEM /STRUCT=5 [...] the disks on OpenVMS Alpha
> (with adequate max files and headers set, as the INIT defaults are
> ~always bad), re-populate the disk contents, and try the transfer again.
>
> Or just shovel the stuff over onto some SSD-based laptop (zip "-V" with
> current zip 3.0 and unzip 6.0) and transfer that over to the new
> network, as four terabytes of storage is dinky by present-day storage
> standards. Or if the local laptops are as dinky as the OpenVMS Alpha
> data, scrounge an external SSD or HDD and use that for the transfer.
>
>
>
>
> --
> Pure Personal Opinion | HoffmanLabs LLC
How about setting up the Itanium system as a cluster node that MSCP serves the target disks. Use shadowing to copy the droves and keep them current until the move? That way all you really need to move is any system disk data. I used this technique a few times where the target system was not yet ready for production but could keep up with data changes.

Dan

Den 2021-12-22 kl. 04:17, skrev abrsvc:
> On Tuesday, December 21, 2021 at 9:54:59 PM UTC-5, Stephen Hoffman wrote:
>> On 2021-12-22 02:28:12 +0000, Rich Jordan said:
>>
>>> I'm trying to set up for a large scale move of data from an Alphaserver
>>> to a remote newer Integrity; we need to do a bulk move (at a scheduled
>>> time) much faster than the intervening networks will allow. The total
>>> transfer will be around 4 terabytes but is able to be stored in
>>> savesets (or raw data, TBD) on those 300GB disks...
>>
>> INIT /ERASE /GPT /SYSTEM /STRUCT=5 [...] the disks on OpenVMS Alpha
>> (with adequate max files and headers set, as the INIT defaults are
>> ~always bad), re-populate the disk contents, and try the transfer again.
>>
>> Or just shovel the stuff over onto some SSD-based laptop (zip "-V" with
>> current zip 3.0 and unzip 6.0) and transfer that over to the new
>> network, as four terabytes of storage is dinky by present-day storage
>> standards. Or if the local laptops are as dinky as the OpenVMS Alpha
>> data, scrounge an external SSD or HDD and use that for the transfer.
>>
>>
>>
>>
>> --
>> Pure Personal Opinion | HoffmanLabs LLC
> How about setting up the Itanium system as a cluster node that MSCP serves the target disks. Use shadowing to copy the droves and keep them current until the move?

Maybe becuse:

"...and we don't have shadow licenses at either end to use that option..."

> That way all you really need to move is any system disk data. I used this technique a few times where the target system was not yet ready for production but could keep up with data changes.
>
> Dan
>

On 12/22/21 3:54 AM, Stephen Hoffman wrote:
> INIT /ERASE /GPT /SYSTEM /STRUCT=5 [...] the disks on OpenVMS Alpha
> (with adequate max files and headers set, as the INIT defaults are
> ~always bad), re-populate the disk contents, and try the transfer again.

The OP said, the disk is "offline". Maybe there is some magic in this
init command but I would not expect that anything on the disk will
change the status, so it will be "online".

The OP said, they want to move data. /GPT is not required for data disks
and I don't see any benefit having a file in the MFD which occupies LBN
1, the traditional home of the home block. It doesn't hurt, either, just
a small waste of disk space and mount time.

On 12/21/2021 9:28 PM, Rich Jordan wrote:

> I connected a tabletop shelf of U320 Universal 300GB disks in a cabinet to
> the KZPEA controller in the Alpha, (HP V8.4), initialized them as ODS5 with
> default settings, created several test backups to different disks, shut down
> and moved the disks to our test Integrity box here (same model and SCSI
> controller as will be added to the real system). The Integrity is running
> VSI V8.4-2L1, SCSI controller IDs as LSI Logic 1030 U320, and is an HP
> branded and supported card.

> but doing a normal mount fails. No errors reported.

What's the exact error message -- if the mount fails, there's got
to be a -F- in there somewhere.

Contact VSI support and verify that adapter is supported by VMS on IA64.

The output of sys$etc:scsi_info might be interesting.

--
-- Rob

Rich,

can you INIT and mount those disks successfully on the Itanium ? If not, there must be a hardware incompatibility.
And then write to them on the Alpha ?

Volker.

On Wednesday, December 22, 2021 at 4:59:57 AM UTC-6, Jan-Erik Söderholm wrote:
> Den 2021-12-22 kl. 04:17, skrev abrsvc:
> > On Tuesday, December 21, 2021 at 9:54:59 PM UTC-5, Stephen Hoffman wrote:
> >> On 2021-12-22 02:28:12 +0000, Rich Jordan said:
> >>
> >>> I'm trying to set up for a large scale move of data from an Alphaserver
> >>> to a remote newer Integrity; we need to do a bulk move (at a scheduled
> >>> time) much faster than the intervening networks will allow. The total
> >>> transfer will be around 4 terabytes but is able to be stored in
> >>> savesets (or raw data, TBD) on those 300GB disks...
> >>
> >> INIT /ERASE /GPT /SYSTEM /STRUCT=5 [...] the disks on OpenVMS Alpha
> >> (with adequate max files and headers set, as the INIT defaults are
> >> ~always bad), re-populate the disk contents, and try the transfer again.
> >>
> >> Or just shovel the stuff over onto some SSD-based laptop (zip "-V" with
> >> current zip 3.0 and unzip 6.0) and transfer that over to the new
> >> network, as four terabytes of storage is dinky by present-day storage
> >> standards. Or if the local laptops are as dinky as the OpenVMS Alpha
> >> data, scrounge an external SSD or HDD and use that for the transfer.
> >>
> >>
> >>
> >>
> >> --
> >> Pure Personal Opinion | HoffmanLabs LLC
> > How about setting up the Itanium system as a cluster node that MSCP serves the target disks. Use shadowing to copy the droves and keep them current until the move?
> Maybe becuse:
>
> "...and we don't have shadow licenses at either end to use that option..."
> > That way all you really need to move is any system disk data. I used this technique a few times where the target system was not yet ready for production but could keep up with data changes.
> >
> > Dan
> >

Yep, needless to say no cluster licenses either.

Hoff, I have a spare disk I can try that with. We always do the increased headers and files. If it works that should solve the problems.

ZIPping takes longer by far than the transfer on a local GbE network but I haven't tried just straight encapsulating ZIPs with no compression. That may be worth a try.

On Wednesday, December 22, 2021 at 9:46:48 AM UTC-6, Volker Halle wrote:
> Rich,
>
> can you INIT and mount those disks successfully on the Itanium ? If not, there must be a hardware incompatibility.
> And then write to them on the Alpha ?
>
> Volker.

Volker, I'll try to test but the integrity box is unavailable until next week; devs are doing builds on it and I had moved the disks back to the alpha.

Rich

On 22/12/2021 16:01, Rich Jordan wrote:
> On Wednesday, December 22, 2021 at 4:59:57 AM UTC-6, Jan-Erik Söderholm wrote:
>> Den 2021-12-22 kl. 04:17, skrev abrsvc:
>>> On Tuesday, December 21, 2021 at 9:54:59 PM UTC-5, Stephen Hoffman wrote:
>>>> On 2021-12-22 02:28:12 +0000, Rich Jordan said:
>>>>
>>>>> I'm trying to set up for a large scale move of data from an Alphaserver
>>>>> to a remote newer Integrity; we need to do a bulk move (at a scheduled
>>>>> time) much faster than the intervening networks will allow. The total
>>>>> transfer will be around 4 terabytes but is able to be stored in
>>>>> savesets (or raw data, TBD) on those 300GB disks...
>>>>
>>>> INIT /ERASE /GPT /SYSTEM /STRUCT=5 [...] the disks on OpenVMS Alpha
>>>> (with adequate max files and headers set, as the INIT defaults are
>>>> ~always bad), re-populate the disk contents, and try the transfer again.
>>>>
>>>> Or just shovel the stuff over onto some SSD-based laptop (zip "-V" with
>>>> current zip 3.0 and unzip 6.0) and transfer that over to the new
>>>> network, as four terabytes of storage is dinky by present-day storage
>>>> standards. Or if the local laptops are as dinky as the OpenVMS Alpha
>>>> data, scrounge an external SSD or HDD and use that for the transfer.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Pure Personal Opinion | HoffmanLabs LLC
>>> How about setting up the Itanium system as a cluster node that MSCP serves the target disks. Use shadowing to copy the droves and keep them current until the move?
>> Maybe becuse:
>>
>> "...and we don't have shadow licenses at either end to use that option..."
>>> That way all you really need to move is any system disk data. I used this technique a few times where the target system was not yet ready for production but could keep up with data changes.
>>>
>>> Dan
>>>
>
> Yep, needless to say no cluster licenses either.
>
> Hoff, I have a spare disk I can try that with. We always do the increased headers and files. If it works that should solve the problems.
>
> ZIPping takes longer by far than the transfer on a local GbE network but I haven't tried just straight encapsulating ZIPs with no compression. That may be worth a try.
>

Have you tried ZIP-ping with a lower compression?

I often used ZIP -3 which gave very slightly less compression but was
significantly faster

--
Chris

On 2021-12-22 15:33:21 +0000, hb said:

> On 12/22/21 3:54 AM, Stephen Hoffman wrote:
>> INIT /ERASE /GPT /SYSTEM /STRUCT=5 [...] the disks on OpenVMS Alpha
>> (with adequate max files and headers set, as the INIT defaults are
>> ~always bad), re-populate the disk contents, and try the transfer again.
>
> The OP said, the disk is "offline". Maybe there is some magic in this
> init command but I would not expect that anything on the disk will
> change the status, so it will be "online".

OP also stated they were able to access those volumes /FOREIGN. Which
would not be expected were this a SCSI controller-level issue and not a
higher-level issue, such as a MOUNT-level issue.

But without commands used and error codes shown, who knows?

> The OP said, they want to move data. /GPT is not required for data
> disks and I don't see any benefit having a file in the MFD which
> occupies LBN 1, the traditional home of the home block. It doesn't
> hurt, either, just a small waste of disk space and mount time.

/GPT use an entirely negligible about of storage, and it is a technique
that will prevent a down-revision Integrity console from stomping on
ODS-2 and ODS-5 storage as has been its wont, if EFI happened to find a
stale GPT around.

Newer EFI firmware allegedly warns before stomping, but I've long been
skeptical of depending on that.

And use of /ERASE gets HDD storage to a known state, clears out any
existing rubbish on the volume, and also provides a simplistic but
fairly effective test of the viability of the HDD storage.

Use of /ERASE and enabling highwater marketing can have benefits around
using SSD storage on some storage hardware too, but this is HDD and not
SSD, and potential SSD optimizations are are fodder for another time.

There were various "fun" bugs when transporting disks, and when
receiving supposedly-new HDD disks that already had GPTs present from
testing or whatever. The ugly hack that allows ODS-2 and ODS-5 to
(badly) coexistence with GPT did trip over some interesting cases, per
the developer that designed and implemented the hack. This'd also be
vastly easier with actual GPT partitioning support in OpenVMS, and
which would also provide a differently-hacked way to use ODS-2 and
ODS-5 volumes on HDDs and SSDs larger than 2 TiB at the cost of
negligible quadword arithmetic for each I/O, but that too is fodder for
another time.

OpenVMS arguably retired the "traditional location" of the homeblock at
V8.0 too, and that placement and the alternates have all been
acceptable for a while, once a few details such as some latent math
bugs were worked out with "unexpected" HDD and SSD storage volume sizes.

--
Pure Personal Opinion | HoffmanLabs LLC

What is the error message returned by MOUNT when it fails?

Make sure the Itanic has the latest mount patch. There was some
weirdness related to mounting a disk from an older system. Or just
$ INIT/ERASE on the Alpha before putting the data on it.

On Thursday, December 23, 2021 at 3:35:05 AM UTC-5, Michael Moroney wrote:
> What is the error message returned by MOUNT when it fails?
>
> Make sure the Itanic has the latest mount patch. There was some
> weirdness related to mounting a disk from an older system. Or just
> $ INIT/ERASE on the Alpha before putting the data on it.

Since you have an Integrity box locally, have you tried initializing the disks on that and mounting them on the alpha for the data transfer only?

Dan

On Wednesday, December 22, 2021 at 9:41:23 AM UTC-6, Robert A. Brooks wrote:
> On 12/21/2021 9:28 PM, Rich Jordan wrote:
>
> > I connected a tabletop shelf of U320 Universal 300GB disks in a cabinet to
> > the KZPEA controller in the Alpha, (HP V8.4), initialized them as ODS5 with
> > default settings, created several test backups to different disks, shut down
> > and moved the disks to our test Integrity box here (same model and SCSI
> > controller as will be added to the real system). The Integrity is running
> > VSI V8.4-2L1, SCSI controller IDs as LSI Logic 1030 U320, and is an HP
> > branded and supported card.
> > but doing a normal mount fails. No errors reported.
> What's the exact error message -- if the mount fails, there's got
> to be a -F- in there somewhere.
>
> Contact VSI support and verify that adapter is supported by VMS on IA64.
>
> The output of sys$etc:scsi_info might be interesting.
>
> --
> -- Rob

Rob,
going to have to wait for more details; dev is using the itanium for some emergency test builds for a year-end problem they just found. I'll try to get error log info later but the reported error looks just like trying to mount a tape that is not loaded:

$ MOUNT/SYSTEM ALTI64$DKB500: TALPHASYS
%MOUNT-I-OPRQST, medium is offline
%MOUNT-I-OPRQST, Please mount volume TALPHASYS in drive _ALTI64$DKB500

If I mount the drive foreign, it mounts and can see the volume name.

I tried wiping the drive and re-initializing it on the Alpha per Hoff's suggestion above, put some data on it, then moving it back to the RX server.
Interestingly the drive mounted, once. Generated two errors. I ran a backup to it from the RX, and that succeeded but generated error counts on the bus and the drive.
Dismount and try to remount and we're back to the medium is offline but a foreign mount is still fine, and generates no errors when dumping blocks (didn't try a write).

Unfortunately I got booted at that point; had to remove the disks and reboot the RX from the dev system disk and probably won't get access again until next week.

I moved the disk shelf back to the Alpha and it and the specific test drive are working completely error free.

Both our test RX server and the customer's have that SCSI card to attach a tape drive (our drive is long dead). They're sending me their spare so I can plug it into our test box to confirm the drive and the HBA are functional, just in case that is the problem, but that is also next week.

Thanks for responses!

Rich

On Thursday, December 23, 2021 at 10:33:07 AM UTC-5, Rich Jordan wrote:
> On Wednesday, December 22, 2021 at 9:41:23 AM UTC-6, Robert A. Brooks wrote:
> > On 12/21/2021 9:28 PM, Rich Jordan wrote:
> >
> > > I connected a tabletop shelf of U320 Universal 300GB disks in a cabinet to
> > > the KZPEA controller in the Alpha, (HP V8.4), initialized them as ODS5 with
> > > default settings, created several test backups to different disks, shut down
> > > and moved the disks to our test Integrity box here (same model and SCSI
> > > controller as will be added to the real system). The Integrity is running
> > > VSI V8.4-2L1, SCSI controller IDs as LSI Logic 1030 U320, and is an HP
> > > branded and supported card.
> > > but doing a normal mount fails. No errors reported.
> > What's the exact error message -- if the mount fails, there's got
> > to be a -F- in there somewhere.
> >
> > Contact VSI support and verify that adapter is supported by VMS on IA64..
> >
> > The output of sys$etc:scsi_info might be interesting.
> >
> > --
> > -- Rob
> Rob,
> going to have to wait for more details; dev is using the itanium for some emergency test builds for a year-end problem they just found. I'll try to get error log info later but the reported error looks just like trying to mount a tape that is not loaded:
>
> $ MOUNT/SYSTEM ALTI64$DKB500: TALPHASYS
> %MOUNT-I-OPRQST, medium is offline
> %MOUNT-I-OPRQST, Please mount volume TALPHASYS in drive _ALTI64$DKB500
>
> If I mount the drive foreign, it mounts and can see the volume name.
>
> I tried wiping the drive and re-initializing it on the Alpha per Hoff's suggestion above, put some data on it, then moving it back to the RX server.
> Interestingly the drive mounted, once. Generated two errors. I ran a backup to it from the RX, and that succeeded but generated error counts on the bus and the drive.
> Dismount and try to remount and we're back to the medium is offline but a foreign mount is still fine, and generates no errors when dumping blocks (didn't try a write).
>
> Unfortunately I got booted at that point; had to remove the disks and reboot the RX from the dev system disk and probably won't get access again until next week.
>
> I moved the disk shelf back to the Alpha and it and the specific test drive are working completely error free.
>
> Both our test RX server and the customer's have that SCSI card to attach a tape drive (our drive is long dead). They're sending me their spare so I can plug it into our test box to confirm the drive and the HBA are functional, just in case that is the problem, but that is also next week.
>
> Thanks for responses!
>
> Rich

What is the interface card in the Integrity box?

On Wednesday, December 22, 2021 at 1:46:18 PM UTC-6, Stephen Hoffman wrote:
> On 2021-12-22 15:33:21 +0000, hb said:
>
> > On 12/22/21 3:54 AM, Stephen Hoffman wrote:
> >> INIT /ERASE /GPT /SYSTEM /STRUCT=5 [...] the disks on OpenVMS Alpha
> >> (with adequate max files and headers set, as the INIT defaults are
> >> ~always bad), re-populate the disk contents, and try the transfer again.
> >
> > The OP said, the disk is "offline". Maybe there is some magic in this
> > init command but I would not expect that anything on the disk will
> > change the status, so it will be "online".
> OP also stated they were able to access those volumes /FOREIGN. Which
> would not be expected were this a SCSI controller-level issue and not a
> higher-level issue, such as a MOUNT-level issue.
>
> But without commands used and error codes shown, who knows?
> > The OP said, they want to move data. /GPT is not required for data
> > disks and I don't see any benefit having a file in the MFD which
> > occupies LBN 1, the traditional home of the home block. It doesn't
> > hurt, either, just a small waste of disk space and mount time.
> /GPT use an entirely negligible about of storage, and it is a technique
> that will prevent a down-revision Integrity console from stomping on
> ODS-2 and ODS-5 storage as has been its wont, if EFI happened to find a
> stale GPT around.
>
> Newer EFI firmware allegedly warns before stomping, but I've long been
> skeptical of depending on that.
>
> And use of /ERASE gets HDD storage to a known state, clears out any
> existing rubbish on the volume, and also provides a simplistic but
> fairly effective test of the viability of the HDD storage.
>
> Use of /ERASE and enabling highwater marketing can have benefits around
> using SSD storage on some storage hardware too, but this is HDD and not
> SSD, and potential SSD optimizations are are fodder for another time.
>
> There were various "fun" bugs when transporting disks, and when
> receiving supposedly-new HDD disks that already had GPTs present from
> testing or whatever. The ugly hack that allows ODS-2 and ODS-5 to
> (badly) coexistence with GPT did trip over some interesting cases, per
> the developer that designed and implemented the hack. This'd also be
> vastly easier with actual GPT partitioning support in OpenVMS, and
> which would also provide a differently-hacked way to use ODS-2 and
> ODS-5 volumes on HDDs and SSDs larger than 2 TiB at the cost of
> negligible quadword arithmetic for each I/O, but that too is fodder for
> another time.
>
> OpenVMS arguably retired the "traditional location" of the homeblock at
> V8.0 too, and that placement and the alternates have all been
> acceptable for a while, once a few details such as some latent math
> bugs were worked out with "unexpected" HDD and SSD storage volume sizes.
> --
> Pure Personal Opinion | HoffmanLabs LLC

Hoff, replied to Rob also with command and output, but didn't get the errorlog info before the RX got commandeered by our dev team, I can get on it again next week. It is booted off a different system disk for dev work...

Did as you suggested, and the drive mounted (/system), but only once on the RX. Got bus and drive errors trying to write to the disk, but a backup to saveset did complete. I then dismounted the drive, tried to remount it and got the offline response. Mounted foreign again, and that worked, and dumping a lot of blocks generated no errors. I didn't get a chance to pull event log entries before losing access to the RX.

Command used and response:

$ MOUNT/SYSTEM ALTI64$DKB500: TALPHASYS
%MOUNT-I-OPRQST, medium is offline
%MOUNT-I-OPRQST, Please mount volume TALPHASYS in device _ALTI64$DKB500

The operator request I didn't log but it was the standard please mount volume. Replying to it didn't work, it generated a new identical request

Sorry for the disjointed responses. Work is supposed to slow down and let us catch up and clean up, but instead we're getting hammered.

Rich

On Thursday, December 23, 2021 at 7:34:35 AM UTC-6, abrsvc wrote:
> On Thursday, December 23, 2021 at 3:35:05 AM UTC-5, Michael Moroney wrote:
> > What is the error message returned by MOUNT when it fails?
> >
> > Make sure the Itanic has the latest mount patch. There was some
> > weirdness related to mounting a disk from an older system. Or just
> > $ INIT/ERASE on the Alpha before putting the data on it.
> Since you have an Integrity box locally, have you tried initializing the disks on that and mounting them on the alpha for the data transfer only?
>
> Dan

Dan, nope; may try next week.

On 12/23/2021 10:33 AM, Rich Jordan wrote:

> Rob,
> going to have to wait for more details; dev is using the itanium for some emergency test builds for a year-end problem they just found. I'll try to get error log info later but the reported error looks just like trying to mount a tape that is not loaded:
>
> $ MOUNT/SYSTEM ALTI64$DKB500: TALPHASYS
> %MOUNT-I-OPRQST, medium is offline
> %MOUNT-I-OPRQST, Please mount volume TALPHASYS in drive _ALTI64$DKB500

It's time to use DKDRIVER logging to get more detail.

The DKDRIVER SDA extension will use a ring buffer to log the SCSI commands sent
and the responses back from the controller.

$ anal/sys

OpenVMS system analyzer

SDA> dklog
DKLOG command format:
DKLOG SHOW {<devnam>|/ADDRESS=<ucbaddr>} [/DIRECTION=[FORWARD|BACKWARD(D)]
DKLOG START {<devnam>|/ADDRESS=<ucbaddr>}[/ENTRIES=[<count>|128(D)]
DKLOG STOP {<devnam>|/ADDRESS=<ucbaddr>}
DKLOG CLEAR {<devnam>|/ADDRESS=<ucbaddr>}
<devnam> acts on all matching device UCBs, <ucbaddr> acts on a single UCB.
SDA>

So, you'd do

SDA> DKLOG START <devnam>
SDA>exit
$ mount . . .
anal/sys
SDA> SET OUT <filename>
SDA> DKLOG SHOW <devnam>
SDA> EXIT
$

--
-- Rob

On 12/23/2021 10:41 AM, Rich Jordan wrote:
> On Wednesday, December 22, 2021 at 1:46:18 PM UTC-6, Stephen Hoffman wrote:
>> On 2021-12-22 15:33:21 +0000, hb said:
>>
>>> On 12/22/21 3:54 AM, Stephen Hoffman wrote:
>>>> INIT /ERASE /GPT /SYSTEM /STRUCT=5 [...] the disks on OpenVMS Alpha
>>>> (with adequate max files and headers set, as the INIT defaults are
>>>> ~always bad), re-populate the disk contents, and try the transfer again.
>>>
>>> The OP said, the disk is "offline". Maybe there is some magic in this
>>> init command but I would not expect that anything on the disk will
>>> change the status, so it will be "online".
>> OP also stated they were able to access those volumes /FOREIGN. Which
>> would not be expected were this a SCSI controller-level issue and not a
>> higher-level issue, such as a MOUNT-level issue.
>>
>> But without commands used and error codes shown, who knows?
>>> The OP said, they want to move data. /GPT is not required for data
>>> disks and I don't see any benefit having a file in the MFD which
>>> occupies LBN 1, the traditional home of the home block. It doesn't
>>> hurt, either, just a small waste of disk space and mount time.
>> /GPT use an entirely negligible about of storage, and it is a technique
>> that will prevent a down-revision Integrity console from stomping on
>> ODS-2 and ODS-5 storage as has been its wont, if EFI happened to find a
>> stale GPT around.
>>
>> Newer EFI firmware allegedly warns before stomping, but I've long been
>> skeptical of depending on that.
>>
>> And use of /ERASE gets HDD storage to a known state, clears out any
>> existing rubbish on the volume, and also provides a simplistic but
>> fairly effective test of the viability of the HDD storage.
>>
>> Use of /ERASE and enabling highwater marketing can have benefits around
>> using SSD storage on some storage hardware too, but this is HDD and not
>> SSD, and potential SSD optimizations are are fodder for another time.
>>
>> There were various "fun" bugs when transporting disks, and when
>> receiving supposedly-new HDD disks that already had GPTs present from
>> testing or whatever. The ugly hack that allows ODS-2 and ODS-5 to
>> (badly) coexistence with GPT did trip over some interesting cases, per
>> the developer that designed and implemented the hack. This'd also be
>> vastly easier with actual GPT partitioning support in OpenVMS, and
>> which would also provide a differently-hacked way to use ODS-2 and
>> ODS-5 volumes on HDDs and SSDs larger than 2 TiB at the cost of
>> negligible quadword arithmetic for each I/O, but that too is fodder for
>> another time.
>>
>> OpenVMS arguably retired the "traditional location" of the homeblock at
>> V8.0 too, and that placement and the alternates have all been
>> acceptable for a while, once a few details such as some latent math
>> bugs were worked out with "unexpected" HDD and SSD storage volume sizes.
>> --
>> Pure Personal Opinion | HoffmanLabs LLC
>
> Hoff, replied to Rob also with command and output, but didn't get the errorlog info before the RX got commandeered by our dev team, I can get on it again next week. It is booted off a different system disk for dev work...
>
> Did as you suggested, and the drive mounted (/system), but only once on the RX. Got bus and drive errors trying to write to the disk, but a backup to saveset did complete. I then dismounted the drive, tried to remount it and got the offline response. Mounted foreign again, and that worked, and dumping a lot of blocks generated no errors. I didn't get a chance to pull event log entries before losing access to the RX.
>
> Command used and response:
>
> $ MOUNT/SYSTEM ALTI64$DKB500: TALPHASYS
> %MOUNT-I-OPRQST, medium is offline
> %MOUNT-I-OPRQST, Please mount volume TALPHASYS in device _ALTI64$DKB500
>
> The operator request I didn't log but it was the standard please mount volume. Replying to it didn't work, it generated a new identical request
>
> Sorry for the disjointed responses. Work is supposed to slow down and let us catch up and clean up, but instead we're getting hammered.
>
> Rich
>

How many physical disks have you tried? If only one, try more.

Not that I'm an expert on this issue, but, it sure sounds to me as if the disk,
or cables, or something has a problem. Talking HW, not software.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2021-12-23 15:41:52 +0000, Rich Jordan said:

> $ MOUNT/SYSTEM ALTI64$DKB500: TALPHASYS
> %MOUNT-I-OPRQST, medium is offline
> %MOUNT-I-OPRQST, Please mount volume TALPHASYS in device _ALTI64$DKB500

For grins, do try a private MOUNT, too. One without the use of /SYSTEM.

--
Pure Personal Opinion | HoffmanLabs LLC

On 12/23/2021 10:33 AM, Rich Jordan wrote:

> Rob,
> going to have to wait for more details; dev is using the itanium for some emergency test builds for a year-end problem they just found. I'll try to get error log info later but the reported error looks just like trying to mount a tape that is not loaded:
>
> $ MOUNT/SYSTEM ALTI64$DKB500: TALPHASYS
> %MOUNT-I-OPRQST, medium is offline
> %MOUNT-I-OPRQST, Please mount volume TALPHASYS in drive _ALTI64$DKB500
>
> If I mount the drive foreign, it mounts and can see the volume name.

What error do you get from $ MOUNT /SYSTEM/NOASSIST?

On Tuesday, December 21, 2021 at 9:28:14 PM UTC-5, Rich Jordan wrote:

> The disks will not mount normally on the integrity; it reports them as offline. I can mount them /foreign, and I can read them (dumping blocks)
: > I could swear I read about similar behavior in the past but haven't found reference to it

It also rings a bell to me, but could find anything. I'm thinking of an issue related the the disk Geometry as reported by $ SHOW DEVICE/FULL
For example
* Cluster size 1
* Total blocks 1000 Sectors per track 6
* Total cylinders 34 Tracks per cylinder 5

Best I know it only comes into play with redundant HOMEBLOCK placement and alternate homeblocks.
The clustersize plays also a role in those (see: VMS File System Internals 2.5.1.2)
Options for that are INIT/HOME=[ GEOMETRY | FIXED (default) | CONTIGUOUS ]

Can you INITIALIZE one on the Itanium, MOUNT and compare the geometry results?

Can you INITIALIZE one on the Itanium, MOUNT on the Alpha, copy data, dismount, mount on Itanium?

Not at all the same problem, but possibly in a similar vein to:
https://stromasys.atlassian.net/wiki/spaces/KBP/pages/24674337

hth,
Hein.

On Thursday, December 23, 2021 at 3:02:11 PM UTC-6, Stephen Hoffman wrote:
> On 2021-12-23 15:41:52 +0000, Rich Jordan said:
>
> > $ MOUNT/SYSTEM ALTI64$DKB500: TALPHASYS
> > %MOUNT-I-OPRQST, medium is offline
> > %MOUNT-I-OPRQST, Please mount volume TALPHASYS in device _ALTI64$DKB500
> For grins, do try a private MOUNT, too. One without the use of /SYSTEM.
> --
> Pure Personal Opinion | HoffmanLabs LLC

Hoff
I'm certain I did MOUNT/OVER=IDENT a couple of times when I didn't remember the volume label. Same error.

Thanks

On Thursday, December 23, 2021 at 9:48:38 AM UTC-6, Robert A. Brooks wrote:
> On 12/23/2021 10:33 AM, Rich Jordan wrote:
>
> > Rob,
> > going to have to wait for more details; dev is using the itanium for some emergency test builds for a year-end problem they just found. I'll try to get error log info later but the reported error looks just like trying to mount a tape that is not loaded:
> >
> > $ MOUNT/SYSTEM ALTI64$DKB500: TALPHASYS
> > %MOUNT-I-OPRQST, medium is offline
> > %MOUNT-I-OPRQST, Please mount volume TALPHASYS in drive _ALTI64$DKB500
> It's time to use DKDRIVER logging to get more detail.
>
> The DKDRIVER SDA extension will use a ring buffer to log the SCSI commands sent
> and the responses back from the controller.
>
> $ anal/sys
>
> OpenVMS system analyzer
>
> SDA> dklog
> DKLOG command format:
> DKLOG SHOW {<devnam>|/ADDRESS=<ucbaddr>} [/DIRECTION=[FORWARD|BACKWARD(D)]
> DKLOG START {<devnam>|/ADDRESS=<ucbaddr>}[/ENTRIES=[<count>|128(D)]
> DKLOG STOP {<devnam>|/ADDRESS=<ucbaddr>}
> DKLOG CLEAR {<devnam>|/ADDRESS=<ucbaddr>}
> <devnam> acts on all matching device UCBs, <ucbaddr> acts on a single UCB..
> SDA>
>
> So, you'd do
>
> SDA> DKLOG START <devnam>
> SDA>exit
> $ mount . . .
> anal/sys
> SDA> SET OUT <filename>
> SDA> DKLOG SHOW <devnam>
> SDA> EXIT
> $
>
> --
> -- Rob

I will try that as soon as I can. Dev is still owning the machine.

Thanks