how to get console variables from alpha system crash dump

[Scotty HD]

crash dump experts,
how do i get console variable information from a alpha crash dump.
what is the command?

Scotty

[Bhadresh]

you can use show symbol command to get console variable information.

Regards,
Bhadresh

[Volker Halle]

Scotty,

'console variables' are stored in the SRM console memory. I don't think this memory is available in an OpenVMS system dump.

What are you interested in ?

Volker.

[Scotty HD]

Bhadresh>>
show symbol command does not give me the console variable information.
it gives only symbol information.

Volker Halle>>
i know how to change console variables but i was curious to know if i get
what AUTO_ACTION is set from the crash dump.

from what you say, console variables might not be stored in the crash dump.
thanks for information.

Scotty

[MichelleP_1]

See if the F$GETENV lexical helps. For example:
$ WRITE SYS$OUTPUT F$GETENV("AUTO_ACTION")

That's if you want current information, not for gleaning it from the dump, so may not be what you're looking for.

[John Gillings · Accepted solution]

Scotty,

I believe F$GETENV and the underlying system service $GETENV request the information on demand from the console subsystem directly, rather than just reading from a structure in memory. That would mean the values aren't stored by the OS, and therefore unlikely to be available from a crash dump. Maybe worth looking at the source of $GETENV to confirm.

Your request seems reasonable to me. Maybe you should log a service case requesting that the console variables be stored somewhere that is written to the dump?

Note that if it is implemented, it's likely to be a compromise. For example, reading all console variables at boot time and stashing them in memory, thus any updates made on the console after boot time may not be reflected in the dump. I'd guess that for most purposes that wouldn't matter.

It's unlikely that OpenVMS engineering would implement a call to $GETENV at the time of the crash, as dump processing is fairly strictly focused on getting the dump out to disk. Since the system is, by definition, in an inconsistent state, there's no scope for doing anything which might make things worse.

[John Gillings]

Scotty,

Thinking about this a bit more, you could run a detached process that reads all the console variables and keeps them in memory. SMOP.

See attached command procedure.

$ @GETENV

will build a non-privileged program and run a detached process to sample the variables.

$ @GETENV #UPDATE

will resample the variables

$ @GETENV #STOP
$ @GETENV #START
$ @GETENV #SHOW

to stop, start and show the process

$ @GETENV #DISPLAY

to dump the block of memory containing the variables using SDA.

$ @GETENV #BUILD [force]

to recompile and relink the sample and update programs.

In a dump, use SHOW SUMMARY to find the process called GETENV, then

SDA> EXAMINE 20000;600

to dump the data. Depending the memory starvation of your system, in practice it may be necessary to add a $LKWSET to keep the data in working set, or in extreme cases maybe even $LCKPAG (privileged). Left as an exercise.

It may also be necessary to add the GETENV process to the priority list for dumping. Somewhere around there's a file containing the priority list.

Minimal testing, seems to work... can't really do much damage, no privilege required.

[undocumented trap for the unwary! $GETENV requires the buffer into which the string is written to be QUAD aligned, hence the line:

.BLKB <8-<<%LENGTH(name)+1>&7>>&7
]

[Scotty HD]

thanks john. i will give that program a try.
closing this for now.

Scotty