Jeff Vance addressed my posix/perl example of abortjob handling with yet
another CI file (among other follow-ups).  My point in posting the
rather cryptic perl script was to at least "expose" some of you to a new
way of thinking, and also to note that it exploits one of the few holes
in the "Berlin wall <Jeanette's terminology>" between MPE and posix -
that the "callci" facility in Posix is one of the few predictable tools
to interact between the two.  Anyway, taking Jeff Vance's example first,
and mind you I'm sort of playing devil's advocate here:

Jeff Vance wrote:
> An equally nerdy CI script (also requiring 5.5) is:
>
> PARM except="MANAGER.SYS OPERATOR.SYS", entry=main
-> So many CI scripts are "multiple" or "multi-entry", cumbersome
> if "!entry" = "main" then
>    showjob >sjout
>    xeq !hpfile !except, entry=abortjob <sjout
-> One of many ways we take CI output and process it via some form of
-> intermediate file; CIOR helped with ">somefile" but still...
>    return
> elseif '!entry' = 'abortjob' then
>    setvar i 0
>    while setvar(i,i+1) <= finfo(hpstdin,'eof') do
-> No concept of reading a file until EOF, so we have to fake it
>       if lft(setvar(buf,input()),1) = '#' and &
-> This is recent (to me) using setvar as an rvalue; most setvar on
-> a separate line.  If the above works, a nice trick to know!  And
-> likewise for input() as an rvalue.  I always considered these to
-> be "statements" and not "functions returning a value".
>           pos(setvar(job,word(buf,,-1)),"!except") = 0 then
-> Jeff V uses the new word() <well, he wrote it!>; we're dealing with
-> a de-facto CI script expert here :-)
>          continue
>          abortjob !job
>       endif
>    endwhile
>    return
> endif

Now to my cryptic mess which, unless you have unix exposure, you
probably glazed over looking at it and paid no attention.  I'll
elaborate, and while I admit it's cryptic, complicated, and typical
unix-speak, there is a quality of elegance about it.  And I'm no perl
expert (I can't read or write it without a manual in my lap) so it can
probably be done better:

> On Nov 7,  4:58pm, Jeff Kell wrote:
> > #!/usr/local/bin/perl
** That just means this is a perl script.  On 5.5, this will invoke the
** perl code rather than having the shell execute what follows.
> > unless (open(PIPE,"callci showjob exec|")) {
> >         die "unable to open showjob pipe";
** This opens a "pipe" like unix or dos for the output of showjob.  Perl
** can open a pipe on either end, you can write output to a pipe (to
** supply input) or take input from a pipe (in this case, the output of
** showjob).  You can open regular files too, of course, but when you
** open a pipe you truly 'multitask' and not single-step as you would
** with the CI.  I'd like to see the CI do this, of course, and since
** this works, they can't say "it can't be done"
> >         }
> > while ($line=<PIPE>) {
** Reads next record into $line, returns false at EOF
> >    if ($line=~/(#[J,S]\d+)\b.*/) {
** The "=~" is a pattern match; the MATCH in Query and VPLUS is rooted
** in the same code, but this version came several Ph.D dissertations
** later.  The "/" characters delimit the match pattern.  It says to
** look for a "#" followed by a "J" or "S", then one or more digits (\d
** means a digit, + is same as in match, one or more occurrances).  The
** parentheses around that group means "remember what matches" and since
** it is the first parenthesized pattern, it is assigned to $1.  The
** last "\b.*" is a blank, followed by zero or more occurrances "*" of
** any character "."
> >         $victim = $1;
** save $1 (the matching J/S number) in $victim
> >         if ($line!~/.*[OPERATOR,MANAGER]\.SYS.*/) {
** Zero or more occurrances of any character ".*" followed by either
** OPERATOR or MANAGER and .SYS (the \. is necessary to escape the "."
** which is a special character) then zero or more occurrances of any
** character (.*).
> >                 print "abortjob $victim \n";
> >                 }
> >         }
> >    }

This processes the file sequentially, in-line, with no worries about
word boundaries, etc.  Stick in a nscontrol killsess if you want to make
Tracy happy, or even parse the stdin ldev (easier than you think) and
include an abortio.  Point remains, you can trivially parse command
output without repetitive input() checking finfo(foo,"eof") or using a
message file and reading until eof.

If you wish to dismiss perl, I'm sure it can be done with awk/grep but
it would take two files (a script and an awk command file).  You could
get fancy and do a 'ps -a' to look for vtserver processes to decide on
the nscontrol killsess, but ps doesn't give job/session numbers, only
the
posix process IDs (is there a mapping of PIDs to PINs?).

In conclusion I'm not necessarily pushing posix/perl/etc., but rather
noting some concepts that I would have preferred to see in the CI to
start with.  If he kept archives, I'm sure Jeff Vance can verify that
I have suggested similar things before.  But posix/perl can do it now,
and it is one case of integrating posix and MPE for useful purposes.

Jeff Kell <[log in to unmask]>