Problem with VMS83A_UPDATE V4.0

[Ken Robinson]

I just upgraded our test alpha server from v7.3-2 to v8.3 and applied the VMS83A_UPDATE V4.0 patch. At the end of the percent counting, when it got to 90%, it suddenly prompted "SYSVERSION>" not knowing what to do, I did a control-z. When the system rebooted the version shows as OpenVMS XB9P-N2O. After some research, I discovered how to run SYSVER to set the version back correctly. This looks like a problem with the patch.

Ken

[Karl Rohwedder]

Ken,

this is done in the routine PCSI_POSTINSTALL.COM:
...
$!This kit provides a new SYS$BASE_IMAGE.EXE. The the system
$!version needs to be reset. This is done by creating and running
$!a small COM file to run the version that was initialized above.
$!
$ os_version = "V8.3"
$ Current_default = F$ENVIRONMENT ("DEFAULT")
$ Set Default SYS$COMMON:[SYS$LDR]
$ ww1 = "write work_1"
$ open/write work_1 post_setsysver.com
$ ww1 "$ run sysver"
$ ww1 "REPLACE ""''os_version'""
$ ww1 "write"
$ ww1 "exit"
$ ww1 "$ exit"
$ close work_1
$!
$!Now run the com file
$!
$ @post_setsysver.com
...
But why it didn't work and asked you instead I don't know (never had a problem with this kit). Have you redefined SYS$COMMAND or such? You should have entered V8.3 instead of ctrl/z. But you can easlily fix it using the above sequence of commands.

regards kalle

[Hoff]

Do you have a WORK_1 logical name around?

--

Though you don't need it, here's the shorter version of the sequence that kalle showed, with this version largely extracted from the OpenVMS FAQ:

$ SET DEFAULT SYS$COMMON:[SYS$LDR]
$ RUN SYSVER
REPLACE V8.3
WRITE
^Z

[Ken Robinson]

I checked the command procedure I used to apply the patch. Just before the

$ prod install

line, I have these defines:

$ define/sys/nolog no_ask$backup true
$ define/sys/nolog no_ask$reboot true
$ define/job/nolog archive_old no
$ def/u sys$input sys$command

I've used this command procedure to install other UPDATE patches and never had a problem before. Shouldn't the patch mechanism work correctly with or with out the last define?

[Karl Rohwedder]

The SYSVER image tries to read its input from SYS$INPUT (i.e. the command procedure). Your definition redirects this to the terminal, could be the culprit.

regards Kalle

[Ken Robinson]

I just did a quick test and that is indeed the problem. I also wrote this quick test command procedure that uses the PIPE command instead using a temporary file. If I don't define sys$input as sys$pipe, the program prompts. When I define sys$input as sys$pipe, it works fine. Maybe this should be incorporated into the patch.

I've attached the procedure.

[Hoff]

You can't redefine SYS$INPUT here, and I'd not depend on a redefine of SYS$PIPE here, either.

SYSVER is far from the only thing that reads data records from the input stream; from data embedded directly in the command procedure file.

DCL I/O redirection is a fairly ugly add-on to the environment. And, well, you've been lucky so far if you've been using this for a while.

(And why are you redefining SYS$INPUT?)

[Ken Robinson]

I was redefining sys$input because I have a habit of doing so before running some commands in a command procedure. I probably just typed it in without realizing it would be a problem. None of the documents that I've read say that this is not allowed when installing products using the product command.

I will remove the line from my command procedure.

[Hoff]

>>> I was redefining sys$input because I have a habit of doing so before running some commands in a command procedure. I probably just typed it in without realizing it would be a problem. None of the documents that I've read say that this is not allowed when installing products using the product command.<<<

Redefining sys$input is a way to get the input to prompt from somewhere else, and that implies the local command environment has some application stuff that prompts from the terminal. If that's the case, you might want to (start to) embed the redirection within the command procedure. Blanket specification of a sys$input is a bad idea.

You've inverted the norm, here. (No, that's not a way to look for norm's pocket change.) OpenVMS documentation classically indicates what is permitted and is supported.

It's simply not possible to document all that can be wrong or that does not work; us end-users are just way too original and way too creative for that documentation approach to ever work. In nerd-speak, the stuff that doesn't work is an infinite set.

FWIW...