At 09:31 AM 12/18/98 -0800, Jeff Vance wrote:
>Below is my first pass at the external specifications for JINFO.
>Please let me know if this will meet your needs.  As always,
>I am open to suggestions on how to improve these specs. I am particularly
>interested in comments about the security rules for JINFO.


Wow! What a response! Thanks for the list of suggestions, Jeff. I have a
question and a couple of comments.

Question.

It seems to me that one of the uses for this will be to get a Job Number, when
we know only how a job has logged on. i.e. What is the job number for any job
called FOOBAR? IIRC we can do this for the JOBINFO intrinsic. How do you see
such a request being handled by this function?

<snip from Intrinsic Manual about the corresponding field in the intrinsic>

                      Passes the job/session number for which information
                      is requested.  Job/session numbers can be displayed
                      by the SHOWME and SHOWJOB commands.  If this value
                      is zero, JOBINFO returns information about your
                      logon job/session (unless the first itemnum has a
                      value of 1; see below).  When you pass a 0 for
                      jsnum, JOBINFO returns the actual job/session
                      number in jsnum.

Comment

It seems that we need a way to handle this, and here is a problem. If we say
that passing a 0 as the 'requested JSNum' can be extended, we need, potentially,
a list of responses. Suppose I want to find out about any Jobs logged on as
"DBA@,@.@". This could pottentially be > 1, right?

Pause for blinding insight - of course I could redirect SHOWJOB and then parse
the output from that. But are we trying to avoid that effort?



Comment (2)

Do you have any plans for both a numerical interface AND a mnemonic interface?
This makes it easier to construct a utility that will go out and 'rigorously'
retrieve all the information about a set of jobs (using numeric parameters from
1 through n, for example). It also avoids the possibility of
meaningful_but_relatively_long parameter names.

I look forward to following this thread with great interest! Thanks once again
to all at HP who helped get this project off the ground!

Tony

PS Denys has already been on my case once today, so let me state that i KNOW
the second comment is really a question in disguise ;-)