Peter Relson wrote:
>I on the other hand do have sympathy. A highly significant reason that
>z/OS still exists (and the same could have been said for its
>predecessors OS/390 and MVS) is because of the enormous amount of time
>and effort we have put into maintaining as much compatibility as we
That should just be made a syntax error. I have no sympathy for the
"compatibility" argument.
I on the other hand do have sympathy. A highly significant reason that z/OS
still exists (and the same could have been said for its predecessors OS/390 and
MVS) is because of the enormous amount of t
On Wed, 11 Oct 2023 15:44:39 +, Peter Relson wrote:
>
>As it happens, the offending sentence had already been removed from the 3.1
>book. Since the thread started before those books were generally available to
>be looked at, it's not surprising that that was not realized.
>
I see that. Than
Paul G wrote
I fear "unpredictable" is too often the writers' excuse when they don't know
the answer to a request for clarification and can't find out.
I don't think you will find that that is true in z/OS books. Writers do not
make up usage of that word. They are asked to do so because the dev
Processing date from control card input is endemic to the financial
industry, not just banks.
I believe it stems from the fact that "daily" processing occurs after midnight,
Michael
At 11:08 AM 10/8/2023, Paul Gilmartin wrote:
On Sat, 7 Oct 2023 22:30:52 +0200, Radoslaw Skorupka wrote:
>To
On Sat, 7 Oct 2023 22:30:52 +0200, Radoslaw Skorupka wrote:
>To be honest I consider date-related variables as pooor when
>compared to batch scheduler features, especially ControlM (it is not
>advertisement, just opinion).
>
You worked for a bank.
I had a co-worker who had worked for a bank.
On Sat, 7 Oct 2023 18:42:42 +, Farley, Peter wrote:
>I’ll admit I have NOT used symbol substitution in the “name” part (left of the
>“=”) at all, only on the right (value) side, so the true answer is “I don’t
>know”. Never had a reason to use substitution in the “name” part.
>
However infre
On Sat, 7 Oct 2023 13:10:36 -0500, Michael Oujesky wrote:
>Dynamic symbols (date/time) can be evaluated at different points in
>time during conversion, so if used multiple time in the JCL, they can
>resolve to different values. My ROT was to never use a dynamic
>symbol more that once in coding a
ctober 7, 2023 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E
needed for installs?]
On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote:
On 9/20/2023 8:23 AM, Farley, Peter wrote:
... JCL symbols as part of the definition of othe
that need.
When I get a chance I will try the new feedback process.
Peter
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Saturday, October 7, 2023 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E
needed for
Dynamic symbols (date/time) can be evaluated at different points in
time during conversion, so if used multiple time in the JCL, they can
resolve to different values. My ROT was to never use a dynamic
symbol more that once in coding and where it was needed multiple
time, set it to my own date
On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote:
>On 9/20/2023 8:23 AM, Farley, Peter wrote:
>> ... JCL symbols as part of the definition of other JCL symbols works
>> flawlessly every time.
>
Is this true alike for substitution both in the name (left of the "=")
and in the value (right of the
On 9/20/2023 8:23 AM, Farley, Peter wrote:
I believe that statement in the JCL Reference is in error and needs to be deleted
or at the very least completely rewritten. My quite substantial experience using
this technique over the last 10-15 years is that using JCL symbols as part of the
defin
Farley, Peter wrote:
>I believe that statement in the JCL Reference is in error and needs to
>be deleted or at the very least completely rewritten. My quite
>substantial experience using this technique over the last 10-15 years
>is that using JCL symbols as part of the definition of other JCL
>symb
Thanks for changing the Subject: as the topic drifted.
On Wed, 20 Sep 2023 15:23:31 +, Farley, Peter wrote:
>I believe that statement in the JCL Reference is in error and needs to be
>deleted or at the very least completely rewritten. My quite substantial
>experience using this technique o
I believe that statement in the JCL Reference is in error and needs to be
deleted or at the very least completely rewritten. My quite substantial
experience using this technique over the last 10-15 years is that using JCL
symbols as part of the definition of other JCL symbols works flawlessly e
16 matches
Mail list logo
