Why does STARTUP.COM turn LGI_CALLOUTS off?

[Jess Goodman]

In the VMS 7.3-2 version of SYS$SYSTEM:STARTUP.COM I found this code:

$if f$getsyi("lgi_callouts").ne.0
$then
$mcr sysgen
use active
set lgi_callouts 0
write active
exit
$stdrv$say f$fao("%STDRV-I-LGI_CALLOUTS, forcing system parameter to 0")
$endif

We use loginout callouts at our site. Why does VMS 7.3-2 want to turh them off?

[Karl Rohwedder]

Have a look at:

http://h18000.www1.hp.com/support/asktima/operating_systems/CTI_SRC030321000328.html

Seems, that HP is aware of this problem, I do not now if it is addressed in newer versions.

regards Kalle

[John Gillings · Accepted solution]

Jess,

Sorry! My fault. I requested this change many years ago - I'd seen too many cases where LGI_CALLOUTS was non-zero but LGI$LOGINOUT_CALLOUTS was not defined, incorrectly defined, or failed to install.

In that situation you cannot login to the system, and it's not at all clear what's wrong. All you can do is power cycle, conversational boot and try to work it out.

The most common reason for LGI_CALLOUTS being set is "SYSGEN abuse", accidently writing the ACTIVE parameter set back to CURRENT, without realising LGI_CALLOUTS was changed as well as whatever else you were changing. In some cases I've seen, the startup procedures would have set LGI$LOGINOUT_CALLOUTS, but LGI_CALLOUTS being non-zero prevented some processes from running, so it never got set. Catch-22. I think there was also a patch once which inadvertently copied ACTIVE to CURRENT, so you might not even have realised there were SYSGEN changes.

Startup now forces LGI_CALLOUTS to 0 very early so it can't interfere with process startups.

I strongly recommend you have LGI_CALLOUTS clear in the active parameter set (which will suppress the %STRDRV-I-LGI_CALLOUTS message). You can still use LGI_CALLOUTS, but you need to explicitly set it AFTER you've defined, installed and validated LGI$LOGINOUT_CALLOUTS. Something like:

$ DEFINE/SYSTEM/EXEC LGI$LOGINOUT_CALLOUTS yourimage
$ INSTALL ADD/OPEN/HEAD/SHARE LGI$LOGINOUT_CALLOUTS
$ IF F$FILE("LGI$LOGINOUT_CALLOUTS","KNOWN")
$ THEN
$ MCR SYSGEN
USE ACTIVE
SET LGI_CALLOUTS 1
WRITE ACTIVE
$ ENDIF

[Jess Goodman]

Well ok, John. I will forgive you. :_)

We define LGI$LOGINOUT_CALLOUTS and install our .EXE in SYSLOGICALS.COM so I guess I can add the SYSGEN...SET LGI_CALLSOUTS commands there - just seems a little ugly to me to be modifing active SYSGEN parameters at that point.

Note in your example that "yourimage" would have to be another logical name that points to the full file spec of the site's callout image. We keep our callout image in SYS$SHARE: on all of our system disks so it's availabe even in a minimum non-cluster boot. So we DEFINE LGI$LOGINOUT_CALLOUTS as just our file name, not a logical (it can not be defined with a full file spec).

To handle ether case you might recommend using F$PARSE to add a default file spec SYS$SHARE:.EXE to "myfile" and use the results for the INSTALL and F$FILE lines.

[John Gillings]

Jess,

The point is there are lots of things that might go wrong defining the logical name or installing the image. For example, a simple error higher up in the procedure causing a premature exit, or running out of GBLSECTIONS or GBLPAGES. If that happens, your system is completely DEAD. Working out the connection to LGI_CALLOUTS, and how to fix it is not easy. I've had at least one customer who lost more than a day because of this.

Worst case with the current behaviour is your system is at lower security levels, but at least it works! You also get a message warning you what OpenVMS has done.