looking for suggestions for new $GETDVI item codes . . .

[Rob Brooks]

Hi VMS fans . . .

I'll make this quick; I'm in the middle of adding several new item
codes for $GETDVI (SYS$, LIB$, F$).

You all have 24 hours (until 14:30 GMT) to make suggestions for new item
codes for $GETDVI!

Some rules . . .

1) This is only for $GETDVI (not $GETSYI, $GETQUI, etc . . .)

2) Only one suggestion per person, please.

3) There is no guarantee that anything will actually get implemented
in V8.2. While we are ramping down the introduction of new
stuff, it's rather simple to add most $GETDVI item codes with
rather low risk. Still, there is no guarantee that any of this
will make V8.2.

4) Please make it clear what information you expect this item code
to return.

5) The decision of the judge (me) is final.

[Tom Linden]

Maybe there is some way to provide similar capability to Tru64

-bash-2.05b$ man consvar
Use the consvar command to get, set, list, and save console environment
variables available on SRM system firmware. Some firmware versions on
some
platforms do not comply with the Alpha SRM when dealing with certain vari-
ables, or operations. To ensure UNIX functionality with such firmware, an
exception database is consulted and these operations are disabled. By
default, consvar accepts and displays device values with Tru64 UNIX device
names, or their device special file names. The raw console bootstrings can
be used by providing the -nc option. For information regarding the console
environment variables, please refer to the Alpha System Reference Manual.


-----Original Message-----
From: Rob Brooks [mailto:***@cuebid.zko.dec.nospam]
Sent: Wednesday, May 05, 2004 7:52 AM
To: Info-***@Mvb.Saic.Com
Subject: looking for suggestions for new $GETDVI item codes . . .



Hi VMS fans . . .

I'll make this quick; I'm in the middle of adding several new item
codes for $GETDVI (SYS$, LIB$, F$).

You all have 24 hours (until 14:30 GMT) to make suggestions for new item
codes for $GETDVI!

Some rules . . .

1) This is only for $GETDVI (not $GETSYI, $GETQUI, etc . . .)

2) Only one suggestion per person, please.

3) There is no guarantee that anything will actually get implemented
in V8.2. While we are ramping down the introduction of new
stuff, it's rather simple to add most $GETDVI item codes with
rather low risk. Still, there is no guarantee that any of this
will make V8.2.

4) Please make it clear what information you expect this item code
to return.

5) The decision of the judge (me) is final.

--

Rob Brooks VMS Engineering -- I/O Exec Group
brooks!cuebid.zko.dec.com

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.667 / Virus Database: 429 - Release Date: 4/23/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.667 / Virus Database: 429 - Release Date: 4/23/2004

[Rob Brooks]

Post by Tom Linden
Maybe there is some way to provide similar capability to Tru64
-bash-2.05b$ man consvar
Use the consvar command to get, set, list, and save console environment
variables available on SRM system firmware. Some firmware versions on
some
platforms do not comply with the Alpha SRM when dealing with certain vari-
ables, or operations. To ensure UNIX functionality with such firmware, an
exception database is consulted and these operations are disabled. By
default, consvar accepts and displays device values with Tru64 UNIX device
names, or their device special file names. The raw console bootstrings can
be used by providing the -nc option. For information regarding the console
environment variables, please refer to the Alpha System Reference Manual.

That's way beyond the scope of what $GETDVI does.

[Hoff Hoffman]

In article <***@kednos.com>, "Tom Linden" <***@kednos.com> writes:
:Maybe there is some way to provide similar capability to Tru64

This stuff is *way* outside $getdvi[w].


:-bash-2.05b$ man consvar
: Use the consvar command to get, set, list, and save console environment
: variables available on SRM system firmware. Some firmware versions on
: some platforms do not comply with the Alpha SRM when dealing with certain
: variables, or operations.

For what reason(s) are you looking at the SRM environment variables for,
and specifically which console environment variables are of interest?

Do remember that console-specific stuff tends to be non-portable, too.

There is a mechanism to display specific SRM variables available, using
the f$getenv lexical and the sys$getenv system service, and the astute
reader will notice other references within starlet.h that might be of
interest. (This SRM-related lexical made it into the FAQ some years
ago, and I know that Tom already knows about the calls and about the
mechanisms.)

There is presently no free-form environment variable query tool
provided, as the lexical and the system service have itemcodes and
not strings. (This too has been discussed.)

It is possible to create a tool which connects back into SRM for this,
and I've seen a few hacks around. There hasn't been a whole lot of
interest, but IIRC one tool has even shipped latent in OpenVMS. (Hmmm.
Possible fodder for my bootcamp presentation. :-)

Tools have been posted to the newsgroups before, too -- a quick search
found various examples. (I also see Tom has asked this consvar question
before, too.) Try `srm getenv' or `srm "environment variable"' searches.
One of the cited examples was posted by Fred Kleinsorge, and was named
"DEFAULT_BOOT"; it reads and writes bootdef_dev.


---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com

[Larry Kilgallen]

Post by Rob Brooks
Hi VMS fans . . .
I'll make this quick; I'm in the middle of adding several new item
codes for $GETDVI (SYS$, LIB$, F$).
You all have 24 hours (until 14:30 GMT) to make suggestions for new item
codes for $GETDVI!
Some rules . . .
1) This is only for $GETDVI (not $GETSYI, $GETQUI, etc . . .)

DVI$_MINE_MINE_MINE (subject to editorial review)

Post by Rob Brooks
2) Only one suggestion per person, please.

That's ok, my others are harder :-)

Post by Rob Brooks
4) Please make it clear what information you expect this item code
to return.

A boolean value indicating whether the subject device will be
totally unavailable if the machine on which the call is made
leaves the cluster. Thus the value would be:

True for single-ported SCSI (and Massbus) disks
False for dual-ported SCSI (and Massbus) disks
False for Fibre Channel disks
True for lineprinters
True for paper tape readers
True for MBA0: and NLA0: (that is a different one on
the other node)

Post by Rob Brooks
5) The decision of the judge (me) is final.

[Rob Brooks]

Post by Larry Kilgallen
A boolean value indicating whether the subject device will be
totally unavailable if the machine on which the call is made
True for single-ported SCSI (and Massbus) disks
False for dual-ported SCSI (and Massbus) disks
False for Fibre Channel disks
True for lineprinters
True for paper tape readers
True for MBA0: and NLA0: (that is a different one on
the other node)

Interesting . . . This one may take more time to accomodate all possible
devices and mechanisms of accessing such devices, so I may not have time
for V8.2, but if not, I'll keep it around for the next release.

[Peter 'EPLAN' LANGSTOEGER]

Post by Rob Brooks
I'll make this quick; I'm in the middle of adding several new item
codes for $GETDVI (SYS$, LIB$, F$).
You all have 24 hours (until 14:30 GMT) to make suggestions for new item
codes for $GETDVI!

MPDEV_AVAILABLE_PATHS and/or similar item codes
to get all the infos that SHOW DEVICE/MULTIPATH provides

[Rob Brooks]

Post by Peter 'EPLAN' LANGSTOEGER
MPDEV_AVAILABLE_PATHS and/or similar item codes
to get all the infos that SHOW DEVICE/MULTIPATH provides

Yes, I've gotten a suggestion via email to add two item codes -- one
that returns the total number of paths, and a second that returns
the number of currently-available paths.

I agree that those are great suggestions!

[David J. Dachtera]

Post by Rob Brooks

Post by Peter 'EPLAN' LANGSTOEGER
MPDEV_AVAILABLE_PATHS and/or similar item codes
to get all the infos that SHOW DEVICE/MULTIPATH provides

Yes, I've gotten a suggestion via email to add two item codes -- one
that returns the total number of paths, and a second that returns
the number of currently-available paths.
I agree that those are great suggestions!

Remember to include a keyword to get the list of paths!

...and the current path!

[Rob Brooks]

Post by David J. Dachtera
...and the current path!

dvi$_mpdev_current_path has been there since V7.3-1

[David J. Dachtera]

Post by Rob Brooks

Post by David J. Dachtera
...and the current path!

dvi$_mpdev_current_path has been there since V7.3-1

...but is not implemented (or not documented) in F$GETDVI(), which is
where it is most needed.

[Rob Brooks]

Post by David J. Dachtera

Post by Rob Brooks
dvi$_mpdev_current_path has been there since V7.3-1

...but is not implemented (or not documented) in F$GETDVI(), which is
where it is most needed.

It's documented in the System Services Reference Manual, which
is the canonical source of the item codes for the $GETxxI routines.

**ANY** item code that is documented for SYS$GETxxx is guaranteed to work
for both LIB$ and F$. As it turns out, the VMS operating system build
procedures are such that an engineer only has to do the work to make
a new item code exist for SYS$GETxxx and the LIB$ and F$ implementations
come along automatically. If an engineer wants to verify the behaviour
from DCL, he or she simply needs to build a version of DCL.EXE with updated
item code definitions to test the lexical form. Otherwise, we just build
a new version of IO_ROUTINES[_MON].EXE to test the SYS$ implementation.

That's probably more information than anyone really wants . . .

Not every piece of documentation is updated for every dashed release.

I'll make sure that is updated for V8.2, although not for the V8.2
field test (the documentation for that is done already, I think).

Thanks for the tip.

[Peter 'EPLAN' LANGSTOEGER]

Post by Rob Brooks

Post by David J. Dachtera

Post by Rob Brooks
dvi$_mpdev_current_path has been there since V7.3-1

...but is not implemented (or not documented) in F$GETDVI(), which is
where it is most needed.

Are you sure it isn't in HELP Lexicals F$GETDVI. I think I saw it there.
And it definitely is there in VMS V7.3-2 HELP.

Post by Rob Brooks
It's documented in the System Services Reference Manual, which
is the canonical source of the item codes for the $GETxxI routines.
**ANY** item code that is documented for SYS$GETxxx is guaranteed to work
for both LIB$ and F$. As it turns out, the VMS operating system build
procedures are such that an engineer only has to do the work to make
a new item code exist for SYS$GETxxx and the LIB$ and F$ implementations
come along automatically. If an engineer wants to verify the behaviour
from DCL, he or she simply needs to build a version of DCL.EXE with updated
item code definitions to test the lexical form. Otherwise, we just build
a new version of IO_ROUTINES[_MON].EXE to test the SYS$ implementation.
That's probably more information than anyone really wants . . .

:-)

Post by Rob Brooks
Not every piece of documentation is updated for every dashed release.

Yes, But OTOH it's a shame that it is a dashed release.
A dash release is per your company's definition a maintenance version
hence no new features, only a sum up of ECOs, which it isn't.

V7.3-1 and V7.3-2 had a lot new features and broke (initially) a lot of
(kernel mode or badly written) applications. They should have been
called V7.4 and V7.5 (or V8.0 and V8.1) which they are. And then the
dash documentation excuse wouldn't pop up here...

Post by Rob Brooks
I'll make sure that is updated for V8.2, although not for the V8.2
field test (the documentation for that is done already, I think).

Show me any bugfree environment ;-)

[David Harrold]

On Thu, 06 May 2004 19:56:15 -0500, "David J. Dachtera"

Post by David J. Dachtera

Post by Rob Brooks

Post by David J. Dachtera
...and the current path!

dvi$_mpdev_current_path has been there since V7.3-1

...but is not implemented (or not documented) in F$GETDVI(), which is
where it is most needed.

$ help lex f$getdvi
LEXICALS

F$GETDVI

Returns a specified item of information for a specified device.

Format

F$GETDVI(device-name,item)

Additional information available:

Return_Value Arguments Examples

LEXICALS F$GETDVI Subtopic? arg
LEXICALS

F$GETDVI

Arguments
[...snip...]
item
[...snip...]
MPDEV_CURRENT_PATH* MT3_DENSITY MT3_SUPPORTED
[...snip...]

$ SH SYS/NOPROC
OpenVMS V7.3-1 on node xxxx 7-MAY-2004 06:55:02.89 Uptime 6 19:13:06

Seems to be there on my systems.....

Dave Harrold

..............................................................................
David Harrold E-Mail: David.Harrold at aurora.org
Lead Software Systems Engineer Phone: [phone]
Pager: [phone]
Aurora Health Care Fax: [phone]
3031 W. Montana Street
Milwaukee, WI 53215

[David J. Dachtera]

Post by David Harrold
On Thu, 06 May 2004 19:56:15 -0500, "David J. Dachtera"

Post by David J. Dachtera

Post by Rob Brooks

Post by David J. Dachtera
...and the current path!

dvi$_mpdev_current_path has been there since V7.3-1

...but is not implemented (or not documented) in F$GETDVI(), which is
where it is most needed.

$ help lex f$getdvi
LEXICALS
F$GETDVI
Returns a specified item of information for a specified device.
Format
F$GETDVI(device-name,item)
Return_Value Arguments Examples
LEXICALS F$GETDVI Subtopic? arg
LEXICALS
F$GETDVI
Arguments
[...snip...]
item
[...snip...]
MPDEV_CURRENT_PATH* MT3_DENSITY MT3_SUPPORTED
[...snip...]
$ SH SYS/NOPROC
OpenVMS V7.3-1 on node xxxx 7-MAY-2004 06:55:02.89 Uptime 6 19:13:06

A matter of knowing the keyword to look for. I was looking HELP LEx
F$GETD from V7.3 when I was typing that text.

Of course, we still need the matching keyword:

MPDEV_PATH_LIST - Returns a comma-separated list of available paths to
the device.

[Phillip Helbig---remove CLOTHES to reply]

How about the possibility to get ALL terminal attributes with one call,
and a way to set them ALL back, instead of one line of DCL for each TT
thingy.

[Larry Kilgallen]

Post by Phillip Helbig---remove CLOTHES to reply
How about the possibility to get ALL terminal attributes with one call,
and a way to set them ALL back, instead of one line of DCL for each TT
thingy.

From DCL, that is done with SET/SHOW terminal.

From anywhere else, the "get" part is natural with $GETDVI.

[Phillip Helbig---remove CLOTHES to reply]

Post by Larry Kilgallen

Post by Phillip Helbig---remove CLOTHES to reply
How about the possibility to get ALL terminal attributes with one call,
and a way to set them ALL back, instead of one line of DCL for each TT
thingy.

From DCL, that is done with SET/SHOW terminal.
From anywhere else, the "get" part is natural with $GETDVI.

Right. However, at the moment one has to get the individual items with
F$GETDVI into separate symbols (I don't want to parse the output of SHOW
TERMINAL), then use SET TERMINAL with a bunch of qualifiers to reset
them. It would be nice if there were some $GETDVI code which would
return, say, a bitmask indicating whether various things visible with
SHOW TERMINAL have "No" in front of them, then use a compact SET
TERMINAL command to reset them.

$ TT_BIT_MASK = F$GETDVI("TT","TT_ALL")
.
.
.
$ SET TERMINAL/ALL_ATTRIBUTES='TT_BIT_MASK'

[Paul Repacholi]

Post by Phillip Helbig---remove CLOTHES to reply
How about the possibility to get ALL terminal attributes with one
call, and a way to set them ALL back, instead of one line of DCL for
each TT thingy.

At the program level, RSX could do that, and I would be amaised if VMS
can't. Time for Kermit to be borged with DCL :)

[Graham Burley]

Post by Rob Brooks
Hi VMS fans . . .
I'll make this quick; I'm in the middle of adding several new item
codes for $GETDVI (SYS$, LIB$, F$).
You all have 24 hours (until 14:30 GMT) to make suggestions for new item
codes for $GETDVI!

BOOT_DEVICE - for disks returns TRUE or FALSE to indicate whether
the device was the boot device.


Graham

[Hoff Hoffman]

In article <***@encompasserve-or-this.org>, Graham Burley <burley.not-***@encompasserve-or-this.org> writes:

:BOOT_DEVICE - for disks returns TRUE or FALSE to indicate whether
:the device was the boot device.

Out of curiousity, what would you expect to see returned with a
shadowset or a RAID controller? (It is possible for the system
disk that was originally bootstrapped to be off-line, after all.)

Depending on what you are looking for with the bootstrap details,
you could look at the SYS$SYSDEVICE logical name, or the f$getenv
returns for booted_dev and bootdef_dev -- the latter can admittedly
look rather unlike devices, however, with an example being:

On a SAN system:

$ x=f$getenv("booted_dev")
$ show symbol x
X = "SCSI3 2 2 0 2 0 0 0 @wwid0 080200 0000000000000200"
$ x=f$getenv("bootdef_dev")
$ show symbol x
X = "SCSI3 2 2 0 1 0 0 0 @wwid0,SCSI3 2 2 0 2 0 0 0 @wwid0"

On another box, with a direct-attached SCSI boot disk:

$ x=f$getenv("booted_dev")
$ show symbol x
X = "SCSI 1 2001 0 1 100 0 0"
$ x=f$getenv("bootdef_dev")
$ show symbol x
X = "SCSI 1 2001 0 1 100 0 0"
$

But again, I'm interested in knowing details of why the bootstrap
disk is of interest? (There could be existing tools or options,
for instance, depending on what the target problem might be.)

---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com

[Rob Brooks]

Post by Graham Burley
BOOT_DEVICE - for disks returns TRUE or FALSE to indicate whether
the device was the boot device.

Where (and why) would you want to know this?

[Graham Burley]

Post by Rob Brooks

Post by Graham Burley
BOOT_DEVICE - for disks returns TRUE or FALSE to indicate whether
the device was the boot device.

Where (and why) would you want to know this?

Preferrably in F$GETDVI. This would be of great use to folks who
perform shadow backups on system disks, so that they can avoid
dismounting the boot device. So, to answer one of Hoffs questions
it should only return TRUE on a shadowset member.


Graham

[David J. Dachtera]

Post by Graham Burley

Post by Rob Brooks

Post by Graham Burley
BOOT_DEVICE - for disks returns TRUE or FALSE to indicate whether
the device was the boot device.

Where (and why) would you want to know this?

Preferrably in F$GETDVI. This would be of great use to folks who
perform shadow backups on system disks, so that they can avoid
dismounting the boot device. So, to answer one of Hoffs questions
it should only return TRUE on a shadowset member.

I'd take that a step further: it should return TRUE regardless of
whether the device is a shadow-set member or not!

...and I'd add a counter-part in F$GETSYI: BOOT_DEVICE_NAME (returns
ALLDEVNAM of the boot device; F$GETDVI() can be used later to determine
whether or not the device is now a shadow-set member.

[Ken Randell]

Post by Rob Brooks
Hi VMS fans . . .
I'll make this quick; I'm in the middle of adding several new item
codes for $GETDVI (SYS$, LIB$, F$).
You all have 24 hours (until 14:30 GMT) to make suggestions for new item
codes for $GETDVI!

How about:

DVI$_EXTEND to return the default extension quantity for a disk
volume, as in the 'Extend quantity' value under '$SHOW DEVICE D/FULL'

This would have been useful to me in certain situations.

[Hoff Hoffman]

In article <***@posting.google.com>, ***@verizon.net (Ken Randell) writes:

:DVI$_EXTEND to return the default extension quantity for a disk
:volume, as in the 'Extend quantity' value under '$SHOW DEVICE D/FULL'

I'm mildly surprised sys$getdvi[w] doesn't already have a way
to return this value, but I don't see it in the listings.

I'll assume you are aware of the system, volume, process and
application-level extend settings -- the volume-level setting
is one of the values of last resort (if not the actual last
resort :-), assuming that the default value has not been set
in one of the other applicable locations. There's more to
this than just the volume extend setting, in other words.


---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com

[David J. Dachtera]

Post by Hoff Hoffman
:DVI$_EXTEND to return the default extension quantity for a disk
:volume, as in the 'Extend quantity' value under '$SHOW DEVICE D/FULL'
I'm mildly surprised sys$getdvi[w] doesn't already have a way
to return this value, but I don't see it in the listings.
I'll assume you are aware of the system, volume, process and
application-level extend settings -- the volume-level setting
is one of the values of last resort (if not the actual last
resort :-), assuming that the default value has not been set
in one of the other applicable locations. There's more to
this than just the volume extend setting, in other words.

...but in large measure, the system-level default is most likely the one
that will be used, in my experience.

Of course, whether ot not the default extend quantity is an entire
cluster constitutes a whole separate discussion.

[Rob Brooks]

Post by Ken Randell
DVI$_EXTEND to return the default extension quantity for a disk
volume, as in the 'Extend quantity' value under '$SHOW DEVICE D/FULL'

Yup, I agree; this will be done.

[David J. Dachtera]

Post by Rob Brooks
Hi VMS fans . . .
I'll make this quick; I'm in the middle of adding several new item
codes for $GETDVI (SYS$, LIB$, F$).
You all have 24 hours (until 14:30 GMT) to make suggestions for new item
codes for $GETDVI!

Ready Rob? Here we go...

Everything on the SHOW DEVICE/FULL display, plus:

FREE_HEADERS - count of unallocated headers in INDEXF.SYS

MAX_HEADER - total count of file headers in INDEXF.SYS

FREE_EXTENTS - count of unused extent bits in BITMAP.SYS

MAX_EXTENT - total count of extent bits in BITMAP.SYS

FREE_INDEXF_MAPWORDS - as displayed by DFU REPORT (gives a clue as to
INDEXF.SYS fragmentation)

MOUNT_COUNT - as displayed by SHOW DEVICE/MOUNTED

MOUNT_NODES - List of node names as displayed by SHOW DEVICE/FULL

Keywords for all of the mapped bits in DEVCHAR, DEVCHAR2, DEVDEPEND and
DEVDEPEND2

SHDW_COPY_NODE - Name of node in cluster handling the current shadow
copy/merge thread for this shadow-set or member.

SHDW_MEMBER_COUNT - Number of members in the shadow-set (counterpart to
VOLCOUNT for volume-set)

MEDIA_FORMAT - Returns "ODS-2", "ODS-5", "ISO-9660", etc. for disk;
[NO]COMPACT for magtape.

TCACHE_AVAILABLE - Returns TRUE or FALSE (tape device caching)

TCACHE_ENABLED - Returns TRUE or FALSE (tape device caching)

TCOMPACT_AVAILABLE - Returns TRUE or FALSE (tape device compaction)

TCOMPACT_ENABLED - Returns TRUE or FALSE (tape device compaction)

TDENSITY - Returns value displayed by SHOW DEVICE/FULL

DISMOUNT_UNLOAD - Returns TRUE or FALSE (unload on DISMOUNT).

WBCACHE - Returns TRUE or FALSE (Write-back caching)

RDCACHE - Returns TRUE or FALSE (Read caching)

SPLQUENAM - Returns the name of the queue through which a
terminal/printer is spooled (counterpart to SPLDEVNAM)

TT_CTS - Returns HIGH or LOW per state of signal.

TT_DTR - Returns HIGH or LOW per state of signal.

TT_DCD - Returns HIGH or LOW per state of signal.

TT_RTS - Returns HIGH or LOW per state of signal.

TT_DSR - Returns HIGH or LOW per state of signal.

TT_BAUD_RATE - Actual value as displayed by SHOW TERMINAL

LP_ONLINE - Returns HIGH or LOW per state of signal.

LP_FAULT - Returns HIGH or LOW per state of signal.

Think that will keep you busy for a while? I'm sure I could come up with
lots more given a longer research window...

[Rob Brooks]

Post by David J. Dachtera
SHDW_COPY_NODE - Name of node in cluster handling the current shadow
copy/merge thread for this shadow-set or member.

shdw_copier_node was put in for V7.3-2

Post by David J. Dachtera
SHDW_MEMBER_COUNT - Number of members in the shadow-set (counterpart to
VOLCOUNT for volume-set)

shdw_mbr_count and shdw_device_count were both added for V7.3-2.
See the documentation for the distinction between the two.

[Bob Koehler]

Post by Rob Brooks
1) This is only for $GETDVI (not $GETSYI, $GETQUI, etc . . .)

Since set terminal/delete=backspace is comming (maybe I got the syntax
wrong), is there a $GETDVI code to find out what the setting is?

[Hoff Hoffman]

In article <***@eisner.encompasserve.org>, ***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
: Since set terminal/delete=backspace is comming (maybe I got the syntax
: wrong), is there a $GETDVI code to find out what the setting is?

SET TERMINAL/BACKSPACE=DELETE, or SET TERMINAL/BACKSPACE=BACKSPACE.

Look for TT3$M_BS to be lit, using standard TTDRIVER $qio[w] requests.

---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com

[David J. Dachtera]

Post by Bob Koehler

Post by Rob Brooks
1) This is only for $GETDVI (not $GETSYI, $GETQUI, etc . . .)

Since set terminal/delete=backspace is comming (maybe I got the syntax
wrong), is there a $GETDVI code to find out what the setting is?

...and a matching keyword for F$GETDVI()?

[Tom Linden]

-----Original Message-----
From: Hoff Hoffman [mailto:***@hp.nospam]
Sent: Wednesday, May 05, 2004 12:05 PM
To: Info-***@Mvb.Saic.Com
Subject: RE: looking for suggestions for new $GETDVI item codes . . .


In article <***@kednos.com>, "Tom
Linden" <***@kednos.com> writes:
:Maybe there is some way to provide similar capability to Tru64

This stuff is *way* outside $getdvi[w].


:-bash-2.05b$ man consvar
: Use the consvar command to get, set, list, and save console environment
: variables available on SRM system firmware. Some firmware versions on
: some platforms do not comply with the Alpha SRM when dealing
with certain
: variables, or operations.

For what reason(s) are you looking at the SRM environment variables for,
and specifically which console environment variables are of interest?

Do remember that console-specific stuff tends to be non-portable, too.

There is a mechanism to display specific SRM variables available, using
the f$getenv lexical and the sys$getenv system service, and the astute
reader will notice other references within starlet.h that might be of
interest. (This SRM-related lexical made it into the FAQ some years
ago, and I know that Tom already knows about the calls and about the
mechanisms.)

There is presently no free-form environment variable query tool
provided, as the lexical and the system service have itemcodes and
not strings. (This too has been discussed.)

It is possible to create a tool which connects back into SRM for this,
and I've seen a few hacks around. There hasn't been a whole lot of
interest, but IIRC one tool has even shipped latent in OpenVMS. (Hmmm.
Possible fodder for my bootcamp presentation. :-)

Oh good, so not a total waste:-)

Tools have been posted to the newsgroups before, too -- a quick search
found various examples. (I also see Tom has asked this consvar question
before, too.) Try `srm getenv' or `srm "environment variable"'
searches.
One of the cited examples was posted by Fred Kleinsorge, and was named
"DEFAULT_BOOT"; it reads and writes bootdef_dev.

I would find it convenient, for example, to change the console from, say,
serial to graphics upon reboot to avoid searching about for cables and
likewise auto_action.

---------------------------- #include <rtfaq.h>
-----------------------------
For additional, please see the OpenVMS FAQ --
www.hp.com/go/openvms/faq
--------------------------- pure personal
opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.667 / Virus Database: 429 - Release Date: 4/23/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.667 / Virus Database: 429 - Release Date: 4/23/2004

[m***@cpva.saic.com]

Post by Rob Brooks
Hi VMS fans . . .
I'll make this quick; I'm in the middle of adding several new item
codes for $GETDVI (SYS$, LIB$, F$).
You all have 24 hours (until 14:30 GMT) to make suggestions for new item
codes for $GETDVI!

How about a DVI$_CLUMOUNTCNT which would return the number of
nodes that have a device mounted in a cluster (matching the
value displayed in a SHOW DEVICE display).

[Rob Brooks]

Post by m***@cpva.saic.com
How about a DVI$_CLUMOUNTCNT which would return the number of
nodes that have a device mounted in a cluster (matching the
value displayed in a SHOW DEVICE display).

Yeah, that's already on the list of things to do. It won't happen for
V8.2, though. It's substantially harder to do within $GETDVI than it is
in SHOW, and we've not been able to come up with a bullet-proof implementation
for $GETDVI.

We know that this is a longstanding annoyance; sorry.