Re: Concatenations and blocksizes

On Thu, 13 Aug 2009 17:44:32 -0500 "Patrick O'Keefe" wrote: :>On Thu, 13 Aug 2009 16:58:21 -0500, Paul Gilmartin :> 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 mar

Re: Concatenations and blocksizes

On Thu, 13 Aug 2009 16:58:21 -0500, Paul Gilmartin 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 offset of th

Re: Concatenations and blocksizes

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

Re: Concatenations and blocksizes

--- Even though the PDS calls it a TTR, each member starts a new block so the situation you describe cannot occur. Never mind that the "R" of TTR refers to the physical record on the track a

Re: Concatenations and blocksizes

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. Doesn't that also argue against what Paul Gilmartin sa

Re: Concatenations and blocksizes

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

Re: Concatenations and blocksizes

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

Re: Concatenations and blocksizes

-- 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

Re: Concatenations and blocksizes

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,

Re: Concatenations and blocksizes

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

Re: Concatenations and blocksizes

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 ha

Re: Concatenations and blocksizes

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 to

Re: Concatenations and blocksizes

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 8/11/2009 11:2

Re: Concatenations and blocksizes

- 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)), // R

Re: Concatenations and blocksizes

[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 -- You have always been able to write a block of only one byte, or even zero bytes

Re: Concatenations and blocksizes

- 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 -- Depending on the DCB attributes involved, you might en

Re: Concatenations and blocksizes

- I thought a count of zero was prohibited in a CCW. (But there may be other ways.) - You are correct. But a DASD Format Write requires a COUNT field of 8 bytes. The count field may, in turn,

Re: Concatenations and blocksizes

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,

Re: Concatenations and blocksizes

-- You have always been able to write a block of only one byte, or even zero bytes, onto a DASD. -- One byte, yes. But if the device reads a count field with a data length of zero, it signals a Unit

Re: Concatenations and blocksizes

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 s

Re: Concatenations and blocksizes

Paul, 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 statement 6 and before statement 7 is the clue. Ron >

Re: Concatenations and blocksizes

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 appare

Re: Concatenations and blocksizes

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

Re: Concatenations and blocksizes

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 UNIT=SYSALLDA,SPACE=(80,(

Re: Concatenations and blocksizes

On Mon, 10 Aug 2009 17:20:48 -0500, 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:

Re: Concatenations and blocksizes

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)), // RECFM=

Re: Concatenations and blocksizes

On Mon, 10 Aug 2009 17:36:44 -0400, Thompson, Steve wrote: >-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: Concat

Re: Concatenations and blocksizes

-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

Re: Concatenations and blocksizes

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 fi

Re: Concatenations and blocksizes

a.edu 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

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.) As for the minimum of 18 for tape, how does the access me

Re: Concatenations and blocksizes

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. Eligible data sets are >partitioned or sequential data se

Re: Concatenations and blocksizes

-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 -- I don&#

Re: Concatenations and blocksizes

- Isn't a STEPLIB opened before the program is loaded? Does the DCB used in that open override the JCL and/or the DSCB? Program Fetch uses the directory data and the c

Re: Concatenations and blocksizes

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 with

Re: Concatenations and blocksizes

-- 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. -- IIRC, that 18-byte min

Re: Concatenations and blocksizes

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 di

Re: Concatenations and blocksizes

Gil, My statement is poorly worded. I know it is not a restriction from XA forward. I was just surprised that it was not required prior to XA Fetch. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Paul Gilmartin > Sent: Monday,

Re: Concatenations and blocksizes

MVS/ESA SP 4 JCL Reference (DFP V3.3): http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea4b608/11.6?ACTION=MATCHES&REQUEST=concatenate&TYPE=FUZZY&SHELF=HAS4BS15&DT=19951023140514&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT tinyurl: h

Re: Concatenations and blocksizes

>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 ho

Re: Concatenations and blocksizes

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

Re: Concatenations and blocksizes

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: Concatenation

Re: Concatenations and blocksizes

>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 tes

Re: 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 now. > And apparently still doesn't. By a crude experiment: //STEPEXEC PGM=IEFBR14 //STEPLIB

Re: Concatenations and blocksizes

Shmuel, Thanks. I'm an XA child, and I was under the impression that the IO mechanism for Fetch changed going from SP2 to XA. 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. Ron > -Original Message---

Re: Concatenations and blocksizes

In <000301ca1735$86fa8130$94ef83...@hawkins1960@sbcglobal.net>, on 08/07/2009 at 01:03 AM, Ron Hawkins 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 away with various releases

Re: Concatenations and blocksizes

In , on 08/06/2009 at 12:21 PM, "Patrick O'Keefe" 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 J.) Metz, SysProg and JOAT ISO position; see

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 with overriding

Re: Concatenations and blocksizes

"Edward Jaffe" 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 realized how little I a

Re: Concatenations and blocksizes

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'

Re: Concatenations and blocksizes

>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 compl

Re: Concatenations and blocksizes

- 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 t

Re: Concatenations and blocksizes

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 thi

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 with overriding attributes where the label contains different >nonzero attributes should ABEND for

Re: Concatenations and blocksizes

John, 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). In one shop I was in a JCL check product was insisting that this was required for production JCL that had worked faultless

Re: Concatenations and blocksizes

On Thu, 6 Aug 2009 18:28:16 -0500 Paul Gilmartin 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 that I have had in t

Re: Concatenations and blocksizes

On Thu, 6 Aug 2009 18:28:16 -0500, Paul Gilmartin 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 >principal us

Re: Concatenations and blocksizes

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

Re: Concatenations and blocksizes

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 lon

Re: Concatenations and blocksizes

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 usin

Re: 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 blocked greater than the blocksize. A

Re: Concatenations and blocksizes

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, wi

Re: Concatenations and blocksizes

>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

Re: Concatenations and blocksizes

This should not be true (AFAIR). >>> "Stocker, Herman" 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 doc that still men

Re: Concatenations and blocksizes

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 tryin

Re: Concatenations and blocksizes

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 lo