locked myself out of the system

[Christian Burschka]

Dear experts,

on my alphastation 255 with vms 6.21-h3
(console set to graphics)
booting the system ends up in a weird situation:
some called com file seems to produce an error, so that systartup_vms.com does not finish normally, but apparently leads to a single user state with window manager running
and no possibility to open a terminal to input any dcl command.

On the screen I have a workspace with application manager etc, but cannot open a terminal by mouseclick neither right or left.

Cant even shut the system down normally.

Thanks for any suggestions!

Chris

[Heinz W Genhart · Accepted solution]

Hi Chritian

one possibility is as follows:

- You can stop the system (push the button)
- then do a conversational boot (B -fl 0,1 disk) Important are the boot flags 0 is the root ,1 means conversational)
- at the sysboot prompt enter the following
set /startup OPA0:
So your console will be the startup command device. Then enter C for continue
- if the system is up, then you will se the $ prompt.
- Enter Spawn to create a subprocess.
- Execute manualy the system Startup procededure. @sys$system:startup. At the end of the system startupprocedure it will logs you out.
- Because you did the spawn before, you are still logged in and the system is up.
- now you have the possibility to do what is required to solve the main problem.
- After solving the problem, don't forgett to reset the Systemstartupprocedure in sysgen
$ MC SYSGEN
set/startup sys$system:startup.com
write current
exit


Hope that helps

Regards

Heinz

[Jan van den Ende]

Chris,

time for a conversational boot.

>>> B -fl 0,1

SYSBOOT> set startup_p1 "MIN"

c

will get you there, but probably the graphic terminal will be "challenging".

Long ago now, but I remember I always hooked up a terminal (or terminal emulator).
I seem to remember a tiny switch next to the ethernet adapter,which can be toggled using a bent-open paperclip, but I am not sure if that also is true for the AS255...

hope this is enough to get you moving on, if not, anybody else: do you have more pertinent details?

Success.

Proost.

Have one on me.

jpe

[Christian Burschka]

Heinz,

thanks a lot, it worked !

now I am at the $ prompt in a spawned process.

what will happen if I run @systartup_vms.com ?

Right now I would like to be able to use an editor like formerly eve etc. But thats a long time ago on a microvax2, I cant remember any command... where should I look ?

just to put a ! into a line and save.

regards
chris

[Karl Rohwedder]

I fear, that on the graphics console a EDIT will not work, because it needs at least VT100 capabilities (Try SET TER/INQ and EDIT).
You may use EDT in linemode:
$ EDIT/EDT file
* commands
e.g.
T types lines, T 1 thru 10, T whole
SET NUMBER enables line numbering
nn go to line NN
S/old/new/ subsitute characters, e.g. s/$/$!/
EX exits

regards Kalle

[Wim Van den Wyngaert]

To use eve while booted minimal :

MCR SYSMAN IO AUTOCONFIGURE
@SYS$MANAGER:DECW$DEVICE
and then use edit/edt.

Wim

[Robert Gezelter]

Christian,

The SPAWN is VERY important. If you just invoke STARTUP.COM, the first error will exit that command file, and exit the process, leaving you in the state that you are trying to avoid.

The SPAWN is a good idea when tracing problems with the STARTUP sequence. The worst side effect is that you have to do two LOGOUT commands when finished. If something does not work right, it guarantees that you get control back at the console.

Most of the screen editors will not work until much of the STARTUP processing has completed. TECO, which will work on any terminal device, and EDT in line mode are usable.

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

[Hein van den Heuvel]

serveral graphics consoles have VT52 emulation built in.
To use a graphical editor try SET TERM/VT52 first.

But EDT in line mode is a good thing to learn/know imho.

Hein.

[Jur van der Burg]

There's a simple way if your system is really toasted, such that a minimal startup won't even run.

Boot conversational, then do this:

SYSBOOT> set /startup opa0:

Then at the $ prompt do this:

$ set noon
$ def/user sys$input sys$sysroot:[sysmgr]vmsimages.dat
$ mc install /nocomm
$ def sys$library sys$sysroot:[syslib]

And then for example to edit:

$ set def sys$sysroot:[sysexe]
$ set term/inquire
$ edit/edt ....

This way you don't need to start anything, and you can still use a full screen editor (for the people that don't know how to use edt in line mode (we had to in the past -- on an LA36!)).

Jur.

[Art Wiens]

I think you get the idea of how to boot and retain control. How about the original problem which leaves you in this bad state?

"some called com file seems to produce an error"

Do you know which COM it is? Or have the details of the error message produced? If so, a simple way to temporarily resolve might be to RENAME the offending proc out of the way.

Give us a few more clues what you think/know is wrong.

Cheers,
Art

[Christian Burschka]

Hi,

thank You all for Your help and hints!
I have to try out some options.
Read some manuals etc.

Have a nice weekend!

Regards Chris

[Christian Burschka]

Thanks for Your patience.
I am not too familiar with the system, it simply worked fine for 10 years!

To give You some more information:
I think I have to look into some log files.
unfortunately the last logfile cant be read.
(where should I look?)

in an earlier logfile I find:

Error opening:
ipds$Dir:[sysmgr]ipds_login.com

(IPDS is an instrument controlled by the alphastation. This com file is definetely not there and should not be, but in a different directory. I think the com file is called at the end of systartup_vms.com. May be I should just copy it there to suppress the error?
But still I wonder why the system looks at the wrong place...may be I pasted something where I didnt intend to)


and further down:
executing:
sys$syroot:[sysmgr]login.com

executing:
mcr CDE$system_defaults:[bin]DTsession
exiting xsession.com

I am afraid this is how I got stuck with the
""single user desktop environment""
This all happened while trying out some changes to get the communication with the
instrument running again.

Although I would like to be able to handle a line editor, i find it somewhat risky in this situation...

Still thinking,

Chris.

[Christian Burschka]

By the way,

can anyone tell me why DEC invented
this (to me confusing) directory tree with
some files duplicate (used or not used ??)

VMS$COMMON ??

What is its purpose ?

I remember editing a Systartup_vms.com
in this directory unintentionally (!!) which was then saved by some default in [SYS0.SYSMGR] unintentionally for whatever reason.

Thanks,

Chris

[Ian Miller.]

VMS$COMMON is part of the structures used where multiple systems boot from the same system disk in a cluster. The advantage of this is that there is reduced system management overhead (e.g one copy of the software to update).

RTFM
http://h71000.www7.hp.com/doc/82FINAL/6318/6318pro_020.html#index_x_721

[Christian Burschka]

To keep You informed:

I copied the concerning com file into
[sys0.sysmgr] where it is not meant to be, but where the system looked for it and now
I get a normal boot.

everything ok, almost, because
there must be at least some wrong logical assignment left somewhere, caused by the author.... :-)

Cheers,

Chris.

[Jan van den Ende]

Chris,

>>>
can anyone tell me why DEC invented
this (to me confusing) directory tree with
some files duplicate (used or not used ??)
<<<

Be aware, those are NOT duplicate files!!!
SYSCOMMON.DIR is and alias name for the toplevel directory VMS$COMMON, and as such is a sub-directoty of EVERY [SYSn] topdirectory.
For each node booting from this system disk, SYS$SYSROOT is a seach path trough its SPECIFIC [SYSn] (SYS$SPECIFIC) and the SYSCOMMON (SYS$COMMON)
So, EACH node has full use of everything in [.SYSCOMMON...], while it is present on disk only once.
Nowadays it is hardly relevant that this saves diskspace, BUT, it makes maintaining a cluster AS A WHOLE just the same as maintaining one system.
King of impossible to explain to non-VMS system managers...


hth

Proost.

Have one on me.

jpe

[Christian Burschka]

Jan,

thanks for Your comment!

so I guess on a standalone system I should
leave everything as it is in SYScommon and VMS$COMMON ?

But if I change systartup_vms.com, (there are about 20 versions on my machine in [sysy0.sysmgr]and about 7 (older) in the "common" directory, which one will the system read, the newest file or the highest version number or the first it finds ?

Regards,

Chris.

[Karl Rohwedder]

It will read the one with the highest version number in the 1st directory of the searchpath, where it finds a match.
So [sys0.sysmgr]systartup_com.com;1 takes precedence over [sysn.syscommon.sysmgr]systartup_vms.com;32000.
If you edit a file, the output file is created in the same directory as the input file.

regards Kalle

[Jan van den Ende]

Chris,

SYS$SYSROOT is a search list trough SYS$SPECIFIC, and then SYS$COMMON.

Each time a file is SYS$SYSROOT (or its derivatives, like SYS$SYSTEM, SYS$LIBRARY, SYS$HELP ...) is referenced, first it is searched in specific, and if not found, then in common. The first hit is used.
(this mechanism is available throughtout VMS: in the file system and in the logical name system, and the list is not limited to 2 entries. It makes for very elegant applications as well)
So IF a file is present in SYS$SPECIC, then normally that file is used.
New allocations by default go to the FIRST entry in the search list.
Of course it IS possible to address the SYSCOMMON environment, by not using the search list name, but an explicit reference.

In a non-clustered system the entries indeed DO have a tendency to get mixed up, and then become somewhat mysterious to those not used to working in a cluster environment. But that really IS because of those managing those systems are unaware, or sloppy...

hth

Proost.

Have one on me.

jpe

[Christian Burschka]

Thank You all for Your comments,

this was very instructive!

Regards

Chris.

[Robert Gezelter]

Christian,

In a configuration that is not a cluster, and as a result does not have a "common system disk", the separate roots still have a use.

The different system roots (e.g., SYS0, SYS1) are selectable from the console boot command. These can be used for booting alternate system configurations or roles. I often use this feature during system testing. Changing a parameter in an alternate system root (cloned from the production root) allow the testing of tuning changes, while retaining the ability to go back to the original configuration instantly.

This also can be used to reduce the amount of editing that needs to be done when an emergency situation occurs. The different failure contingencies can be pre-planned and pre-configured, and adopted instantly by merely rebooting.

I hope that the above is helpful.

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

[Christian Burschka]

Robert,

this is indeed very helpful!
Never thought of that possibility !

Thanks for Your answer.

Regards

Chris.

[Jan van den Ende]

Chris,

indeed is SO helpful, that SYSF is "Reserved fo Digital" because for an OS upgrade, they first use SYSF to build an intermediate config, boot from there, and use that to update the rest of the system (any other roots found on the system disk, and VMS$COMMON). After the changes, they boot again from the original root, into a now-updated system.

hht

Proost.

Have one on me.

jpe

[Christian Burschka]

Dear experts,

I still need Your kind advice. May be I did not get an important point. The situation:
I can get around the problem, but I can not trace the error. To find the error, I think I have to use the faulty system.

Faulty-Startup does not run free of some error. (where shall I look?)
The windowmanager starts, but I cannot open
a terminal window.

Ok, by a conversational boot I get into the console to use dcl commands, fine.

How should I tune the startup...coms to trace the error?

Regards

Chris

[Volker Halle]

Chris,

you can set the system-parameter STARTUP_P2="D" to get startup messages written into SYS$SYSTEM:STARTUP.LOG

>>> B -fl root,1
SYSBOOT> SET STARTUP_P2 "D"
SYSBOOT> C

After startup is finished, you can then check that file for error messages.

Volker.