Hello Folks @ 3000-l,

Re: supported SYSSTART commands

------------------------------------------------------Mel Rees wrote--
>>Hi all, I wrote: I am trying to find the list of commands
>> that can be executed by SYSSTART, but it is taking some time ;(.

...cut out stuff...

I'll probably get chewed out for this one (again), but here goes.

To Use NETCONTROL and NSCONTROL in the systart, add the "OVERRIDE"
option to the command.  I have no idea where this is documented, but
it works and has worked for at least 7 years.

:NETCONTROL START;NET=LAN1;OVERRIDE
:NSCONTROL START;OVERRIDE

The issues about the NETCP process could still be an issue and so HP
recommends you start the network after the console is logged on.

Another issue about streaming jobs in the start up is seem to
require embedded password.  This may be because the console is not
really "logged on" yet so no security options have taken place.  Or
maybe because the sysstart executes under the user that is about to
be automatically logged on.  Small point.
----------------------------------------------------------------------

Naw, I won't chew you out... I will just give you and the folks on the
list some feed back on the "override" option... The key point is as
Mel mentioned above "I have no idea where this is documented" because
it is not documented for customer use "i.e. not supported for customer
use".

I use the OVERRIDE function infrequently because it avoids version
checking of the modules reported by :NMMAINT,3.  This is useful from
a support perspective if you want to isolate to and install a single
fix which would intentionally result in a version mismatch, but was
valid for internal "testing" purposes.  This is something you would
never want to do on a production machine, especially in the
circumstance of the multi-layer protocol network code.

An "override" option is present for both ":netcontrol" and
":nscontrol".

In a few cases the ":nscontrol start;override" is used when a issue
arises on the purchased NS product not being included with a subsys
tape on an update to a new O.S.  The ":nscontrol start;override" may
be recommended by HP to support inbound PC connections while the
subsys tape with the remainder of the NS-Services is delivered on
tape.

I know of no valid reasons that a ":netcontrol start;net=ni;override"
is appropriate for a production machine.  I would consider it
dangerous to execute the "override" option as the "default" and risk
the possibility of data loss or corruption at the worst or a system
abort or unexpected error due to protocol module not started as a
result of miss-matched or corrupt network code modules.  The version
mismatch message when attempting to start the networks is much less
painful than the above unexpected failures or corruption.

I can't say it enough, it is important for ":netcontrol start" to
perform it's version check after "EVERY" NS-Transport "NST" patch
is installed.   If you specify the "override" option, this is not
happening. Sometimes I think I sound like the "network cop" //:~).

Feed back on ":netcontrol start" in the sysstart file.  I know of
some sites who have been successful with out "override" and then
updated to a new release or installed a patch or installed new
hardware and found it stop's working.  When they call the RC, the
answer is it is not supported, but putting the network startup in a
job stream which is streamed by :sysstart works fine.  This is the
way to go.

What is going on here ?  The ":netcontrol start" talks to the
"NETCP" process and on system startup the "NETCP" system process
needs to create data structures and allocate resources prior to it's
being in a state where it can listen for commands from ":netcontrol"
which is not it's only task.  The bottom line reason "NETCP" is not
supported to be executed in a ":sysstart" file is that "NETCP" is
not guaranteed to be in this listening state at the point the
sysstart code is executed.

It is interesting that the "override" option on ":netcontrol start"
works in the :sysstart file any better than with out it... What you
are saying is the system is not up far enough to support the ability
of "NETCP" performing a module version check, but it is up enough
for "NETCP" to start network interfaces (I will let you guess which
one is a more complex procedure).

Bottom line:  Put your ":netcontrol start" in a separate "netstart"
job stream which is streams by ":sysstart".  It is much preferable
to check the $stdlist of the "netstart" job stream to determine why
your network did not start than to read a memory dump.

Regards,

James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.