On Wed, 30 Jul 2008 08:57:49 -0500, Jeff Holst wrote:
Problem came when the 370 arrived and we upgraded to a new COBOL
compiler. Now, a character moveof more that 256 characters were compiled
as a MVCL. For MVCL, when source and target fields overlap, a condition code
is set and no data movement
On Wed, 30 Jul 2008 09:02:48 -0500, Jeff Holst wrote:
On Tue, 29 Jul 2008 09:45:44 -0500, Paul Gilmartin wrote:
Hmmm. I wonder what happens when there are two (or more) overriding
DD statements referring to the same DDNAME in the PROC. Absent any
explicit exclusion, I'd expect from the general
On Wed, 30 Jul 2008 08:57:49 -0500, Jeff Holst wrote:
IBM's out was that they had said that the results of the overlappping MOVE
were unpredictable, so this did not violate their compatablity statement that
programs would be source level compatable if they were coded according to
the language
On Tue, 29 Jul 2008 10:05:15 -0500, Paul Gilmartin [EMAIL PROTECTED]
wrote:
Copout! This is irresponsible language design. If the JCL developers
had any pride of craftsmanship, they would remove all references to
unpredictable and unsupported from the language specification
by variously
On Tue, 29 Jul 2008 09:45:44 -0500, Paul Gilmartin [EMAIL PROTECTED]
wrote:
Hmmm. I wonder what happens when there are two (or more) overriding
DD statements referring to the same DDNAME in the PROC. Absent any
explicit exclusion, I'd expect from the general description both (all)
to be
On Mon, 28 Jul 2008 15:58:53 EDT, IBM Mainframe Discussion List wrote:
In a message dated 7/28/2008 10:55:50 A.M. Central Daylight Time,
PaulG writes:
I certainly remember (though obviously not as clearly as Mr. Blair)
a day and age when overriding DD statements were required to appear
in the
In a message dated 7/29/2008 3:25:25 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Suppose someone who does not know that proc X is used by 10 other jobs with
overriding DDs in them decides to rearrange the DD statements within proc
X.
Why ever would anyone do that?
Possible
On Mon, 28 Jul 2008 10:55:40 -0500, Paul Gilmartin [EMAIL PROTECTED]
wrote:
I'll sometimes disable a lot of JCL with IF. Which is why I regret
that IF FALSE is documented as not supported and unpredictable
in behavior (although no error is reported and the construct has
(almost) the intuitive
On Thu, 24 Jul 2008 15:56:17 -0500, Jeff Holst wrote:
However, on page 5-4 of that same manual it says:
Place modifying OUTPUT JCL and DD statements in the following order, after
the EXEC statement that calls the procedure:
For each procedure step in the invoked procedure:
1. Overriding
On Tue, 29 Jul 2008 09:18:54 -0500, Jeff Holst wrote:
On Mon, 28 Jul 2008 10:55:40 -0500, Paul Gilmartin wrote:
I'll sometimes disable a lot of JCL with IF. Which is why I regret
that IF FALSE is documented as not supported and unpredictable
in behavior (although no error is reported and the
On Fri, 25 Jul 2008 17:56:35 -0500, William H. Blair
[EMAIL PROTECTED] wrote:
Jeff Holst noted that an IBM SRL states:
1. Overriding statements can appear in any order when
they explicitly specify the step that is being
overridden.
This is apparently the missing documentation.
On Mon, 28 Jul 2008 09:22:03 -0500, Jeff Holst wrote:
On Fri, 25 Jul 2008 17:56:35 -0500, William H. Blair wrote:
Jeff Holst noted that an IBM SRL states:
1. Overriding statements can appear in any order when
they explicitly specify the step that is being
overridden.
If you go on to
In a message dated 7/28/2008 10:55:50 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
I certainly remember (though obviously not as clearly as Mr. Blair)
a day and age when overriding DD statements were required to appear
in the same order as the overridden DDNAMEs in the proc. I
Jeff Holst noted that an IBM SRL states:
1. Overriding statements can appear in any order when
they explicitly specify the step that is being
overridden.
This is apparently the missing documentation. However,
it is not completely technically correct, because it is
obviously not, in
In
[EMAIL PROTECTED],
on 07/16/2008
at 08:43 PM, John Mattson [EMAIL PROTECTED] said:
Perfect example of a program being TOO HELPFUL.
If it's changing the order then it's not helpful, just wrong.
So, is this a bug or working as designed?
Did you report it? It sure sounds like a bug.
In [EMAIL PROTECTED], on 07/17/2008
at 03:54 PM, Matthew Stitt [EMAIL PROTECTED] said:
The confusing issue was begun a very long time ago. If there is apparent
input data with no specific DD statement to match it up with, there was a
SYSIN dd statement generated above it. Until recently,
In [EMAIL PROTECTED], on
07/17/2008
at 12:05 PM, Gibney, Dave [EMAIL PROTECTED] said:
I guess this shouldn't have changed for the sake of backass
compatibility. But, I've always been bothered (and debugged application
JCL) when overrides didn't match the order in procs (and the messages
In [EMAIL PROTECTED], on 07/17/2008
at 02:21 AM, William H. Blair [EMAIL PROTECTED] said:
Regardless, IT'S STILL DOCUMENTED TO WORK THE OLD WAY. Since it is hard
for me to believe that this behavior is not intentional, you probably
have as your only recourse a Readers' Comments form submission
In [EMAIL PROTECTED], on 07/17/2008
at 08:55 PM, Paul Gilmartin [EMAIL PROTECTED] said:
Now advancing technology has relieved those
constraints and IBM is DTRT in making JCL infinitesimally closer to what
it should have been from the beginning.
Not all change is progress. This change was ill
On Thu, 17 Jul 2008 02:21:29 -0500, William H. Blair
[EMAIL PROTECTED] wrote:
Note that page 12-14 of the z/OS V1R9.0 MVS JCL Reference SRL
_still_ states:
To override more than one DD statement in a procedure, place the
overriding DD statements in the same order as the overridden DD
On Mon, Jul 21, 2008 at 3:18 PM, McKown, John
[EMAIL PROTECTED] wrote:
I agree, in part. I tried to use DisplayWrite/370. shudder. But the
main problem, as usual, is management. The mainframe has been around a
long time. We have a lot of policies and procedures. Some of which are
good and
Wow, I thought I had been called everything in the book, but this
is the first time for: lacking in referential transparency. I think I
actually like it. No doubt my wife would agree with this evaluation, and
add a few creative epithets of her own.
As I said before about JCL.
---snip
... or a DC-3. But like them, it still works.
--unsnip
The durability of the DC-3 saved my a** in Viet Nam three times; I'd
really hate to see anyone bash it. It's old and
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman
Sent: Monday, July 21, 2008 1:16 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Example of what a very small JCL Interpreter can
do to your installation.
snip
Unlikely today's programs which tend to crash quickly and often. Not
mentioning any particular OS, but you can see through that, can't you?
---unsnip--
Bet your sweet
On 21 Jul 2008 11:32:07 -0700, in bit.listserv.ibm-main you wrote:
snip
Unlikely today's programs which tend to crash quickly and often. Not
mentioning any particular OS, but you can see through that, can't you?
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris
Sent: Monday, July 21, 2008 2:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Example of what a very small JCL Interpreter can
do to your installation.
On 21 Jul 2008 11:32:07
On 21 Jul 2008 11:26:40 -0700, [EMAIL PROTECTED] (McKown,
John) wrote:
The durability of the DC-3 saved my a** in Viet Nam three times; I'd
really hate to see anyone bash it. It's old and slow, but it still
works very well.
The same holds true of an awful lot of programs; they're old and
On Thu, 17 Jul 2008 20:55:10 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote:
I have long been in the habit of using:
//HIDDEN DD * (text to be ignored)
All the unprocessed text
that I want.
I think this makes my intent far more clear than relying on your
What's wrong
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave
Sent: Thursday, July 17, 2008 2:05 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Example of what a very small JCL Interpreter can
do to your installation.
I guess this
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
On Thu, 17 Jul 2008 20:55:10 -0500, Paul Gilmartin wrote:
I have long been in the habit of using:
//HIDDEN DD * (text to be ignored)
All the unprocessed text
that I
Date: Fri, 18 Jul 2008 09:47:14 -0500
From: [EMAIL PROTECTED]
Subject: Re: Example of what a very small JCL Interpreter can do to your
installation.
To: IBM-MAIN@BAMA.UA.EDU
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
On Thu, 17 Jul 2008
On Fri, 18 Jul 2008 07:47:20 -0500, Mark Zelden wrote:
On Thu, 17 Jul 2008 20:55:10 -0500, Paul Gilmartin wrote:
I have long been in the habit of using:
//HIDDEN DD * (text to be ignored)
All the unprocessed text
that I want.
I think this makes my intent far more
On Thu, 17 Jul 2008 20:55:10 -0500, Paul Gilmartin
[EMAIL PROTECTED] wrote:
...
o Duplicate DDNAMEs within a step should be treated as a JCL error.
(I understand JES3 already does this.) This itself would have
blocked the pitfall described in this thread.
...
I've seen jobs that actually
John Mattson wrote:
Somewhere between OS390 2.10 (our old system) and zos 1.08 (our
new system) the JCL interpreter changed.
Funny you should notice that ... was wondering if anybody would.
The change was first introduced in z/OS 1.8. It worked the old way
in z/OS 1.7. When I first found
On Wed, 16 Jul 2008 20:43:03 -0700, John Mattson [EMAIL PROTECTED]
wrote:
There has been some talk about changing JCL interpretation. Sure
it is old, and ugly, but we are used to it, and it does work. Here is
what happened going from os390 to zos 1.08
Somewhere between OS390
How on earth can IBM make a change as significant as this and not even document
the change in behavior? I can imagine this affecting many job streams with
negative consequences.
Mark Zelden [EMAIL PROTECTED] 7/17/2008 8:54 AM
APAR Identifier .. OA12842 Last Changed 08/06/10
On Thu, 17 Jul 2008 10:37:50 -0400, Scott Rowe [EMAIL PROTECTED] wrote:
How on earth can IBM make a change as significant as this and not even
document the change in behavior? I can imagine this affecting many job
streams with negative consequences.
May occur if a SYSIN DD * statement is
I guess this shouldn't have changed for the sake of backass
compatibility. But, I've always been bothered (and debugged application
JCL) when overrides didn't match the order in procs (and the messages
there were almost non-existent).
Folks relying in //SYSIN DD * GENERATED STATEMENT are
I'm confused. Are you saying that APAR OA12842 broke it? or that it fixed
it? It looks to me like they fixed a problem.
It says
The solution for this APAR has been shipped in the base code of
z/OS 1.8 (HBB7730), JES2 1.8 (HJE7730) and JES3 1.8 (HJS7730).
If I understood the original poster,
The confusing issue was begun a very long time ago. If there is apparent
input data with no specific DD statement to match it up with, there was a
SYSIN dd statement generated above it. Until recently, that extraneous
SYSIN dd statement had no effect on the JCL except to prevent either a JCL
Dave Gibney wrote:
Folks relying in //SYSIN DD * GENERATED STATEMENT are getting
what they deserve. :)
You didn't read everything I wrote. This has nothing to do with
the automatically-generated //SYSIN DD * statement. Explicit DD
statements are being reordered. What is happening happens
On Thu, 17 Jul 2008 02:21:29 -0500, William H. Blair wrote:
But, 42 years of experience with IBM tells me that this is how
it is going to be, so I'm going to have to find some other way
of hiding in-stream data sets. (You're not the only one to
use this technique. It's not unheard of. I've seen
There has been some talk about changing JCL interpretation. Sure
it is old, and ugly, but we are used to it, and it does work. Here is
what happened going from os390 to zos 1.08
Somewhere between OS390 2.10 (our old system) and zos 1.08 (our
new system) the JCL interpreter
44 matches
Mail list logo
