On Tue, 29 Nov 2011 15:43:46 -0500, John Gilmore wrote:
>That prospect is disheartening.
>
>Separate, neither of us is likely to be confused with the other; but a
>merged monstrosity might well have his and my disagreeable
>characteristics combined disagreeably.
>
This appears to be a followup to
That prospect is disheartening.
Separate, neither of us is likely to be confused with the other; but a
merged monstrosity might well have his and my disagreeable
characteristics combined disagreeably.
--jg
On 11/29/11, Paul Gilmartin wrote:
> On Tue, 29 Nov 2011 13:40:31 -0600, Robert Prins wro
On Tue, 29 Nov 2011 13:40:31 -0600, Robert Prins wrote:
>
>If you rally insist on RC=0 throughout, you can use this snippet:
>
>/* REXX edit macro
>"isredit macro (parm)"
>l = '-'
>"isredit line_after 0 = (L)"
>say rc
>"isredit (N) = linenum .zl"
>say rc
>if n = 1 then
> do
>"isredit del .zl .
Robert Prins writes
> On Mon, 28 Nov 2011 21:34:31 -0500, John Gilmore wrote:
>
> I took such a view lately. In an ISPF edit macro I enabled
> tracing of all errors. But I needed to determine the size of
> the file being edited, even though it might be empty. I could
> find no way to detect tha
> On Mon, 28 Nov 2011 21:34:31 -0500, John Gilmore wrote:
>
> I took such a view lately. In an ISPF edit macro I enabled
> tracing of all errors. But I needed to determine the size of
> the file being edited, even though it might be empty. I could
> find no way to detect that the file was empty
On Mon, 28 Nov 2011 21:34:31 -0500, John Gilmore wrote:
>My first post does not reflect disapproval of the JOBRC= facility as
>such. It has entirely legitimate uses. My intent was only to note
>that it will, inevitably, be misused and, inter alia, to express
>disapproval of the OP's notion of ho
On Tue, 29 Nov 2011 10:53:20 -0600, Paul Gilmartin wrote:
>
>I took such a view lately. In an ISPF edit macro I enabled
>tracing of all errors. But I needed to determine the size of
>the file being edited, even though it might be empty. I could
>find no way to detect that the file was empty wi
Sounds good to me. Are you going to propose it?
>
> From: Paul Gilmartin
>To: IBM-MAIN@bama.ua.edu
>Sent: Monday, November 28, 2011 6:48 PM
>Subject: Re: SETTING CONDITION CODE
>
>On Mon, 28 Nov 2011 17:17:13 -0800, Frank Swarbrick
>
In <1099851805226441.wa.paulgboulderaim@bama.ua.edu>, on
11/28/2011
at 09:01 PM, Paul Gilmartin said:
>What!? You find Ted more irritating than me?
He's not the only one.
>I must not be trying hard enough.
That's the problem; you try while he is trying.
--
Shmuel (Seymour J.)
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Gilmore
> Sent: Monday, November 28, 2011 4:39 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: SETTING CONDITION CODE
>
> Jack Schudel has made the cruc
On Mon, 28 Nov 2011 10:15:52 -0800, John Dawes wrote:
>G'Day,
Can I override a condition code so as to force it to a ? For example the
job-step executes successfully and puts out a COND CODE=0002. The job
continues on to the next step which is what we want. The reason I need a
in
On Mon, 28 Nov 2011 21:34:31 -0500, John Gilmore wrote:
>
>One of the artefacts of my new, all but uniformly better Google-based
>email support is that I am once again exposed to Mr MacNeil's jejune
>comments. I should wish not to see them, but all of the mechanism
>for excluding them that I have
My first post does not reflect disapproval of the JOBRC= facility as
such. It has entirely legitimate uses. My intent was only to note
that it will, inevitably, be misused and, inter alia, to express
disapproval of the OP's notion of how to asolve his problem.
All useful facilities lend themselv
IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of John Dawes
Sent: Monday, November 28, 2011 1:16 PM
To: IBM-MAIN@bama.ua.edu
Subject: SETTING CONDITION CODE
G'Day,
Can I override a condition code so as to force it to a ? For example
the job-step executes successfully and
On Mon, 28 Nov 2011 17:17:13 -0800, Frank Swarbrick
wrote:
>Now that's a nice enhancement. This, along with the allowing of instream
>datasets in a PROC, gives me hope that IBM is open to further improvements to
>JCL!
>
How about symbol substitution in instream datasets in a PROC next?
(Provi
28, 2011 3:13 PM
>Subject: Re: SETTING CONDITION CODE
>
>If you are running at the z/OS 1.13 level there are new options on the JOB
>card for letting you decide which COND CODE gets reported. (Highest, last, or
>a named step.)
>
>See the JOB CARD section of the JCL Reference
On Mon, 28 Nov 2011 13:04:01 -0600, McKown, John wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List
>> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes
>> Sent: Monday, November 28, 2011 12:16 PM
>> To: IBM-MAIN@bama.ua.edu
>
>With the availability of the JOBRC= parameter on the JOB statement, any job,
>however troubled, can have RC=0. One simply begins it with a step, call it
>MISLEAD. that executed an innocuous program, a certain wrell known do-nothing
>IBM utility will do, and specifies the stepname MISLEAD in th
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of John Gilmore
> Sent: Monday, November 28, 2011 5:39 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: SETTING CONDITION CODE
>
> Jack Schudel has made the cruc
a.ua.edu] On
> Behalf Of John Dawes
> Sent: Monday, November 28, 2011 1:16 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: SETTING CONDITION CODE
>
> G'Day,
>
> Can I override a condition code so as to force it to a ? For example
> the job-step executes successfully a
Jack Schudel has made the crucial point.
With the availability of the JOBRC= parameter on the JOB statement,
any job, however troubled, can have RC=0. One simply begins it with a
step, call it MISLEAD. that executed an innocuous program, a certain
wrell known do-nothing IBM utility will do, and s
Message -
From: "John Dawes"
Newsgroups: bit.listserv.ibm-main
To:
Sent: Monday, November 28, 2011 1:15 PM
Subject: SETTING CONDITION CODE
G'Day,
Can I override a condition code so as to force it to a ? For example
the job-step executes successfully and puts out a COND
Here is the JCL to execute TSOBATCH:
//jobname JOB account,'your job card',CLASS=X,MSGCLASS=X, etc
//TSOBATCH EXEC PGM=IKJEFT01,DYNAMNBR=50
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN DD *
EXEC 'userid.CLIST(member)'
(replace with library and member
IT Consultant | cgrant...@ameritas.com
5900 O Street, Lincoln NE 68510 | p: 402-467-7382 | c: 402-429-3579 | f:
402-325-4030
John Dawes
Sent by: IBM Mainframe Discussion List
11/28/2011 12:35 PM
Please respond to
IBM Mainframe Discussion List
To
IBM-MAIN@bama.ua.edu
cc
Subject
Re: SE
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes
> Sent: Monday, November 28, 2011 12:16 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: SETTING CONDITION CODE
>
> G'Day,
>
Mike,
No, I am not aware of this (TSO batch job). Would you have an example which I
could try?
From: Mike Schwab
To: IBM-MAIN@bama.ua.edu
Sent: Monday, 28 November 2011 1:22 PM
Subject: Re: SETTING CONDITION CODE
The IDCAMS logic only applies to the various
, November 28, 2011 1:16 PM
To: IBM-MAIN@bama.ua.edu
Subject: SETTING CONDITION CODE
G'Day,
Can I override a condition code so as to force it to a ? For example the
job-step executes successfully and puts out a COND CODE=0002. The job
continues on to the next step which is what we want.
The IDCAMS logic only applies to the various commands within the IDCAMS step.
Have your tried a TSO Batch job, with proceeding allocate and follow
free statements, followed by the TSO Clist statements to check and set
the condition codes (same as your example)?
On Mon, Nov 28, 2011 at 12:15 PM, J
G'Day,
Can I override a condition code so as to force it to a ? For example the
job-step executes successfully and puts out a COND CODE=0002. The job
continues on to the next step which is what we want. The reason I need a
instead of a 0002 is because I get paged because the operat
29 matches
Mail list logo
