Enumerating logicals

Enumerating logicals

Post by Johan Nilsso » Thu, 03 Jul 2003 18:19:30



Hi,

is there a way to programmatically enumerate all logical definitions
contained in a specific logical name table, without resorting to parse the
output of show log/table=xxx .

// Johan

 
 
 

Enumerating logicals

Post by Martin Vorlaende » Thu, 03 Jul 2003 19:33:43



> is there a way to programmatically enumerate all logical definitions
> contained in a specific logical name table, without resorting to
> parse the output of show log/table=xxx .

There's a package written by Ferry Bolhar. You can find it at
ftp://ftp.process.com/vms-freeware/fileserv/lnmlookup.zip
It's a user-written system service, so requires privileges
(at least for the installation).

cu,
  Martin
--
  OpenVMS:                | Martin Vorlaender  |  VMS & WNT programmer

   God runs the           |   http://www.pdv-systeme.de/users/martinv/


 
 
 

Enumerating logicals

Post by Hoff Hoffm » Fri, 04 Jul 2003 03:13:19



:is there a way to programmatically enumerate all logical definitions
:contained in a specific logical name table, without resorting to parse the
:output of show log/table=xxx .

  No wildcard-capable logical name API interface exists for any
  version of OpenVMS, and the only existing mechanism that provides
  this is the kernel-mode code within SHOW LOGICAL itself.  

  There are various previous discussions of this, with discussions
  arising roughly yearly.

  Parsing the output of any DCL commands is generally not supported
  and is generally not recommended -- the command output contents and
  output format can and does change.

  What are you up to?  (You might be implementing something odd here
  and there may be an alternative approach, or you might be using
  logical names in a way that was not intended.)

 ---------------------------- #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

 
 
 

Enumerating logicals

Post by Keith A. Lew » Fri, 04 Jul 2003 04:19:10




>:is there a way to programmatically enumerate all logical definitions
>:contained in a specific logical name table, without resorting to parse the
>:output of show log/table=xxx .

>  No wildcard-capable logical name API interface exists for any
>  version of OpenVMS, and the only existing mechanism that provides
>  this is the kernel-mode code within SHOW LOGICAL itself.  

Hoff, you and your employer may not approve of Lnmlookup, but it does exist!

I've been using it in our main VMS app since 1996.  Back then I got it from
ftp://ftp.hhs.dk/misc/lnmlookup.zip.  I have been keeping up with the latest
versions of VMS (7.3-1 now), and I have never needed to update Lnmlookup
(although I have had to rebuild/reinstall it after certain VMS upgrades).  

Quote:>  What are you up to?  (You might be implementing something odd here
>  and there may be an alternative approach, or you might be using
>  logical names in a way that was not intended.)

I'll tell you what I use it for.  Our app is a heterogeneous system of
30-300 VMS processes which use VMS mailboxes to communicate.  We use logical
names to point to the MBA device names.  When the app was already fairly
mature, I started work on a subsystem which would monitor the rest of the
system for various failures.  MBA devices are well-suited for this because
using the opcount and the queue length data, you can calculate message
throughput.  My monitoring subsystem scans the logical name table for names
which match a pattern and creates a table of mailboxes for which it gathers
stats.  Only the monitoring subsystem needs Lnmlookup, because all of the
other subsystems know where they're supposed to read and write their
messages, so they can just to a straight TRNLNM.  But for the monitoring
subsystem, Lnmlookup has been incredibly useful.  It really ought to be
incorporated into the utility library, IMHO.

The legacy mailbox monitoring tool which I inherited parsed the output of
SHOW LOGICAL.

--Keith Lewis              klewis$mitre.org
The above may not (yet) represent the opinions of my employer.

 
 
 

Enumerating logicals

Post by Johan Nilsso » Fri, 04 Jul 2003 05:58:37





> :is there a way to programmatically enumerate all logical definitions
> :contained in a specific logical name table, without resorting to parse
the
> :output of show log/table=xxx .

>   No wildcard-capable logical name API interface exists for any
>   version of OpenVMS, and the only existing mechanism that provides
>   this is the kernel-mode code within SHOW LOGICAL itself.

>   There are various previous discussions of this, with discussions
>   arising roughly yearly.

>   Parsing the output of any DCL commands is generally not supported
>   and is generally not recommended -- the command output contents and
>   output format can and does change.

Perhaps, but I might resort to this anyway - I'd just pick up the logical
names and then use sys$trnlnm to get the values.

Quote:

>   What are you up to?  (You might be implementing something odd here
>   and there may be an alternative approach, or you might be using
>   logical names in a way that was not intended.)

I don't know how odd it is, but ...

I'm trying to use the make replacement Jam, available from www.perforce.com.
It's usable for OpenVMS (with a few quirks), but under other environments
(Win32, *nix, ...) it automatically imports the environment variables which
obviously can't be done under VMS. Ok ... well, it can .. but there aren't
really many of them and I don't believe that they are user definable. I know
that getenv does lookup logical names, but I'd need to load them at startup
and not dynamically during program execution.

As a replacement I was looking into support for loading the contents of a
specific logical name table instead, controlled by a command-line option or
in a Jamfile; e.g.:

jam "-sVMSIMPORT=LNM$PROCESS"

// Johan

 
 
 

Enumerating logicals

Post by David J. Dachter » Fri, 04 Jul 2003 10:23:02




> :is there a way to programmatically enumerate all logical definitions
> :contained in a specific logical name table, without resorting to parse the
> :output of show log/table=xxx .

>   No wildcard-capable logical name API interface exists for any
>   version of OpenVMS, and the only existing mechanism that provides
>   this is the kernel-mode code within SHOW LOGICAL itself.

>   There are various previous discussions of this, with discussions
>   arising roughly yearly.

>   Parsing the output of any DCL commands is generally not supported
>   and is generally not recommended -- the command output contents and
>   output format can and does change.

>   What are you up to?  (You might be implementing something odd here
>   and there may be an alternative approach, or you might be using
>   logical names in a way that was not intended.)

Well, for starters, just about any DCL proc.'s intended to help automate
system management must currently rely on parsing the output of SHOW
LOGICAL as this is currently the only mechanism available in vanilla
VMS, supported or not.

More specific?

See:
http://www.djesys.com/freeware/vms/freedisk.zip

This uses F$DEVICE() which does, oddly enough, have better wildcard
support than SHOW DEVICE.

Now, suppose I wanted to display the capacity/utilization of disks where
the LOGVOLNAM (P3 to the MOUNT command) started with, say "BACK_". With
SHOW LOGICAL, I can use the expression "BACK_*". F$TRNLNM(), however,
returns nothing, as does F$DEVICE(). If F$TRNLNM() *DID* support
wild-card lookups, I could get what I need without having to spend extra
time hacking/cobbling DCL to work-around this missing piece of
functionality.

So, if there *IS* an alternative (supported?) to parsing output from
SHOW LOGICAL, some of us out here are all ears.

--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

 
 
 

Enumerating logicals

Post by Patrick Spinle » Sat, 05 Jul 2003 05:12:25



>   No wildcard-capable logical name API interface exists for any
>   version of OpenVMS, and the only existing mechanism that provides
>   this is the kernel-mode code within SHOW LOGICAL itself.  

>   There are various previous discussions of this, with discussions
>   arising roughly yearly.

>   Parsing the output of any DCL commands is generally not supported
>   and is generally not recommended -- the command output contents and
>   output format can and does change.

>   What are you up to?  (You might be implementing something odd here
>   and there may be an alternative approach, or you might be using
>   logical names in a way that was not intended.)

Me - I'd just like a working, fully functional VMS Perl logical
interface module.  Something that, for instance, would allow me to tie a
logical name table to a perl hash, and treat it as such.

Part of Perl's hash functionality is to obtain all the available keys.
Ergo, the perl module to implement this function would have to get a
list of all logicals in a specific table.

I have some prototype code which I use from time to time, but it's far
too ugly to release.  A large part of it's uglyness is that it
internally has to lib$spawn a dcl process to do a "show
logical/table=XXX".  Ugh.

Well, not only for perl, I use wildcard logical lookup in DCL for all
sorts of things.  For example, we have a script text menu system which
defines the menus in logicals.  So, for example, to get all the menu
items for a particular menu, we have to do things like this: "show log
/table=<menu_table> menu_item_*"

As another example, we also have a system of applications on our
cluster, which consist, amoung other things, of application servers
which do processing.  The list of servers, commands to run them, their
arguments and other information we define in logical name tables.
Again, to get the list of servers to start, we end up doing things like
"show log /table=<app_config_table> daemon_command_*"

I could go on, but I think you get the point.  It's just an incredibly
useful facility.

-- Pat