In article <07073105454533_202003EE@antinode.org>,
sms@antinode.org (Steven M. Schweda) wrote:

> From: "P. Sture"
>
> > > For the record, VMS VAX installation save sets (VMS%%%.%) must be in
> > > the [000000] directory, or else the installation will fail. (VMS%%%.B
> > > may be an exception, when it's handled manually, outside the normal
> > > installation procedure, but it's normally found in the same place as the
> > > others, and they must be in [000000].)
> >
> > Is the [000000] restriction still true? Maybe I'm dreaming, but I
> > thought it had been relaxed at some point.
>
> According to the "OpenVMS VAX Version 7.3 Upgrade and Installation
> Manual",
>
> http://h71000.www7.hp.com/doc/73fina...30pro_003.html
>
> The procedure prompts you to specify which drive holds the
> distribution kit. Enter the device name for the source drive.
>
> If all you can specify is a device name, where will it look for the
> files?
>
> In "Chapter 5 Before Upgrading the OpenVMS VAX Operating System",
>
> http://h71000.www7.hp.com/doc/73fina...30pro_006.html
>
> it still says:
>
> 5.1.7 Save Set Location
>
> If you move the OpenVMS VAX save sets from the distribution media
> to the system disk or some other disk before beginning the
> upgrade, the save sets must be in the [000000] directory of the
> disk, or the upgrade will fail.
>
> [...]
>
>
> But if you can demonstrate that it works when they're somewhere else,
> I'll be happy to gain enlightenment.
>

I must indeed have been dreaming. I stand corrected.

--
Paul Sture

Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~stu...bookmarks.html

Steven M. Schweda wrote:
> http://h71000.www7.hp.com/doc/73fina...30pro_003.html
>
> The procedure prompts you to specify which drive holds the
> distribution kit. Enter the device name for the source drive.

One would have to look at the source code of the "temporary" startup.com
that is supplied with the B saveset (which then continues the
installation after you reboot) to see how it does it.

If it is smart enough, it would do an F$PARSE to extract the device
name, then mount that device, and then use the full spec (ok, device +
diretory to be sure!) for the backup oprations to restore the subsequent
savesets.

On Aug 1, 3:12 am, "P. Sture" wrote:
> In article <07073105454533_20200...@antinode.org>,
> s...@antinode.org (Steven M. Schweda) wrote:
>
>
>
> > From: "P. Sture"
>
> > > > For the record, VMS VAX installation save sets (VMS%%%.%) must be in
> > > > the [000000] directory, or else the installation will fail. (VMS%%%.B
> > > > may be an exception, when it's handled manually, outside the normal
> > > > installation procedure, but it's normally found in the same place as the
> > > > others, and they must be in [000000].)
>
> > > Is the [000000] restriction still true? Maybe I'm dreaming, but I
> > > thought it had been relaxed at some point.
>
> > According to the "OpenVMS VAX Version 7.3 Upgrade and Installation
> > Manual",
>
> >http://h71000.www7.hp.com/doc/73fina...30pro_003.html
>
> > The procedure prompts you to specify which drive holds the
> > distribution kit. Enter the device name for the source drive.
>
> > If all you can specify is a device name, where will it look for the
> > files?
>
> > In "Chapter 5 Before Upgrading the OpenVMS VAX Operating System",
>
> >http://h71000.www7.hp.com/doc/73fina...30pro_006.html
>
> > it still says:
>
> > 5.1.7 Save Set Location
>
> > If you move the OpenVMS VAX save sets from the distribution media
> > to the system disk or some other disk before beginning the
> > upgrade, the save sets must be in the [000000] directory of the
> > disk, or the upgrade will fail.
>
> > [...]
>
> > But if you can demonstrate that it works when they're somewhere else,
> > I'll be happy to gain enlightenment.
>
> I must indeed have been dreaming. I stand corrected.
>

Maybe I'm dreaming, too, but I'd swear I've used rooted logicals for
upgrades from save sets that I've copied down from tape to a disk
subdirectory. Much water has passed under the bridge since when,
though.

Doug Phillips wrote:
> Maybe I'm dreaming, too, but I'd swear I've used rooted logicals for
> upgrades from save sets that I've copied down from tape to a disk
> subdirectory.


Consider a case where an upgrade may need a couple of reboots during the
upgrade. The rooted logical may work for the first phase, but after the
first reboot, the rooted logical will no longer be available.

On Aug 1, 8:35 pm, JF Mezei wrote:
> Doug Phillips wrote:
> > Maybe I'm dreaming, too, but I'd swear I've used rooted logicals for
> > upgrades from save sets that I've copied down from tape to a disk
> > subdirectory.
>
> Consider a case where an upgrade may need a couple of reboots during the
> upgrade. The rooted logical may work for the first phase, but after the
> first reboot, the rooted logical will no longer be available.


I still find definitions like:
$assign/sys/exec $disk2:[updates.] updir:
or such in some "old" systartup's, but maybe I used that for something
else;-)

At the point when the system reboots, if it needs to, it's usually
finished with the source device, isn't it? At least I don't remember
ever needing the tape after the system rebooted except to install
another different update.

Updates from CD's might be different, but I still don't recall any
that need the source media available to finish the update after
reboot.

Everything the update needs should have been placed on the target disk
before reboot. After reboot, updates usually just clean up old files &
temporary work space & maybe do a verification.

Doug Phillips wrote:
> I still find definitions like:
> $assign/sys/exec $disk2:[updates.] updir:
> or such in some "old" systartup's, but maybe I used that for something
> else;-)

However, during an upgrade, STARTUP.COM doesn't get executed. The first
phase of the upgrade will reset SYSGEN to point to another /startup file
and it is that file which executes when the system reboots to continue
the upgrade, and thus, none of the local logical name definitions get
executed.

Savesets may or may not be extracted during the first phase, so it is a
gamble to know whether the upgrade will try to access savesets after the
first phase (or whether there will be reboots during the procedure)

On Aug 2, 1:11 am, JF Mezei wrote:
> Doug Phillips wrote:
> > I still find definitions like:
> > $assign/sys/exec $disk2:[updates.] updir:
> > or such in some "old" systartup's, but maybe I used that for something
> > else;-)
>
> However, during an upgrade, STARTUP.COM doesn't get executed. The first
> phase of the upgrade will reset SYSGEN to point to another /startup file
> and it is that file which executes when the system reboots to continue
> the upgrade, and thus, none of the local logical name definitions get
> executed.
>

Yes, I know how that works. The logical was defined before the update
began. When it hit the reboot point, the media could be removed and
the update would still succeed --- at least for all of the ones I
recall. Any multi-tape updates I recall would ask for the next tape to
be mounted during the current phase (before the reboot), and/or would
allow you to abort to $ after the post-reboot phase completed. The
MUP's are the only ones that come to mind.

> Savesets may or may not be extracted during the first phase, so it is a
> gamble to know whether the upgrade will try to access savesets after the
> first phase (or whether there will be reboots during the procedure)

I guess I was just lucky, then. I didn't copy the tapes to disk until
I met the TK50 and had enough free disk to do so. I could do the tape
to disk copy unattended during the day or overnight and reduce my
"babysitting" time in the evening or weekend when I did the update.
Once CD's came along, I no longer felt that need.

Still, I have yet to think of a single update or upgrade that required
the media to still be mounted after it did an auto-reboot. I don't
remember any that did a second reboot without asking permission, or re-
asking for the source device, either. Maybe you or someone else can
name one so I can stop wracking my tired old brain?