On Thu, 13 Aug 2009 17:44:32 -0500 Patrick O'Keefe patrick.oke...@wamu.net
wrote:
:On Thu, 13 Aug 2009 16:58:21 -0500, Paul Gilmartin
:paulgboul...@aim.com wrote:
:My understanding/conjecture is that when the Assembler
:(for example), using BPAM, encounters a COPY nested
:within another COPY
I just ran into something tryng to assemble...I have a program that I am
assembling, and in my SYSLIB I have PDS-1 that uses a blocksize of 3120 and
PDS-2 that uses 32720 (I didn't create this!).
When I run with PDS-1 ahead of PDS-2, I get error messages ASMA057E
Undefined operation code...
When
On Thu, 13 Aug 2009 11:05:39 -0400, Donald Johnson wrote:
I just ran into something tryng to assemble...I have a program that I am
assembling, and in my SYSLIB I have PDS-1 that uses a blocksize of 3120 and
PDS-2 that uses 32720 (I didn't create this!).
When I run with PDS-1 ahead of PDS-2, I
---snip---
I just ran into something tryng to assemble...I have a program that I am
assembling, and in my SYSLIB I have PDS-1 that uses a blocksize of 3120 and
PDS-2 that uses 32720 (I didn't create this!).
When I run with PDS-1 ahead of
Willdo...Thanks for the tip. I was thinking that maybe since the first PDS
was 3120, that became the BLKSIZE for the DCB, and the opcode (macro) I was
looking for was further than 3120 into a block.
I'll let you know if this is still a problem.
Don
On Thu, Aug 13, 2009 at 4:34 PM, Rick Fochtman
Even though the PDS calls it a TTR, each member starts a new block so
the situation you describe cannot occur.
-Original Message-
From: Donald Johnson
Sent: Thursday, August 13, 2009 1:39 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Concatenations and blocksizes
Willdo...Thanks for the tip
On Thu, 13 Aug 2009 14:02:48 -0700, Schwarz, Barry A
barry.a.schw...@boeing.com wrote:
Even though the PDS calls it a TTR, each member starts a new block so
the situation you describe cannot occur.
...
Thank you for corfirming what my questionable memory told me.
Doesn't that also argue
snip---
Even though the PDS calls it a TTR, each member starts a new block so
the situation you describe cannot occur.
--unsnip--
Never mind that the R of TTR refers to the physical record on the
On Thu, 13 Aug 2009 16:26:54 -0500, Patrick O'Keefe wrote:
On Thu, 13 Aug 2009 14:02:48 -0700, Schwarz, Barry A wrote:
Even though the PDS calls it a TTR, each member starts a new block so
the situation you describe cannot occur.
...
Thank you for corfirming what my questionable memory told me.
On Thu, 13 Aug 2009 16:58:21 -0500, Paul Gilmartin
paulgboul...@aim.com wrote:
...
My understanding/conjecture is that when the Assembler
(for example), using BPAM, encounters a COPY nested
within another COPY member, it:
o Does a NOTE to mark the current block.
o Saves the NOTE word _and_ the
On Tue, 11 Aug 2009 14:58:18 -0500 Patrick O'Keefe patrick.oke...@wamu.net
wrote:
:On Tue, 11 Aug 2009 10:37:31 -0500, Rick Fochtman
:rfocht...@ync.net wrote:
:
:
:... I was told that if you couldn't master the concepts of
:blocking/deblocking in BSAM, you had no business messing
:around with
On Tue, 11 Aug 2009 16:59:52 -0500, Rick Fochtman
rfocht...@ync.net wrote:
Ok. I didn't word things very clearly.
...
QSAM handles individual members just fine so FIND, READ, WRITE
and STOW are working under the covers. Seems like that covers
most of the functions.
Here I was just trying to
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
Paul Gilmartin
Sent: Monday, August 10, 2009 4:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] Concatenations and blocksizes
On Mon, 10 Aug 2009 17:48:31 -0500, Richard Peurifoy
On Mon, 10 Aug 2009 23:35:47 -0700, Ron Hawkins wrote:
I believe your problem occurs because you now have SYS1.MACLIB concatenated
with SYS1.MACLIB, except the first one in the concatenation has DCB in the
JCL that does not match the actual dataset - hence your error.
The override X/ on
---snip---
You have always been able to write a block of only one byte, or even
zero bytes, onto a DASD.
unsnip--
One byte, yes. But if the device reads a count field with a data length
of zero, it
Paul Gilmartin wrote:
On Mon, 10 Aug 2009 17:48:31 -0500, Richard Peurifoy wrote:
Paul Gilmartin wrote:
On Mon, 10 Aug 2009 16:52:59 -0500, Patrick O'Keefe wrote:
I'm just puzzled that the enhancement limited itself to QSAM.
No mention of BPAM.
I had hoped this was an oversight in the doc,
snip-
I thought a count of zero was prohibited in a CCW. (But there may be
other ways.)
unsnip-
You are correct. But a DASD Format Write requires a COUNT field of 8
bytes. The count field
--snip---
OTOH, if you concatenate PDSs together as PDS and then stick in a
DSORG=PS I would imagine you will get a very interesting ABEND
-unsnip-
Depending on the DCB attributes involved,
[mailto:ibm-m...@bama.ua.edu] On Behalf Of
Rick Fochtman
Sent: Tuesday, August 11, 2009 10:20 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Concatenations and blocksizes
---snip---
You have always been able to write a block of only one byte, or even
zero bytes
--snip-
Ok. I'll buy that. But NOTE didn't return anything at all until they
wrote it. So I'll regress: These smart people could also have written
NOTEX or QNOTE that returned all that was required to do queued
processing of the member. There
---snip--
I'm just puzzled that the enhancement limited itself to QSAM.
No mention of BPAM.
I had hoped this was an oversight in the doc, but apparently
not. An assembly with:
//SYSLIBDD UNIT=SYSALLDA,SPACE=(80,(1,1)),
Most likely because the BLKSIZE is in the JFCB, and so acts as an override. If
the small BLKSIZE is only in the DSCB it is treated differently. I actually
thought about testing this yesterday, but didn't have time. I suspected that
it would work this way.
Richard Peurifoy
Scott Rowe wrote:
Most likely because the BLKSIZE is in the JFCB, and so acts as an override. If
the small BLKSIZE is only in the DSCB it is treated differently. I actually
thought about testing this yesterday, but didn't have time. I suspected that
it would work this way.
This appears
On Tue, 11 Aug 2009 11:24:25 -0500, Richard Peurifoy wrote:
Scott Rowe wrote:
Most likely because the BLKSIZE is in the JFCB, and so acts as an override.
If the small BLKSIZE is only in the DSCB it is treated differently. I
actually thought about testing this yesterday, but didn't have
On Tue, 11 Aug 2009 10:37:31 -0500, Rick Fochtman
rfocht...@ync.net wrote:
... I was told that if you couldn't master the concepts of
blocking/deblocking in BSAM, you had no business messing
around with BPAM, which was designed as a add on
product for BSAM. ...
He was right, but that logic
On Tue, 11 Aug 2009 14:58:18 -0500, Patrick O'Keefe wrote:
On Tue, 11 Aug 2009 10:37:31 -0500, Rick Fochtman wrote:
... I was told that if you couldn't master the concepts of
blocking/deblocking in BSAM, you had no business messing
around with BPAM, which was designed as a add on
product for
--snip-
... I was told that if you couldn't master the concepts of
blocking/deblocking in BSAM, you had no business messing
around with BPAM, which was designed as a add on
product for BSAM. ...
He was right, but that logic
In listserv%200908061221126682.0...@bama.ua.edu, on 08/06/2009
at 12:21 PM, Patrick O'Keefe patrick.oke...@wamu.net said:
1. How long ago did this requirement disappear?
Which requirement? For PO? For PS? There are multiple dates, depending on
what you're asking.
--
Shmuel (Seymour
In 000301ca1735$86fa8130$94ef83...@hawkins1960@sbcglobal.net, on
08/07/2009
at 01:03 AM, Ron Hawkins ron.hawkins1...@sbcglobal.net said:
The largest blksize first restriction did go away with for Fetch in XA,
There was no such restriction for Fetch. The various restrictions for PO
and PS went
-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
Shmuel Metz (Seymour J.)
Sent: Monday, August 10, 2009 8:00 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] Concatenations and blocksizes
In 000301ca1735$86fa8130$94ef83...@hawkins1960@sbcglobal.net, on
08
On Mon, 10 Aug 2009 10:43:55 -0700, Ron Hawkins wrote:
So you are saying that the largest BLKSIZE first restriction on
JOBLIB/STEPLIB did not apply before XA. I did not know that, but I do now.
And apparently still doesn't. By a crude experiment:
//STEPEXEC PGM=IEFBR14
//STEPLIB
And apparently still doesn't. By a crude experiment:
//STEPEXEC PGM=IEFBR14
//STEPLIB DD DISP=SHR,DSN=SYS1.LINKLIB,BLKSIZE=1
Worked fine.
Of course it did!
IEFBR14 has (effectively) two instructions:
SR 15,15
BR 14
NO open.
(But did I really test what I thought I
Isn't a STEPLIB opened before the program is loaded? Does the DCB used
in that open override the JCL and/or the DSCB?
-Original Message-
From: Ted MacNEIL [mailto:eamacn...@yahoo.ca]
Sent: Monday, August 10, 2009 11:44 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Concatenations
Ted MacNEIL wrote:
And apparently still doesn't. By a crude experiment:
//STEPEXEC PGM=IEFBR14
//STEPLIB DD DISP=SHR,DSN=SYS1.LINKLIB,BLKSIZE=1
Worked fine.
Of course it did!
IEFBR14 has (effectively) two instructions:
SR 15,15
BR 14
NO open.
(But did I really test
Isn't a STEPLIB opened before the program is loaded?
Sorry, my bad.
Poor eyesight and a BlackBerry means I missed the DDNAME.
Does the DCB used in that open override the JCL and/or the DSCB?
I'm not actually sure what BLKSIZE is used for a STEPLIB, actual or specified.
I'll go back into my
MVS/ESA SP 4 JCL Reference (DFP V3.3):
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea4b608/11.6?ACTION=MATCHESREQUEST=concatenateTYPE=FUZZYSHELF=HAS4BS15DT=19951023140514CASE=searchTopic=TOPICsearchText=TEXTsearchIndex=INDEXrank=RANKScrollTOP=FIRSTHIT#FIRSTHIT
tinyurl:
, August 10, 2009 11:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] Concatenations and blocksizes
On Mon, 10 Aug 2009 10:43:55 -0700, Ron Hawkins wrote:
So you are saying that the largest BLKSIZE first restriction on
JOBLIB/STEPLIB did not apply before XA. I did not know that, but I do
The answer to (what I think is) the original question is DFP 2.3. Which
means it was included with DFP 3.1 (MVS/ESA) or MVS/XA 2.2.3 (which was
required to install DFP 3.1 under MVS/XA IIRC).
CONCATENATION ENHANCEMENT: Like-attribute concatenation will be
allowed for eligible data sets with
snip--
I don't think so, there used to be a minimum BLKSIZE of 18, but that's
not detected until you try to open the DSN. No open; no error.
IEFBR14 does no open.
---unsnip---
IIRC, that
At 18:28 -0500 on 08/06/2009, Paul Gilmartin wrote about Re:
Concatenations and blocksizes:
It is a misdesign that the OS allows this ever to happen. The
principal use of this facility is to correct errors that were
introduced by its earlier inadvertent use. Simply, any OPEN for
WRITE
---snip--
Isn't a STEPLIB opened before the program is loaded? Does the DCB used
in that open override the JCL and/or the DSCB?
--unsnip--
Program Fetch uses the directory
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Rick Fochtman
Sent: Monday, August 10, 2009 3:50 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Concatenations and blocksizes
snip--
I don't
On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden
mark.zel...@zurichna.com wrote:
...
CONCATENATION ENHANCEMENT: Like-attribute concatenation will be
allowed for eligible data sets with different block sizes in any
order; the largest no longer need be first. Eligible data sets are
partitioned or
On Mon, 10 Aug 2009 16:55:31 -0400, Bill Fairchild wrote:
You have always been able to write a block of only one byte, or even zero
bytes, onto a DASD.
I thought a count of zero was prohibited in a CCW. (But
there may be other ways.)
As for the minimum of 18 for tape, how does the access
Subject: Re: Concatenations and blocksizes
On Mon, 10 Aug 2009 16:55:31 -0400, Bill Fairchild wrote:
You have always been able to write a block of only one byte, or even zero
bytes, onto a DASD.
I thought a count of zero was prohibited in a CCW. (But
there may be other ways
On Mon, 10 Aug 2009 16:15:18 -0500, Patrick O'Keefe wrote:
On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden wrote:
...
CONCATENATION ENHANCEMENT: Like-attribute concatenation will be
allowed for eligible data sets with different block sizes in any
order; the largest no longer need be first.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Patrick O'Keefe
Sent: Monday, August 10, 2009 4:15 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Concatenations and blocksizes
On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden
mark.zel
: Concatenations and blocksizes
On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden
mark.zel...@zurichna.com wrote:
...
Interesting wording.
partitioned ... data sets ... accessed by QSAM ...
f they really meant that, wouldn't that restrict this enhancement
to a concatenation sequential datasets and/or PDS
On Mon, 10 Aug 2009 16:31:31 -0500, Paul Gilmartin
paulgboul...@aim.com wrote:
...
(I could ask for the umpteenth time why there is no QPAM, but
I won't.)
If you had asked (which you didn't) someone might have answered
that it's because the definition of the NOTE word has no
provision for
On Mon, 10 Aug 2009 16:52:59 -0500, Patrick O'Keefe wrote:
I'm just puzzled that the enhancement limited itself to QSAM.
No mention of BPAM.
I had hoped this was an oversight in the doc, but apparently
not. An assembly with:
//SYSLIBDD UNIT=SYSALLDA,SPACE=(80,(1,1)),
//
On Mon, 10 Aug 2009 17:20:48 -0500, Paul Gilmartin
paulgboul...@aim.com wrote:
On Mon, 10 Aug 2009 16:52:59 -0500, Patrick O'Keefe wrote:
I'm just puzzled that the enhancement limited itself to QSAM.
No mention of BPAM.
I had hoped this was an oversight in the doc, but apparently
not. An
Paul Gilmartin wrote:
On Mon, 10 Aug 2009 16:52:59 -0500, Patrick O'Keefe wrote:
I'm just puzzled that the enhancement limited itself to QSAM.
No mention of BPAM.
I had hoped this was an oversight in the doc, but apparently
not. An assembly with:
//SYSLIBDD
Bill Fairchild wrote:
The block length is indicated by the data length within the
count field. A DASD block is written on the track with a
Write Count, Key and Data or Write Count, Key, and Data Next
Track command. The length of a count field is always 8. If
you are to write a block length of
On Mon, 10 Aug 2009 17:48:31 -0500, Richard Peurifoy wrote:
Paul Gilmartin wrote:
On Mon, 10 Aug 2009 16:52:59 -0500, Patrick O'Keefe wrote:
I'm just puzzled that the enhancement limited itself to QSAM.
No mention of BPAM.
I had hoped this was an oversight in the doc, but apparently
not.
On Thu, 6 Aug 2009 18:28:16 -0500 Paul Gilmartin paulgboul...@aim.com wrote:
:On Thu, 6 Aug 2009 14:33:32 -0400, John Kington wrote:
:I would look at the blocksize on each dataset in your concatenation and
verify that you do not have any members blocked greater than the blocksize. A
problem
] Concatenations and blocksizes
Herman
Really, I took it out and the job failed. Put it back in and it worked
without incident. And yes I still have it in that job to date.
I would look at the blocksize on each dataset in your concatenation and
verify
that you do not have any members
It is a misdesign that the OS allows this ever to happen. The
principal use of this facility is to correct errors that were
introduced by its earlier inadvertent use. Simply, any OPEN for
WRITE with overriding attributes where the label contains different
nonzero attributes should ABEND for
Ron,
The largest blksize first restriction did go away with for Fetch in XA, and
it was before the restriction was lifted for SAM-E datasets (refer to Ed
Jaffe's comments).
I stand corrected on when the restriction was removed.
In one shop I was in a JCL check product was insisting that this
- Louisville
kenneth.kl...@kyfb.com
502-495-5000 x7011
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of John Kington
Sent: Friday, August 07, 2009 7:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Concatenations and blocksizes
It is a misdesign
ISTM, this restriction is still in place. I ran isrddn the other day and it
flagged a dataset in the concatenation that had a smaller blocksize than those
following it.
We reblocked that data set and isrddn did not complain.
Did ISRDDN complain because it is a TRUE problem?
Or, did it complain
On Fri, 7 Aug 2009 08:08:50 -0400, Klein, Kenneth wrote:
ISTM, this restriction is still in place. I ran isrddn the other day and
it flagged a dataset in the concatenation that had a smaller blocksize
than those following it. We reblocked that data set and isrddn did not
complain.
Really? I've
Edward Jaffe edja...@phoenixsoftware.com wrote in message
news:4a7b14a0.20...@phoenixsoftware.com...
Patrick O'Keefe wrote:
On another list someone found some product doc that still
mentioned having the largest blocksize first in a concatenation.
While trying to reassure the person I
---snip
It is a misdesign that the OS allows this ever to happen. The
principal use of this facility is to correct errors that were
introduced by its earlier inadvertent use. Simply, any OPEN for
WRITE with
On another list someone found some product doc that still
mentioned having the largest blocksize first in a concatenation.
While trying to reassure the person I realized how little I actually
knew about the topic. So I've got some questions. (Idle curiosity.)
1. How long ago did this
Patrick O'Keefe wrote:
On another list someone found some product doc that still
mentioned having the largest blocksize first in a concatenation.
While trying to reassure the person I realized how little I actually
knew about the topic. So I've got some questions. (Idle curiosity.)
1. How
I can remember that as late as 1.4 that I had to place the blksize=32760 on
the first data set in Steplib dd statement to get around this.
- snip-
On another list someone found some product doc that still mentioned
having the largest blocksize first in a concatenation.
While trying to
This should not be true (AFAIR).
Stocker, Herman herman.stoc...@avisbudget.com 8/6/2009 1:42 PM
I can remember that as late as 1.4 that I had to place the blksize=32760 on
the first data set in Steplib dd statement to get around this.
- snip-
On another list someone found some product
I can remember that as late as 1.4 that I had to place the blksize=32760 on
the first data set in Steplib dd statement to get around this.
Really?
As somebody pointed out, the restriction was removed in MVS/ESA 4.3.
The only JCL I've seen, since that, with the 32760 specification is that which
Really, I took it out and the job failed. Put it back in and it worked
without incident. And yes I still have it in that job to date.
Regards,
Herman Stocker
- snip-
Really?
As somebody pointed out, the restriction was removed in MVS/ESA 4.3.
The only JCL I've seen, since that,
Herman
Really, I took it out and the job failed. Put it back in and it worked
without incident. And yes I still have it in that job to date.
I would look at the blocksize on each dataset in your concatenation and verify
that you do not have any members blocked greater than the blocksize. A
Stocker, Herman wrote:
I can remember that as late as 1.4 that I had to place the blksize=32760 on
the first data set in Steplib dd statement to get around this.
I don't know what error you were getting, but STEPLIBs never
required DCB parameters, because the system loads modules
without
On Thu, 6 Aug 2009 13:58:33 -0400, Stocker, Herman wrote:
Really, I took it out and the job failed. Put it back in and it worked
without incident. And yes I still have it in that job to date.
It's possible that there was a data set in the concatenation
that was originally created with a
On Thu, 6 Aug 2009 14:33:32 -0400, John Kington wrote:
I would look at the blocksize on each dataset in your concatenation and verify
that you do not have any members blocked greater than the blocksize. A problem
that I have had in the past was someone updating a PDS with a blocksize on the
DD
On Thu, 6 Aug 2009 18:28:16 -0500, Paul Gilmartin paulgboul...@aim.com wrote:
A problem that I have had in the past was someone updating
a PDS with a blocksize on the DD which causes the blocksize in
the vtoc to be changed.
It is a misdesign that the OS allows this ever to happen. The
74 matches
Mail list logo
