On Mon, 19 Oct 2009 11:23:02 -0500, Chase, John 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 definition
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
>
> On Mon, 19 Oct 2009 08:31:40 -0500, Paul Gilmartin
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
> >
On Mon, 19 Oct 2009 08:31:40 -0500, Paul Gilmartin 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. If I ent
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 arc
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*
-
> -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
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
> -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
> follow
>>> On 10/16/2009 at 3:31 PM, in message
, Paul Gilmartin
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
> following characters.) Saves me a couple keystrokes
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 believ
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.
>
Frank Swarbrick 10/16/2009 1:54 PM >>>
> I use SDSF STATUS all the
He was referring to the TSO STATUS command, not to SDSF.
>>> Frank Swarbrick 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
<200910122230.n9cmteps015...@jefferson.pa
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.)"
wrote:
> In <000d01ca43b2$7ddc9c10$7995d4...@net>, on 10/02/20
On 10/14/2009 03:44 PM, 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
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
On 10/13/2009 02:58 PM, 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?
>>>
-
"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
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 a
> -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
>
> "I cannot recom
In <34793d8ab1354e73914a9f13db920...@tbabonas>, on 10/05/2009
at 04:15 PM, "Tony B." 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 there is none.
In <6134cdf9e3c17546be1c9d525bdeef95f081776...@hqmail.rocketsoftware.com>,
on 10/09/2009
at 08:03 AM, Bob Shannon 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, with the
.inf file organize
In <4accb43c.6040...@ync.net>, on 10/07/2009
at 10:31 AM, Rick Fochtman 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.) Metz, SysPr
In , on 10/10/2009
at 01:41 PM, Paul Gilmartin 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 cont
In , on
10/02/2009
at 01:54 PM, "McKown, John" 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/36
In <000d01ca43b2$7ddc9c10$7995d4...@net>, on 10/02/2009
at 03:48 PM, Ulrich Krueger 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 retur
In
<575253278-1254703734-cardhu_decombobulator_blackberry.rim.net-3855232...@bda488.bisx.prod.on.blackberry>,
on 10/05/2009
at 12:48 AM, Ted MacNEIL said:
>Why OWNER?
Because it's USERID.
>Userid is the common control for production (independent of job-name).
They're synonymous.
--
In
<565251895-1254708894-cardhu_decombobulator_blackberry.rim.net-20340310...@bda488.bisx.prod.on.blackberry>,
on 10/05/2009
at 02:14 AM, Ted MacNEIL said:
>>How can the programmer control these independently?
>USER= & PASSWORD= are valid JOB CARD parms.
K3wl, but it has nothing to do with t
In , on 10/05/2009
at 12:05 AM, Paul Gilmartin 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 positio
In , on 10/02/2009
at 05:49 PM, Paul Gilmartin 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 p
In <4aca49e5.2070...@ync.net>, on 10/05/2009
at 02:32 PM, Rick Fochtman 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 pr
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
>, Peter
>Relson wrote:
>>
>> According to the SDSF folks, their commands are documented in the help
>> panels. Sounds strange to me. But
On Fri, 9 Oct 2009 17:08:30 -0500, Shmuel Metz (Seymour J.) wrote:
>In , 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
In , 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?
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
len
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 a
ars 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
Th
gt 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
In , on 10/03/2009
at 03:26 PM, Paul Gilmartin 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
state
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"
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 - L
>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
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
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 wrote:
> On Wed, 7 Oct 2009 10:31:08 -0500, Rick Fochtman wrot
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.)
>
---
??? 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 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?
>>
>-
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. O
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."
Subject: Re: Multip
Rick Fochtman pisze:
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 statem
>>> On 10/5/2009 at 5:00 PM, in message
, "Gibney,
Dave" 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".
>
> Asi
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
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
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 a
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:
++SRC
On Fri, 2 Oct 2009 16:53:47 -0700, Edward Jaffe
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 (n
ussion 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 T
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 PA
>>> On 10/5/2009 at 1:32 PM, in message <4aca49e5.2070...@ync.net>, 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?
RACF seems to do t
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
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
> -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
> But you still need to prevent testers
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
>>> On 10/5/2009 at 5:43 AM, in message
, Peter
Relson 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 h
>>> 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
On Mon, 5 Oct 2009 08:41:26 +0100, Terry Sambrooks
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 sh
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 acad
Paul Gilmartin wrote:
On Mon, 5 Oct 2009 08:41:26 +0100, Terry Sambrooks
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
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* (t
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).
Paul Gilmartin pisze:
On Mon, 5 Oct 2009 08:41:26 +0100, Terry Sambrooks
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 dif
On Mon, 5 Oct 2009 08:41:26 +0100, Terry Sambrooks
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
>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 th
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 fo
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.
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?
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 Softw
>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 f
>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 use
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 submitte
>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 product
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
-
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
>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
-
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.
On
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
>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 you'r
>>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 (poss
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
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 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 /
Shane wrote:
On Fri, 2009-10-02 at 22:00 -0500, Paul Gilmartin wrote:
Why cah't they devise a single SDSF screen that shows all spool
objects I own?
Have a chat to Ed - maybe he can suggest something that might even do
what customers actually want ... ;-)
The ST equivalent displa
At 13:54 -0500 on 10/02/2009, McKown, John wrote about Re: multiple
jobs / same name:
Programmers especially think that if "n" jobs are submitted in the
same job class, then they are guaranteed to run in the order
submitted. They really aren't guaranteed, but it happens in 9
On Fri, 2009-10-02 at 22:00 -0500, Paul Gilmartin wrote:
> Why cah't they devise a single SDSF screen that shows all spool
> objects I own?
Have a chat to Ed - maybe he can suggest something that might even do
what customers actually want ... ;-)
Shane ...
--
On Fri, 2 Oct 2009 19:05:13 -0600, Frank Swarbrick wrote:
>
>I almost always use SDSF "ST" to look at my output
>
Amen. The enormous benefit of "ST" is it shows the input queue,
executing jobs, and job output, both held and not held, all in one
display. Ths significant drawback of "ST" is that it
Frank Swarbrick wrote:
Edward Jaffe wrote:
It's not at all surprising to me that IBM completely dropped support for
ISFPARMS with SDSF for JES3 in z/OS 1.10.
Ed, you just made my day!
Though I have no idea what ISFPARMS is, it sounds like that may be a good
thing. :-)
I'm usin
>>> On 10/2/2009 at 5:53 PM, in message <4ac6928b.7000...@phoenixsoftware.com>,
Edward Jaffe wrote:
> Frank Swarbrick wrote:
>> I am not a system programmer, but I am certainly trying to control my own
> destiny. Which is why I am arguing for reasonable standards, or better yet
> in this case,
I realize that most people have much larger shops than we do, but in our
environment we have no "chargeback" processing. We're one big happy family
(bank). Our applications are so intertwined there would be no way we could say
one set of jobs belongs to one "department" while another belongs t
Comments interspersed:
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO USA
P: 303-235-1403
On 10/2/2009 at 4:48 PM, in message <000d01ca43b2$7ddc9c10$7995d4...@net>,
Ulrich Krueger wrote:
> Frank,
> I have worked for a n
I use the Programmer-name field to distinguish my jobs. It shows up in
SDSF when you View the Alternate field list.
Here is the job card
//BOLANU JOB (...my acct info...),'UNTERSE SEQ_',
In SDSF, under View, you can display the Alternate fields which include
the Programmer-name and arrange
Frank Swarbrick wrote:
I am not a system programmer, but I am certainly trying to control my own destiny. Which
is why I am arguing for reasonable standards, or better yet in this case, the ability to
name my job what ever I want and not be forced to some silly standard from the 1960's.
So y
Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL
> Sent: Friday, October 02, 2009 4:05 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: multiple jobs / same name
>
> That is a set of unfair statements.
> Especially with today's fiscal environment, you MUST j
1 - 100 of 148 matches
Mail list logo
