Why? My understanding is that you can retrieve an SVC dump from SPOOL and
process it in IPCS. As long as it is in a hold class, what problems does it
cause?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List
IEAVTABX.
Real time, when there is a dump.
Check if SYSMDUMP is to SYSOUT, and then suppress it.
On Tue, 22 Sep 2020 12:11:43 + Mark Jacobs
<0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
:>We have developers who put SYSMDUMP output to SYSOUT rather than a dataset.
I'm looking at
Hello all,
to resolve the case Problem I use linemac available at CBT 961. Thanks to Yves,
there is a command called JU (JCL upper), so only JCL is modified, comments
remain as they are. Here is the orignal help of it:
! === Other Commands ==
! JU
__
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, April 9, 2020 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL & UNIX coding.
On Thu, 9 Apr 2020 07:02:26 -0500, John McKown wrot
_
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, April 9, 2020 1:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: JCL & UNIX coding.
On Thu, 9 Apr 2020 16:24:24 +
Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Thursday, April 9, 2020 1:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL & UNIX coding.
ISPF edit line commands.
On Thu, 9 Apr 2020 20:29:27 +0300, ITschak Mugzach wrote:
>Submit command (ispf & tso) can be replaced by a program that will fold yo
>uppercase, depending on content (dir names bs dataset names, etc.).
>
I have done something similar, primarily to relieve SUBMIT's archaic
Fixed-80 constraint.
9, 2020 10:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL & UNIX coding.
On Thu, 9 Apr 2020 10:07:50 -0700, Charles Mills wrote:
>
>When what I would like is
>
>//SYSPRINT DD SYSOUT=*the blah blah report
>
>Need the "do what I meant" feature implemented i
Submit command (ispf & tso) can be replaced by a program that will fold yo
uppercase, depending on content (dir names bs dataset names, etc.).
ITschak
בתאריך יום ה׳, 9 באפר׳ 2020, 20:18, מאת Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu>:
> On Thu, 9 Apr 2020 10:07:50 -0700,
On Thu, 9 Apr 2020 10:07:50 -0700, Charles Mills wrote:
>
>When what I would like is
>
>//SYSPRINT DD SYSOUT=*the blah blah report
>
>Need the "do what I meant" feature implemented in ISPF edit.
>
Isn't there a JCL language profile that should do that? Does it
also highlight keywords in
ERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Thursday, April 9, 2020 9:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL & UNIX coding.
On Thu, 9 Apr 2020 08:33:50 -0700, Charles Mills wrote:
>I agree totally but FWIW I find that the line commands UC and UCC/UCC go a
>long way towar
On Thu, 9 Apr 2020 16:24:24 +, Pommier, Rex wrote:
>ISPF edit session line commands to convert the line or block of lines to
>uppercase.
>
Ah! Thanks. Not in my repertoire. I'm accustomed to typing
what I mean and shunning any system overrides.
"Line"? I say "prefix". Or am I
ISPF edit session line commands to convert the line or block of lines to
uppercase.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Thursday, April 9, 2020 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: JCL & UNIX co
On Thu, 9 Apr 2020 08:33:50 -0700, Charles Mills wrote:
>I agree totally but FWIW I find that the line commands UC and UCC/UCC go a
>long way toward making the process tolerable.
>
Context? ISPF Primary panel? TSO READY prompt? JCL? OMVS? Other (specify)?
(No habla UCC.)
I remember
I agree totally but FWIW I find that the line commands UC and UCC/UCC go a long
way toward making the process tolerable.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John McKown
Sent: Thursday, April 9, 2020 5:02 AM
To:
On Thu, 9 Apr 2020 07:02:26 -0500, John McKown wrote:
>
>So, I kind of wish that the JCL converter or interpreter would accept JCL
>in lower case. In particular, upper casing the JCL statements which are not
>inclosed in ticks. It would just make my life easier. I.E JCL should ignore
>case when
On 4/9/20 6:02 AM, John McKown wrote:
JCL should ignore
case when not in ticks.
Dragging z/OS kicking and screaming into the late 1970's.
--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the
Totally Agree !
Thank You!
Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144
Office Hours: M-F 7A - 3:45 pm
Out-Of-The-Office:
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
I liked having DD's in my proc, but I had a second one with no DD's like
you recommend. That saved the embarrassment of having to wander over to
another sysprog's desk with my head held low.
On 3/6/2020 10:20 AM, Steve Smith wrote:
IMHO, a TSO logon proc should have no (0, zero, none, nada,
It' s not my dog.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Steve Smith
Sent: Friday, March 6, 2020 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL error during TSO/E logon
IMHO
z3
> > >
> > >
> > > ____________
> > > From: IBM Mainframe Discussion List on
> behalf
> > > of ITschak Mugzach
> > > Sent: Friday, March 6, 2020 6:07 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > >
_
> > From: IBM Mainframe Discussion List on behalf
> > of ITschak Mugzach
> > Sent: Friday, March 6, 2020 6:07 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: JCL error during TSO/E logon
> >
> > You can used recycled paper as well... I thought no
Discussion List On Behalf Of
ITschak Mugzach
Sent: Friday, March 6, 2020 6:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: JCL error during TSO/E logon
CAUTION EXTERNAL EMAIL
Shmuel,
I did mentioned the need to have an allocation free TMP procedure. However, if
the OP can't login
/mason.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf
> of ITschak Mugzach
> Sent: Friday, March 6, 2020 6:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL error during TSO/E logon
>
> You can used recycled
@LISTSERV.UA.EDU
Subject: Re: JCL error during TSO/E logon
You can used recycled paper as well... I thought no one can login, so you
must use the console to modify stcclass and print to viee.
ITschak
בתאריך יום ו׳, 6 במרץ 2020, 13:05, מאת Seymour J Metz :
> Why kill a tree?
>
>
> --
> Sh
Actually just submit a JOB naming the logon PROC and see what happens. Just
be sure you have a message class that is saved to sysout
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jesse 1 Robinson
Sent: Thursday, March 5, 2020 5:09
on.gmu.edu/~smetz3
>
>
>
> From: IBM Mainframe Discussion List on behalf
> of ITschak Mugzach
> Sent: Friday, March 6, 2020 1:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL error during TSO/E logon
>
> Modify tso class in j
Why kill a tree?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
ITschak Mugzach
Sent: Friday, March 6, 2020 1:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL error during TSO/E logon
Modify tso class in jess to keep the joblog. Your operators can print it
for you to review the error
ITschak
בתאריך יום ו׳, 6 במרץ 2020, 1:08, מאת Jesse 1 Robinson <
jesse1.robin...@sce.com>:
> From the dawn of time, it was deucedly difficult to find the cause of a
> JCL error during TSO
Back in Ye Olde Days I had such a problem (very annoying when users would call
the support desk about these things).
We had a modified IKJEFLD that allowed overrides of PROCs and accounts without
requiring UADS entries.
What I did would call the accounting system to verify that the account was
On Thu, 5 Mar 2020 21:07:32 -0500, Tom Conley wrote:
>
>..., I've used the following JCL
>for years to check out procs that fail (typically my STC sysout goes to
>the bit bucket):
>
>//IBMUSERC JOB 'IBMUSER',
>// CLASS=A,
>// NOTIFY=,
>//
On 3/5/2020 6:08 PM, Jesse 1 Robinson wrote:
From the dawn of time, it was deucedly difficult to find the cause of a JCL
error during TSO logon. Then several releases ago, we were treated to a 'fix'.
The error would be displayed on the user's screen, allowing the problem to be
corrected
If your TSO JES2 definition has the output go to a queue in JES2 that is not
purged immediately, that is where I typically look.
Other option is to review the SAF setup for the TSO Logon Proc and then test
the Logon proc in your TSO Session. Or use a JCL Scanner to verify the proc
the user is
-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of CM
Poncelet
Sent: Tuesday, July 23, 2019 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: JCL disp on abend
... and "//DDIN DD DSN=file1,DISP=(OLD,DELETE
... and "//DDIN DD DSN=file1,DISP=(OLD,DELETE,KEEP)" states that file1
should be deleted regardless on jobstep termination *unless* it abends.
On 23/07/2019 06:24, Dan D wrote:
> "IEF142I TYC1DABK EDIOUT2 STEP02 - STEP WAS EXECUTED - COND CODE 0012"
>
> As you can see from the IEF142I the job
It's traditional for utility programs to trap abends and convert to a
return code. Whether that's a good idea or not is a classic moot point.
And it has been mooted for decades.
Generally, you would need to have conditional (likely IEFBR14) steps to
control the disposition of datasets. You
Thanks for the help!
Elaine
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, July 22, 2019 9:12:18 PM
Subject: Re: JCL disp on abend
'//EDIOUT2 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//DDIN DD DSN=file1,DISP=(OLD,DELETE,KEEP)
//DDOUT1 DD DSN=file2,
// DISP=(,CATLG),MGMTCLAS=MC60DY,
// LIKE=file1
//SYSIN DD DISP=SHR,DSN=PROCLI
"IEF142I TYC1DABK EDIOUT2 STEP02 - STEP WAS EXECUTED - COND CODE 0012"
As you can see from the IEF142I the job did NOT abend but rather IDCAMS ended
with a return code 12.
Dan
--
For IBM-MAIN subscribe / signoff / archive
'//EDIOUT2 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//DDIN DD DSN=file1,DISP=(OLD,DELETE,KEEP)
//DDOUT1 DD DSN=file2,
// DISP=(,CATLG),MGMTCLAS=MC60DY,
// LIKE=file1
//SYSINDD DISP=SHR,DSN=PROCLIB(AIBACKC1) --> sysin is just reporo in to
out
//*
When these abend with a
Elaine Beal wrote:
>We have a job that is coded as follows-
>step1 - idcams repro dummy in to file1,disp=(mod,catalg)
>step2 repro above (dummied) file1 , disp=(old,delete,keep) to file2
>disp=(,catlg)
>when we get a B37 on step2 file2, file1 is deleted even though it has
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, July 18, 2019 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL
COND Parameter)
I hope that he meant 2**X
From: IBM Mainframe Discussion List on behalf of
Clark Morris
Sent: Thursday, July 18, 2019 4:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
[Default] On 18 Jul 2019 09:42:13 -0700, in bit.listserv.ibm
y 18, 2019 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
[Default] On 18 Jul 2019 09:42:13 -0700, in bit.listserv.ibm-main
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:
>On Tue, 16 Jul
[Default] On 18 Jul 2019 09:42:13 -0700, in bit.listserv.ibm-main
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:
>On Tue, 16 Jul 2019 19:22:51 +, Seymour J Metz wrote:
>>
>>The cardinal sin in language design is to make the compiler simpler at the
>>expense of the
rame Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, July 18, 2019 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
On Thu, 18 Jul 2019 16:51:57 +, Seymour
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, July 18, 2019 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Par
On Thu, 18 Jul 2019 16:51:57 +, Seymour J Metz wrote:
>OOREXX now allows the equivalent of expressions in tails:
>
> stem[tail expression]
>
What are those strange characters, "[" and "]"? What are their EBCDIC code
points?
>If X is a floating point (REAL) variable, why shouldn't x**(-1)
://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Bernd Oppolzer
Sent: Wednesday, July 17, 2019 5:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
Am 17.07.2019 um 19:54
List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, July 18, 2019 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
On Tue, 16 Jul 2019 19:22:51 +, Seymour J Metz
On Tue, 16 Jul 2019 19:22:51 +, Seymour J Metz wrote:
>
>The cardinal sin in language design is to make the compiler simpler at the
>expense of the user. ...
>
I see a notable example of this in Rexx's not supporting expressions in compound
symbol tails which some have justified as making
On 7/17/19 9:55 AM, David Crayford wrote:
On 2019-07-16 4:44 AM, Tom Marchant wrote:
Some C programmers are fond of if (7 == foo) rather than the more
conventional if (foo == 7) because if one gets in the habit of doing
so and then accidentally codes if (7 = foo) one gets a compile error
On Wed, 17 Jul 2019 23:59:04 +0200, Bernd Oppolzer wrote:
>
>One program had a coding like this:
>
> IF 9 < ZZ < 20 THEN DO;
> ...
There's an argument here for strong typing, prohibiting comparing
a boolean to a numeric without a cast.
> ... Obviously this is not what the coder intended;
Am 17.07.2019 um 19:54 schrieb Paul Gilmartin:
On Wed, 17 Jul 2019 12:22:35 -0400, Steve Smith wrote:
The original sin was making "=" the assignment operator. I guess we can
blame that on FORTRAN, and it must make mathematicians cringe still.
I once (ca. 1967) needed to enlighten and
On Wed, 17 Jul 2019 12:22:35 -0400, Steve Smith wrote:
>The original sin was making "=" the assignment operator. I guess we can
>blame that on FORTRAN, and it must make mathematicians cringe still.
>
I once (ca. 1967) needed to enlighten and disillusion a naive
but persistent physics graduate
Mainframe Discussion List Im Auftrag von
John McKown
Gesendet: Wednesday, July 17, 2019 19:09
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
On Wed, Jul 17, 2019 at 11:59 AM Seymour J Metz wrote:
> That's an excuse for Fo
-
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List on behalf
> of John McKown
> Sent: Wednesday, July 17, 2019 12:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Where put t
McKown
Sent: Wednesday, July 17, 2019 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
On Wed, Jul 17, 2019 at 11:23 AM Steve Smith wrote:
> The original sin was making "=" the assignment operator. I guess w
On Wed, Jul 17, 2019 at 11:23 AM Steve Smith wrote:
> The original sin was making "=" the assignment operator. I guess we can
> blame that on FORTRAN, and it must make mathematicians cringe still.
>
I haven't said anything, but I think you're correct. Of course, in the "bad
old days" of punch
.ua.edu>
Sent: Tuesday, July 16, 2019 4:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
On Tue, 16 Jul 2019 21:37:38 +0200, Bernd Oppolzer wrote:
>Am 16.07.2019 um 21:22 schrieb Seymour J Metz:
>>> Furthermore:
The original sin was making "=" the assignment operator. I guess we can
blame that on FORTRAN, and it must make mathematicians cringe still.
sas
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
On 2019-07-16 4:44 AM, Tom Marchant wrote:
Some C programmers are fond of if (7 == foo) rather than the more conventional
if (foo == 7) because if one gets in the habit of doing so and then
accidentally codes if (7 = foo) one gets a compile error rather than unexpected
behavior.
For those
https://en.wikipedia.org/wiki/Pascal_MicroEngine
In a message dated 7/16/2019 6:02:25 PM Central Standard Time,
bernd.oppol...@t-online.de writes:
and Pascal :-)
Pascal makes the same difference between := (assignment) and = (comparison)
So does C.
On Tue, 16 Jul 2019 22:36:43 +0200, Bernd Oppolzer wrote:
>>>
>>> I added BREAK, CONTINUE, RETURN, MODULE, LOCAL and STATIC;
>>> this was in the years from 2011 to 2016. No more need since.
>>>
>> I've done many of these as predefined quasi-identifiers, similar to Pascal's
>> predefined standard
Am 16.07.2019 um 22:16 schrieb Paul Gilmartin:
On Tue, 16 Jul 2019 21:37:38 +0200, Bernd Oppolzer wrote:
Am 16.07.2019 um 21:22 schrieb Seymour J Metz:
Furthermore: the more modern languages like Pascal, C and Java etc.
forbid the use of reserved symbols as variable names. This may be
On Tue, 16 Jul 2019 21:37:38 +0200, Bernd Oppolzer wrote:
>Am 16.07.2019 um 21:22 schrieb Seymour J Metz:
>>> Furthermore: the more modern languages like Pascal, C and Java etc.
>>> forbid the use of reserved symbols as variable names. This may be
>>> restrictive, but makes the compilers much
Am 16.07.2019 um 21:22 schrieb Seymour J Metz:
Furthermore: the more modern languages like Pascal, C and Java etc.
forbid the use of reserved symbols as variable names. This may be
restrictive, but makes the compilers much much simpler.
The cardinal sin in language design is to make the
u/~smetz3
From: IBM Mainframe Discussion List on behalf of
Bernd Oppolzer
Sent: Tuesday, July 16, 2019 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
Space is permitted almost everywhere in PL/1,
not in the middle of id
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
This double meaning of =, together with the absence of reserved words
makes PL/1 parsing extremely hard. Consider for example
IF (1) = (2);
now what does that mean?
Given a declaration
DCL IF (25) BIN FIXED (31
uly 16, 2019 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
Am 16.07.2019 um 20:40 schrieb Seymour J Metz:
>> Pascal makes the same difference between := (assignment) and = (comparison)
> Pascal is a castr
Am 16.07.2019 um 20:40 schrieb Seymour J Metz:
Pascal makes the same difference between := (assignment) and = (comparison)
Pascal is a castrated version of Algol 60,
Hmmm ... the only feature that Pascal lacks IMO is call-by-name,
but this is something not easy to understand (and explain) to
"=" is much less likely.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Bernd Oppolzer
Sent: Tuesday, July 16, 2019 2:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the noti
.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Bernd Oppolzer
Sent: Tuesday, July 16, 2019 2:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL
tserv.ua.edu>
Sent: Monday, July 15, 2019 4:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
On Mon, 15 Jul 2019 13:30:51 -0700, Charles Mills wrote:
Some C programmers are fond of if (7 == foo) rather than the more c
This double meaning of =, together with the absence of reserved words
makes PL/1 parsing extremely hard. Consider for example
IF (1) = (2);
now what does that mean?
Given a declaration
DCL IF (25) BIN FIXED (31);
that is, if IF is an array of integers, the "IF" statement above is a
valid
equ...@listserv.ua.edu>
Sent: Monday, July 15, 2019 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL COND Parameter
On Mon, 15 Jul 2019 16:51:43 +0100, CM Poncelet wrote:
>If '//STEP000 EXEC PGM=IEFBR14' is commented out, then 'STEPA030' will
>execute with CC=00 instead of NXEQ'd.*
ur J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of Tom
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Monday, July 15, 2019 4:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional consta
Of Tom Marchant
Sent: Monday, July 15, 2019 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND
Parameter)
On Mon, 15 Jul 2019 13:30:51 -0700, Charles Mills wrote:
>Some C programmers are fond of if (7 == foo) rather than the m
On Mon, 15 Jul 2019 13:30:51 -0700, Charles Mills wrote:
>Some C programmers are fond of if (7 == foo) rather than the more conventional
>if (foo == 7) because if one gets in the habit of doing so and then
>accidentally codes if (7 = foo) one gets a compile error rather than
>unexpected
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Monday, July 15, 2019 11:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL COND Parameter
On Mon, 15 Jul 2019 16:51:43 +0100, CM Poncelet wrote:
>If '//STEP
Think of it as "execute this step *unless*
COND=(CC,is{GT|GE|EQ|LT|LE}[{,some prior step|any prior step}]) is true".
Bear in mind that COND= will not apply to prior step(s) that were not
executed.
E.g.
"STEP000 EXEC PGM=IEFBR14" will execute with CC=00.
"STEP010 EXEC
On Mon, 15 Jul 2019 16:51:43 +0100, CM Poncelet wrote:
>If '//STEP000 EXEC PGM=IEFBR14' is commented out, then 'STEPA030' will
>execute with CC=00 instead of NXEQ'd.*
>*
Of course you're right. I was misled by a strong habit I have. When coding
tests, I try to put the notional variable on the
On Mon, 15 Jul 2019 18:56:09 +0100, CM Poncelet wrote:
>The '//STEPA030 EXEC PGM=IEFBR14,COND=(7,GT)' NXEQ'S because 7 is GT the
>CC=00 from '//STEP000 EXEC PGM=IEFBR14' (regardless of the CC=16 from
>STEP010) - so STEPA030 *does not* execute.
>
>If STEP000 is commented out, the only previous
OND checking in STEPA040.
Rex
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Monday, July 15, 2019 12:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: JCL COND Parameter
On Mon, 15 Jul 2019 16:51:43 +0100, CM Poncelet wrote:
>If '//STEP0
The '//STEPA030 EXEC PGM=IEFBR14,COND=(7,GT)' NXEQ'S because 7 is GT the
CC=00 from '//STEP000 EXEC PGM=IEFBR14' (regardless of the CC=16 from
STEP010) - so STEPA030 *does not* execute.
If STEP000 is commented out, the only previous step is then STEP010 and
it has CC=16, and 7 is not GT than 16,
On Mon, 15 Jul 2019 16:51:43 +0100, CM Poncelet wrote:
>If '//STEP000 EXEC PGM=IEFBR14' is commented out, then 'STEPA030' will
>execute with CC=00 instead of NXEQ'd.*
>*
I don't see that. From the JCL Ref.:
If you omit stepname, the code you specify is compared to the return codes
from
gt; --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List on behalf of
> Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Friday, July 12, 2019 3:41 PM
> To: IBM
10
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL COND Parameter
>
> COND= was invented by a Sadist.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Brennan
> Se
[External] Re: JCL COND Parameter
On 2019-07-13 10:42 AM, Steve Smith wrote:
> Whenever
> multiple CONDs are present, I'm lost. Is it OR or AND and is that in
> the positive or negative sense?
When I started I was told:
Always say "Bypass this step if" and then begin readin
ObPrinessBride What gives you that idea?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Lizette Koehler
Sent: Friday, July 12, 2019 4:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL COND
On Behalf Of
Charles Mills
Sent: Saturday, July 13, 2019 9:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: JCL COND Parameter
COND= was invented by a Sadist.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Brennan
COND= was invented by a Sadist.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Brennan
Sent: Friday, July 12, 2019 6:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL COND Parameter
I always guessed COND
On 2019-07-13 10:42 AM, Steve Smith wrote:
Whenever
multiple CONDs are present, I'm lost. Is it OR or AND and is that in the
positive or negative sense?
When I started I was told:
Always say "Bypass this step if" and then begin reading the COND parameter.
Cheers,
Greg
I always guessed COND= was invented by someone who took a Boolean Logic
or Digital Electronics class, where I once heard that negative logic
NAND/NOR ends up with less logic or hardware than AND/OR.
On 7/12/2019 5:41 PM, Steve Smith wrote:
As a long-time assembler programmer and JCL wrangler,
As a long-time assembler programmer and JCL wrangler, I absolutely think
that COND is backwards, confusing, and the opposite of intuitive. Whenever
multiple CONDs are present, I'm lost. Is it OR or AND and is that in the
positive or negative sense?
The new* IF / ELSE / ENDIF statements are an
On Fri, 12 Jul 2019 13:05:59 -0700, Lizette Koehler wrote:
>Older JCL Condition Code checking was based on RPN _ Revere Polish Notation
>
Doesn't appear that way to me. In Polish Postfix (RPN, _ Revere Polish
Notation)
I'd expect to see not COND=(7,GT,STEP010)
but:
Older JCL Condition Code checking was based on RPN _ Revere Polish Notation
You can use the newer
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab600/ifuse.htm
//[name] IF [(]relational-expression[)] THEN [comments]
.
.action when
On Fri, 12 Jul 2019 18:50:00 +, Edgington, Jerry wrote:
>Condition code testing in JCL, has always seemed backward logic to me.
>
I suspect it's intuitive to an Assembler programmer accustomed to
branching *around* a section of code.
>But, as I understand it, maybe, the reason STEPA030
STEP000 executes as expected with CC=00.
STEP010 executes as expected with CC=16.
STEPA030 does not execute because CC=07 *is* greater than the CC=00 of
STEP000.
STEPA040 does execute because CC=07 *is not* greater than the CC=16 of
STEP010.
HTH Chris Poncelet (retired sysprog)
On 12/07/2019
Yes, you specify under which condition(s) to NOT run.
On Fri, Jul 12, 2019 at 6:44 PM Tony Sambataro
wrote:
>
> Having a discussion at our site as to how the jcl below should execute as far
> a cond code handling. I believe the two steps with COND= coded should both
> execute. But in my test
201 - 300 of 718 matches
Mail list logo
