7.3-2 Upgrade Inquiries

[Bill Salsbery]

We currently run 7.2-2 and have plans to upgrade to 7.3-2 on March 12th (Yes, we are bit behind). I was wondering of any major issues that I should be aware of going from 7.2-2 to 7.3-2. We are running on an Alpha 4100.

I was told that the existence of certain files in the SYS$SPECIFIC directories such as SYS$LIBRARY:DCLTABLES.EXE and SYS$SYTEM:DCL.EXE may interfere with the upgrade. Any thoughts or experiences with this?

I've also been told that each root must have a SYSCOMMON.DIR and it must have the same "File ID" as VMS$COMMON.DIR in SYS$SYSDEVICE:[000000]. How can I check this on my system and is this indeed an issue?

Again, any help much appreciated.

[Jan van den Ende]

Bill,

first of all,
WELCOME TO THE VMS FORUM!!

Your question really requires some more info to be able to give specific answers:

- are you running Cluster or Stand-alone?

- if cluster, are you planning a Rolling upgrade, or shutdown-upgrade-reboot?

Speculating for it in view uf your SYS$SPECIFIC formulation, I would _guess_ a standalone system, and I will try answering from that perspective, although "each root" seems to point to cluster....

-- SYS$LIBRARY & SYS$SYSTEM actually each refer to a searchlist of 2 directories:
SYS$SPECIFIC:[SYSLIB],SYS$COMMON:[SYSLIB], resp the corresponding [SYSEXE] dirs.

Now, in a standalone config that difference is not really spectacular, nor obvious, and more or less the same goes for heterogenuous clusters with a separate system disk per node.
In a homogenous cluster however, SYS$SPECIFIC is unique for each node, while SYS$COMMON _IS_ one and the same for multiple nodes. _THE_ big thing about VMS clusters!

Unless you are running VERY non-homogenous cluster, it is usual, and VERY advisable, to have as little as absolutely needed in the various SYS$SPECIFICs (different for each node), and as much as possible in SYS$COMMON
(only once for the cluster)
(but it IS possible to have intermediate configs; if that is your case, you should give us a LOT more detail).

So, assuming Standalone:
during the upgrade, the upgrade temporarily uses an alternate system root [SYSF], and practically the entire upgrade concerns SYS$COMMON
Only some explicit specific operations operate on those, and then the upgrade 'finds out' ALL your (actually active, and potentially configured but unused) specifics, has ways to address them non-transparantly, and upgrades them all one by one.

With this background we get to the SYSCOMMON.DIR issue.

Although you can see SYSCOMMON.DIR in every [SYS*] of your system disk, there SHOULD be none.
There SHOULD be a toplevel directory VMS$COMMON.DIR, and the aforementioned SYSCOMMONs _should_ be aliasses.
-- and because BACKUP had some issues with it in the passed, many systems that were restored from savesets have them confused :-(

So first, let us check that.
Do DIR/FULL for each [SYS*]SYSCOMMON
Look for FILE ID and Directory Backlink Pointer.
If your File ID's are NOT all the same, _OR_ your Directory Backlink Pointers are not _ALL_ (4,4,0), then
--- report that to us, and we need to correct that first !!!! ----

And if your DCLTABLES.EXE is in SYS$SPECIFIC, then who knows what else may be.

Perhaps you can do:
$ DIR SYS$SYSDEVICE:[SYS*.*]/OUT=.TXT,
and attach that textfile to a posting.
We will take it from there.

Enough for now, do come back with your info, and we will get you through!

Proost.

Have one on me.

Jan

[Galen Tackett]

Bill,

II'll assume that you have a cluster with a common system disk. If you had copies of, say, DCLTABLES in one or more SYS$SPECIFIC directories you would probably wind up with at least two nodes that wouldn't accept all the same DCL syntax after the upgrade. I'm not wise enough to comment in detail on what might happen with other, more sensitive images being located in SYS$SPECIFIC. But I can't imagine anything good would come of it.
:-)

To check if you have SYSCOMMON.DIR files that don't have the same File ID, try this:

$ DIR/FULL/OUTPUT=TMP.TXT SYS$SYSDEVICE:[SYS*]SYSCOMMON.DIR
$ SEARCH TMP.TXT "File ID:"

In the output from SEARCH check that the numbers after "File ID:" are the same on each line.

(I don't have privileged access to a VMS system from this room so can't try it out to make sure it works...)

Hope this helps,

Galen

[Bill Salsbery]

Sorry for the lack of info but we are running a single node system and are not clustering.

[Volker Halle]

Bill,

having OpenVMS-owned .EXE files in SYS$SPECIFIC: directories could be dangerous. The update should warn you, if there is a file with the same name in a specific directory, before it is going to update the file in SYS$COMMON.

You could use the following command to check for those files before the upgrade:

$ dir sys$sysdevice:*.exe

and maybe fix those problems first.

Volker.

[Bill Salsbery]

Jan,
Thanks so much for your help. See the attachment for the text file requested. - Bill

[Bill Salsbery]

I've also read that when I do a:
$ SHOW DEV/FILES SYS$SYSDEVICE
my file specs should be:
[VMS$COMMON.subdirectory]filename
however, I see them as:
[SYSCOMMON.subdirectory]filename

How do I fix this problem?

[Ian Miller.]

acquire the DFU tool - its on the freeware
CD and is available from
http://h71000.www7.hp.com/freeware/freeware70/dfu/
with earlier version in
http://h71000.www7.hp.com/freeware/freeware60/dfu/

this tool can check and correct the problem with VMS$COMMON (and do many other useful things).

[Bill Salsbery]

As an FYI, I rectified the alias directory issue by following the stpes outline in article: "Checking the Alias Directory Structure on the System Disk."

[Mobeen_1]

Bill,
This is something you need to be aware of, some of my colleagues performed this upgrade and they saw consistently on some systems the following

Following files in sys$loadable_images were complained about during the upgrade
SYS$DUDRIVER_MON.EXE
SYS$TUDRIVER_MON.EXE

On other systems there was nothing of that sort. On the systems that these were complained about, there are no issues. The systems are just working fine :)

regards
Mobeen

[Robert Gezelter]

Bill,

In addition to the alias information, a cautionary suggestion: Remember to check out your alternate system roots and do the needed housekeeping after the upgrade.

It is not uncommon to have alternate roots in a non-clustered environment, for any number of operational reasons. Following an upgrade, you will need to check each of the roots (including a boot) to make sure that all needed parameters have been reset as needed (e.g., run AUTOGEN).

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Bill,

I am awake again.

So, this concerns a standalone system.

I read that you already dealt with the SYSCOMMON issue. Good.

Your [SYS*] directories: Looks better than I feared after your initial request!

General note: some purging may be usefull,
Stay on the carefull side:
$ PURGE SYS$SYSDEVICE:[SYS*.*]/keep =2/before="-35-"
(keep at least 2 versions, and keep everything younger than 35 days)

For the LPD logs you can be more severe:
$ PURGE SYS$SYSDEVICE:[SYS*.lpd*]*.log


-- those directories that have _ONLY_ directories in them need deeper checking whether the files are in the sub-dir of COMMON or SPECIFIC

-- DIA$TOOLS needs be specific. So, ok

-- in SYS$STARTUP and SYSERR I find no problematic issues

-- SYSEXE: I do not know MVMS.EXE, but probably that one should move to SYS$COMMON:[SYSEXE}
Unless you have special requirements, move NETPROXY.DAT & NET$PROXY.DAT to common as well

-- the files in [SYSLIB] : better move them to common

-- I can only gueass why the *ZIP* files are in [SYSMAINT], but I would have them in common (and not in SYSMAINT anyhow). However, their location suggests they were put there once by Field Service, and should not matter, _OR_, if you actively use them, check the exact sysntax of the use before changing. They have no releation to your upgrade.


This summarizes what I could find.

Success.

Proost.

Have one on me.

Jan