Newsgroups: bit.listserv.ibm-main
Date:         Mon, 13 Apr 1992 12:30:36 EDT
From:         Walt Farrell <wfarrell@VNET.IBM.COM>
Subject:      MVS Jobname Conventions
Comments: To: ibm-main%RUTVM1.bitnet@cunyvm.cuny.edu

On Thu, 9 Apr 1992 11:42:54 EDT I said:
>
>In case you aren't aware of it, beginning with MVS/ESA 3.1.3, JES2 3.1.3,
>RACF 1.9, and SDSF 1.3.1 there is a true concept of job ownership.

And on thu, 9 Apr 1992 at 11:56:35 EST Matt Simpson <SYSMATT@UKCC.UKY.EDU>
replied:

>I am aware of it. I have spent a lot of time recently reading SDSF
>documentation and coding different versions of ISFPARMS trying to
>get this stuff to work in a reasonable way. I would love to hear
>from someone who has gotten it to work for them
>My specific question is as follows: Suppose we allow users to submit
>jobs with random names. The user would like to view a list of all his
>jobs on the held output queue, by entering the SDSF H panel. Entering H
>with no operands will give him a list of all jobs with his userid in the
>jobname. No good. Entering H ALL will give him a list of all jobs on the
>held output queue, subject to whatever filtering is specified either in
>ISFPARMS or by the user. Also no good. The OWNER filter can not be
>specified in ISFPARMS, it can only be specified by the user. Relying on
>the user to specify it is not good, because if he forgets, specifying H
>ALL can result in a *long* response as SDSF traipses through the entire
>held output queue.

One thing to remember is that once the user does specify an OWNER filter,
it will be remembered until he changes it.  You can establish an OWNER
initially for a user when you first create the userid, by establishing a
default ISPF profile data set for the user with an xxxPROF (xxx is your
SDSF application id)
member that has the "OWNER userid" filter specified in it.  You need to
put in the specific userid, of course, and so this is extra work for
the administrator that creates the userid.

But, since the filter will be remembered until changed, this may be
worth doing.  Another trick that I have used is to have several different
ISPF options for invoking SDSF, and using different APPL ids for each one.
This also gives different profiles.  So, in my case I can use option S,
and have a filter that includes OWNER WFARRELL, or option SX that has no
OWNER, but has a DEST filter to show only jobs for the 3820 printer
near my office.  This approach can be useful if the user will sometimes
need to have the OWNER filter, and sometimes not, as there is less chance
of forgetting to reestablish the filter.  Just use different ISPF options,
instead.

>Also, if we allow the user to specify the OWNER
>command, we have no control over what he codes as owner. I realize that
>after he gets the lisf of jobs, there is further security on whether he
>can actually view them. But for the sake of user-friendliness and
>performance, we would rather not present the user with a list of jobs
>which he is not authorized to view.

Remember, too, that a user can be allowed to view jobs or output he
normally wouldn't be able to see, just by someone establishing a JESSPOOL
profile. Using a "hard-coded" rule like "OWNER must equal USERID"
eliminates this flexibility.  To keep the flexibility, and have the
user-friendliness that you want, will probably hurt performance as a
security check would need to be made for each row before displaying the
table.  But it can be done, if you want; see the comments below.

The above have been my comments, as an SDSF user and a RACF developer.
I also asked one of my friends in SDSF development to look at your note,
and she had the following comments:

  Walt, We currently have no facility in the product which will enable the
  customer to restrict a display by OWNER. The only thing he can do is have his
  end users set OWNER to their userid and then enter "H ALL" to see all jobnames
  for which the OWNER is equal.

  An alternative to this would be to enable the HELD display table row exit and
  either filter the display by the OWNER field which gets passed in, or SAF
 check
  each row to filter out anything not owned by the user. The table row exit,
 when
  enabled, gets called for each row of the display as we build it; the only
  problem here is that the HELD display default is jobname prefix, which means
  that under normal entry conditions if PREFIX is set to '*' you will only get
  jobnames that match your TSO user prefix. But it can definitely be used to
  catch the condition where PREFIX and OWNER are set to "*" and the user has
  entered the "H ALL" command for the entire HELD queue contents; this exit
  could eliminate the users having to get the entire held queue.

  The table row build exit is enabled by setting a flag bit in our ISFUSER user
  exit module initialization exit. The table row exit can be selectively
  enabled for any/all of our tabular displays.

I hope this information is helpful.

  Walt Farrell, RACF Design & Planning, IBM
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU