Startup processing

[Neville Brown]

Yes a silly question for which I apologise.

Is the order of operations for startup documented somewhere? ie: this runs and calls this, on completion chains to this etc etc...

[Hein van den Heuvel]

The system starts : SYS$MANAGER:SYSTARTUP_VMS.COM
And the rest is pretty much up to the end user.
VMS has no is no 'init.d' directory with numbered steps like many Unix's have.
Many system managers of course have there own conventitions to make sure the right dependencies are met: mounting disks, defining logicals, installing images, starting queues and finally allowiing user in.
Take a look around in SYS$STARTUP:*.COM, and perhaps more so SYS$STARTUP:*.TEMPLATE.


hth,
Hein

[Robert_Boyd]

There are a couple of places to read about startup processing. The HP OpenVMS System Manager's Manual, Volume 1: Essentials discusses the startup. Also, you'll want to look at the documentation for the SYSMAN STARTUP functions in HP OpenVMS System Management Utilities Reference Manual.

Here are a couple of links:

http://h71000.www7.hp.com/DOC/732FINAL/aa-pv5mh-tk/aa-pv5mh-tk.HTMl

http://h71000.www7.hp.com/DOC/732FINAL/6048/6048PRO.HTML

Robert

[Neville Brown]

Yes, that is the usual start for the system specific startup. STARTUP.COM gets in before that, as do things like SYPAGSWPFILES and the SYSMAN startup phases. Hence the quesion.

[Peter Quodling]

VMS Was Open Sourcing, long before it became trendy. The system startups are done within STARTUP.com systartup_vms.com, sysman, and sundry procedures called by all of the above.

Thereis a certain amount of adapatability in how these happen, so the best way to get get a good insight is to Read the Code.

If you are looking to optimuize your startup, then it is also worth looking at the sysgen parameter startup_p2, which depending on it's setting can log the details of the startup to a file - I find this invaluable for building more robust startups, and checking existing ones for flaws.

q

[Robert_Boyd]

I want to add my vote for reading the code -- including the output from SYSMAN STARTUP SHOW FILE * and all the other pieces such as SYPAGSWPFILES.COM, SYLOGICALS.COM, SYSTARTUP_VMS.com, and anything called by these.

During the years that I managed a group of system managers, whenever I hired and trained someone new I would give them an assigment to study the system startups of all our systems and to report back to me what they learned. This usually proved to be helpful to them and to me both. We got a fresh review of how we had the startups configured and the new system manager got a full immersion into the basics of the configuration.

If I were hiring and training someone today I would still think this is a great exercise for someone. It's challenging, entertaining, and ultimately worth the effort.

Robert

[Neville Brown]

People do seem to be somewhat missing the point...
I have been doing this sort of thing for enough years that I certainly Could read the code and derive it from first principles. Given however that I find myself on a rats-nest site where nothing can be relied upon and everything has some delightfully arcane special undocumented use, I was looking for some independant starting point. I shall assume from responses that such a map does not exist, and that we wing it and see.

[John Gillings]

Hi Neville,

The section in the System Manager's Manual headed "Understanding Site-Specific Startup Command Procedures", table 1 is fairly unambiguous, giving you the sequence of "standard" modifiable procedures: SYCONFIG, SYLOGICALS, SYPAGSWPFILES, SYSECURITY, SYSTARTUP_VMS.

If you want to go deeper, the best place to look is in the SYSMAN startup databases. Try this:

SYSMAN> STARTUP SET DATABASE STARTUP$STARTUP_VMS
SYSMAN> STARTUP SHOW FILE

This will show you the "low level" startup sequence. See SHOW LOGICAL STARTUP$STARTUP to see what other data bases are available.

BTW, I recommend everyone have another look at SYSMAN. It's by far the easiest way of managing startup sequences, especially in a cluster.

[Wim Van den Wyngaert]

I once made a resume ...

When VMS startup has reached the level where it is running, the process STARTUP
will start SYS$SYSTEM:STARTUP.COM (based upon mc sysgen show/start).
This procedure will start several VMS components. The components started
depends on the version of VMS (e.g. lancp is started on vms 7 but not in other
versions). The components to start can be setup/viewed with sysman.

If something is started in batch, node$batch is used !

A file named sys$startup:vms$phases.dat exists which defines a number of phases
that are executed during the boot. A number of these phases are defined by
Digital and may not be changed. The client CAN however add new phases.

2 files exists that define what has to be executed in each phase. The first one
(is also executed before the second one) is called sys$startup:vms$vms.dat and
the second one sys$startup:vms$layered.dat. For each phase found in the phases
file, the startup actions are searched in each of these files.

In the last Digital phase (LPBEGIN), SYS$STARTUP:VMS$LPBEGIN-050_STARTUP.COM is
executed that will start sys$startup:systartup_vms.com and afterwards
(hardcoded) decwindows. Make sure that systartup_vms is completed completely
when decwindows is started !

Certain 'things' are however started directly in the script startup.com, e.g.
ldr$wrapup.exe.

[Bart Zorn_1]

Wim van den Wyngaert wrote:

"If something is started in batch, node$batch is used !"

I could not find this in the documentation.
Our systems do not have a 'nodename'$BATCH queue, nor such a logical name pointing to a batch queue.
In my experience, the default queue name SYS$BATCH is used, either as logical name or as a real queue name.

Regards,

Bart Zorn