Operating System - OpenVMS
1748227 Members
4211 Online
108759 Solutions
New Discussion юеВ

What might have turned LGI_CALLOUTS to 1?

 
SOLVED
Go to solution
comarow
Trusted Contributor

What might have turned LGI_CALLOUTS to 1?

After installing the recent of a ECOs for
a 7.3-2 alpha, Update 8 and the other current
ecos, after rebooting we had a problem which
ended up being LGI_Callouts was turned on,
which disabled telnet connectivity, (running Multinet).

What could have possibly changed the parameter?

Autogen was not run. There were no references to it iny any params.dat

ECOs Installed were
Update_v0800
acrtl_v0300
audserver_v0300
RMS_v0300
SECSRV_v0100
SYS_v1100
TDF_v0400
XFC_v0300

I've seen articles on how it IS set to zero,
but what might NOT be set to zero.

Much thanks.

7 REPLIES 7
Jim_McKinney
Honored Contributor
Solution

Re: What might have turned LGI_CALLOUTS to 1?

> (running Multinet)

Sounds as if someone mistakenly enabled the ACCESS service (SecureIP authentication)? If so, you should also find a newly created MULTINET:START_ACCESS.COM.
comarow
Trusted Contributor

Re: What might have turned LGI_CALLOUTS to 1?

Are you saying that this program actually changed the sysgen parameter?

Wouldn't that mean it would come back on reboots?
Jim_McKinney
Honored Contributor

Re: What might have turned LGI_CALLOUTS to 1?

I don't recall all the details surrounding this service, but, I think you'll find that if it is active that it sets the LGI_CALLOUTS to 1 on the fly during the system startup via MULTINET:START_ACCESS.COM which is invoked by START_MULTINET.COM if it exists.

The command that activates this service and creates MULTINET:START_ACCESS.COM is

$ MULTINET CONFIGURE/ACCESS

if I recall correctly. If you don't have a MULTINET:START_ACCESS.COM file then the service wasn't activated.
comarow
Trusted Contributor

Re: What might have turned LGI_CALLOUTS to 1?

It was a great start. But the file
had existed for ages. The apparent change
in the sysgen behavior was after the ecos.
John Gillings
Honored Contributor

Re: What might have turned LGI_CALLOUTS to 1?

comarow,
The most common reasong for LGI_CALLOUTS to be set to 1 is something like this:

MCR SYSGEN
SYSGEN> SET something
SYSGEN> WRITE CURRENT

Since this copies ACTIVE parameters to CURRENT, it can inadvertently set things that shouldn't be set. Note it doesn't matter what parameter was modified, LGI_CALLOUTS would be taken along for the ride. In general, if you want to use LGI_CALLOUTS you should define the logical name and install the target image FIRST. When it's known to have been successful, THEN set the parameter in the active set.

I thought OpenVMS startup was modified to force LGI_CALLOUTS to 0 because setting it when it shouldn't be set will block all access to the system. I'm not sure what version that happened in. If you're post the change, something in your startup must have turned it on. Maybe turning on SYSGEN auditing and/or alarms might help find it?
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: What might have turned LGI_CALLOUTS to 1?

comarow,

just checked...

LGI_CALLOUTS is forced to 0 on V7.3-2 in SYS$SYSTEM:STARTUP.COM. If it's changed, you'll see a console message:

%STDRV-I-LGI_CALLOUTS, forcing system parameter to 0

Maybe try

$ SEARCH SYS$SYSDEVICE:[000000...]*.COM LGI_CALLOUTS

A crucible of informative mistakes
comarow
Trusted Contributor

Re: What might have turned LGI_CALLOUTS to 1?

Thanks John,

Will check when back at the shop. I can assure
you it was not changed interactively, as it occured while only I was on it, doing a round of ECOs.

But I'll check the logs.

Bob