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 movem
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 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
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 e
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 vari
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 a
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. Overri
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 intu
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?
Possi
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 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 wa
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.
>>
>
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" documenta
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, i
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 D
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 wa
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 messa
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 su
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
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 recentl
On Mon, Jul 21, 2008 at 3:18 PM, McKown, John
<[EMAIL PROTECTED]> wrote:
> I agree, in part. I tried to use DisplayWrite/370. . 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 neces
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'
> -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 -0700, in bit.listserv.ibm-main you wrote:
>
>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?
>---
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?
-
Bet your sweet "bippy".
> -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
---
... or a DC-3. But like them, it still works.
--
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
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
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 actu
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
> 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 Beh
> -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
> >
> -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 install
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
Wha
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
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 lo
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
erro
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, h
D STATEMENT are getting what
they deserve. :)
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Bruno Sugliani
Sent: Thursday, July 17, 2008 7:46 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Example of what a very small JCL Interpreter can do to your
in
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
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 0
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
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 th
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
