Since the system had to be restarted...

[Bill Thompson_8]

Since the system had to be restarted and since it is unknown what was being done and what damage had been done, we are not finding we have all sorts of problems that have so far been fixed by enabling various system settings (like enabling and restarting FPT).

So, here is my question. There are some system lables and logicals that are defined during the login.com, but there seems to be other system-wide .COM files that also define lables and logicals that the user's login.com takes advantage. For instance, in the user's login.com file there is a line that says something to the effect:

BRIEF_COMMAND :== @DEV$EXEC:SOME_DOT_COM

and if the user types

BRIEF_COMMAND

at the command line, the error is something to the effect:

%DCL-E-OPENIN, error opening DEV$EXE:[OURUSER]SOME_DOT_COM.COM; as input
-RMS-F-DEV, error in device name or inappropriate device type for operation

Now, I did some research and I fould out that SOME_DOT_COM.COM is located in SYS$SYSDEVICE:[SPECIAL.DEVELOPMENT].

WHAT system-wide file or system-wide setting needs to be changed and what system utility do I need to run to make this happen?

[William Webb_2]

System-wide logicals are usually set up in SYS$STARTUP:SYLOGICALS.COM

Common login items are usually set up in SYS$MANAGER:SYLOGIN.COM

It appears that DEV$EXEC is not a "rooted logical" from the error message you posted, or something to that effect.

Please be precise.

Approximate information will result in approximate answers.


WWWebb

[Peter Quodling · Accepted solution]

Type and post results.

Show log/full dev$exe
show log/full dev$exec

It would appear that you might have a mismatch between them.

q

[Willem Grooters]

First step should be to check SY*.COM involved in startup (SYLOGICALS, SYSTARTUP_VMS and others) and watch for other commandprocedures that are invoked - it's quite common to have application logicals be set in separate procedures.
These will give you SYSTEM and GROUP logicals.
Mind: It is by no means obligatory to use the supplied procedures. A system manager can decide to leave these untouched and execute his own! (even re-do the whole startup....)

Next investigation is checking SYLOGIN, look again for procedures that set up logicals and look for these. Also take a look at user's LOGIN.COM, doing the same. This search id for PROCESS and JOB logicals.

Beware that, in most cases, a logical is searched scanning tabels in sequence as defined in table LNM$PROCESS_DIRECTORY; normally it will be PROCESS - JOB - GROUP - SYSTEM but others may have been put in there (You can tell by $ SHOW LOGICAL/TABLE=LNM$PROCESS_DIRECTORY). The first match encountered will be used.

In your case, it might be that there are different definitions of DEV$EXE:. Given the statement, I expect this would have the CONCEALED attribute at least.

[Martin Vorlaender]

Willem,

>>>
(You can tell by $ SHOW LOGICAL/TABLE=LNM$PROCESS_DIRECTORY).
<<<

AFAIK, you get the tables that are searched by $ SHOW LOGICAL LNM$FILE_DEV /TABLE=*

cu,
Martin

[Antoniov.]

Hi Bill,
it appear as a mismatch between dev$exec and dev$exe.
So you must create a logical name dev$exec like follow command
$ DEF/SYSTEM DEV$EXEC -
SYS$SYSDEVICE:[SPECIAL.DEVELOPMENT]
in SYLOGICALS.COM
or if DEV$EXE is valid you have to change SYLOGIN.COM; to check for dev$exe you can type
$ @DEV$EXE:SOME_DOT_COM

Antonio Vigliotti

P.S.
Bill, may I hint you assign some point? Just for thanking vms guys here :-)

[Doug Phillips]

If the EXE EXEC difference is just your typo; since some other things that should have happened in startup didn't, it's possible that your startup procedure encountered an error and failed to execute completely. Most often this happens (to me, anyway;-) in sys$startup:systartup_vms.com because of a typo.

[Willem Grooters]

@Martin:
I tried this one this morning ;-) But you're right.
@Doug:
That's also true. A common error (as I found out myself very recently)

So Bill, check ALL procedures that are used in the startup sequence, that they have either SET NOON whereever something MIGHT go wrong, or take appropiate action (that is: have a decent error handling) so startup will finish normally. Same, by the way, applies to LOGIN procedures.

[Bill Thompson_8]

I assigned points to all since all have helped.

What helped the most was finding a system that was simular. Although it was not an OpenVMS, it was useful to do a side-by-side comparison and to look at OpenVMS online documentaion and your suggestions to see what line of code needed to be added to the SYS$MANAGER:SYSTARTUP_VMS.COM file.