Larry writes:

...
> system was booted.  That does *not* mean the device does not exist or
> has not been configured.  It merely means that LISTSPF tried to find
> files on a queue for it and did not.

good point!

> If you want a command to verify your configuration, invent one
> (VALIDATEDEVICE or some such).  Don't overload other commands with
> unrelated functionality.

Good suggestion!  (See tail end for elaboration)

> And don't call it a bug (unless you can
> find a spec that says LISTSPF will identify all non-existent devices).

So, I decided to look closely at the syntax for LISTSPF...

        LISTSPF [[IDNAME=] { spoolid                }]
                           {(spoolid [,spoolid ]...)}
                [[;SELEQ=]select_eq ]
                           {^indirect_file }
                [{;DETAIL}]
                 {;STATUS}
   ...
                       <select-eq> ::= [<equation>]

                       <equation>  ::= {(<equation>)              }
                                       {(NOT <equation>)          }
                                       {<equation><AND><equation> }
                                       {<equation><OR><equation>  }
                                       {                          }
                                       {     {> }                 }
                                       {     {>+}                 }
                                       {     {< }                 }
                                       {parm {<+} value           }
                                       {     {<>}                 }
                                       {     {+ }                 }
   ...

   DEV                 Ldev number, device name, or device class
                       name.  Wildcarding is supported for device
                       name and device class name.

BTW, there's a line missing from the help text (I assume), because
the syntax above says you can't have a select-eq with an "="
in it (e.g., SELEQ=[DEV=LP]), but that actually works fine.

OTOH, it says I can use operators other than "<>" (and "="), like
"<" and ">" ... as in:

   :listspf @;seleq=[dev > lp]

but, that gets the error:

    "=" and '<>' are the only applicable relational operator for operators
   for DEV parameter in SELEQ. (CIERR 4562)

And, it looks like none of the "+" forms of the equation are actually
allowed.

Ok...enough of the "destructive testing" :)


Larry pointed out that I was trying to add a secondary purpose
to LISTSPF: validating printer device names, and suggested that the
specifications don't say that LISTSPF will identify all non-existent devices.

(Note, Larry said "specifications", but I'm referring to the on-line
help text, which of course isn't the same thing, but we don't have
access to MPE internal documents like specifications.)

I had tried using LISTSPF as a printer device class name checker
because the help text said it accepted a device name.
It didn't say "a string of 1 to 8 letters and/or digits, with a leading
letter" (i.e., a "token" that fits the device name syntax restrictions).

So, I expected some degree of checking from LISTSPF ... and
indeed, it does some checking...just less than I expected.  It
properly rejects "device names"  that are too long, or have
illegal characters.

OTOH, I must admit: the help text said nothing about the device name
having to be a PRINTER device.  So, even if LISTSPF did restrict the
"device name" parameter to be a legal device name, that wouldn't mean
a legal PRINTER!

So, I'm out of luck anyway!

But, this exercise in reading the help text closely was
instructive to me: I hadn't realized that LISTSPF allows
wildcarded device names and wildcarded device class names!

(However, it suffers from a common MPE shortcoming that you can't
enter a wildcard pattern that has more than 8 characters in it,)
like: @[log in to unmask]  LISTF (but not LISTFILE) has the same problem.)


What's the summary?  I really like Larry's suggestion!

> (VALIDATEDEVICE or some such).  Don't overload other commands with

but, I'd suggest something like FINFO...three new CI
functions (and matching intrinsics) like:


   HPLDEVTYPE (ldev) --> returns string with type of device:

      "UNKNOWN", "DISC", "TAPE", "TERMINAL", "PRINTER",
      "SERIAL_PRINTER", "SPOOLER", "DATACOMM", "DSTERM",
      "DSPRINTER", "USERDEVICE"
      (values taken directly from the MPE type "io_device_classes")

      (If the ldev is not a configured ldev, "UNKNOWN" is returned)
      (I.e., the existing MPE routine io_device_class (ldev) is called)

   HPDEVICENAMETYPE (devicename) --> returns string with type of device:

      The devicename is mapped onto an ldev.  If the mapping fails,
      "UNKNOWN" is returned.  Otherwise, HPLDEVTYPE (ldev) is returned.

   HPDEVICECLASSTYPE (devicename, nthldev) --> returns string with type of
                                               device
      For nthldev = 0:
         If all devices in the class are of the same HPDEVICENAMETYPE, that
         name is returned.  If not, then "MULTIPLE" is returned.

      For nthldev <> 0:
         If nthldev < 0 or nthldev > #ldevs in class, "UNKNOWN" is returned.
         The HPLDEVTYPE of the nth ldev in the class is returned.

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html