Leonard asked:
 
1. Is there a way that an executing MPE/iX command file can determine its
name (file-name, group, account)?
 
This is an enhancement to MPEX based upon user requests.  True, one might
argue that at the time you are writing a command file, you (should) know the
name of it, but this doesn't help for cases where the command file might be
moved to another group and/or account.  (unless, of course, it still resides
on the HPPATH)
 
2. Can I perform I/O on a file within a loop and read successive records? I
tried a WHILE loop but I keep reading the same record:
 
    SETVAR COUNTER 1
    WHILE COUNTER < FINFO ("file","EOF) DO
        INPUT variable<file
        do something else
        SETVAR COUNTER COUNTER + 1
    ENDWHILE
 
   I think I know how to do this within MPEX using its FILE I/O FUNCTIONS,
but
I'd rather do it at the MPE/iX level.
 
The problem stems from the fact that the INPUT command opens the file, reads
the (first) record, then CLOSES the file.  The next time the INPUT command
is processed, it RE-opens the file, RE-reads the first record, and so on.
 As you noted, MPEX allows you to explicitly open a file and KEEP it open
between successive INPUT calls (or, more accurately, VEFREAD calls).
 However, in order to do this without MPEX, you have two choices: call a
SECOND command file using CIOR to pass the contents of the data file to your
command file as if it were $STDIN, or use a message file.  For example:
 
   mycmd1 <parameters>
  [do something that builds "datafile"]
  mycmd2 < datafile
  [do some more stuff, if desired]
 -----
  mycmd2
  errclear
  while hpcierr <> 900
     continue
     input somedata > $null
     [do something with somedata]
   endwhile
 -----
CI error 900 is eof on input, and the redirection of the INPUT command to
$null eliminates the rather annoying (yet expected) CIERR900 message from
appearing.  (although I suppose HPMSGFENCE could be used for this as well).
 Using a message file, your original logic won't change much since each time
you read from the file, you reduce the EOF by one.  Eventually, the EOF will
be zero, so you should test for that condition instead of relying on the
counter.  (this has an added advantage of being able to run simultaneously
with another process "feeding" it data into the message file)
 
3. How could I have constructed a search within LaserRom/PC to have answered
these questions?
 
Dunno.  LaserRom is great *IF* you know which manual contains the
information you're looking for (and *IF* that manual is included!), but I've
never had much success with searches.  Either I get WAY too many matches
because of some obscure wording in several manuals, or I get one or two
items for which my search criteria matched text in a "sample output" screen
or some such.
 
For example, I tried the keywords "read file", and got every occurance of
"filename" (imagine how many times THAT occurs in ALL of the manuals!).
 Next I tried "[read file]", which limits the search to cases where both
words are "in close proximity" to each other, better, but still not quite
(got all the "altsec" and similar commands, since "r" means "read file
access")  finally, I limited it to "input and [read file]", since I was
interested in the INPUT command and the ability to read files.  Better, but
I still had to manuall find the "command interpreter access and variables"
manual (which I already knew talked about CIOR), but nothing in this section
pointed out the fact that EACH call to INPUT < SOMEFILE actually opens
"somefile", reads ONLY the first record, then closes it before continuing,
nor was there an example of reading/processing an entire file via a command
file.