Odd message from AUTOGEN

[Brian Reiter]

Volker

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

cheers

Brian

[Volker Halle]

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]

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]

> 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.]

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.

[Galen Tackett]

> 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]

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]

> 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]

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.]

Fixed in VMS732_MANAGE-V0500

ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-2/VMS732_MANAGE-V0500.txt
ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-2/VMS732_MANAGE-V0500.PCSI-DCX_AXPEXE