Online Expert Day - HPE Data Storage - Live Now
April 24/25 - Online Expert Day - HPE Data Storage - Live Now
Read more
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Odd message from AUTOGEN

Brian Reiter
Valued Contributor

Odd message from AUTOGEN

Hi Folks,

After installing DEC AXPVMS VMS732_UPDATE V5.0 patch, I get the following error out of AUTOGEN (needed to up some parameters).


$ @sys$update:autogen savparams reboot nofeedback
%AUTOGEN-I-BEGIN, SAVPARAMS phase is beginning.
%AUTOGEN-I-SKIP, SAVPARAMS phase is being skipped. Feedback information
is not recorded or used if the INITIAL or NOFEEDBACK option is chosen.
%AUTOGEN-I-END, SAVPARAMS phase has successfully completed.
%AUTOGEN-I-BEGIN, GETDATA phase is beginning.
%AUTOGEN-I-NEWFILE, A new version of SYS$SYSTEM:PARAMS.DAT has been created.
You may wish to purge this file.
%AUTOGEN-I-END, GETDATA phase has successfully completed.
%AUTOGEN-I-BEGIN, GENPARAMS phase is beginning.
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
\FIRST_MESSAGE_SYS$OUTPUT\
%AUTOGEN-I-BADFILE, Bad versions of SYS$SYSTEM:SETPARAMS.DAT
and SYS$MANAGER:VMSIMAGES.DAT may
exist. We recommend that you delete all versions and start again.
%AUTOGEN-I-ERROR, GENPARAMS phase was aborted due to an unexpected error.
%SYSTEM-F-ABORT, abort

It looks like a genuine mistake in the command file. For the record the file is dated 26-JUN-2005 19:07:28.44. Versions of autogen on other 7-3-2 systems (patched to V0400) don't have symbols named FIRST_MESSAGE_SYS$OUTPUT.

Any clues? Any known workarounds?

I can recover the system quite easily but I'd rather not :)

regards

Brian
19 REPLIES
Ian Miller.
Honored Contributor

Re: Odd message from AUTOGEN

I've checked the file on my system and it also has this. It does look like a bug to me. Have you reported it to hp?
____________________
Purely Personal Opinion
Brian Reiter
Valued Contributor

Re: Odd message from AUTOGEN

Ian,

Not yet - I'll have to through the resellers. I'll drop an email to them now and see whats going on.

cheers

Brian
Volker Halle
Honored Contributor

Re: Odd message from AUTOGEN

Brian,

I see usage of the symbol 'first_message_sys$output' in AUTOGEN.COM on OpenVMS Alpha V8.2. It's being assigned a value of 0 or 1 and it's being used in some IF ( first_message_sys$output .eq. 0) statements.

Looks like you may be hitting a path, where the symbol is used, but didn't get defined first. Could you run your AUTOGEN with verify turned on:

$ define agen$verify true
$ @SYS$UPDATE:AUTOGEN ...

Volker.
Ian Miller.
Honored Contributor

Re: Odd message from AUTOGEN

I don't see any place where first_message_sys$output is set to 0.
I wonder if that is what is missing.
____________________
Purely Personal Opinion
Steven Schweda
Honored Contributor

Re: Odd message from AUTOGEN

Hmmm. It's a trend.

Looks as if first_message gets set to zero in
a couple of places for initialization, but
not first_message_sys$output.

I suspact that if you find the statements
"first_message = 0" and add the obvious
analogues, then all might be well again.

In V8.2, it seems to do it for the first one:

$invalid_param_found = 0
$first_message = 0
$first_message_sys$output = 0
$in_name="MODPARAMS.DAT"

but not the second one:

$fc50:
$first_message = 0
$count = count + 1

So that could be right.

My memory is failing, but didn't the "less
than 24 hours" complaint appear at the
terminal in the old days? In V8.2 it seems
to be only in AGEN$PARAMS.REPORT.

Disappointing.
Volker Halle
Honored Contributor

Re: Odd message from AUTOGEN

Brian,

the 'bad' AUTOGEN.COM file must be coming from VMS732_MANAGE-V0400, which is the only V7.3-2 patch including that file. I assume, you didn't have that patch installed before...

If you can confirm, that there is no command in AUTOGEN.COM, that defines a value for symbol FIRST_MESSAGE_SYS$OUTPUT, then it's definitely a straight forward bug, if there are some definitions and you are not hitting one of them, it gets a little bit more complicated...

Volker.
Brian Reiter
Valued Contributor

Re: Odd message from AUTOGEN

Hi Volker et al

It looks as though first_message_sys$output needs initialising just prior to the label genparams10: (same place where first_message is initialised). With this tweak autogen runs to completion.

I know there are warnings from MODPARAMS.DAT (been there years) and I'm guessing these may break it. I've attached the trace from the run using AGEN$VERIFY.

So, I'm now in the situation where the issue could be fixed - but I'd would much rather HP fix the problem rather than rely on my tweak. I can't guess what else may fail.

Ah well. Made a change to debugging Pascal.

cheers

Brian
Steven Schweda
Honored Contributor

Re: Odd message from AUTOGEN

> [...] I can't guess what else may fail.

Probably the same stuff as fails on V8.2 (if
any).
Volker Halle
Honored Contributor

Re: Odd message from AUTOGEN

Brian,

OpenVMS engineering already knows about this problem and is in the process of fixing it.

No need to raise another call, I would assume some patch kit will appear soon...

Volker.
Brian Reiter
Valued Contributor

Re: Odd message from AUTOGEN

Volker

Well at least thats something. Question is though, do I trust the actions of my tweaked Autogen?

cheers

Brian
Volker Halle
Honored Contributor

Re: Odd message from AUTOGEN

Brian,

your workaround is certainly safe. It's in the same place as in the V8.2 version of AUTOGEN.COM

...
$first_message = 0
$first_message_sys$output = 0 ! add this as workaround
$in_name="MODPARAMS.DAT"
$genparams10:
...

Volker.
comarow
Trusted Contributor

Re: Odd message from AUTOGEN

There is a problem with some customer's after installing DEC-AXPVMS-VMS732_MANAGE-V0400

You have the sympton.

Did you install that ECO? If so log a call with the support center and if you put it to my attention and there is an existing elevation.

If not, put the eco in place which will get you a new copy of autogen.

Also, if you're not sure where it's bombing out you can turn autogen into a verification mode with setting the logical
AGEN$VERIFY "TRUE"

and you will see where it is bombing out. The particular issue I'm mentioning happens right in the start and doesn't create any new problems.

Also, make sure you have nothing in syconfig.com when you run autogen.

Thanks.

Bob Comarow
Steven Schweda
Honored Contributor

Re: Odd message from AUTOGEN

> Also, make sure you have nothing in
> syconfig.com when you run autogen.

Oh. yeah. As if I'm likely to replace
SYCONFIG.COM with a template every time I
want to run AUTOGEN? Sure thing.

A nice related problem to be fixed would be
the one where
SYS$STARTUP:VMS$DEVICE_STARTUP.COM skips the
SYS$STARTUP:VMS$INITIAL-050_CONFIGURE.COM
step (and a few other things) when
SYCONFIG.COM sets
STARTUP$AUTOCONFIGURE_ALL == 0. This can
seriously confuse a cluster, and it seems not
to be mentioned anywhere (except comp.os.vms
archives).

And "customer's"? Save yourself a keystroke.
Ian Miller.
Honored Contributor

Re: Odd message from AUTOGEN

I have had a go at reproducing this on a VMS V7.3-2 system with all the latest patches and can't. I do see the problem in the code. If you can reproduce it on your system and can log a call then do so as more calls gives the beancounters in hp more beans to count and will encourage the production of the fix as a patch sooner.
____________________
Purely Personal Opinion
Galen Tackett
Valued Contributor

Re: Odd message from AUTOGEN

> Oh. yeah. As if I'm likely to replace SYCONFIG.COM with a template every
> time I want to run AUTOGEN? Sure thing.

I once had a modified SYCONFIG.COM that would exit unless F$GETJPI("ACCOUNT") equalled "" or some similar text I may not precisely recall.

If you frequently need to execute SYCONFIG.COM on a running system (does anyone?) you could define a symbol or logical name that SYCONFIG could check to see if it should run anyway.

This may not be perfect but it worked well at a former job of mine.

Galen
Brian Reiter
Valued Contributor

Re: Odd message from AUTOGEN

Hi Volker,

Glad the workaround is safe. Now I can get back to sorting out NFS.

Ian,

I suspect the failure is due to warnings in MODPARAMS.DAT. I'll check tomorrow when I try and get rid of the warnings (should be fun). When the reseller gets back to me, I'll see about raising the issue formally.

cheers

Brian
Steven Schweda
Honored Contributor

Re: Odd message from AUTOGEN

> I once had a modified SYCONFIG.COM [...]

I changed my SYCONFIG.COM to avoid auto
config of a CD-R/RW drive. It's been a
while, but as I recall, I didn't want it
MSCP-served, as that caused errors if I
powered it off. It may also be true that it
responded at all the LUNs, and I didn't like
all the extra (non-)devices.

Some time after changing it to set
STARTUP$AUTOCONFIGURE_ALL == 0, I discovered
that I was missing FTA0 and MPA0, so I added
code to connect those manually if they didn't
already exist.

Much later, I learned that the MSCP disk
sharing was hosed because the CONFIGURE
process wasn't being started, and that that
was because VMS$INITIAL-050_CONFIGURE.COM was
_also_ being skipped. My solution there was
to check f$getsyi( "NOAUTOCONFIG"), and then
look for a process named CONFIGURE. If no
and no, then run that skipped procedure.

It remains a mystery to me why all this stuff
needed to be skipped just to avoid auto
config of some stray device or other.
Brian Reiter
Valued Contributor

Re: Odd message from AUTOGEN

Hi Folks,

Looks as though the problem was down to warnings generated by autogen, of the form.

** WARNING ** - Conflicting specifications for GBLSECTIONS found in MODPARAMS.DAT.

Correction of the offending parameters in MODPARAMS.DAT allowed that version of AUTOGEN to run to completion.

Thanks for all you help


cheers

Brian

Ian Miller.
Honored Contributor

Re: Odd message from AUTOGEN