DECnet proxy files converted during upgrade to 7.3-2?

[Chris Warne_1]

Hi.
I've come across a rather strange problem when upgrading a couple of Alphas from 7.2-1 to 7.3-2.
For operational reasons, we use a pre-built upgraded "image" then copy various config files and run procedures from the existing systems, then boot off the new image to achieve the upgrade. Two of the files copied are NETPROXY.DAT and NET$PROXY.DAT. On two particular systems, after the upgrade, doing a SHOW/PROXY * or SHOW/PROXY/OLD * results in a "%RMS-W-RTB, 298124 byte record too large for user's buffer" error and the OPCOM message "%SECSRV-W-NORDPROXYREC, proxy record is internally inconsistent; cannot read it".

We've done this procedure lots of time before, and I've never seen this problem, and can find no info on it anywhere! Have we just been lucky up to now with copying the "old" proxy files?
(Needless to say there's no problems with proxies prior to the upgrade on these systems).

Any ideas greatfully received!

Chris

[Jan van den Ende]

Chris,

I am pretty convinced that your copy somehow blew up


"%RMS-W-RTB, 298124 byte record


the file with this info is DEFINITELY not kosher.

RMS does not do well on records over 32767 bytes.

First thing to do is check DIR/FULL on copy source & target, and compare.

My guess would be that you used FTP for the copy, and your record format got corrupted.

I DO hope that is the case, it would be the easiest thing to correct.


I have NO knowledge of any change in them. And, since we did rolling upgrades from 7.2-1 to 7.3-1, and 7.3-1 to 7.3-2, during which times ONE AND THE SAME file was SHARED (using Logical Name) between the systems running old and those running upgraded VMS, I am quite convinced that the same file is unchanged accessible from the different versions.

hth

Proost.

Have one on me.

Jan

[Chris Warne_1]

Thanks for the reply, Jan, but I'm afraid I didn't use FTP to copy - just a straight disk to disk copy on the same node.
Even if I subseuqntly copy the files again after the upgrade (and restart the security server), the problem presists - i.e. it's as if the 7.3-2 system can't read the 7.2-1 proxy files!

Having experimented a little more, I've been able to reproduce the problem on three different systems. However, one point of note - on systems I've tried where the proxy data files (and SYSUAF) are not on the system disk, the problem doesn't occur!

[Kris Clippeleyr]

Chris,

A very strange phenomenon indeed.
I just did the test (copied over NETPROXY.DAT & NET$PROXY.DAT from a 7.2-1 system to a 7.3-2 system) and everything keeps on working. The Security Server restarts like a charm. So I think that the format of the files wasn't altered.
How did you copy them (COPY or BACKUP)?
I used BACKUP/IGNORE=INTERLOCK (I know, also not save, since NET$PROXY is held open by the Security Server).

Greetz,

Kris (aka Qkcl)

[Volker Halle]

Chris,

NETPROXY.DAT and NET$PROXY.DAT are simple index-sequential files with 2 resp. 1 key(s). You can check them with ANAL/RMS and dump their records with DUMP/REC.

Did you check HELP/MESS NORDPROXYREC ?

Volker.

[Hein van den Heuvel]

Like Kirs wrote: "How did you copy them (COPY or BACKUP)?"

Kris wrote "I used BACKUP/IGNORE=INTERLOCK (I know, also not save, since NET$PROXY is held open by the Security Server."

You really don't want to do that, or at least validate the resulting file.

I suggest convert/share to copy this file, and others like it (vmsmail_profile, sysuaf, rightslist,...)

It might be somewhat interesting to find the corruption point. Suggestions:
- anal/rms [/int]
- search/num/forn=non (just to get the last record number before the corruption
- dump/reco=star=n (from search). This will give an rfa to look at.

maybe you can recognize the data corruption pattern, maybe not.

Hein.

[Chris Warne_1]

Thanks for the help, guys, but I've sorted it - I'm afraid it was a bit of a red herring!
The procedure used for transferring the files was copying them from SYS$COMMON, not SYS$SPECIFIC, and there were spurious versions in the common area - don't know where these came from (perhaps pre-format change?) but they were causing the problem.

So, nothing to do with the upgrade, or the copying mechanism as sych, just a dodgy configuration of our systems.

Regards,

Chris (with a red face)