subject:"Multiple jobs\/same name"

In 4aca49e5.2070...@ync.net, on 10/05/2009
   at 02:32 PM, Rick Fochtman rfocht...@ync.net said:

But you still need to prevent testers from submitting jobs with a 
production USERID. We used a TSO exit to remove USER/PASSWORD parms from 
the JOB statement. Got a better idea?

Sure; don't have passwords for production jobs. Only allow them to be
submitted by a user with surrogate access to the production user id. Only
give that surrogate access to user ids that need it, e.g., scheduler.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: multiple jobs / same name

In listserv%200910021749338415.0...@bama.ua.edu, on 10/02/2009
   at 05:49 PM, Paul Gilmartin paulgboul...@aim.com said:

The Old Timers will shout,

Why don't you speak for yourself, John?

This old timer says that it was a convention that never made sense and
should have been buried long since.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

In listserv%200910050005416948.0...@bama.ua.edu, on 10/05/2009
   at 12:05 AM, Paul Gilmartin paulgboul...@aim.com said:

Until someone shows me documentation or an example to the
contrary, I'll believe that OWNER is a synonym for userid.

It is. But RACF also uses GROUP to control access.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

In
565251895-1254708894-cardhu_decombobulator_blackberry.rim.net-20340310...@bda488.bisx.prod.on.blackberry,
on 10/05/2009
   at 02:14 AM, Ted MacNEIL eamacn...@yahoo.ca said:

How can the programmer control these independently?

USER=  PASSWORD= are valid JOB CARD parms.

K3wl, but it has nothing to do with the question. PASSWORD= doesn't
control the owner, it simply establishes your permission to specify the
owner on the USER= keyword.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

In
575253278-1254703734-cardhu_decombobulator_blackberry.rim.net-3855232...@bda488.bisx.prod.on.blackberry,
on 10/05/2009
   at 12:48 AM, Ted MacNEIL eamacn...@yahoo.ca said:

Why OWNER?

Because it's USERID.

Userid is the common control for production (independent of job-name).

They're synonymous.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: multiple jobs / same name

In 000d01ca43b2$7ddc9c10$7995d4...@net, on 10/02/2009
   at 03:48 PM, Ulrich Krueger u...@pacbell.net said:

The tradition of using your TSO userid for batch job names dates back to
the invention of TSO and has been a default (or should I say, de-facto
standard) ever since then.

If you wanted STATUS to return a list of your jobs then you had to[1]
stick to userid plus one character. With SDSF practically omnipresent, I
doubt that STATUS gets much use any more.

[1] I don't know whether the restriction still exists in current
z/OS releases.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: multiple jobs / same name

In a6b9336cdb62bb46b9f8708e686a7ea005bde01...@nrhmms8p02.uicnrh.dom, on
10/02/2009
   at 01:54 PM, McKown, John john.mck...@healthmarkets.com said:

I'm not an expert on this. But, as I understand it, HASP was an add on
to OS/MVT

My recollection is that it supported MFT before it supported MVT. 

And this was in the days before there were such things as job numbers 

Correct; OS/360 and OS/VS2 (SVS) had no code to deal with ASP or HASP job
numbers.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Job name standards (Was: multiple jobs / same name)

In listserv%200910101341489068.0...@bama.ua.edu, on 10/10/2009
   at 01:41 PM, Paul Gilmartin paulgboul...@aim.com said:

The OUTPUT JCL statement,

Then you're talking about a length restriction of OUTPUT, not of SJF.

The vendor appears to be IBM,

Not even close; you gave the right answer to a question that nobody asked.
It should have been clear from context that I was referring to 3rd party
venders, e.g., CA, Xerox.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Job name standards (Was: multiple jobs / same name)

2009-10-10 Thread Paul Gilmartin

On Fri, 9 Oct 2009 17:08:30 -0500, Shmuel Metz (Seymour J.) wrote:

In listserv%200910090945570233.0...@bama.ua.edu, on 10/09/2009
   at 09:45 AM, Paul Gilmartin said:

FSVO arbitrary.  This is the USERDATA parameter, isn't it?.

Userdata parameter of what?

The OUTPUT JCL statement, which I found by following a chain of
references from SJF, and which you mentioned in your previous
ply.

There are vendors adding their own DD keywords via SJF; I don't know
whether they are under NDA's. If not, perhaps one of them could comment on
length restrictions.

The vendor appears to be IBM, and I belive no NDA prohibits my discussing:

Title: z/OS V1R11.0 MVS JCL Reference
22.0 Chapter 22.  OUTPUT JCL Statement
22.71 USERDATA Parameter
22.71.2 Subparameter Definition
   value
  Specifies the installation defined values for the
  installation's prescribed processing. You can code
  up to 16 installation-defined values. Each value
  may be from 1 to 60 EBCDIC text characters.

(Since the processing is installation defined, I don't know why
this section states the string is restricted to EBCDIC text
characters.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-10 Thread Paul Gilmartin

On Thu, 8 Oct 2009 11:59:16 -0600, Frank Swarbrick wrote:

Documentation?  We don't need no stinkin' documentation!  :-)

On 10/8/2009 at 8:48 AM, in message
of355dbbe3.6bf1f654-on85257649.0050d158-85257649.00516...@us.ibm.com, Peter 
Relson wrote:

 According to the SDSF folks, their commands are documented in the help
 panels. Sounds strange to me. But it's not my component.

UNIX has long had the admirable practice of generating the online
and hardcopy documentation from the same source.  z/OS Unix has
followed this practice: the man(1) pages and the Commands manual
are generated (the former dynamically) from Bookmaster source.
It works well enough save for a few dangling references in the
man pages.

SDSF could have done similarly.

(z/OS Unix lacks the catman -w and makewhatis commands present
in many other flavors of UNIX to extract the equivalent of the TSO
HELP COMMANDS member.)

(How much hardcopy doc have you in your office nowadays?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Job name standards (Was: multiple jobs / same name)

2009-10-09 Thread Shmuel Metz (Seymour J.)

In listserv%200910031526437940.0...@bama.ua.edu, on 10/03/2009
   at 03:26 PM, Paul Gilmartin paulgboul...@aim.com said:

There's a smoldering need here for a means to pass arbitrary name/value
pairs from JCL to job processing components other than by steganographic
jobname coding. 

SJF. Unfortunately, IBM has only documented its use for DD and OUTPUT
statements.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SV: Multiple jobs/same name

2009-10-09 Thread Thomas Berg

The help function in SDSF has always been somewhat byzantine...
I think they looked at it as: was it hard to code, it should be hard to use :)
 


Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 



 

 -Ursprungligt meddelande-
 Från: IBM Mainframe Discussion List 
 [mailto:ibm-m...@bama.ua.edu] För Peter Relson
 Skickat: den 8 oktober 2009 16:49
 Till: IBM-MAIN@bama.ua.edu
 Ämne: Re: Multiple jobs/same name
 
 I was not aware of PREFIX **.
 This appears to work well!
 Thanks for the heads up!
 Where is this documented, anyway?
 SDSF seems to only have one manual,
 SDSF Operation and Customization,
 and I can't find PREFIX documented anywhere in there.
 
 According to the SDSF folks, their commands are documented in 
 the help panels. Sounds strange to me. But it's not my component.
 
 From SDSF option H,
 Help - 1 for Extended Help - 2 for Syntax of the H command 
 to second page for 2 Displaying all jobs
 
 And yes, that too sounds somewhat unfriendly to me, as you 
 are not trying to display all jobs and you really are trying 
 to display only your own jobs which was option 1 on that 
 last panel. But that option turns out to be only your own 
 jobs as long as they have names that match your user ID 
 according to the displayed text..
 
 Peter Relson
 z/OS Core Technology Design
 --
 For IBM-MAIN subscribe / signoff / archive access 
 instructions, send email to lists...@bama.ua.edu with the 
 message: GET IBM-MAIN INFO Search the archives at 
 http://bama.ua.edu/archives/ibm-main.html
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-09 Thread Bob Shannon

 The help function in SDSF has always been somewhat byzantine...
I think they looked at it as: was it hard to code, it should be hard to use 
:)

I think they decided to use the OS/2 model of only having online documentation. 
There is an old user's guide from years ago that is helpful but no longer 
complete.

Bob Shannon
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Thomas Berg
Sent: Friday, October 09, 2009 7:34 AM
To: IBM-MAIN@bama.ua.edu
Subject: SV: Multiple jobs/same name

The help function in SDSF has always been somewhat byzantine...
I think they looked at it as: was it hard to code, it should be hard to use :)
 


Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 



 

 -Ursprungligt meddelande-
 Från: IBM Mainframe Discussion List 
 [mailto:ibm-m...@bama.ua.edu] För Peter Relson
 Skickat: den 8 oktober 2009 16:49
 Till: IBM-MAIN@bama.ua.edu
 Ämne: Re: Multiple jobs/same name
 
 I was not aware of PREFIX **.
 This appears to work well!
 Thanks for the heads up!
 Where is this documented, anyway?
 SDSF seems to only have one manual,
 SDSF Operation and Customization,
 and I can't find PREFIX documented anywhere in there.
 
 According to the SDSF folks, their commands are documented in 
 the help panels. Sounds strange to me. But it's not my component.
 
 From SDSF option H,
 Help - 1 for Extended Help - 2 for Syntax of the H command 
 to second page for 2 Displaying all jobs
 
 And yes, that too sounds somewhat unfriendly to me, as you 
 are not trying to display all jobs and you really are trying 
 to display only your own jobs which was option 1 on that 
 last panel. But that option turns out to be only your own 
 jobs as long as they have names that match your user ID 
 according to the displayed text..
 
 Peter Relson
 z/OS Core Technology Design
 --
 For IBM-MAIN subscribe / signoff / archive access 
 instructions, send email to lists...@bama.ua.edu with the 
 message: GET IBM-MAIN INFO Search the archives at 
 http://bama.ua.edu/archives/ibm-main.html
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Job name standards (Was: multiple jobs / same name)

2009-10-09 Thread Paul Gilmartin

On Thu, 8 Oct 2009 17:52:00 -0500, Shmuel Metz (Seymour J.) wrote:

There's a smoldering need here for a means to pass arbitrary name/value
pairs from JCL to job processing components other than by steganographic
jobname coding.

SJF. Unfortunately, IBM has only documented its use for DD and OUTPUT
statements.

FSVO arbitrary.  This is the USERDATA parameter, isn't it?.  I
believe John McKown (IIRC) mentioned this in these lists several
months ago.  Each userdata string is limited to 60 characters,
which is somewhat less than another notorious JCL string length
limitation.  And JCL symbols are not resolved in userdata strings
surrounded by apostrophes, severely limiting the use of symbols
in USERDATA.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Job name standards (Was: multiple jobs / same name)

2009-10-09 Thread Shmuel Metz (Seymour J.)

In listserv%200910090945570233.0...@bama.ua.edu, on 10/09/2009
   at 09:45 AM, Paul Gilmartin paulgboul...@aim.com said:

FSVO arbitrary.  This is the USERDATA parameter, isn't it?. 

Userdata parameter of what?

There are vendors adding their own DD keywords via SJF; I don't know
whether they are under NDA's. If not, perhaps one of them could comment on
length restrictions.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-08 Thread Peter Relson

I was not aware of PREFIX **.
This appears to work well!
Thanks for the heads up!
Where is this documented, anyway?
SDSF seems to only have one manual,
SDSF Operation and Customization,
and I can't find PREFIX documented anywhere in there.

According to the SDSF folks, their commands are documented in the help
panels. Sounds strange to me. But it's not my component.

From SDSF option H,
Help - 1 for Extended Help - 2 for Syntax of the H command
to second page for 2 Displaying all jobs

And yes, that too sounds somewhat unfriendly to me, as you are not trying
to display all jobs and you really are trying to display only your own
jobs which was option 1 on that last panel. But that option turns out to
be only your own jobs as long as they have names that match your user
ID according to the displayed text..

Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-08 Thread Frank Swarbrick

Documentation?  We don't need no stinkin' documentation!  :-)

Thanks for the pointer.  I see it.  Certainly not a good example of the 
principle of least astonishment.  Ah well.

Frank
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


On 10/8/2009 at 8:48 AM, in message
of355dbbe3.6bf1f654-on85257649.0050d158-85257649.00516...@us.ibm.com, Peter
Relson rel...@us.ibm.com wrote:
 I was not aware of PREFIX **.
This appears to work well!
Thanks for the heads up!
Where is this documented, anyway?
SDSF seems to only have one manual,
SDSF Operation and Customization,
and I can't find PREFIX documented anywhere in there.
 
 According to the SDSF folks, their commands are documented in the help
 panels. Sounds strange to me. But it's not my component.
 
 From SDSF option H,
 Help - 1 for Extended Help - 2 for Syntax of the H command
 to second page for 2 Displaying all jobs
 
 And yes, that too sounds somewhat unfriendly to me, as you are not trying
 to display all jobs and you really are trying to display only your own
 jobs which was option 1 on that last panel. But that option turns out to
 be only your own jobs as long as they have names that match your user
 ID according to the displayed text..
 
 Peter Relson
 z/OS Core Technology Design
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-08 Thread Edward Jaffe


Peter Relson wrote:

From SDSF option H,
Help - 1 for Extended Help - 2 for Syntax of the H command
to second page for 2 Displaying all jobs

And yes, that too sounds somewhat unfriendly to me, as you are not trying
to display all jobs and you really are trying to display only your own
jobs which was option 1 on that last panel. But that option turns out to
be only your own jobs as long as they have names that match your user
ID according to the displayed text..
  


So, this inconsistent handling of PREFIX is an attempt to treat job 
names that match your userid differently from other jobs? That seems 
entirely consistent with previously-stated observations about common 
practices at JES2/SDSF shops. In this instance, installations that 
rigidly confirm to the userid+1 character job naming convention might 
never notice or complain about this behavioral inconsistency...


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-07 Thread Rick Fochtman


snip---


???  Testers didn't have SURROGAT (I assume they weren't Production
Support, and didn't have access to automation), and they didn't
know the production password?  How were they bypassing?

 


---unsnip--
Until the RACF amd JES2 controls were available, they would use IEBGENER
to submit a PDS member to INTRDR. We stopped most of that by changing
the PROD id's password and not letting it be known. We also used a TSO

   


Most?  I would expect all.  Do you mean that the password
was leaked to some unauthorized persons?
 


--unsnip
Yes it was. The person responsible was promoted to the sidewalk after 
he admitted this fact.


--snip---


SUBMIT exit to parse the JOB statement on any SUBMIT'ed JOB statement,
removing the USER and PASSWORD operands (among others) and cutting an

   


Isn't there a JES or INTRDR exit (discussed here long ago) that
should be preferred to the SUBMIT exit because it traps all
jobs, not just those SUBmitted by TSO.  (Nowadays FTP QUOTE SITE
FILE=JES provides another bypass.)
 


---unsnip-
Yes, a JES2 exit might have been used, but we felt that a SUBMIT exit 
was easier and equally effective, since our users had no other mechanism 
(we thought) to submit a job. We hadn't thought of them using IEBGENER 
to INTRDR; most of them weren't that bright. :-)


---snip---


SMF record for violations. After a few reprimands to persistant
violators, we managed to convince people that our standards were NOT
just window dressing and the majority of the problem went away. One
person was able to hack his way past all our standards, etc. by using
a 3rd party SVC; he was terminated when we finally got tired of
listening to his excuses and dealing with the problems he caused. The

   


Career death wish?
 


-unsnip
Apperantly. He's selling used cars now. When he asked us for a 
reference, our only comment was not eligible for re-hire.


-snip---


owner of the SVC was informed of how it was being abused and has
installed safeguards to prevent recurrance. They have also supplied the
SVC code in source form to allow us to critique their fix. Thank you,
CA/IDMS Tech Support. Your action was timely, effective and efficient.
(Big bouquet of roses) Vastly different from the various responses of
your Marketting Team. :-)

   


Good for them.
 


---unsnip
My sentiments exactly.

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-07 Thread Paul Gilmartin

On Wed, 7 Oct 2009 10:31:08 -0500, Rick Fochtman wrote:

Isn't there a JES or INTRDR exit (discussed here long ago) that
should be preferred to the SUBMIT exit because it traps all
jobs, not just those SUBmitted by TSO.  (Nowadays FTP QUOTE SITE
FILE=JES provides another bypass.)
---unsnip-
Yes, a JES2 exit might have been used, but we felt that a SUBMIT exit
was easier and equally effective, since our users had no other mechanism
(we thought) to submit a job. We hadn't thought of them using IEBGENER
to INTRDR; most of them weren't that bright. :-)

I.e. they got caught.

But since I don't believe in Security through Obscurity, I'll
cheerfully share with anyone who asks my EDIT macro to copy from
the ISPF buffer directly to INTRDR.  It:

o Bypasses the the SUBMIT exit (but that wasn't its motivation).

o Uses no temp data set, therefore avoids SPACE abends.

o Uses (by default) the attributes of the file being edited,
  rather than forcing F80.

-unsnip
Apperantly. He's selling used cars now. When he asked us for a

Something's poetic about that.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-07 Thread Donald Johnson

Somewhere I missed the earlier post...how can I get hold of he Edit Macro to
learn more about this kind of programming (not sure I will roll it out, but
would be nice to understand)?
Don

On Wed, Oct 7, 2009 at 1:13 PM, Paul Gilmartin paulgboul...@aim.com wrote:

 On Wed, 7 Oct 2009 10:31:08 -0500, Rick Fochtman wrote:
 
 Isn't there a JES or INTRDR exit (discussed here long ago) that
 should be preferred to the SUBMIT exit because it traps all
 jobs, not just those SUBmitted by TSO.  (Nowadays FTP QUOTE SITE
 FILE=JES provides another bypass.)

 ---unsnip-
 Yes, a JES2 exit might have been used, but we felt that a SUBMIT exit
 was easier and equally effective, since our users had no other mechanism
 (we thought) to submit a job. We hadn't thought of them using IEBGENER
 to INTRDR; most of them weren't that bright. :-)
 
 I.e. they got caught.

 But since I don't believe in Security through Obscurity, I'll
 cheerfully share with anyone who asks my EDIT macro to copy from
 the ISPF buffer directly to INTRDR.  It:

 o Bypasses the the SUBMIT exit (but that wasn't its motivation).

 o Uses no temp data set, therefore avoids SPACE abends.

 o Uses (by default) the attributes of the file being edited,
  rather than forcing F80.


 -unsnip
 Apperantly. He's selling used cars now. When he asked us for a
 
 Something's poetic about that.

 -- gil

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SUBMIT Macros (was: Multiple jobs/same name)

2009-10-07 Thread Paul Gilmartin

On Wed, 7 Oct 2009 13:27:38 -0400, Donald Johnson wrote:

Somewhere I missed the earlier post...how can I get hold of he Edit Macro to
learn more about this kind of programming (not sure I will roll it out, but
would be nice to understand)?

On Wed, Oct 7, 2009 at 1:13 PM, Paul Gilmartin wrote:

 cheerfully share with anyone who asks my EDIT macro to copy from
 the ISPF buffer directly to INTRDR.  It:

 o Bypasses the the SUBMIT exit (but that wasn't its motivation).

 o Uses no temp data set, therefore avoids SPACE abends.

 o Uses (by default) the attributes of the file being edited,
  rather than forcing F80.

Examples sent offline.  YMMV.  Let me know if it worked.
(Or if it got through at all.)

Added suggestion that the best thing to do is to browse the
archives (here and ISPF-L) for everything Dave Salt ever
posted.  (Yes, there are others too numerous to mention.  I'd
be one of the poorer choices.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-06 Thread R.S.


Rick Fochtman pisze:

snip


On Mon, 5 Oct 2009 14:32:53 -0500, Rick Fochtman wrote:
 


But you still need to prevent testers from submitting jobs with a
production USERID. We used a TSO exit to remove USER/PASSWORD parms from
the JOB statement. Got a better idea?

  

Change the password?
 


unsnip---
We did. Our Production Support staff and our automation product had 
SURROGAT authority but the production password was a closely guarded 
secret, known only by me.


I would suggest better solution: NO PASSWORD.
No password cannot be disclosed, even by you.
Such facility is available in RACF since 1999 or 2000 AFAIR.

TSO exit can be easily replaced with JESJOBS SUBMIT.n.j.u profiles.

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-06 Thread Robert S. Hansel (RSH)

John  Tony,

John, you could use JESJOBS to restrict the batch use of non-PROTECTED IDs.
If the user does not have READ access to a profile such as the one below,
the user would not be permitted to submit jobs having USER=OTHERID with
either the password or SURROGAT authority:

JESJOBS SUBMIT.*.*.OTHERID

Use of these profiles would enable you to avoid having to code a submit
exit.

Tony, you might not be able to logon even with the password. If trying to
enter TSO, the ID would need a UADS entry or a TSO segment with access to
TSO resources. If trying to enter FTP, the ID would need an OMVS segment
with uid and be connected to a group with a gid. (BTW, this is an area where
FACILITY BPX.DEFAULT.USER can open exposures.)


This has been an interesting thread. I tend to fall into the camp of
preferring job naming conventions for jobs submitted by the job scheduler
primarily to identify the corresponding application and owner and thus help
production control and security ensure the correct batch ID is being
assigned to each job, which can also be enforced with job scheduler exits.
Several of my consulting engagements have involved straightening out batch
ID assignments and access authority, and the lack of naming conventions
makes this a much more difficult task.


Regards, Bob

-
Robert S. Hansel   | 2009 RACF Training
Lead RACF Specialist   |
RSH Consulting, Inc.   |  Audit for Results   - Boston - NOV 3-5
www.rshconsulting.com  |
617-969-8211   | Visit our website for registration  details
-

-Original Message-
Date:Mon, 5 Oct 2009 15:08:18 -0500
From:Tony B. tbabo...@comcast.net
Subject: Re: Multiple jobs/same name

If I knew the password I'd simply log on myself and submit..

From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of McKown, John
Sent: Monday, October 05, 2009 2:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Multiple jobs/same name

 -Original Message-
 From: IBM Mainframe Discussion List
 [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman
 Sent: Monday, October 05, 2009 2:33 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: Multiple jobs/same name
snip
 But you still need to prevent testers from submitting jobs with a
 production USERID. We used a TSO exit to remove USER/PASSWORD parms
 from the JOB statement. Got a better idea?

 Please remember: much of what I describe was developed before RACF was
 able to filter job submission.

 Rick


Use a PROTECTED id in RACF and SURROGAT authority to allow the scheduler's
RACF id to submit jobs with the specified ID(s). PROTECTED says that you
cannot use USER=  PASSWORD= on the job card to assign the RACF id. RACF
will simply not allow it. The attempt fails with a RACF error. SURROGAT says
that the scheduler can specify USER= without PASSWORD= to run a job with the
specified (authorized) RACF id. This is what we do with CA-7 scheduling.

Of course, you still need the submit exit for non-PROTECTED ids which a
person may know the password to. And it is easy to bypass:

//MYIDA JOB
//SUBMIT EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD SYSOUT=(*,INTRDR)
//SYSUT1 DD DISP=SHR,DSN=some.pds(member)

some.pds(member):

//OTHERID JOB USER=otherid,PASSWORD=password
//* THE REST OF THE JOB
//* ...
//

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com *
www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. HealthMarkets(r) is the brand name for products underwritten and
issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake
Life Insurance Company(r), Mid-West National Life Insurance Company of
TennesseeSM and The MEGA Life and Health Insurance Company.SM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-06 Thread Rick Fochtman


-snip---


But you still need to prevent testers from submitting jobs with a
production USERID. We used a TSO exit to remove USER/PASSWORD parms from
the JOB statement. Got a better idea?

   


Change the password?

 


We did. Our Production Support staff and our automation product had
SURROGAT authority but the production password was a closely guarded
secret, known only by me.

   


???  Testers didn't have SURROGAT (I assume they weren't Production
Support, and didn't have access to automation), and they didn't
know the production password?  How were they bypassing?
 


---unsnip--
Until the RACF amd JES2 controls were available, they would use IEBGENER 
to submit a PDS member to INTRDR. We stopped most of that by changing 
the PROD id's password and not letting it be known. We also used a TSO 
SUBMIT exit to parse the JOB statement on any SUBMIT'ed JOB statement, 
removing the USER and PASSWORD operands (among others) and cutting an 
SMF record for violations. After a few reprimands to persistant 
violators, we managed to convince people that our standards were NOT 
just window dressing and the majority of the problem went away. One 
person was able to hack his way past all our standards, etc. by using 
a 3rd party SVC; he was terminated when we finally got tired of 
listening to his excuses and dealing with the problems he caused. The 
owner of the SVC was informed of how it was being abused and has 
installed safeguards to prevent recurrance. They have also supplied the 
SVC code in source form to allow us to critique their fix. Thank you, 
CA/IDMS Tech Support. Your action was timely, effective and efficient. 
(Big bouquet of roses) Vastly different from the various responses of 
your Marketting Team. :-)


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-06 Thread Paul Gilmartin

On Tue, 6 Oct 2009 15:41:10 -0500, Rick Fochtman wrote:

???  Testers didn't have SURROGAT (I assume they weren't Production
Support, and didn't have access to automation), and they didn't
know the production password?  How were they bypassing?

---unsnip--
Until the RACF amd JES2 controls were available, they would use IEBGENER
to submit a PDS member to INTRDR. We stopped most of that by changing
the PROD id's password and not letting it be known. We also used a TSO

Most?  I would expect all.  Do you mean that the password
was leaked to some unauthorized persons?

SUBMIT exit to parse the JOB statement on any SUBMIT'ed JOB statement,
removing the USER and PASSWORD operands (among others) and cutting an

Isn't there a JES or INTRDR exit (discussed here long ago) that
should be preferred to the SUBMIT exit because it traps all
jobs, not just those SUBmitted by TSO.  (Nowadays FTP QUOTE SITE
FILE=JES provides another bypass.)

SMF record for violations. After a few reprimands to persistant
violators, we managed to convince people that our standards were NOT
just window dressing and the majority of the problem went away. One
person was able to hack his way past all our standards, etc. by using
a 3rd party SVC; he was terminated when we finally got tired of
listening to his excuses and dealing with the problems he caused. The

Career death wish?

owner of the SVC was informed of how it was being abused and has
installed safeguards to prevent recurrance. They have also supplied the
SVC code in source form to allow us to critique their fix. Thank you,
CA/IDMS Tech Support. Your action was timely, effective and efficient.
(Big bouquet of roses) Vastly different from the various responses of
your Marketting Team. :-)

Good for them.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-05 Thread R.S.


Paul Gilmartin pisze:
[...]

Until someone shows me documentation or an example to the
contrary, I'll believe that OWNER is a synonym for userid.
Different components should always use different names for
the same entities -- it keeps programmers alert.  Or perhaps
it's just Conway's law again.


SDSF and JES2 and at least some batch scheduleres use the same OWNER 
meaning as above. BTW: to be more precise: OWNER = execution userid. 
Execution userid need not to be submitting userid.



BTW: jobnames can be easily protected using standard RACF class JESJOBS.
The profile is SUBMIT.nodename.jobname.userid
One can define who (not a part of the profile) on what system (NJE 
node), what jobname, *with what OWNER* (the last qualifier).

So even in shared RACF db environment there is a possibility that
Group APPLPRG can submit job ABC12345 with owner PRODBTCH, but only on 
TEST system. And it is possible to prevent userid propagation - so TSO 
segment is not a problem.


BTW2: the class PROPCNTL also prevent userid propagation, but doesn work 
selectively.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

USER/OWNER/SYSUID (was Multiple jobs/same name

2009-10-05 Thread Terry Sambrooks

Hi,

Paul Gilmartin wrote in Re: Multiple jobs/same name

EXEC PGM=IEFBR14,PARM='SYSUID' substitutes the USER= value from the JOB
CARD for SYSUID.

Until someone shows me documentation or an example to the
contrary, I'll believe that OWNER is a synonym for userid.

The column headed OWNER in SDSF will contain a Userid as per the attached
listing (note that in this case the Userid exceeds 7 characters, because
SPACEMAN has nothing to do with TSO).

This field illustrates a difference when RACF SURROGATE is used, and the job
is submitted on behalf of another user, as in the case below, where the
submitter is an STC called AUTOOPS, but the job needs the authority of
SPACEMAN. 

It is a useful way of identifying that a job is owned by a User, even if
they did not submit it.

  Display  Filter  View  Print  Options  Help 
--
SDSF HELD OUTPUT DISPLAY CLS XLINES 1,749  LINE 1-7 (7)   
COMMAND INPUT ===SCROLL === 
NP   JOBNAME  JobIDOwnerPrty C ODisp Dest Tot-Rec 
 CICSFIL1 JOB02109 SPACEMAN  144 X HOLD  LOCAL475 
 CICSFIL2 JOB02110 SPACEMAN  144 X HOLD  LOCAL475 
 CICSFIL3 JOB02111 SPACEMAN  144 X HOLD  LOCAL490 
 CSD1REFR JOB02116 SPACEMAN  144 X HOLD  LOCAL 94 
 CSD2REFR JOB02117 SPACEMAN  144 X HOLD  LOCAL 94 
 CSD3REFR JOB02115 SPACEMAN  144 X HOLD  LOCAL 89

When using RACF SURROGATE only USER= is required on the JOB statement.

Kind regards - Terry

Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore, Sheffield, S17 3LA, UK

Tel: +44 (0)114 262 0933
WEB: www.legac-e.co.uk

Company Reg: 3767263 at the above address

All outgoing E-mail is scanned, but it remains the recipient's
responsibility to ensure their system is protected from spy-ware, trojans,
viruses, and worms.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-05 Thread Peter Relson

I don't use SDSF H generally because of it defaulting to your userID as
prefix
(must use H ALL to override).

I consider that the default default.

OWNER yourid
PREFIX **
works very nicely for me. So, yes, you had to do something to get this in
place, but once it's there it stays so from then on could be considered
your default.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USER/OWNER/SYSUID (was Multiple jobs/same name

On Mon, 5 Oct 2009 08:41:26 +0100, Terry Sambrooks 
terry.sambro...@btclick.com wrote:

The column headed OWNER in SDSF will contain a Userid as per the attached
listing (note that in this case the Userid exceeds 7 characters, because
SPACEMAN has nothing to do with TSO).

This field illustrates a difference when RACF SURROGATE is used, and the job
is submitted on behalf of another user, as in the case below, where the
submitter is an STC called AUTOOPS, but the job needs the authority of
SPACEMAN.

It is a useful way of identifying that a job is owned by a User, even if
they did not submit it.

  Display  Filter  View  Print  Options  Help
--
SDSF HELD OUTPUT DISPLAY CLS XLINES 1,749  LINE 1-7 (7)
COMMAND INPUT ===SCROLL ===
NP   JOBNAME  JobIDOwnerPrty C ODisp Dest Tot-Rec
 CICSFIL1 JOB02109 SPACEMAN  144 X HOLD  LOCAL475
 CICSFIL2 JOB02110 SPACEMAN  144 X HOLD  LOCAL475
...

The excerpt does not show the submitting user, AUTOOPS.  Is it available
elsewhere, in another display, or is it simply replaced by OWNER in all
control blocks related to the job?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USER/OWNER/SYSUID (was Multiple jobs/same name

2009-10-05 Thread R.S.


Paul Gilmartin pisze:

On Mon, 5 Oct 2009 08:41:26 +0100, Terry Sambrooks 
terry.sambro...@btclick.com wrote:

The column headed OWNER in SDSF will contain a Userid as per the attached
listing (note that in this case the Userid exceeds 7 characters, because
SPACEMAN has nothing to do with TSO).

This field illustrates a difference when RACF SURROGATE is used, and the job
is submitted on behalf of another user, as in the case below, where the
submitter is an STC called AUTOOPS, but the job needs the authority of
SPACEMAN.

It is a useful way of identifying that a job is owned by a User, even if
they did not submit it.

 Display  Filter  View  Print  Options  Help
--
SDSF HELD OUTPUT DISPLAY CLS XLINES 1,749  LINE 1-7 (7)
COMMAND INPUT ===SCROLL ===
NP   JOBNAME  JobIDOwnerPrty C ODisp Dest Tot-Rec
CICSFIL1 JOB02109 SPACEMAN  144 X HOLD  LOCAL475
CICSFIL2 JOB02110 SPACEMAN  144 X HOLD  LOCAL475

...

The excerpt does not show the submitting user, AUTOOPS.  Is it available
elsewhere, in another display, or is it simply replaced by OWNER in all
control blocks related to the job?


It is available. I don't know about control blocks, but SMF (type30?) 
contains such information. It can be easily extracted using RACF utility 
IRRADU00. You will find both: submitting userid and execution userid.


Caution: it is possible to mess the things: Submitting user ABC submits 
job A, under execution userid XYZ. Then the job A submits another job B.
In this case job B is run under user (owner) XYZ, and submitter is also 
XYZ.
From the other hand you can prevent it by using PROPCNTL class and 
blocking XYZ userid propagation...


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

On Mon, 5 Oct 2009 09:11:21 +0200, R.S. wrote:

BTW: jobnames can be easily protected using standard RACF class JESJOBS.
The profile is SUBMIT.nodename.jobname.userid
One can define who (not a part of the profile) on what system (NJE
node), what jobname, *with what OWNER* (the last qualifier).
So even in shared RACF db environment there is a possibility that
Group APPLPRG can submit job ABC12345 with owner PRODBTCH, but only on
TEST system. And it is possible to prevent userid propagation - so TSO
segment is not a problem.

Does the syntax permit a universal rule with wildcards, e.g.:

SUBMIT.nodename.SYSUID.%.SYSUID

... ?  I.e. every user may submit (only) jobnames consisting of
the userid plus one character and only for his own userid?  Or
must the administrator create a specific rule for each user?

And I have YA motive for eschewing the userid+1 practice:  When I
submit a job from the SMP/E ISPF panels, SMP/E attempts to snag
the output with the OUTPUT (ugh!) TSO command.  Fortunately, SMP/E
lets me edit the JCL before submission, so OUTPUT can't find it and
I can split the screen and examine it with SDSF, which I much prefer.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-05 Thread R.S.


Paul Gilmartin pisze:

On Mon, 5 Oct 2009 09:11:21 +0200, R.S. wrote:

BTW: jobnames can be easily protected using standard RACF class JESJOBS.
The profile is SUBMIT.nodename.jobname.userid
One can define who (not a part of the profile) on what system (NJE
node), what jobname, *with what OWNER* (the last qualifier).
So even in shared RACF db environment there is a possibility that
Group APPLPRG can submit job ABC12345 with owner PRODBTCH, but only on
TEST system. And it is possible to prevent userid propagation - so TSO
segment is not a problem.


Does the syntax permit a universal rule with wildcards, e.g.:

SUBMIT.nodename.SYSUID.%.SYSUID

... ?  I.e. every user may submit (only) jobnames consisting of
the userid plus one character and only for his own userid?  Or
must the administrator create a specific rule for each user?


Variables like SYSUID are not allowed in RACF profiles. However you can 
use GAT (Global Access Table). In GAT you can use special variable 
RACUID which is equivalent for SYSUID.

The entry should look like:
SUBMIT.node.RACUID%.RACUID/READ

Disclaimer: I didn't test it.

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USER/OWNER/SYSUID (was Multiple jobs/same name

2009-10-05 Thread Edward Jaffe


Paul Gilmartin wrote:

On Mon, 5 Oct 2009 08:41:26 +0100, Terry Sambrooks 
terry.sambro...@btclick.com wrote:
  

It is a useful way of identifying that a job is owned by a User, even if
they did not submit it.

 Display  Filter  View  Print  Options  Help
--
SDSF HELD OUTPUT DISPLAY CLS XLINES 1,749  LINE 1-7 (7)
COMMAND INPUT ===SCROLL ===
NP   JOBNAME  JobIDOwnerPrty C ODisp Dest Tot-Rec
CICSFIL1 JOB02109 SPACEMAN  144 X HOLD  LOCAL475
CICSFIL2 JOB02110 SPACEMAN  144 X HOLD  LOCAL475


...

The excerpt does not show the submitting user, AUTOOPS.  Is it available
elsewhere, in another display, or is it simply replaced by OWNER in all
control blocks related to the job?
  


If you look in SYS1.MACLIB(ICHRUTKN) you'll see two fields:
TOKSUSR  DSCL8  SUBMITTING USERID
TOKUSER  DSCL8  SESSION OWNER USERID

It's easy enough to display both values as shown below. SubUser is 
submitting userid:


|STATUS   729S  0X  733W  0H  225T  12,352,171 Records  0 Pages
|Command ===
|Cmd JobName  JobIDStatus   OwnerSubUser  Queue  AMbr C JP ...
|---  /   --  - -- ...
|DASDLIST J0066845 ACTIVE   SYSOPER  AUTO EXEC   S70  A  9 ...
|NETTESTR S0066842 ACTIVE   PHOENIX  PHOENIX  EXEC   SA015 ...
|EDJX2T0066784 QUEUED   EDJX2EDJX2PRINT  1 ...

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-05 Thread William H. Blair

Edward Jaffe notes:

 As I stated, I've seen it done far more than I ever expected. 

The problem, Ed, is that you expect (or at least hope for) mostly
rational behavior, and you view such mechanisms as irrational and
odd (because there are better, more appropriate, ways to do this).

While I academically agree, I bet many such [remaining] practices
are rooted in history, from a time when RACF (et al.) security
control of access to SPOOLed SYSOUT data was simply not supported
or a site didn't have an ESM to begin with.  

Paul Gilmartin remembers:

 And as a user, I too have endured practices of bootleging 
 information to job processing components via the jobname, 
 simply because no other vehicle exists.  I believe we have 
 test subsystems on which I still must adjust my jobname to 
 select a library tape subpool.

Folks used existing knobs to control/enable desired function, 
and long ago there were insufficient knobs (particularly the 
concept of a JOB's so-called owner). So they used the knobs 
they knew they had at hand. JOB name was nothing more than a 
convenient knob, because little else was convenient/available. 

Edward Jaffe added:

 Many JES2/SDSF shops control job/spool access primarily by 
 enforcing job name standards. It's pretty ugly...

in response to Ted MacNEIL:

 Welcome to 1980!
 I know of nobody using jobname to protect access.

As a software vendor, I can tell you authoritatively that 
this practice occurs at a significant plurality of customer
sites. We frequently have to deal with customers who need
a bit of help getting the rules right. They expect to be
able to access certain output, and blame us when they can't.
We hold their hands and help them understand the mess they
are in, and figure out how to make it work for our products 
in their shop (at least on that particular day). 

Ed is right, it's pretty ugly. And more widespread that you
would ever (rationally) expect.

In fact, in the very early days of ESMs, back when ACF2 didn't 
even have a SAF interface (because SAF didn't yet exist or was
still brand-new), instead of using the (still brand-new) USER=
keyword parameter on the JOB statement (if it even was supported
by the customer's current MVS/SP system), many installations 
used a feature of Top Secret to derive what TSS calls the ACID
(what RACF calls the USER) from up to 8 characters selected by
rule from fields such as the JOB name, Programmer Name, Accounting
Information [sub]fields, etc. That practice continued at many
TSS shops for years, and I recently shot a problem at a customer
site where it's still the way things are done (~25 years later).
Even for JES2 sites (who could use SDSF if they were desperate), 
RYO SPOOL browsers were common and used a variety of installation-
specific knobs to control end (TSO) user access to SYSOUT data in
both the distant and not-so-distant past.

Stuff like this is hard for shops to change, much less give up.
The reason I have little sympathy for them is that most of the
pain is self-inflicted, especially since the cure is less costly 
than the continued hit on end user productivity.

In the early 90s I remember being onsite at a large insurance 
company -- a TSS customer with very arcane rules for JOB and
programmer names and accounting information field contents, all
of which were used to construct the actual TSS ACID to be used. 
The rules were so restrictive that it was difficult for me to 
come up with much more than 20 different JOB names, much less
mnemonic or suggestive ones. When I looked at the JOB queue,
I typically saw dozens, even hundreds of identically-named
JOBs. Picking up my own printouts at the remote printer was an
exercise in snooping on everybody else's work, since the rules
tended to make lowly programmers use JOB names that matched
those submitted by other programmers. I was fighting not only
the rules to get more than one of my JOBs to execute at the 
same time (an absolute requirement for a multi-address space
product), but other programmers' JOBs as well. 

--
WB

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USER/OWNER/SYSUID (was Multiple jobs/same name

2009-10-05 Thread George Fogg

On Mon, 5 Oct 2009 08:41:26 +0100, Terry Sambrooks 
terry.sambro...@btclick.com wrote:

Hi,

Paul Gilmartin wrote in Re: Multiple jobs/same name

EXEC PGM=IEFBR14,PARM='SYSUID' substitutes the USER= value from the 
JOB
CARD for SYSUID.

Until someone shows me documentation or an example to the
contrary, I'll believe that OWNER is a synonym for userid.


You are correct, it's the exection userid and not the submitter's userid.
As I have mentioned in this list several times over the years, the userid in 
the 
SDSF OWNER column is from the JSABUSID field in JSAB that is a JES CB. You 
won't see a OWNER userid for jobs not started by JES like SUB=MSTR.
George Fogg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

 On 10/4/2009 at 9:14 AM, in message 4ac8bbf3.1040...@ync.net, Rick 
 Fochtman wrote:
 - You are NOT allowed to submit production jobs / reruns from your TSO (must
 go through the job scheduler)
 
 Absolutely agree.
 
 - You are NOT allowed to submit test jobs using a production jobname.
 Period. No discussion. Not even on a separate system.
  

 
 Bizarre.  Why not?
 --unsnip
 Some automation packages are quite capable of triggering product streams 
 when a particular ad-hoc jobname completes. You wouldn't want your 
 development 
 team triggering production streams at the wrong time of day would you?
 
 --snip-- 

Certainly not.  If I had a job scheduler that treated a test job as if it were 
a production job I would treat that as a bug in the scheduler and have the 
vendor fix it.  Certainly there are several ways of distinguishing between a 
production job and a test job.  For instance the scheduler user ID is used to 
submit production jobs...

Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

 On 10/5/2009 at 5:43 AM, in message
of10f77fcc.d152952f-on85257646.00402abf-85257646.00405...@us.ibm.com, Peter
Relson rel...@us.ibm.com wrote:
 I don't use SDSF H generally because of it defaulting to your userID as
 prefix
(must use H ALL to override).
 
 I consider that the default default.
 
 OWNER yourid
 PREFIX **
 works very nicely for me. So, yes, you had to do something to get this in
 place, but once it's there it stays so from then on could be considered
 your default.

Hi Peter,

I was not aware of PREFIX **.
This appears to work well!
Thanks for the heads up!
Where is this documented, anyway?  SDSF seems to only have one manual, SDSF 
Operation and Customization, and I can't find PREFIX documented anywhere in 
there.

I'm still confused by why the H screen functions differently than the O, ST, 
and DA screens with regard to how PREFIX is treated, but...

Thanks!
Frank


-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-05 Thread Rick Fochtman


---snip-


On 10/4/2009 at 9:14 AM, in message 4ac8bbf3.1040...@ync.net, Rick Fochtman 
wrote:
   


- You are NOT allowed to submit production jobs / reruns from your TSO (must
 


go through the job scheduler)
   


Absolutely agree.

   


- You are NOT allowed to submit test jobs using a production jobname.
Period. No discussion. Not even on a separate system.
   




 


Bizarre.  Why not?
--unsnip
Some automation packages are quite capable of triggering product streams 
when a particular ad-hoc jobname completes. You wouldn't want your development 
team triggering production streams at the wrong time of day would you?


--snip-- 
   



Certainly not.  If I had a job scheduler that treated a test job as if it were 
a production job I would treat that as a bug in the scheduler and have the 
vendor fix it.  Certainly there are several ways of distinguishing between a 
production job and a test job.  For instance the scheduler user ID is used to 
submit production jobs...


-unsnip-
But you still need to prevent testers from submitting jobs with a 
production USERID. We used a TSO exit to remove USER/PASSWORD parms from 
the JOB statement. Got a better idea?


Please remember: much of what I describe was developed before RACF was 
able to filter job submission.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-05 Thread McKown, John

 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman
 Sent: Monday, October 05, 2009 2:33 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: Multiple jobs/same name
snip
 But you still need to prevent testers from submitting jobs with a 
 production USERID. We used a TSO exit to remove USER/PASSWORD 
 parms from 
 the JOB statement. Got a better idea?

 Please remember: much of what I describe was developed before 
 RACF was 
 able to filter job submission.

 Rick

Use a PROTECTED id in RACF and SURROGAT authority to allow the scheduler's RACF 
id to submit jobs with the specified ID(s). PROTECTED says that you cannot use 
USER=  PASSWORD= on the job card to assign the RACF id. RACF will simply not 
allow it. The attempt fails with a RACF error. SURROGAT says that the scheduler 
can specify USER= without PASSWORD= to run a job with the specified 
(authorized) RACF id. This is what we do with CA-7 scheduling.

Of course, you still need the submit exit for non-PROTECTED ids which a person 
may know the password to. And it is easy to bypass:

//MYIDA JOB
//SUBMIT EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD SYSOUT=(*,INTRDR)
//SYSUT1 DD DISP=SHR,DSN=some.pds(member)

some.pds(member):

//OTHERID JOB USER=otherid,PASSWORD=password
//* THE REST OF THE JOB
//* ...
//

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-05 Thread Tony B.

If I knew the password I'd simply log on myself and submit..



 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of McKown, John
Sent: Monday, October 05, 2009 2:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Multiple jobs/same name

 -Original Message-
 From: IBM Mainframe Discussion List
 [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman
 Sent: Monday, October 05, 2009 2:33 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: Multiple jobs/same name
snip
 But you still need to prevent testers from submitting jobs with a 
 production USERID. We used a TSO exit to remove USER/PASSWORD parms 
 from the JOB statement. Got a better idea?
 
 Please remember: much of what I describe was developed before RACF was 
 able to filter job submission.
 
 Rick
 

Use a PROTECTED id in RACF and SURROGAT authority to allow the scheduler's
RACF id to submit jobs with the specified ID(s). PROTECTED says that you
cannot use USER=  PASSWORD= on the job card to assign the RACF id. RACF
will simply not allow it. The attempt fails with a RACF error. SURROGAT says
that the scheduler can specify USER= without PASSWORD= to run a job with the
specified (authorized) RACF id. This is what we do with CA-7 scheduling.

Of course, you still need the submit exit for non-PROTECTED ids which a
person may know the password to. And it is easy to bypass:

//MYIDA JOB
//SUBMIT EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD SYSOUT=(*,INTRDR)
//SYSUT1 DD DISP=SHR,DSN=some.pds(member)

some.pds(member):

//OTHERID JOB USER=otherid,PASSWORD=password
//* THE REST OF THE JOB
//* ...
//

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com *
www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. HealthMarkets(r) is the brand name for products underwritten and
issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake
Life Insurance Company(r), Mid-West National Life Insurance Company of
TennesseeSM and The MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

___
No viruses found in this incoming message Scanned by iolo AntiVirus 1.5.8.3
http://www.iolo.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

On Mon, 5 Oct 2009 14:32:53 -0500, Rick Fochtman wrote:

But you still need to prevent testers from submitting jobs with a
production USERID. We used a TSO exit to remove USER/PASSWORD parms from
the JOB statement. Got a better idea?

Change the password?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

 On 10/5/2009 at 1:32 PM, in message 4aca49e5.2070...@ync.net, Rick 
 Fochtman
rfocht...@ync.net wrote:
 But you still need to prevent testers from submitting jobs with a 
 production USERID. We used a TSO exit to remove USER/PASSWORD parms from 
 the JOB statement. Got a better idea?

RACF seems to do this for us.  I tried to submit a job using another 
programmer's user ID and got this:

$HASP100 MYJOBON INTRDRFROM TSU08747 FJS
ICH408I USER(RSG ) GROUP(APPPROG ) NAME(ROBIN GORDON) 811   
  SUBMITTER(FJS )   
  LOGON/JOB INITIATION - SUBMITTER IS NOT AUTHORIZED BY USER

I'm not going to try using the scheduler's user ID, but I would hope something 
similar would occur!
 
 Please remember: much of what I describe was developed before RACF was 
 able to filter job submission.

For better or worse I am not familar with the pre-RACF world.  So any 
limitations that may be in place because of that world may strike me as 
silly, simply because I didn't have to deal with it.  In any case, since I 
don't live in that world I don't believe I should be limited by its 
restrictions.  That's what I'm getting at.

Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-05 Thread Edward Jaffe


Rick Fochtman wrote:
But you still need to prevent testers from submitting jobs with a 
production USERID. We used a TSO exit to remove USER/PASSWORD parms 
from the JOB statement. Got a better idea?


Really?
1. You use a TSO/E user exit to block this? What if they submit a job 
with USER= and PASSWORD= to INTRDR using IEBGENER in a batch job?
2. Your testers know a userid/password combination that will give them 
production credentials?


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-05 Thread Tony B.

The whole idea of production user profiles is that they have no passwords,
thus limiting the access to them to surrogat profiles.  The RACF surrogat
class, in the form userid.submit,  as others have cited, can provide the
ability for USERA to submit a job with USER=USERB, with no password operand
on the job card.  

In rationally configured shops only the scheduling package started task has
access to any surrogat profiles. Odd that this is continuing on IBM-MAIN.
It's rather basic RACF-L subject matter.





-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Edward Jaffe
Sent: Monday, October 05, 2009 4:01 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Multiple jobs/same name

Rick Fochtman wrote:
 But you still need to prevent testers from submitting jobs with a 
 production USERID. We used a TSO exit to remove USER/PASSWORD parms 
 from the JOB statement. Got a better idea?

Really?
1. You use a TSO/E user exit to block this? What if they submit a job with
USER= and PASSWORD= to INTRDR using IEBGENER in a batch job?
2. Your testers know a userid/password combination that will give them
production credentials?

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

___
No viruses found in this incoming message Scanned by iolo AntiVirus 1.5.8.3
http://www.iolo.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Job name standards (Was: multiple jobs / same name)

2009-10-05 Thread Arthur Gutowski

On Fri, 2 Oct 2009 16:53:47 -0700, Edward Jaffe 
edja...@phoenixsoftware.com wrote:

I have personally not put my userid into a job name in nearly 25 years.
If I submit a job to compress a PDS, it's called COMPRESS. That's what
makes sense to me.

Except when there are hundreds or thousands of applications to support (not 
uncommon for a z/OS shop, I suspect).  AFAIK, JES3 still does not allow for 
duplicate jobnames to exeute in tandem without modification (other than the 
bypass for UNIX tasks).  As vendors IBM keeps (kept?) a vendor module prefix 
registry to reduce LPA and LINK list collisions, JOBNAME standards are 
required, though agreeably NOT for security.

Before RACF, JES did not keep track of job ownership like it does today.
Job/spool security pretty much had to be based on job name. At least, it
was the most convenient method available in the 1960s and 1970s. That
was a long, long time ago. But, old habits die hard.

(E)JES taught me the hard way that a VERY significant number--possibly
the vast majority--of JES2/SDSF installations still do job/spool
security by job name. And, most of them don't want to invest one iota of
extra time to convert from their arcane, jobname-based security scheme
to an elegant, modern, ownership-based standard--whether SAF or not.
Based on their requirements, we spent (IMHO too much) time adding job
name security functionality to make their conversions transparent. I
suspect IOF and the others have done similar things.

Amen, and worse dragging the ball-and-chain of JES2 exits that enforce these 
arcane standards for no other reason than that's how we've always done it.

Regards,
Art Gutowski
Ford Motor Company

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Job name standards (Was: multiple jobs / same name)

2009-10-05 Thread Edward Jaffe


Arthur Gutowski wrote:
...  AFAIK, JES3 still does not allow for 
duplicate jobnames to exeute in tandem without modification (other than the 
bypass for UNIX tasks).
  


I agree it's crazy. I suspect nearly every JES3 shop in the world has 
this (very old) one line modification in place:


++SRCUPD(IATGRJS) .
./ CHANGE NAME=IATGRJS
B MSSCH030ACCEPT MULTIPLE LOGON   UMJES06  
38244010


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Starting fresh, was Multiple jobs/same name

2009-10-05 Thread Gibney, Dave

  I agree with Frank here. He's starting with a new z/OS system, albeit
converting from VSE. He should not be encumbered by any of the baggage
from pre RACF or any other this is the way we had to do it last
century.

  Aside from logical job ownership controls and flexible job names, what
other advice can we give him?

Set up for multi-logon TSO from the start? Be prepared for Sysplex later
even if monoplex now. Keep sandbox/test/development/production separate
from the start? Others?

  

Dave Gibney
Information Technology Services
Washington State University


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
 Behalf Of Frank Swarbrick
 Sent: Monday, October 05, 2009 1:49 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re:  
 
  On 10/5/2009 at 1:32 PM, in message 4aca49e5.2070...@ync.net,
 Rick Fochtman
 rfocht...@ync.net wrote:
  But you still need to prevent testers from submitting jobs with a
  production USERID. We used a TSO exit to remove USER/PASSWORD parms
 from
  the JOB statement. Got a better idea?
 
 RACF seems to do this for us.  I tried to submit a job using another
 programmer's user ID and got this:
 
 $HASP100 MYJOBON INTRDRFROM TSU08747
 FJS
 ICH408I USER(RSG ) GROUP(APPPROG ) NAME(ROBIN GORDON) 811
   SUBMITTER(FJS )
   LOGON/JOB INITIATION - SUBMITTER IS NOT AUTHORIZED BY USER
 
 I'm not going to try using the scheduler's user ID, but I would hope
 something similar would occur!
 
  Please remember: much of what I describe was developed before RACF
 was
  able to filter job submission.
 
 For better or worse I am not familar with the pre-RACF world.  So any
 limitations that may be in place because of that world may strike me
as
 silly, simply because I didn't have to deal with it.  In any case,
 since I don't live in that world I don't believe I should be limited
by
 its restrictions.  That's what I'm getting at.
 
 Frank
 
 --
 
 Frank Swarbrick
 Applications Architect - Mainframe Applications Development
 FirstBank Data Corporation - Lakewood, CO  USA
 P: 303-235-1403
 
 
 
 
 The information contained in this electronic communication and any
 document attached hereto or transmitted herewith is confidential and
 intended for the exclusive use of the individual or entity named
above.
 If the reader of this message is not the intended recipient or the
 employee or agent responsible for delivering it to the intended
 recipient, you are hereby notified that any examination, use,
 dissemination, distribution or copying of this communication or any
 part thereof is strictly prohibited.  If you have received this
 communication in error, please immediately notify the sender by reply
 e-mail and destroy this communication.  Thank you.
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-05 Thread Rick Fochtman


snip


On Mon, 5 Oct 2009 14:32:53 -0500, Rick Fochtman wrote:
 


But you still need to prevent testers from submitting jobs with a
production USERID. We used a TSO exit to remove USER/PASSWORD parms from
the JOB statement. Got a better idea?

   


Change the password?
 


unsnip---
We did. Our Production Support staff and our automation product had 
SURROGAT authority but the production password was a closely guarded 
secret, known only by me.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

On Mon, 5 Oct 2009 18:28:35 -0500, Rick Fochtman wrote:

But you still need to prevent testers from submitting jobs with a
production USERID. We used a TSO exit to remove USER/PASSWORD parms from
the JOB statement. Got a better idea?

Change the password?

We did. Our Production Support staff and our automation product had
SURROGAT authority but the production password was a closely guarded
secret, known only by me.

???  Testers didn't have SURROGAT (I assume they weren't Production
Support, and didn't have access to automation), and they didn't
know the production password?  How were they bypassing?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Starting fresh, was Multiple jobs/same name

 On 10/5/2009 at 5:00 PM, in message
edfbe8a9b39ed541ba3c8177c32ff0c8cde...@exchangevs-02.ad.wsu.edu, Gibney,
Dave gib...@wsu.edu wrote:
 I agree with Frank here. He's starting with a new z/OS system, albeit
 converting from VSE. He should not be encumbered by any of the baggage
 from pre RACF or any other this is the way we had to do it last
 century.
 
   Aside from logical job ownership controls and flexible job names, what
 other advice can we give him?
 
 Set up for multi-logon TSO from the start? Be prepared for Sysplex later
 even if monoplex now. Keep sandbox/test/development/production separate
 from the start? Others?

Thanks Dave!

We already have production separate from dev separate from a systems sandbox.  
We have test/dev together, but we've always had that and never found a reason 
not to.  (If we were a larger shop we might.)

What is multi-logon TSO?

We just a week or two ago had our business partner come in and discuss Sysplex 
with us, so I hope our SPs will make us prepared for Sysplex later.

And yes, any other advice is appreciated!

Thanks,
Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: multiple jobs / same name

2009-10-04 Thread Rick Fochtman


-snip---
The simplest way to insure that Jobs run in a specific order (without 
the need for a scheduler package to do this) is to just place a INTRDR 
step as step 1 of the Job to submit the next job. The use of the same 
job name will then have it wait for the current job to complete before 
the submitted job is eligible to execute.

-unsnip-
That works very well, but if you make the LAST step submit the next job, 
then you can stop the stream in case of problems.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: multiple jobs / same name

2009-10-04 Thread Rick Fochtman


--snip---
If you wish to run without standards, you are entirely entitled to do 
so. On the other hand, you are also entitled to never be able to justify 
upgrades, as well.

--unsnip--
On the other hand, having and enforcing at least a minimal set of 
standards can be of tremendous benefit when planning security, disaster 
recovery/business continuity, performance standards, SLA's, etc.


Standards don't have to be straight jackets to make management easier. 
They just have to provide good workable guidelines for how the complex 
is used. As always, the most important standards are those that assure 
that the business needs of the company/corporation are met in a timely 
fashion. Better management helps to assure this. And better management 
MIGHT forstall upgrades.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: multiple jobs / same name

And better management MIGHT forstall upgrades.

Only for so long.
If a company is thriving, upgrades are a fact of life.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

I have worked for a number of different companies since I entered the
mainframe arena in the late 70's. And all of these shops worked along the
same lines:
- TSO - submitted jobs are named userid + 1 or more characters.

I don't see any good reason for this, other than inertia.
unsnip---
Agreed. I never followed this standard myself, preferring to use more
descriptive jobnames.

-snip---

- Output from these jobs goes to the Hold Queue.

This is OK as long as it can be overriden when desired.
unsnip
AFAIK, this has always been possible.

--snip

- Default setup in SDSF H shows you your jobs, by jobname prefix and

owner.

I don't use SDSF H generally because of it defaulting to your userID as prefix (must
use H ALL to override).
I almost always use SDSF ST to look at my output

- You are allowed to submit jobs using other jobnames (e.g., program
compiles: jobname = pgmname) at your discretion, but ...

Generous! :-)
unsnip---
Generous but MIGHT be a problem.

---snip--

- You are NOT allowed to submit production jobs / reruns from your TSO (must

go through the job scheduler)

Absolutely agree.

- You are NOT allowed to submit test jobs using a production jobname.
Period. No discussion. Not even on a separate system.

Bizarre. Why not?
--unsnip
Some automation packages are quite capable of triggering product streams when a
particular ad-hoc jobname completes. You wouldn't want your development team
triggering production streams at the wrong time of day would you?

--snip--

The tradition of using your TSO userid for batch job names dates back to the
invention of TSO and has been a default (or should I say, de-facto standard)
ever since then. Some shops enforce this rule more strictly than others, but
I found that I could live with these rules, without any trouble whatsoever.

Obviously I have not found I can live with it, at least not without being
grumpy. And since I have some pull with how our z/OS systems are being set up
I will push for what I like. Won't win all the time, of course, but I see no
reason not to try. I've been here 18 years (13 in IT, on VSE) and have no
plans to go elsewhere, so...

Thanks for your comments!
--unsnip---
I agree that this de-facto standard is unnecessarily rigid. But the idea of not
submitting test jobs with production jobnames makes perfect sense to me. As the non-believer said
at the seance, It's time to strike a happy medium.

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-04 Thread Paul Gilmartin

On Sun, 4 Oct 2009 10:14:59 -0500, Rick Fochtman wrote:

 - You are NOT allowed to submit production jobs / reruns from your TSO (must
 go through the job scheduler)

Absolutely agree.

 - You are NOT allowed to submit test jobs using a production jobname.
 Period. No discussion. Not even on a separate system.

At first I agreed, but I'm reconsidering.

Bizarre.  Why not?

Some characteristic might be better than jobname.  What
about jobclass?  And I still think about OWNER.  Either
production jobs run with job scheduler as OWNER, or
job scheduler has sufficient authority to control the
OWNER of submitted jobs.  Some programmers might have
both test and production IDs.  The production IDs would
have no RACF TSO segments, guranteeing that production
jobs are not submitted from TSO sessions.  RACF profiles
would severely limit test ID access to production data
sets (likely read-only).  Much of the enforcement could
be delegated to common RACF facilities, with less than
the historical (pre-RACF technology) dependency on user
exits sensitive to jobnames.

I hope Ed J. would approve.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

Some characteristic might be better than jobname.  What about jobclass?  And I 
still think about OWNER.  Either
production jobs run with job scheduler as OWNER, or job scheduler has 
sufficient authority to control the
OWNER of submitted jobs.

Why OWNER?
Userid is the common control for production (independent of job-name).

Some programmers might have
both test and production IDs.  The production IDs would have no RACF TSO 
segments, guranteeing that production jobs are not submitted from TSO sessions.

Giving programmers production ID's is one heck of an exposure.

RACF profiles would severely limit test ID access to production data
sets (likely read-only).

In most (if no all) shops this is already restricted.
And, usually, not even read only is allowed.

Much of the enforcement could
be delegated to common RACF facilities, with less than the historical (pre-RACF 
technology) dependency on user
exits sensitive to jobnames.

Welcome to 1980!
I know of nobody using jobname to protect access.
But, I could be wrong!
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

2009-10-04 Thread Paul Gilmartin

On Mon, 5 Oct 2009 00:48:49 +, Ted MacNEIL wrote:

Some characteristic might be better than jobname.  What about jobclass?  And 
I still think about OWNER.  Either
production jobs run with job scheduler as OWNER, or job scheduler has 
sufficient authority to control the
OWNER of submitted jobs.

Why OWNER?
Userid is the common control for production (independent of job-name).

I'm naive; enlighten me.  In what cases does userid differ from OWNER?
How can the programmer control these independently?  Rexx has a
userid() function; JCL has SYSUID.  Does either Rexx or JCL have
a function or variable to query OWNER?  Conversely, SDSF shows OWNER.
If I scroll right far enough, will I see userid?

Some programmers might have
both test and production IDs.  The production IDs would have no RACF TSO 
segments, guranteeing that production jobs are not submitted from TSO sessions.

Giving programmers production ID's is one heck of an exposure.

I'm naive; I don't work in a production shop.  I bow to your expertise
about separation of functions.

RACF profiles would severely limit test ID access to production data
sets (likely read-only).

In most (if no all) shops this is already restricted.
And, usually, not even read only is allowed.

As above.

Much of the enforcement could
be delegated to common RACF facilities, with less than the historical 
(pre-RACF technology) dependency on user
exits sensitive to jobnames.

Welcome to 1980!
I know of nobody using jobname to protect access.
But, I could be wrong!

Jobname must be protecting access to something, else what's
the point of enforcing jobname rules and the intense concern
that test programmers not use production jobnames?  Prior
plies in this thread suggest that in some chargeback shops
jobname is used to protect access to funds in those charged
accounts.  But this could be likewise based on OWNER (userid?).
And isn't there an ACCOUNT parameter on the JOB statement
which seems to be designed for this purpose?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

I'm naive; enlighten me.  In what cases does userid differ from OWNER?

OWNER is, I believe, the userid that submits the job.
Having never used OWNER for anything, I can't truly say.

How can the programmer control these independently?

USER=  PASSWORD= are valid JOB CARD parms.

Rexx has a userid() function; JCL has SYSUID.  Does either Rexx or JCL have
a function or variable to query OWNER?

I don't know.

Conversely, SDSF shows OWNER. If I scroll right far enough, will I see userid?

I don't know. Try it.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name