Newbie Question

[David Meier]

Hi all,

I am rather new to VMS and need some advice from the lots of experienced administrators on this list.

What is good administrative practice to save logicals and foreign commands so they are available on next reboot?

e.g. I am setting up CWSW 2.1 with Perl, PHP and MySQL. Should all the logical definitions (PERL_ROOT or PERLSHR) be packed into a separate COM-file and then be appended to SYSTARTUP.COM? What about foreign commands (PERL or MYSQLADMIN)? Should they be inserted into SYLOGIN.COM?

What do real VMS-Administrators do with these?

Thanks for input. Dave.

[Kris Clippeleyr · Accepted solution]

David,
Welcome to the OpenVMS forum.

Over here we do the following:
1. each layered product should have its own startup file in which all logicals are defined (if not provided, we create one).
2. these separate startup files are invoked from SYSTARTUP_VSMS.COM
3. foreign commands for a number of products, tools, applications, etc. are defined in SYLOGIN.COM if they need to be known to everyone; or in a separate general LOGIN.COM for system managers only.

Hope this helps,
Kris (aka Qkcl)

[Jan van den Ende]

David,

Welcome from me too!

We act somewhat similar to Kris, but even more explicit.

1. We try to put as many logicals as possible in clusterwide logical name tables.
As long as the ENTIRE cluster does no go down, (nearly 9 years now) those keep existing.
2. All our concealed logical name definitions for physical devices are concentrated in ONE procedure. This is the one and only location where we tolerate use of Physical device names. Each one does NOT get redefined, but only defined if not already existing (see #1).
Procedure is executed from SYLOGICALS.COM
3. General LNMs are concentrated into ONE procedure. Executed directly after the previous one.
4. Each product has its own INSTAL procedure. Defines LNMs, INSTALLs images, starts server processes, and/or ... (everything needed by the product)
5. Each product has its own SETUP procedure, which sets symbols and foreign commands, and/or defines its product-LNM to be included in LNM$FILE_DEV.

If 4. and 5. are not supplied by the product, or if LNMs and symbols are mixed (Ougch!!), or they are spread out over multiple files, then we split/collect them into exactly one each.

For our rather complicated (4 nodes, 30 applics, 7000+ users) environment, this has worked out quite well.
It is easily maintainable and quite flexible.

hth

Proost.

Have one on me.

jpe

[Galen Tackett]

Just a tip on startup and sylogin/login technique for invoking other .COM files--

I usually test for a command procedure before invoking them, in order to avoid misleading error messages if the command procedure can't be found, and optionally to print a more explanatory message of my own. It goes like this:

$ IF F$SEARCH("sys$manager:somefile.com") .NES. ""
$ THEN
$ @sys$manager:somefile.com
$ ELSE
$ !
$ ! This "else" part is optional if you
$ ! don't care to know that somefile.com
$ ! was not executed.
$ !
$
$ ENDIF

If this is done repeatedly, it looks a lot cleaner and is probably a bit safer to use a subroutine (though the overhead is greater):

$ CALL COND_INVOKE first_file.com
$ CALL COND_INVOKE second_file.com
...
$ COND_INVOKE: SUBROUTINE
$ !
$ ! Note that when the subroutine is called, the
$ ! symbol P1 will contain the filename.
$ !
$ IF F$SEARCH(p1) .NES. ""
$ THEN
$ @'p1'
$ ELSE
$
$ ENDIF
$ ENDSUBROUTINE

I hope this may be helpful, Dave. Others may have suggestions on this subject as well...

[Willem Grooters]

David,

A welcome from me too.

In general, each package will have it's own startup- and (often) a shutdown procedure in SYS$STARTUP: just look what you get when you issue $ DIR SYS$STARTUP:*STARTUP*.COM.

These are to be invoked in SYSTARTUP_VMS.COM (there are some examples in commented there). CSWS, PERL and MYSQL startup are some of these. Use the method specified by others:
$! Startup
$ FILE=f$search ("SYS$STARTUP:STARTUP.COM")
$ if FILE .nes. "" then @'file'

Normally these will install files (if required), and set up all required logicals (mostly /SYSTEM). APACHE$ROOT, PERL_ROOT and a number of MYSQL logicals are examples.

Other commandfiles a USER may need are often stored in SYS$MANAGER, or in the application environment. These will normally setup /PROCESS or /JOB logicals, and process-specific symbols. Where you invoke them is a matter of practice. If all, or most users need access, have these files invoked by SYLOGIN.COM, if just a few need them, put then invokation in LOGIN.COM.

Often this information is in the releasenotes or the ionstallation and configuration guides. Most install procedures will show this information as well.

Willem

[David Meier]

Thanks to all of you for taking your time. Your input is appreciated very much and things got clearer now.

Dave