On Thu, 11 Apr 2013 22:17:31 -0400, Shmuel Metz (Seymour J.) wrote:
on 04/10/2013 at 08:27 AM, Paul Gilmartin said:
On Wed, 10 Apr 2013 08:52:55 -0400, Shmuel Metz (Seymour J.) wrote:
on 04/07/2013 at 04:57 PM, Sam Siegel said:
diff3 allows a 3 way merge between the original source and 2
In 5227567289602393.wa.paulgboulderaim@listserv.ua.edu, on
04/12/2013
at 01:48 AM, Paul Gilmartin paulgboul...@aim.com said:
Sam said diff3 _allows_ a 3 way merge, which is correct, not that it
_performs_ a 3-way merge, which you appear to be imputing to him
A normal reading of diff3
In 8635543010896767.wa.paulgboulderaim@listserv.ua.edu, on
04/10/2013
at 08:27 AM, Paul Gilmartin paulgboul...@aim.com said:
On Wed, 10 Apr 2013 08:52:55 -0400, Shmuel Metz (Seymour J.) wrote:
on 04/07/2013 at 04:57 PM, Sam Siegel said:
diff3 allows a 3 way merge between the original
In
CAAJSdjiR92bsAKH-HP2jVkdDZ+ekptT=6=yo-7p0mqze9+p...@mail.gmail.com,
on 04/10/2013
at 07:37 AM, John McKown john.archie.mck...@gmail.com said:
True. As I recall from looking at the JES2 source long ago, a START
command (SUB=JES2 version) had a hard coded job card put as the
first JCL card,
In 4838075892518636.wa.paulgboulderaim@listserv.ua.edu, on
04/09/2013
at 09:21 AM, Paul Gilmartin paulgboul...@aim.com said:
I may have been elliptical. I meant to ask whether symbol
substitution is performed if the data set referenced by the PARMDD
parameter on the EXEC statement is
In 0de6a9840123e547b061ac5b6765c02698e...@exmb-05.ad.wsu.edu, on
04/09/2013
at 05:56 PM, Gibney, Dave gib...@wsu.edu said:
I would hope converter/interpreter.
That wouldn't work.
If not, then instream substitution would not be available for
Started Tasks.
That doesn't follow. STC goes
True. As I recall from looking at the JES2 source long ago, a START
command (SUB=JES2 version) had a hard coded job card put as the
first JCL card, followed by a // EXEC PROC=stcname. This was fed to
the converter/interpreter to create the internal text. Then a special
initiator was started which
John McKown wrote:
This is according to my organic memory module, which is suffering ECC checks
any more, so I may be off a bit (or maybe even a byte).
With all your good postings, I doubt your organic memory module is defective.
;-D
But hey, I must 'byte' you, one good thing about aging is,
In 6384885757679699.wa.paulgboulderaim@listserv.ua.edu, on
04/09/2013
at 06:33 PM, Paul Gilmartin paulgboul...@aim.com said:
On Tue, 9 Apr 2013 19:24:53 -0400, Shmuel Metz (Seymour J.) wrote:
on 04/07/2013 at 04:57 PM, Sam Siegel said:
diff3 allows a 3 way merge between the original
It is not the converter/interpreter that does the substitution. For
instream data sets, you can think of JES as acting as the access method.
The user (converter/interpreter in the PARMDD case) invokes GET. That
processing invokes the access method code that is appropriate. For
non-instream
A completely different topic, but sequence numbers are obviously (I think. Am
I wrong?) entirely a vestigial organ left from the days of punched cards. They
were a lifesaver if you dropped your cards on the floor, and the compilers put
out a warning if you loaded the cards into the reader in
Think Black Team.
Sorry, but that is not relevant. We try not to waste time and resources
implementing things that no one needs (with less than 100% success, I'm
sure).
It is not a question of exercising the outlying cases of an implementation
trying to break something.
Should I infer from
To: IBM-MAIN@listserv.ua.edu,
Date: 04/09/2013 12:45 PM
Subject:Re: 32760? (was: PARMDD?)
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
Think Black Team.
Sorry, but that is not relevant. We try not to waste time and resources
implementing things that no one needs
On Tue, 9 Apr 2013 07:45:18 -0400, Peter Relson wrote:
Should I infer from this that only symbol substitution by instream data
set processing occurs, and if the PARMDD data set is not instream
no symbol processing is possible?
Yes you should. There is no intrinsic support in GET to ask for
On Tue, 9 Apr 2013 09:21:59 -0500, Paul Gilmartin paulgboul...@aim.com wrote:
I have an outlying case to test my understanding:
// SET FOO='WOM'
// SET BAR=BAT
// SET WOMBAT='SDB=YES'
//*
//STEP EXEC PGM=IEBGENER,PARMDD=SYSUT1
//SYSUT2DD SYSOUT=(,)
//SYSUT1DD *,SYMBOLS=JCL
Just a question that may be a bit pedantic. It is JES doing the
substitution (a HASP program) or is it the converter/interpreter? I
guess the main reason is to determine who to yell at. grin/
On Tue, Apr 9, 2013 at 12:46 PM, Walt Farrell walt.farr...@gmail.comwrote:
On Tue, 9 Apr 2013
On Tue, 9 Apr 2013 13:28:57 +0100, Martin Packer martin_pac...@uk.ibm.com
wrote:
I'm running a residency in the Autumn on 2.1 code (and you'll see an
announcement as this one is expected to welcome customer etc nominations
shortly). I mention this because Symbol Substitution via PARMDD is quite
List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of John McKown
Sent: Tuesday, April 09, 2013 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 32760? (was: PARMDD?)
Just a question that may be a bit pedantic. It is JES doing the
substitution (a HASP program) or is it the converter
On Tue, 9 Apr 2013 17:56:09 +, Gibney, Dave wrote:
I would hope converter/interpreter. If not, then instream substitution would
not be available for Started Tasks.
I'm not sure what yo mean by this. If you mean for started tasks that run
SUB=MSTR, then instream data sets are not
On Tue, 9 Apr 2013 12:51:49 -0500, John McKown wrote:
Just a question that may be a bit pedantic. It is JES doing the
substitution (a HASP program) or is it the converter/interpreter? I
guess the main reason is to determine who to yell at. grin/
Hardly cause to yell. If you need an
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Tom Marchant
Sent: Tuesday, April 09, 2013 1:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 32760? (was: PARMDD?)
On Tue, 9 Apr 2013 17:56:09 +, Gibney, Dave wrote:
I
:48 PM, Gibney, Dave gib...@wsu.edu wrote:
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Tom Marchant
Sent: Tuesday, April 09, 2013 1:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 32760? (was: PARMDD?)
On Tue, 9 Apr 2013 17
@LISTSERV.UA.EDU
Subject: Re: 32760? (was: PARMDD?)
I don't think that instream data for a PROC started via SUB=MSTR will
ever occur. The reason is that instream data is kept in the SPOOL. And
there is no SPOOL associated with SUB=MSTR. This is the same reason
that there is no support for SYSOUT
In
CAFMxNWJ6H_0KLL4Mo9-o5Q-AtwU_wJodAFh=X8vh1Vj=qf6...@mail.gmail.com,
on 04/07/2013
at 04:57 PM, Sam Siegel s...@pscsi.net said:
Patch is the unix version of SUPERC that shows the delta between
source files.
ITYM diff; the patch utility applies an update.
diff3 allows a 3 way merge between
On Tue, 9 Apr 2013 19:24:53 -0400, Shmuel Metz (Seymour J.) wrote:
on 04/07/2013 at 04:57 PM, Sam Siegel said:
diff3 allows a 3 way merge between the original source and 2
different updates to the original source.
No; it merges two updates.
ksh:1+ man diff3
Reformatting page. Please Wait...
In 134e01ce33be$b50687f0$1f1397d0$@mcn.org, on 04/07/2013
at 11:35 AM, Charles Mills charl...@mcn.org said:
A completely different topic, but sequence numbers are obviously (I
think. Am I wrong?) entirely a vestigial organ left from the days of
punched cards.
You're wrong; sequence numbers
+1 for CMS UPDATE, 45+ years old and going strong.
I've been irritated by the update-by-replacement theology since I first
encountered it. The ability to easily look and see what lines were hit by an
update without having to re-run diffs (which takes a long time, relatively
speaking,
Charles Mills wrote:
more consideration should have been given to usability
If I were the product manager for z/OS, I probably would have thrown the tentative design
out here on IBMMAIN for comment *before* it was too late to make changes.
What a fabulous resource this list would be if used
In many other cases, there are trailing blanks and the programer
considers them to be significant. That's why ISPF has a PRESERVE
option. The PARMDD rules appear to thwart the programmers'
and ISPF's intent here.
I'm afraid that some of the comments on this thread do not reflect real
world
On Mon, 8 Apr 2013 05:49:58 -0700, Phil Smith wrote:
In addition, I suspect/believe that update-by-replacement encourages more
changes than necessary: that is, for 30 years, when I've made a change using
XEDIT in UPDATE mode, I've ALWAYS looked at the resulting update before
committing it, to
On Mon, 8 Apr 2013 09:11:09 -0400, John Eells wrote:
What a fabulous resource this list would be if used in that fashion: a
hundred intelligent, experienced programmers willing to do volunteer
software design for IBM. What a shame to let it go to waste.
snip
Don Ault did precisely that
On Mon, 8 Apr 2013 09:12:39 -0400, Peter Relson wrote:
I'm afraid that some of the comments on this thread do not reflect real
world practical usage. The EXEC PGM= PARM= string is not typically (ever?)
used in this way. Maybe that's because of the long-standing
implementation, but that is
In
CAE1XxDHVL_wm_RvFP=rckprfhqooja1tioo8llyb8tl73fo...@mail.gmail.com,
on 04/07/2013
at 02:58 PM, John Gilmore jwgli...@gmail.com said:
Alexander Pope's abjuration, Be not the first by whom the new are
tried, nor yet the last to lay the old aside, nicely encapsulates
their attitudes.
My
In 139601ce33da$91189ec0$b349dc40$@mcn.org, on 04/07/2013
at 02:55 PM, Charles Mills charl...@mcn.org said:
BASIC and FORTRAN both used sequence numbers as labels but they
were on the left, not the right, correct?
Those weren't sequence numbers, and sequence numbers are only on the
right for
On Sat, 6 Apr 2013 23:19:33 -0400, Shmuel Metz (Seymour J.) wrote:
on 04/06/2013 at 09:27 AM, Peter Relson said:
Q.Does this apply alike for FB, LRECL other than 80?
A.Yes (I believe we checked that things ISPF do sequence numbers
even for FB LRECL other than 80).
ISPF also supports seqience
I agree will Gil. I know it is likely too late to get it changed, but I
disagree that being ISPF compatible is desirable. ISPF edit was designed
for program coding. And IBM programming languages normally put sequence
numbers in those columns. So it made sense for a programming editor to
maintain
ISPF also supports sequence numbers for RECFM=VB; I hope that
you're not saying that those are not stripped when FB
sequence numbers are.
That is exactly what I am saying. I suppose it comes down to: if it hurts
to do that, then don't do that.
The rules will be documented. As with most things,
On Sun, 7 Apr 2013 09:51:48 -0400, Peter Relson wrote:
ISPF also supports sequence numbers for RECFM=VB; I hope that
you're not saying that those are not stripped when FB
sequence numbers are.
That is exactly what I am saying. I suppose it comes down to: if it hurts
to do that, then don't do
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Sunday, April 07, 2013 7:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 32760? (was: PARMDD?)
On Sun, 7 Apr 2013 09:51:48 -0400, Peter Relson wrote:
ISPF also supports sequence numbers for RECFM=VB; I hope that you're
We have had the discussion about the residual value of sequence
numbers many times here, but I suspect that it is already to late to
chase their defenders back into the woodwork.
Alexander Pope's abjuration, Be not the first by whom the new are
tried, nor yet the last to lay the old aside, nicely
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Skip Robinson
Sent: Sunday, April 07, 2013 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 32760? (was: PARMDD?)
++MACUPD and ++SRCUPD depend entirely on FB sequence numbers. Without
sequence
In 7843121008695274.wa.paulgboulderaim@listserv.ua.edu, on
04/07/2013
at 06:35 AM, Paul Gilmartin paulgboul...@aim.com said:
And there, I disagree intensely. If, by happenstance the
programmer's data have 8 numeric digits on the left, the programmer
will be compelled to reformat. If the
In
caajsdjgzupa4xvctgir+ajeb9muauso2tgedwc7fpoo_5oo...@mail.gmail.com,
on 04/07/2013
at 07:06 AM, John McKown john.archie.mck...@gmail.com said:
I agree will Gil. I know it is likely too late to get it changed, but
I disagree that being ISPF compatible is desirable. ISPF edit was
designed for
On Sun, 7 Apr 2013 11:35:37 -0700, Charles Mills wrote:
I dislike sequence numbers anyway
A completely different topic, but sequence numbers are obviously (I think. Am
I wrong?) entirely a vestigial organ left from the days of punched cards. They
were a lifesaver if you dropped your cards on
On Sun, 7 Apr 2013 12:21:09 -0700, Charles Mills wrote:
Well, you're right, that's certainly an example of a 21st century value to
sequence numbers.
One might counter-argue that in 2013 the difference between distributing a
20-line patch versus an entire 2000-line macro (about 158K before any
@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Sunday, April 07, 2013 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 32760? (was: PARMDD?)
On Sun, 7 Apr 2013 11:35:37 -0700, Charles Mills wrote:
I dislike sequence numbers anyway
A completely different topic, but sequence numbers
From: Paul Gilmartin paulgboul...@aim.com
Date: 04/07/2013 05:40 PM
SNIPPAGE
But do sequence numbers have a lick of value today?
Shmuel and some of my coworkers think so. A telling observation
is that few editors other than from the IBM culture implement them.
BASIC used them both for
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 04/07/2013 11:35 AM
Subject:Re: 32760? (was: PARMDD?)
Sent by:IBM Mainframe Discussion List IBM-
m...@listserv.ua.edu
more consideration should have been given to usability
If I were the product manager for z/OS, I probably would have
On Sun, Apr 7, 2013 at 4:16 PM, Steve Thompson sthomp...@us.ibm.com wrote:
From: Paul Gilmartin paulgboul...@aim.com
Date: 04/07/2013 06:15 PM
On Sun, 7 Apr 2013 18:08:54 -0400, Steve Thompson wrote:
As a result this wonderful language, Java, has no sequence numbers, can
be
wider
On Sun, Apr 7, 2013 at 5:19 PM, Paul Gilmartin paulgboul...@aim.com wrote:
On Sun, 7 Apr 2013 16:57:23 -0700, Sam Siegel wrote:
On Sun, Apr 7, 2013 at 4:16 PM, Steve Thompson wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/patch.html
snip
I read this rapidly. I'm
On 7 Apr 2013 14:55:23 -0700, in bit.listserv.ibm-main Charles Mills
wrote:
Culture is a key here.
IBM's background was in punched cards. IBM's strength in punched card
tabulating is what transferred over to their success in computer data
processing. They never forgot that.
Many other
On 7 April 2013 20:19, Paul Gilmartin paulgboul...@aim.com wrote:
Slight correction. The UNIX version of SUPERC is diff. (I suspect
they use similar algorithms.)
Not so similar, as you pointed out back in January:
On 8 January 2013 15:02, Paul Gilmartin paulgboul...@aim.com wrote:
That's
On Sun, 7 Apr 2013 22:27:15 -0400, Tony Harminc wrote:
On 7 April 2013 20:19, Paul Gilmartin paulgboul...@aim.com wrote:
Slight correction. The UNIX version of SUPERC is diff. (I suspect
they use similar algorithms.)
Not so similar, as you pointed out back in January:
On 8 January 2013
I'd prefer to see no stripping of trailing blanks or digits. If the
programmer enters the data, respect it. It makes the rules
simpler.
While it does make the rules simpler, this was done intentionally
and will likely not be changed. It make it far easier for users trying
to meet a syntax that
On Sat, 6 Apr 2013 09:27:07 -0400, Peter Relson wrote:
I'd prefer to see no stripping of trailing blanks or digits. If the
programmer enters the data, respect it. It makes the rules
simpler.
While it does make the rules simpler, this was done intentionally
and will likely not be changed. It
. (Or, arguably, keep a
maximum of one leading blank.)
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Friday, April 05, 2013 6:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 32760? (was: PARMDD?)
...
What I don't
In
of737e9422.2e599f47-on85257b45.00497bb4-85257b45.0049f...@us.ibm.com,
on 04/06/2013
at 09:27 AM, Peter Relson rel...@us.ibm.com said:
Q.Does this apply alike for FB, LRECL other than 80?
A.Yes (I believe we checked that things ISPF do sequence numbers
even for FB LRECL other than 80).
With this change, when the JCL interpreter sees the PARMDD=, it
allocates the buffer of 32768 bytes
Did you see that documented somewhere?
As one should expect, how the system chooses to allocate storage it uses
is not documented, as there is no need for the user to care.
Informally, for
OK, I'll byte (ah, bite). Can the DD be allocated to a UNIX file? I don't
see why not, but then ... .
//parmdd DD PATH='/home/myid/my-parm-file.txt',
// FILEDATA=TEXT,
// RECFM=VB,LRECL=32756,BLKSIZE=32760
// PATHOPTS=(ORDONLY)
On Fri, Apr 5, 2013 at 8:28 AM, Peter Relson rel...@us.ibm.com
On Fri, 5 Apr 2013 09:10:14 -0500, John McKown wrote:
OK, I'll byte (ah, bite). Can the DD be allocated to a UNIX file? I don't
see why not, but then ... .
//parmdd DD PATH='/home/myid/my-parm-file.txt',
// FILEDATA=TEXT,
// RECFM=VB,LRECL=32756,BLKSIZE=32760
// PATHOPTS=(ORDONLY)
(or even
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Shmuel Metz (Seymour J.)
Sent: Wednesday, April 03, 2013 9:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 32760? (was: PARMDD?)
In 8189023945771520.wa.paulgboulderaim@listserv.ua.edu, on
04/03/2013
at 07:29 AM, Paul Gilmartin
On Wed, 3 Apr 2013 16:48:55 -0500, Mike Schwab wrote:
With this change, when the JCL interpreter sees the PARMDD=, it
allocates the buffer of 32768 bytes
Did you see that documented somewhere? I would have expected
that it allocates a buffer large enough to hold the long parm, which
might be
The (new) abend/reason code happens to be 306 reason x'44'. In most (but
not all) cases, it is unimportant to understand in advance what the abend
code is going to be when something bad happens.
What is important generally is that if you get that abend you can easily
understand what the problem
When the jobstep is not to be marked APF-authorized (i.e., the
environment
is not APF or the jobstep program is not AC(1) ), the 100 character
restriction is not applied.
I'm confused. Is your statement not the reverse of ...
I obviously was not successful at responding, trying to phrase
Peter's most recent response:
begin extract
The 100 character restriction is applied to the following case, only:
environment is APF; and jobstep program is AC(1); and the program is
not bound with LONGPARM.
/end extract
is admirable, unambiguous, and, I think, definitive.
John Gilmore,
John Gilmore wrote:
is admirable, unambiguous, and, I think, definitive.
Who am I to argue with you, the language guru. ;-D
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access
By now I suppose that Paul Gilmartin and I are expected to disagree,
and we do again here.
Peter's response would not have been improved by being rewritten by
one of IBM's lawyers to envisage every possible contigency from the
first day of the world to these days present.
Moreover, while
On 3 Apr 2013 05:29:17 -0700, in bit.listserv.ibm-main you wrote:
On Wed, 3 Apr 2013 06:47:01 -0500, John Gilmore wrote:
Peter's most recent response:
begin extract
The 100 character restriction is applied to the following case, only:
environment is APF; and jobstep program is AC(1); and the
On Wed, 3 Apr 2013 12:48:35 -0300, Clark Morris wrote:
This has been interesting. I recall when the maximum PARM length was
144. I learned to code to make sure the PARM length was in the range
144? When?
I was expecting (normally far less than either 144 or 100). Since the
most an initiator
Paul Gilmartin wrote:
begin extract
Not entirely. The original invokee might choose to pass its PARM
unmodified, unverified, and uncopied as an argument to a subsequent
module, so the PARM passed by the initiator can be relevant.
/end extract
Paul is of course right here. The original PARM=
Actually, you can, and always could, call a program with a longer
variable length parameter. You just had to allocate the desired
buffer size 1-32760 (plus the length field), and fill in the data and
the length and call with the pointer to it.
When you called the program from JCL, the JCL
On Wed, 3 Apr 2013 16:48:55 -0500, Mike Schwab wrote:
... If (the length is over 100 and / or the PARMDD was used) ...
Can you please show the truth table for the and / or connective?
..., it will ABEND.
ABEND? What code? Or JCL Error? Or other (specify)?
I hope when the 2.1 JCL RM is
I will try it out when we get z/OS 2.1 installed. Probably Summer 2014 or so.
On Wed, Apr 3, 2013 at 7:02 PM, Paul Gilmartin paulgboul...@aim.com wrote:
On Wed, 3 Apr 2013 16:48:55 -0500, Mike Schwab wrote:
... If (the length is over 100 and / or the PARMDD was used) ...
Can you please
On Wed, 3 Apr 2013 07:29:11 -0500, Paul Gilmartin paulgboul...@aim.com wrote:
On Wed, 3 Apr 2013 06:47:01 -0500, John Gilmore wrote:
Peter's most recent response:
begin extract
The 100 character restriction is applied to the following case, only:
environment is APF; and jobstep program is
In 8189023945771520.wa.paulgboulderaim@listserv.ua.edu, on
04/03/2013
at 07:29 AM, Paul Gilmartin paulgboul...@aim.com said:
It leaves a couple holes
Not really.
o Jobstep program is AC(1), from an authorized library, so
the environment was authorized.
Then that program is responsible
if a program is running in an APF environment but is not
itself marked AC(1), do the PARMDD considerations apply?
No.
When the jobstep is not to be marked APF-authorized (i.e., the environment
is not APF or the jobstep program is not AC(1) ), the 100 character
restriction is not applied.
Peter Relson wrote:
if a program is running in an APF environment but is not itself marked AC(1),
do the PARMDD considerations apply?
No.
When the jobstep is not to be marked APF-authorized (i.e., the environment is
not APF or the jobstep program is not AC(1) ), the 100 character restriction
I think it's Peter's phraseology.
the 100 character restriction is not applied This sentence has two
negatives in it. In math, if might be not(APF) = not(100 character
restriction) The 100 character restriction phrase means that the
initiator checks for the length of the PARM string when the
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: Ed Jaffe edja...@phoenixsoftware.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 03/29/2013 07:28 AM
Subject:Re: 32760
On Mon, 1 Apr 2013 08:49:38 -0700, Skip Robinson wrote:
Sorry for reaching back to an older posting in this thread. I did not see
this question handled. I worked with Ed at that same institution, the late
great Security Pacific Bank. While it's true that (undoubtedly) no module
in the widely
In 5677548326024323.wa.walt.farrellgmail@listserv.ua.edu, on
03/29/2013
at 06:01 PM, Walt Farrell walt.farr...@gmail.com said:
If application code changes were necessary to make use of the
longer parameters, then there would be no System Integrity concern,
and no need for the new
I did not find Kevin Kelley's post entirely persuasive. This
restriction long antedates 2 Kibyte pages, and the equation 8 x 4096 =
32768 is thus historically irrelevant.
Kevin was not trying to persuade. He was merely stating facts. The number
of pages is not the relevant part of the
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Friday, March 29, 2013 14:39
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 32760? (was: PARMDD?)
On Fri, 29 Mar 2013 09:08:36 -0400, Peter Relson wrote:
I did not find Kevin Kelley's post entirely persuasive
specs/assumptions.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Friday, March 29, 2013 14:39
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 32760? (was: PARMDD?)
On Fri, 29 Mar 2013 09:08:36
This thread has exhausted itself. We are rehashing trivia. I do not
need to be reminded of the capacity of a halfword, signed or unsigned;
and Kevin can defend his views himself if he wants to bother to do so.
For what it may be worth, I judge that the new facility is a happy
compromise of very
On 3/29/2013 6:46 AM, Vernooij, CP - SPLXM wrote:
Code has to be written to use PARMDD and will therefore not crash production
applications unexpectedly.
When I worked for a large bank, none of our production batch
applications were APF authorized. However, changes to production JCL
went
Uh oh, new GMail Reply format will irritate the bottom-posters -- now
it's non-trivial to not top-post. Let the flamewars resume.
On Fri, Mar 29, 2013 at 10:56 AM, zMan zedgarhoo...@gmail.com wrote:
And this is new how? :-)
On Fri, Mar 29, 2013 at 10:16 AM, John Gilmore jwgli...@gmail.com
From: Paul Gilmartin paulgboul...@aim.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, March 27, 2013 10:20:56 AM
Subject: Re: 32760? (was: PARMDD?)
Does STORAGE OBTAIN still, in the 21st Ce ntury,
limit the size of the obtained block to 32768?
I don't believe that the limit was ever
For a batch job the manual says, reasonably enough, that the size of a
STORAGE OBTAIN request is limited by the size of its JCL REGION=
parameter.
I should guess that Paul Gilmartin knew that the answer to his
rhetorical question was no when he asked it. Many program objects and
load modules
I did not find Kevin Kelley's post entirely persuasive. This
restriction long antedates 2 Kibyte pages, and the equation 8 x 2048 =
32768 is thus historically irrelevant.
Does the two-fullword---not doubleword?---prefix have the structure
|?|?|?|?|?||?|?|c|c|, in which |c|c| is the length L = 0
I should f course have written 8 x 4096 = 32768
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
On 3/28/2013 1:17 PM, John Gilmore wrote:
I did not find Kevin Kelley's post entirely persuasive. This
restriction long antedates 2 Kibyte pages, and the equation 8 x 2048 =
32768 is thus historically irrelevant.
Does the two-fullword---not doubleword?---prefix have the structure
On Thu, 28 Mar 2013 13:17:31 -0500, John Gilmore wrote:
I did not find Kevin Kelley's post entirely persuasive. This
restriction long antedates 2 Kibyte pages, and the equation 8 x 2048 =
32768 is thus historically irrelevant.
The restriction to 32760 is new with z/OS 2.1. Formerly it was
Paul Gilmartin wrote:
begin extract
It has been patiently explained to me here that STORAGE OBTAIN is
biased toward doubleword multiples. But PARM contains a halfword
length that doesn't count itself. So I'd expect the limit to be
either 32758 (8*4095-2) or 32766 (8*4096-2). Again, why 32760?
On Wed, 27 Mar 2013 10:03:03 -0500, John Gilmore wrote:
Consider now what happens if storage is allocated on a doubleword
boundary D. The next doubleword boundary is at D + 8. Placing the
halfword current-length prefix at D + 6 ensures that any doubleword
alignment for what begins at D + 8 is
This has all been very entertaining but there are two reasons why it is 32760:
1) the storage layout has always consisted of two fullword fields followed by
the parameter string storage. The two fullwords plus 32760 bytes of parameters
conveniently fits in 8 pages, and 2) 32760 is also the
96 matches
Mail list logo
