CSWS not starting Automatically (VMS 8.3)

[OwensJ]

So I have gotten my issue resovled, and it was due to my lack of knowledge of how the operating system works.

The system is not running in a cluster. And I was modifying the file STARTUP_VMS.COM in the SYSMGR directory under SYS$COMMON instead of the one under SYS$ROOT. So the file was never being run at all. I was just editing a file for the fun of it.

Though in my defense, I'll have to say that the documentation never states to look at that ;) But I should know better, hey it's only my third day using this OS!

Thank you all for your help, maybe my misfortune in this will help someone else in the future!

[Rick Retterer]

Well, for only 3 days of hands-on with the OpenVMS software, you are doing well. Some folks never catch on to the SYS$COMMON/SYS$SYSROOT directory structures.

I hope that you fall in love with OpenVMS as I have, and many others before me have. I'm 21 years supporting OpenVMS, and I am still as enthusiastic about it today as I was 21 years ago. I hope you will be as well.

It's as rock solid OS, and built like an anvil.

This is no kidding, we had a server in our ice-lab that had been up for over 2 years without a reboot... and it was still humming along as smoothly as the day that we booted it up.

Enjoy, and thanks again for sharing with us the solution to your specific problem.

Cheers,
Rick Retterer

[RBrown_1]

Glad you got it fixed.

Since you say your are not in a cluster, in your place, the next thing I would do is get all of the command files out of SYS$SPECIFIC:[SYSMGR] and into SYS$COMMON:[SYSMGR].

Generally, you want all of your stuff in SYS$COMMON:[etc]. The SYS$SPECIFIC stuff is for node specific files when you are running in a cluster.

Have fun!

[Steven Schweda]

> [...] I was modifying the file
> STARTUP_VMS.COM in the SYSMGR directory
> under SYS$COMMON instead of the one under
> SYS$ROOT.

You can certainly use the one under
SYS$COMMON. Around here, for example:

ALP $ show default
SYS$SYSROOT:[SYSMGR]
= SYS$SYSROOT:[SYSMGR]
= SYS$COMMON:[SYSMGR]

ALP $ dire sys$startup:systartup_vms.com;

Directory SYS$COMMON:[SYSMGR]

SYSTARTUP_VMS.COM;15

Total of 1 file.

But that means that you can't be creating
another one under SYS$SPECIFIC, too.
SYS$SYSROOT is a search list, and the
SYS$SPECIFIC part comes before the SYS$COMMON
part, so a file under SYS$SPECIFIC takes
precedence over one under SYS$COMMON.

Note that using a typical DEC-native editor
on SYS$COMMON:[SYSMGR]SYSTARTUP_VMS.COM is
likely to get you a new version under
SYS$COMMON, but using some foreign editor
like, say, Vim, is likely to drop the new
file into SYS$SPECIFIC, the first part of the
search list. Everything's complicated. (And
traps are hidden everywhere.)

[Robert Gezelter]

OwensJ,

I am glad that you sorted out your immediate problem.

A good practice to avoid accidents is to never edit files using one of the search path logical names (e.g., SYS$SYSTEM, SYS$MANAGER, SYS$STARTUP). Always explicitly identify whether it is the SYS$SPECIFIC or SYS$COMMON tree together with the specific directory.

Even though your system is not in a cluster, there is a benefit to the SYS$SPECIFIC/SYS$COMMON dichotomy: It allows you to create alternate systems configurations. These make it far safer for testing changes in startup procedures and parameters.

If your system is not yet in production, you may find my article on Soloist OpenVMS Clusters on OpenVMS.org to be of interest (see http://www.openvms.org/stories.php?story=10/01/13/0826890 ).

As you explore OpenVMS, you will find that it is far more regular than many other systems. While there is no IA64 emulator (other than HPVM on the actual IA64 hardware), you may want to consider creating a virtual Alpha for personal experimentation and education on your home Windows/Linux system. It will allow you to hone your skills in total safety.

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

Owen,

> And I was modifying the file
>STARTUP_VMS.COM in the SYSMGR directory
>under SYS$COMMON instead of the one under
>SYS$ROOT. So the file was never being run
>at all. I was just editing a file for the
>fun of it.

So, if I'm reading this correctly, you're saying there was an existing STARTUP_VMS.COM in SYS$SPECIFIC which was masking the copy in SYS$COMMON, so the edits you made to the SYS$COMMON were not being executed. You've fixed it by applying the changes to the SYS$SPECIFIC copy.

Correct diagnosis, but probably not the best solution.

There are a few schools of thought here. My preference is to use SYS$COMMON files. Treat all systems as if they are clusters. Keep stuff out of the node specific roots in order to avoid the type of confusion you've just experienced, and to keep nodes as consistent as possible.

If there's a lot of node specific stuff, you may decide to put it in a node specific file, but I'd always add a call to the cluster common code. Something like this:

$ common=F$PARSE("SYS$COMMON",";",F$ENVIRONMENT("PROCEDURE"))
$ IF F$SEARCH(common).NES."" THEN @'common'

[OwensJ]

John,

Actually my name is John as well (Owens is my last name)

$common=F$PARSE "SYS$COMMON",";",F$ENVIRONMENT("PROCEDURE"))
$ IF F$SEARCH(common).NES."" THEN @'common'

Where does this go exactly? I get that you say to treat all systems like they are clusters. So I had startup and shutdown files that existed in the sys$specific (sysroot) instances of SYSMGR which were overriding the ones in the sys$common SYSMGR that I was modifying yes. I've read some people say just to delete those files in the sys$specific.

So in your example, where are you suggesting I put those two statements? Remember I am very new to openvms.

[John Gillings]

John,

>I've read some people say just to delete
>those files in the sys$specific.

Probably better to move them into SYS$COMMON. The trick then, as others have said, is to always refer to the files by their cluster common name when editing. I have a sanity check procedure that looks for files in the common root which may be obscured.


As you've learned, files in a SYS$SPECIFIC root will mask one in SYS$COMMON. If you find some circumstance where it makes sense to have a separate SYS$SPECIFIC file, you can explicitly execute the SYS$COMMON version from it. For example, suppose we want to startup APACHE on just one node. I'm assuming that the TCPIP startup will be in the common startup, so we want to start APACHE after the common has completed.

SYS$SPECIFIC:[SYSMGR]STARTUP_VMS.COM

$ SET NOON ! Continue regardless of errors
$ node=F$GETSYI("NODENAME")
$ self=F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))
$ WRITE SYS$OUTPUT "Executing node specific startup for ''node' at ''F$TIME()' ''self'"
$
$ ! Do stuff which needs to be done before the common startup here
$
$ common= F$PARSE("SYS$COMMON",self)
$ IF F$SEARCH(common).NES."" THEN @'common'
$
$ ! Do stuff which needs to wait until the common startup is complete here
$
$ apache="SYS$STARTUP:APACHE$STARTUP.COM"
$ IF F$SEARCH(apache).NES."" THEN @'apache'
$
$ WRITE SYS$OUTPUT "Node specific startup completed for ''node' at ''F$TIME()'"
$ EXIT

Common startup looks like this:

SYS$COMMON:[SYSMGR]SYSTARTUP_VMS.COM

$ SET NOON ! Continue regardless of errors
$ node=F$GETSYI("NODENAME")
$ self=F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))
$ WRITE SYS$OUTPUT "Executing cluster common startup for ''node' at ''F$TIME()' ''self'"
$
$ ! Do startups
$
$ WRITE SYS$OUTPUT "Cluster common startup completed for ''node' at ''F$TIME()' ''self'"
$ EXIT


This is just one way to configure your cluster. In practice, it's better that all nodes in the cluster run the same software, so the startup procedure is identical for all nodes, and kept in SYS$COMMON. Having common code wherever possible means there's less chance for inconsistencies.

(I also have a policy of never hardcoding anything which can be determined easily. For example, finding the executing procedure name with F$ENVIRONMENT("PROCEDURE"), rather than coding it as "SYSTARTUP_VMS" means that identical code can be used in any of the SYS$STARTUP procedures).

[Steven Schweda]

> [...] The trick then, as others have said,
> is to always refer to the files by their
> cluster common name when editing. [...]

Or, as one other has said, you don't always
_need_ to do that.

Around here, for example, creating a new file
requires some care:

ALP $ show default
SYS$SYSROOT:[SYSMGR]
= SYS$SYSROOT:[SYSMGR]
= SYS$COMMON:[SYSMGR]

ALP $ edit /tpu fred.com
[...]
1 line written to file SYS$SYSROOT:[SYSMGR]fred.com;1

Wrong place. I'll move it:

ALP $ rename fred.com sys$common:

Now it's in SYS$COMMON:

ALP $ dire /date fred

Directory SYS$COMMON:[SYSMGR]

fred.com;1 22-NOV-2010 15:34:46.85

Total of 1 file.

And now, editing it with EDIT /TPU leaves the
new version in the same place:

ALP $ edit /tpu fred.com
[...]
1 line written to file SYS$COMMON:[SYSMGR]fred.com;2

ALP $ dire /date fred

Directory SYS$COMMON:[SYSMGR]

fred.com;2 22-NOV-2010 15:37:25.36
fred.com;1 22-NOV-2010 15:34:46.85

Total of 2 files.

Similarly for EDIT /EDT:

ALP $ edit /edt fred.com
[...]
*exit
SYS$COMMON:[SYSMGR]fred.com;3 1 line

ALP $ dire /date fred

Directory SYS$COMMON:[SYSMGR]

fred.com;3 22-NOV-2010 15:38:05.68
fred.com;2 22-NOV-2010 15:37:25.36
fred.com;1 22-NOV-2010 15:34:46.85

Total of 3 files.


The story may change if a non-native editor
is used:

ALP $ vim --version
VIM - Vi IMproved 6.3 (2004 June 7, compiled Apr 29 2005 10:41:09)
[...]

ALP $ vim fred.com
[...]
"SYS$SYSROOT:[SYSMGR]fred.com" 1L, 16C written

ALP $ dire /date fred

Directory SYS$SYSROOT:[SYSMGR]

fred.com;1 22-NOV-2010 15:39:52.66

Total of 1 file.

Directory SYS$COMMON:[SYSMGR]

fred.com;3 22-NOV-2010 15:38:05.68
fred.com;2 22-NOV-2010 15:37:25.36
fred.com;1 22-NOV-2010 15:34:46.85

Total of 3 files.

Grand total of 2 directories, 4 files.


So, if you avoid creating files under
SYS$SPECIFIC in the first place, then simple
editing is not guaranteed to wreck anything,
provided that you don't use the wrong editor.
Which is a good thing, as I might not be able
to remember to be that careful every time I
edit some command procedure as SYSTEM.