-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
[ snip ]
BTW, I have seen suggested here PREFIX ** and PREFIX *.
Zero asterisks is sufficent (Think of it as selecting any
jobname that consists of the null string plus optional
following
On Mon, 19 Oct 2009 07:09:24 -0500, Chase, John wrote:
Perhaps we have something misconfigured, but I've wondered why I must
append an asterisk to a prefix value, say, to display all the CICS
regions on the DA screen. If I enter PRE CICS I get a blank screen,
but if I enter PRE CICS* I see all
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
On Mon, 19 Oct 2009 07:09:24 -0500, Chase, John wrote:
Perhaps we have something misconfigured, but I've wondered why I must
append an asterisk to a prefix value, say, to display all the CICS
In a message dated 10/19/2009 9:38:57 A.M. Central Daylight Time,
jch...@ussco.com writes:
Well, PRE *ICS returns a blank DA screen, but PRE *ICS* shows all
the CICS regions.
Long ago and far away started using ---da ostc cics*
I hardly ever use PREFIX anymore, preferring SELECT for its ephemeral
nature.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the
On Mon, 19 Oct 2009 08:31:40 -0500, Paul Gilmartin paulgboul...@aim.com wrote:
On Mon, 19 Oct 2009 07:09:24 -0500, Chase, John wrote:
Perhaps we have something misconfigured, but I've wondered why I must
append an asterisk to a prefix value, say, to display all the CICS
regions on the DA screen.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
On Mon, 19 Oct 2009 08:31:40 -0500, Paul Gilmartin
paulgboul...@aim.com wrote:
On Mon, 19 Oct 2009 07:09:24 -0500, Chase, John wrote:
Perhaps we have something misconfigured, but I've wondered why I
On Mon, 19 Oct 2009 11:23:02 -0500, Chase, John jch...@ussco.com wrote:
You can have SDSF automatically append the * again. See APAR PK79932.
There was also a discussion in IBM-MAIN about this a few months ago.
http://www-01.ibm.com/support/docview.wss?uid=isg1PK79932
Yabbut By
I use SDSF STATUS all the time. It works well with PRE * (or PRE **) and
OWNER FJS (where FJS is my user ID).
On 10/12/2009 at 4:11 PM, in message
200910122230.n9cmteps015...@jefferson.patriot.net, Shmuel Metz (Seymour J.)
shmuel+ibm-m...@patriot.net wrote:
In
He was referring to the TSO STATUS command, not to SDSF.
Frank Swarbrick frank.swarbr...@efirstbank.com 10/16/2009 1:54 PM
I use SDSF STATUS all the time. It works well with PRE * (or PRE **) and
OWNER FJS (where FJS is my user ID).
On 10/12/2009 at 4:11 PM, in message
Oh. Since I don't even know what that is, I guess I don't use it! :-)
On 10/16/2009 at 11:57 AM, in message 4ad87ba9.8489.00d...@joann.com, Scott
Rowe scott.r...@joann.com wrote:
He was referring to the TSO STATUS command, not to SDSF.
Frank Swarbrick frank.swarbr...@efirstbank.com
On Fri, 16 Oct 2009 14:36:15 -0600, Frank Swarbrick wrote:
Oh. Since I don't even know what that is, I guess I don't use it! :-)
On 10/16/2009 at 11:57 AM, in message 4ad87ba9.8489.00d...@joann.com, Scott
Rowe wrote:
He was referring to the TSO STATUS command, not to SDSF.
I believe it's
On 10/16/2009 at 3:31 PM, in message
listserv%200910161631557945.1...@bama.ua.edu, Paul Gilmartin
paulgboul...@aim.com wrote:
BTW, I have seen suggested here PREFIX ** and PREFIX *.
Zero asterisks is sufficent (Think of it as selecting any
jobname that consists of the null string plus optional
--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?
Sure; don't have passwords for
On 10/14/2009 03:44 PM, Rick Fochtman wrote:
--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?
In 4accb43c.6040...@ync.net, on 10/07/2009
at 10:31 AM, Rick Fochtman rfocht...@ync.net said:
Apperantly. He's selling used cars now. When he asked us for a
reference, our only comment was not eligible for re-hire.
I cannot recommend this employee too highly.
--
Shmuel (Seymour J.)
In 6134cdf9e3c17546be1c9d525bdeef95f081776...@hqmail.rocketsoftware.com,
on 10/09/2009
at 08:03 AM, Bob Shannon bshan...@rocketsoftware.com said:
I think they decided to use the OS/2 model of only having online
documentation.
No; the OS/2 model includes having both[1] .hlp and .inf files,
In 34793d8ab1354e73914a9f13db920...@tbabonas, on 10/05/2009
at 04:15 PM, Tony B. tbabo...@comcast.net said:
In rationally configured shops only the scheduling package started task
has access to any surrogat profiles.
No; just because you haven't anticipated a legitimate use doesn't mean
that
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.)
Sent: Tuesday, October 13, 2009 11:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Multiple jobs/same name
snip
I cannot recommend this employee too highly
--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?
Sure; don't have passwords for production jobs.
---snip--
I cannot recommend this employee too highly.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
I prefer: If you can get this person to work for you, you will be doing well.
--
John McKown
Systems Engineer IV
IT
On 10/13/2009 02:58 PM, Rick Fochtman wrote:
--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?
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
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.
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.
--
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
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
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
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.
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
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
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
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.
-
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
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
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
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
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
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 -
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
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?
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.)
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
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:
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
/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
-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
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?
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.
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
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
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
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).
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
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*
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
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
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
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.
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.
---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)
-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
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
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
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
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
...@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
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
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:
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
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
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
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
-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
--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.
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
snip-
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
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
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
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
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
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?
Jobname are often used by job schedulers to control production streams.
Would you like your app people to accidentally
Ted MacNEIL wrote:
Welcome to 1980!
I know of nobody using jobname to protect access.
As I stated, I've seen it done far more than I ever expected. Many
JES2/SDSF shops control job/spool access primarily by enforcing job name
standards. It's pretty ugly...
--
Edward E Jaffe
Phoenix
On Mon, 5 Oct 2009 02:14:51 +, Ted MacNEIL wrote:
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=
On Fri, 2 Oct 2009 23:01:09 +, Ted MacNEIL wrote:
What's wrong with OWNER?
SMF doesn't/didn't collect it.
I would call that something wrong with SMF, not something
wrong with OWNER.
-- gil
--
For IBM-MAIN subscribe /
On Fri, 2 Oct 2009 23:08:07 +, Ted MacNEIL wrote:
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.
There's a non sequitur here. You appear to be arguing that because I
don't
On Fri, 2 Oct 2009 16:53:47 -0700, Edward Jaffe wrote:
(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
SMF doesn't/didn't collect it.
I would call that something wrong with SMF, not something
wrong with OWNER.
Yes, but.
We are required to use the tools delivered.
NOT, B*TCH about those lacking.
As a capacity analyst, I have to answer today's questions, today.
NOT worry about tomorrow's
There's a non sequitur here. You appear to be arguing that because I
don't subscribe to your biases concerning job naming practices, any
argument I might advance supporting an upgrade is worthless.
Since I never ascribed to any bias, except have an enforcable standard, I have
no idea what
I have a complaint (shocking, I know). What is the reasoning behind MVS not
allowing more than one job with the same name to run at the same time? For
instance just now I wanted to do an IDCAMS PRINT on two files. I do this often
on VSE with a job I have set up that has this:
PRINT
Frank Swarbrick wrote:
I have a complaint (shocking, I know). What is the reasoning behind MVS not
allowing more than one job with the same name to run at the same time? For
instance just now I wanted to do an IDCAMS PRINT on two files. I do this
often on VSE with a job I have set up
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick
Sent: Friday, October 02, 2009 1:44 PM
To: IBM-MAIN@bama.ua.edu
Subject: multiple jobs / same name
I have a complaint (shocking, I know). What is the reasoning
But unless I change the job name on the JOB card on z/OS the second one won't
run until the first is done.
It's actually an installation option under JES (didn't used to be).
Under OS/390 2.7(ish) it was introduced as DUPJOB=DELAY -- I believe that is
the correct name.
The default was set to
On 2 Oct 2009 11:53:39 -0700, mark.jac...@custserv.com (Mark Jacobs)
wrote:
As you correctly surmised the default to delay duplicate jobnames is due
to the way it's always worked. I assume that it was used as a very
simple job scheduling mechanism.
I worked at a place that used CLISTs to submit
On 2 Oct 2009 11:55:07 -0700, john.mck...@healthmarkets.com (McKown,
John) wrote:
This one at a time has persisted to this day as a primitive way to try to
ensure that jobs run in a specific sequence. Programmers especially think
that if n jobs are submitted in the same job class, then they
I suppose you could set some job classes to allow the NODELAY, and have
automation look for a particular JOBPARM which would result in moving the
job to those classes.
Don
On Fri, Oct 2, 2009 at 3:14 PM, Howard Brazee howard.bra...@cusys.eduwrote:
On 2 Oct 2009 11:55:07 -0700,
12:43:38 -0600
From: frank.swarbr...@efirstbank.com
Subject: multiple jobs / same name
To: IBM-MAIN@bama.ua.edu
I have a complaint (shocking, I know). What is the reasoning behind MVS not
allowing more than one job with the same name to run at the same time? For
instance just now I wanted
Web: www.rocketsoftware.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Dave Salt
Sent: Friday, October 02, 2009 2:34 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: multiple jobs / same name
Hi Frank,
I used to work at a place
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO USA
P: 303-235-1403
On 10/2/2009 at 12:51 PM, in message 4ac64ba1.7090...@custserv.com, Mark
Jacobs mark.jac...@custserv.com wrote:
Frank Swarbrick wrote:
I have a
On 10/2/2009 at 1:12 PM, in message
d2kcc59q08skconl4etbbktdraechud...@4ax.com, Howard Brazee
howard.bra...@cusys.edu wrote:
On 2 Oct 2009 11:53:39 -0700, mark.jac...@custserv.com (Mark Jacobs)
wrote:
As you correctly surmised the default to delay duplicate jobnames is due
to the way it's
1 - 100 of 147 matches
Mail list logo
