Re: Concatenations and blocksizes

[Edward Jaffe]

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 long ago did this requirement disappear?
  


ISTR this restriction--and many others--disappeared with the first 
release of DFSMS/MVS circa MVS/ESA 4.3.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Stocker, Herman]

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 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 requirement disappear?
>   

ISTR this restriction--and many others--disappeared with the first release
of DFSMS/MVS circa MVS/ESA 4.3.
-


The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during transmission. By reading the
message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. The sender's employer is not liable for any loss or damage
arising in any way from this message or its attachments.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Scott Rowe]

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 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 requirement disappear?
>   

ISTR this restriction--and many others--disappeared with the first release
of DFSMS/MVS circa MVS/ESA 4.3.
-


The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during transmission. By reading the
message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. The sender's employer is not liable for any loss or damage
arising in any way from this message or its attachments.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html 



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ted MacNEIL]

>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 
hadn't been opened up since then.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Stocker, 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.

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, with the 32760 specification is that
which hadn't been opened up since then.

--


The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during transmission. By reading the
message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. The sender's employer is not liable for any loss or damage
arising in any way from this message or its attachments.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[John Kington]

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

I believe Ed and Ted are right about the largest blocksize first restriction on 
concatenations being lifted with MVS/ESA.

Regards,
John

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Gerhard Postpischil]

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 using SAM support, but with CCWs directly, where text 
block size is set from the previous control record, without ever 
checking a DCB or other control block for sizes.


For other libraries, I recall the easing of the requirement in 
the eighties; we skipped ESA 4, so the change could have come as 
early as XA or even SP?


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

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 longer BLKSIZE and subsequently
opened and written with a shorter BLKSIZE.  Thus it would contain
(perhaps even to this day) a block exceeding the length in the DSCB.
This would cause I/O errors which could be circumvented by
overriding to 32760.

>-< snip>-
>
>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 hadn't been opened up since then.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

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 which causes the blocksize in the vtoc to be changed.
>
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 inconsistent attributes.

If the programmer feels compelled to change attributes the
recourse should be:

o ZAP the VTOC, or

o COPY, reblock, and rename.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Patrick O'Keefe]

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 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 inconsistent attributes.
 
I strongly agree with that, but ...

>If the programmer feels compelled to change attributes the
>recourse should be:
>
>o ZAP the VTOC, or

... I don't agree with that.Using a utility that requires knowing
the format of the label is asking for trouble.  Sure, zapping the VTOC
is don't gazillions of times a year, but it's (usually) done by techies.
The fixing of a hosed over blocksize should be able to be done by
the same people that hosed it over in the first place, and it should 
be safe enough that it won't hose over something else.  But it 
should NOT be a function available in data copying utilities like GENER.
The should fail as you mentioned.
 
>o COPY, reblock, and rename.

Well, yes, definitely ... if the dataset is readable enough do do that.

Pat O'Keefe
>...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Binyamin Dissen]

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 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 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 inconsistent attributes.

And they should have training wheels on their tricycle?

:>If the programmer feels compelled to change attributes the
:>recourse should be:

:>o ZAP the VTOC, or

:>o COPY, reblock, and rename.

I could accept requiring a special DCB option to do this, but to prevent the
user from manipulating his data?

Will you require double checking the DCB against the label for every operation
as either may have changed?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ron Hawkins]

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 faultlessly for years.

Are you able to recreate the error and post it to the list?

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> John Kington
> Sent: Thursday, August 06, 2009 11:34 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] 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
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.
> 
> I believe Ed and Ted are right about the largest blocksize first
restriction
> on concatenations being lifted with MVS/ESA.
> 
> Regards,
> John
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[John Kington]

>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 inconsistent attributes.

>If the programmer feels compelled to change attributes the
>recourse should be:

>o ZAP the VTOC, or
I use the same mis-design to reset it back to the original blocksize. If the 
change was recent (last couple of days), I make an attempt to find the culprit 
and have them fix their jcl. Zapping the vtoc is the last (*very* reluctant) 
resort and only to be done by a very select few. 

>o COPY, reblock, and rename.
This is the proper way to make a planned, permanent change to the dataset 
attributes.

Regards,
John

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[John Kington]

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 was
>required for production JCL that had worked faultlessly for years.
>
>Are you able to recreate the error and post it to the list?

I believe Herman has the problem with blocksize in a concatenation.

Regards,
John

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Klein, Kenneth]

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. 


Ken Klein
Sr. Systems Programmer
Kentucky Farm Bureau Insurance - 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 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 inconsistent attributes.

>If the programmer feels compelled to change attributes the recourse 
>should be:

>o ZAP the VTOC, or
I use the same mis-design to reset it back to the original blocksize. If
the change was recent (last couple of days), I make an attempt to find
the culprit and have them fix their jcl. Zapping the vtoc is the last
(*very* reluctant) resort and only to be done by a very select few. 

>o COPY, reblock, and rename.
This is the proper way to make a planned, permanent change to the
dataset attributes.

Regards,
John

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ted MacNEIL]

>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 because that portion of the code is out of date?

Until I see a true problem posted (and documented), I'm going to continue to 
believe this issue was 'fixed' aeons ago.
I've not seen this occur in years!

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Tom Marchant]

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 seen ISRDDN report other kinds of error, like a mix of FB and
VB.  I jost looked and saw this (dsnames omitted):

Blksz Lrecl RCFM Org  Act DDname  
 408080 FB   >ISPCTL0 
 408080 FB   >ISPCTL1 
 408080 FB   >ISPCTL2 
 408080 FB   >ISPCTL3 
 >ISPLLIB 
18432** UPO  >
18432** UPO  >
18432** UPO  >
27998** UPO  >
 6144** UPO  >
32760** UPO  >
32760** UPO  >
18432** UPO  >
 >ISPMLIB 
 360080 FB   PO  >
 312080 FB   PO  >
 312080 FB   PO  >
2792080 FB   PO  >
2792080 FB   PO  >
2792080 FB   PO  >
 >ISPPLIB 
2792080 FB   PO  >
 312080 FB   PO  >
 312080 FB   PO  >
2792080 FB   PO  >
2792080 FB   PO  >
2792080 FB   PO  >
2792080 FB   PO  >
2792080 FB   PO  >
 616080 FB   PO  >ISPPROF 
 >ISPSLIB 
 312080 FB   PO  >
2792080 FB   PO  >
2792080 FB   PO  >
2792080 FB   PO  >
2792080 FB   PO  >
 >ISPTLIB 
2792080 FB   PO  >
2792080 FB   PO  >
2792080 FB   PO  >
 >SYSEXEC 
2792080 FB   PO  >
3272080 FB   LIB >
2792080 FB   PO  >
2792080 FB   PO  >
2792080 FB   PO  >
 >SYSHELP 
2792080 FB   PO  >
2792080 FB   PO  >
 >SYSPROC 
3272080 FB   LIB >
2792080 FB   PO  >
2792080 FB   PO  >   

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Michel Castelein]

"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 actually
> > knew about the topic.  So I've got some questions.  (Idle curiosity.)
> >
> > 1.  How long ago did this requirement disappear?
> >
>
> ISTR this restriction--and many others--disappeared with the first
> release of DFSMS/MVS circa MVS/ESA 4.3.
>

IMHO, it's beginning with MVS/DFP V3R3 that you can concatenate in any order
of block size DASD(!) data sets that are accessed by QSAM or BSAM.
MVS/DFP V3R3 is the immediate predecessor of DFSMS/MVS V1R1.

Michel Castelein
z/OS instructor
http://www.arcis-services.net/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Rick Fochtman]

---


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 inconsistent attributes.
   


If the programmer feels compelled to change attributes the
recourse should be:
   


o ZAP the VTOC, or
   

I use the same mis-design to reset it back to the original blocksize. If the change was recent (last couple of days), I make an attempt to find the culprit and have them fix their jcl. Zapping the vtoc is the last (*very* reluctant) resort and only to be done by a very select few. 
 


---
IIRC AMASPZAP will ask the operator for permission before allowing this 
sort of ZAP. Our operators were told that under NO CIRCUMSTANCES were 
they to allow this. I had a special (private) version of AMASPZAP that 
did not issue the operator query and via RACF Program Protection, the 
use of that version was limited to exactly two people, who could not 
both be on vacation at the same time (for a variety of reasons.)


For this particular problem, we just used IEBGENER to copy a dummy 
member into the dataset and provided the correct dataset attributes on 
the DD statement. I had a "quick and dirty" program to determine the 
size of the largest block in the dataset, and the member name, so that I 
could affect the necessary corrections.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Shmuel Metz (Seymour J.)]

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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Shmuel Metz (Seymour J.)]

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 of DFP and DFSMS.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ron Hawkins]

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-
> 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/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 of DFP and DFSMS.
> 
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

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  DD  DISP=SHR,DSN=SYS1.LINKLIB,BLKSIZE=1

Worked fine.

(But did I really test what I thought I tested?)

>> -Original Message-
>> 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
>>
>> >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 of DFP and DFSMS.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ted MacNEIL]

>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 tested?)

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.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Schwarz, Barry A]

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 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 tested?)

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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Richard Peurifoy]

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 what I thought I tested?)


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.


I think what he Gill was testing was that program fetch didn't care
about blksize, in which case I think he did test it, and got the
result I would expect. There may have been a time when program fetch
cared, but if so, I don't remember it.

By the way I think the 18 byte minimum was only for tape.

--
Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ted MacNEIL]

>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 hole, now!
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Mark Zelden]

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: http://tinyurl.com/m95evc


MVS/ESA SP 5 JCL Reference (DFSMS V1):

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea4b601/11.6?ACTION=MATCHES&REQUEST=concatenate&TYPE=FUZZY&SHELF=HAS4BK13&DT=19920925103155&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT

tinyurl: http://tinyurl.com/m25p6y


More info from DFP 3.3 Using Data Sets on concatenating like data sets:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igg3d400/3.7.2.2.1?ACTION=MATCHES&REQUEST=blksize&TYPE=FUZZY&SHELF=IGG3BK04&DT=19911220191126&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT

tinyurl: http://tinyurl.com/lvonxq


--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ron Hawkins]

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, 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
now.
> >
> And apparently still doesn't.  By a crude experiment:
> 
> //STEPEXEC PGM=IEFBR14
> //STEPLIB  DD  DISP=SHR,DSN=SYS1.LINKLIB,BLKSIZE=1
> 
> Worked fine.
> 
> (But did I really test what I thought I tested?)
> 
> >> -Original Message-
> >> 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
> >>
> >> >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 of DFP and DFSMS.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Mark Zelden]

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 different block sizes in any
order; the largest no longer need be first.  Eligible data sets are
partitioned or sequential data sets that are DASD-resident, accessed
by QSAM, and for which the system obtained buffer space.
   This enhancement responded to SHARE requirement SOMVSE85065."

http://www-01.ibm.com/common/ssi/ShowDoc.jsp?docURL=/common/ssi/rep_ca/8/897/ENUS292-308/index.html&breadCrum=DET001PT022&url=buttonpressed=DET002PT005&specific_index=DET001PEF502&DET015PGL002=DET001PEF011&submit.x=7&submit.y=8&lang=en_US

tinyurl:  http://tinyurl.com/nn7zk2

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html




On Mon, 10 Aug 2009 14:22:04 -0500, Mark Zelden 
wrote:

>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: http://tinyurl.com/m95evc
>
>
>MVS/ESA SP 5 JCL Reference (DFSMS V1):
>
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea4b601/11.6?ACTION=MATCHES&REQUEST=concatenate&TYPE=FUZZY&SHELF=HAS4BK13&DT=19920925103155&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
>
>tinyurl: http://tinyurl.com/m25p6y
>
>
>More info from DFP 3.3 Using Data Sets on concatenating like data sets:
>
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igg3d400/3.7.2.2.1?ACTION=MATCHES&REQUEST=blksize&TYPE=FUZZY&SHELF=IGG3BK04&DT=19911220191126&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
>
>tinyurl: http://tinyurl.com/lvonxq
>
>
>--
>Mark Zelden
>Sr. Software and Systems Architect - z/OS Team Lead
>Zurich North America / Farmers Insurance Group - ZFUS G-ITO
>mailto:mark.zel...@zurichna.com
>z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
>Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Rick Fochtman]

--
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 minimum applied only to tape. It was necessary so 
that the drive could distinguish between inter-block gaps and legitimate 
blocks.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Robert A. Rosenberg]

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


IMO: This is (or should be) only an error if the supplied Blocksize 
is SMALLER than the VTOC one. Making the Blocksize larger (so long as 
it is still a multiple of the LRECL for a FB file and the RECFM is 
not FBS) has no effect since the now shorter blocks will still be 
read correctly. Only REDUCING the VTOC Blocksize would make 
older/larger blocks unreadable.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Rick Fochtman]

-
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 control data imbedded in 
the load module to do its I/O at a channel program level. As long as 
it's a valid LMOD, the DCB info is completely meaningless to Fetch. 
IIRC, the DCB it uses is a "skeleton" DCB similar to that used during 
EXCP or XDAP processing. As long as it has a valid DEB, that's what 
really matters.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Bill Fairchild]

You have always been able to write a block of only one byte, or even zero 
bytes, onto a DASD.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-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'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 minimum applied only to tape. It was necessary so 
that the drive could distinguish between inter-block gaps and legitimate 
blocks.

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Patrick O'Keefe]

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 sets that are DASD-resident, accessed
>by QSAM, and for which the system obtained buffer space.
>...

Interesting wording. 
"partitioned ... data sets ... accessed by QSAM ..."

If they really meant that, wouldn't that restrict this enhancement
to a concatenation sequential datasets and/or PDS members?
Doesn't a PDS or concatenation of PDSs have to be accessed by
BPAM? 

I assume they meant QSAM or BPAM.
(I could ask for the umpteenth time why there is no QPAM, but
I won't.)

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

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
method deal with a program that does RECFM=VB; OPEN
PUT RDW has count of 4; CLOSE; which would generate
an 8-byte block.  This might easily happen inadvertently
if a preceding block was filled and the 8-byte (or up
to 17-byte) block was the last block written before
CLOSE.  If RECFM=VBS, the access method _could_
pad with a null segment, but I don't know that null
segments are allowed for non-Spanned RECFM.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Bill Fairchild]

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 zero onto a track, you put the block 
length into an 8-byte area in which you are building the count field and you 
set the CCW's byte count to 8, for the number of bytes to be transferred to the 
controller and written onto the track as a count field.  When your software 
tries to read this block back later, the controller sees the data length of 
zero and signals unit exception along with the other ending status, then the 
access method interprets unit exception as end of file and invokes your EOF 
routine if you have one.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Paul Gilmartin
Sent: Monday, August 10, 2009 4:18 PM
To: IBM-MAIN@bama.ua.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.)

As for the minimum of 18 for tape, how does the access
method deal with a program that does RECFM=VB; OPEN
PUT RDW has count of 4; CLOSE; which would generate
an 8-byte block.  This might easily happen inadvertently
if a preceding block was filled and the 8-byte (or up
to 17-byte) block was the last block written before
CLOSE.  If RECFM=VBS, the access method _could_
pad with a null segment, but I don't know that null
segments are allowed for non-Spanned RECFM.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

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.  Eligible data sets are
>>partitioned or sequential data sets that are DASD-resident, accessed
>>by QSAM, and for which the system obtained buffer space.
>>...
>
I think an earlier contributor wrote "DASD or tape".  I
found that unlikely because each tape label would have
to be read by OPEN; I welcome the clarification.  But
I could believe it would suffice if either the largest
block size was DASD-resident or it was specified in the
DD statement.

>Interesting wording.
>"partitioned ... data sets ... accessed by QSAM ..."
>
>If they really meant that, wouldn't that restrict this enhancement
>to a concatenation sequential datasets and/or PDS members?
>Doesn't a PDS or concatenation of PDSs have to be accessed by
>BPAM?
>
>I assume they meant QSAM or BPAM.
>(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 specifying the offset of the current record
within a block.  But that merely regresses the question (which
you didn't ask) one level.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Thompson, Steve]

-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 
 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 sets that are DASD-resident, accessed
>by QSAM, and for which the system obtained buffer space.
>...

Interesting wording. 
"partitioned ... data sets ... accessed by QSAM ..."

If they really meant that, wouldn't that restrict this enhancement
to a concatenation sequential datasets and/or PDS members?
Doesn't a PDS or concatenation of PDSs have to be accessed by
BPAM? 



No. If you take a program that uses a QSAM DCB and point the DD
statement to a PDS with member name, it will read that member and treat
it as if it were reading a DSORG=PS data set. The QSAM code will detect
end of member and treat that as if it were EOD (and I think it even
drives your EOV exit if you have one).

So if you concatenate a series of DSORG=PS data sets together, you can't
concatenate a PDS as a PDS in the middle. Well, maybe you can, if you
forced RECFM=U and BUFL=32760. But enjoy the dir blocks followed by ALL
the data blocks (as gas or still in use). 

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 when the
FIND or BLDL that you do doesn't find any directory blocks in the
DSORG=PS file (you might even get an early ABEND out of OPEN - I haven't
tried this trick in a while).

Regards,
Steve Thompson

-- Opinions expressed by this poster may not reflect those held by
poster's employer --

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Patrick O'Keefe]

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: Concatenations and blocksizes
>
>On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden
> 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 members?

Ok.   I shouldn't have included that statement.  It just muddied the
water.

>Doesn't a PDS or concatenation of PDSs have to be accessed by
>BPAM?

That's what I was really trying to ask.  

>...
>No. If you take a program that uses a QSAM DCB and point the DD
>statement to a PDS with member name, it will read that member 
>and treat it as if it were reading a DSORG=PS data set. The QSAM
>code will detect end of member and treat that as if it were EOD 
>(and I think it even drives your EOV exit if you have one).

I know a single member can be read with QSAM.
I assume a concatenation of members can be read by QSAM.
I was actually trying to exclude that uninteresting case from 
consideration.

>...
>So if you concatenate a series of DSORG=PS data sets together, 
>you can't concatenate a PDS as a PDS in the middle. ...

And I didn't want to.

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

And luckily I didn't want to do that, either.

I'm just puzzled that the enhancement limited itself to QSAM.
No mention of BPAM.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

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=FB,LRECL=80,BLKSIZE=80
//  DD  DISP=SHR,DSN=SYS1.MACLIB

Fails with:

* TOP OF DATA **
** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYSL
 ,HELLO   ,C   ,4140,D,SYSLIB  ,UNKOWN,WRNG.LEN.RECORD,1F7100030
 BOTTOM OF DATA 

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Patrick O'Keefe]

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:
>
>//SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,1)),
>//  RECFM=FB,LRECL=80,BLKSIZE=80
>//  DD  DISP=SHR,DSN=SYS1.MACLIB
>
>Fails with:
>
>* TOP OF DATA 
**
>** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent 
I/O error on SYSL
> ,HELLO   ,C   ,4140,D,SYSLIB  ,UNKOWN,WRNG.LEN.RECORD,00
001F7100030
>...

Um, I've got a hunch that wasn't a concatenation problem.  Did you 
have another dataset in the concatenation with a large blocksize?
If not, you probably got a blocksize of 80 ... much smaller than the
length of the records (blocks) that have to be read.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Richard Peurifoy]

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,(1,1)),
//  RECFM=FB,LRECL=80,BLKSIZE=80
//  DD  DISP=SHR,DSN=SYS1.MACLIB

Fails with:

* TOP OF DATA **
** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYSL
 ,HELLO   ,C   ,4140,D,SYSLIB  ,UNKOWN,WRNG.LEN.RECORD,1F7100030
 BOTTOM OF DATA 



Unless there is a typo, you concatenated a seq file (no directories)
with the PDS.

--
Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Gerhard Postpischil]

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 zero onto a track, you put
the block length into an 8-byte area in which you are
building the count field and you set the CCW's byte count to
8, for the number of bytes to be transferred to the
controller and written onto the track as a count field.  When
your software tries to read this block back later, the
controller sees the data length of zero and signals unit
exception along with the other ending status, then the access
method interprets unit exception as end of file and invokes
your EOF routine if you have one.


Correct, but slightly (?) misleading. The CCW byte count alone 
won't do it, unless the count record also has a key length and 
data length of zero set (interesting I/O errors result 
otherwise). To complicate matters, it is valid and occasionally 
desirable to have a write length other than 8, by writing a key 
+ zero data length. It's one way of stopping a search CCW on a 
later I/O.




Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

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.  An assembly with:
>>
>> //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,1)),
>> //  RECFM=FB,LRECL=80,BLKSIZE=80
>> //  DD  DISP=SHR,DSN=SYS1.MACLIB
>>
>Unless there is a typo, you concatenated a seq file (no directories)
>with the PDS.
>
You mean I need _two_ commas, not just one?

Why does OPEN let me do that, and not just ABEND?

OK.  I changed to:

   6 //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,,1)),
 //  DISP=NEW,DSN=&&MAC,
 //  RECFM=FB,LRECL=80,BLKSIZE=80
 X/SYSLIB   DD  DSN=SYS1.MACLIB,DISP=SHR
   7 //  DD  DISP=SHR,DSN=SYS1.MACLIB

I needed to specify DISP and DSN to override those in the
library proc.

And it fails the same with:

* TOP OF DATA **
** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYSL
 ,HELLO   ,C   ,4140,D,SYSLIB  ,UNKOWN,WRNG.LEN.RECORD,1F7100030
 BOTTOM OF DATA 

Experimental control: if I change BLKSIZE from 80 to 32760,
it assembles with no errors, and library macros are fetched
from the second catenand.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ron Hawkins]

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

> -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 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.  An assembly with:
> >>
> >> //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,1)),
> >> //  RECFM=FB,LRECL=80,BLKSIZE=80
> >> //  DD  DISP=SHR,DSN=SYS1.MACLIB
> >>
> >Unless there is a typo, you concatenated a seq file (no directories)
> >with the PDS.
> >
> You mean I need _two_ commas, not just one?
> 
> Why does OPEN let me do that, and not just ABEND?
> 
> OK.  I changed to:
> 
>6 //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,,1)),
>  //  DISP=NEW,DSN=&&MAC,
>  //  RECFM=FB,LRECL=80,BLKSIZE=80
>  X/SYSLIB   DD  DSN=SYS1.MACLIB,DISP=SHR
>7 //  DD  DISP=SHR,DSN=SYS1.MACLIB
> 
> I needed to specify DISP and DSN to override those in the
> library proc.
> 
> And it fails the same with:
> 
> * TOP OF DATA
> **
> ** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error
on
> SYSL
>  ,HELLO   ,C   ,4140,D,SYSLIB
> ,UNKOWN,WRNG.LEN.RECORD,1F7100030
>  BOTTOM OF DATA
> 
> 
> Experimental control: if I change BLKSIZE from 80 to 32760,
> it assembles with no errors, and library macros are fetched
> from the second catenand.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

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 statement 6 and before statement 7 is the clue.
>
It appears that line displays the content of the overridden statement,
not the overriding.  When I change only the BLKSIZE:

6 //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,,1)),
  //  DISP=NEW,DSN=&&MAC,
  //  RECFM=FB,LRECL=80,BLKSIZE=32760
  X/SYSLIB   DD  DSN=SYS1.MACLIB,DISP=SHR
7 //  DD  DISP=SHR,DSN=SYS1.MACLIB

the assembly succeeds with no messages.  The Assembler Summary in
SYSPRINT shows a temp DSN as the first catenand:

   Diagnostic Cross Reference and Assembler Summ

  No Statements Flagged in this Assembly
 HIGH LEVEL ASSEMBLER, 5696-234, RELEASE 5.0, PTF UK10754
 SYSTEM: z/OS 01.07.00  JOBNAME: HELLO   STEPNAME: DOIT   PR
 Data Sets Allocated for this Assembly
  Con DDname   Data Set NameVolume  Member
   P1 SYSINuser.HELLO.JOB05565.D101.?
   L1 SYSLIB   SYS09222.T170822.RA000.HELLO.MAC.H01 WORK02
   L2  SYS1.MACLIB  MVS3RS
  SYSLIN   SYS09222.T170822.RA000.HELLO.OBJ.H01
  SYSPRINT user.HELLO.JOB05565.D102.?
  SYSTERM  user.HELLO.JOB05565.D104.?

>> -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
>>
>> OK.  I changed to:
>>
>>6 //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,,1)),
>>  //  DISP=NEW,DSN=&&MAC,
>>  //  RECFM=FB,LRECL=80,BLKSIZE=80
>>  X/SYSLIB   DD  DSN=SYS1.MACLIB,DISP=SHR
>>7 //  DD  DISP=SHR,DSN=SYS1.MACLIB
>>
>> I needed to specify DISP and DSN to override those in the
>> library proc.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Rick Fochtman]

--
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 Exception, meaning a EOF mark.


That's what you might call a "special case". :-)

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Richard Peurifoy]

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, but apparently
not.  An assembly with:

//SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,1)),
//  RECFM=FB,LRECL=80,BLKSIZE=80
//  DD  DISP=SHR,DSN=SYS1.MACLIB


Unless there is a typo, you concatenated a seq file (no directories)
with the PDS.


You mean I need _two_ commas, not just one?

Why does OPEN let me do that, and not just ABEND?

OK.  I changed to:

   6 //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,,1)),
 //  DISP=NEW,DSN=&&MAC,
 //  RECFM=FB,LRECL=80,BLKSIZE=80
 X/SYSLIB   DD  DSN=SYS1.MACLIB,DISP=SHR
   7 //  DD  DISP=SHR,DSN=SYS1.MACLIB

I needed to specify DISP and DSN to override those in the
library proc.

And it fails the same with:

* TOP OF DATA **
** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYSL
 ,HELLO   ,C   ,4140,D,SYSLIB  ,UNKOWN,WRNG.LEN.RECORD,1F7100030
 BOTTOM OF DATA 

Experimental control: if I change BLKSIZE from 80 to 32760,
it assembles with no errors, and library macros are fetched
from the second catenand.


Interesting, I tried a temp PDS, and also failed, so I tried
a permanent PDS with a small blksize and it worked ok.

I then tried allocating a temp pds in a previous step and passed it.
This also worked ok. I don't know why it fails if allocated in
the same step.

--
Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Rick Fochtman]

-
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, have a value of zero for the data 
length, thus writing a EOF mark.


If a Update Write doesn't have the correct size, you'll get a Unit Check 
or Unit Exception (I forget which) with Incorrect Length set..


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Rick Fochtman]

-
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 end up reading all 
the directories. The old ASMG product from the University of Waterloo 
used this method to load the directories of all the SYSLIB datasets, 
saving a lot of time and I/O during macro expansion. By so doing, it was 
able to use POINT, rather than BLDL/FIND to locate macros and copy code 
in the SYSLIB concatenation.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Bill Fairchild]

My point was that one is smaller than 18, and zero is also smaller than 18.  
The controversy is whether or not a DASD block with a block size smaller than 
18 can be written onto a DASD, not over what happens when said block is read 
back in.  An earlier post said that a block size smaller than 18 is considered 
a noise record.  That is true for tapes but not DASD.  A unit exception, aka 
EOF, is not the same as a noise record.  EOF is signaled on tape with a tape 
mark, which is written with a Write Tape Mark CCW command, not with a Write CCW 
with a length smaller than 18, but an EOF on DASD is signaled with a data 
length of zero, which is written with a WCKD or WCKD Next Track CCW command, 
with a byte count of at least 8, and pointing to a count field containing zero 
in the data field.  There has never been a requirement on IBM mainframe DASD, 
from S/360 through z/whatever, that the data field be no smaller than 18.  
There is such a requirement for tape I/O.

Does anyone have a copy of the 3081 Channel Characteristics manual?  I have 
been told that this book describes a situation in which a 3380 did not work 
correctly with a block size smaller than 18 and want to see exactly what it 
says.  Thanks.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [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, onto a DASD.
--
One byte, yes. But if the device reads a count field with a data length 
of zero, it signals a Unit Exception, meaning a EOF mark.

That's what you might call a "special case". :-)

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Rick Fochtman]

-


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=FB,LRECL=80,BLKSIZE=80
   //  DD  DISP=SHR,DSN=SYS1.MACLIB

 


Unless there is a typo, you concatenated a seq file (no directories)
with the PDS.

   


You mean I need _two_ commas, not just one?

Why does OPEN let me do that, and not just ABEND?

OK.  I changed to:

  6 //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,,1)),
//  DISP=NEW,DSN=&&MAC,
//  RECFM=FB,LRECL=80,BLKSIZE=80
X/SYSLIB   DD  DSN=SYS1.MACLIB,DISP=SHR
  7 //  DD  DISP=SHR,DSN=SYS1.MACLIB

I needed to specify DISP and DSN to override those in the
library proc.

And it fails the same with:

* TOP OF DATA **
** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYSL
,HELLO   ,C   ,4140,D,SYSLIB  ,UNKOWN,WRNG.LEN.RECORD,1F7100030
 BOTTOM OF DATA 

Experimental control: if I change BLKSIZE from 80 to 32760,
it assembles with no errors, and library macros are fetched
from the second catenand.
 


-
In your first example, you concatenated a PDS behind a PS dataset; 
AFAIK, this is never allowed.


In both examples, you seem to expect exactly correct records to be 
available. You have NO right to expect this because of your first 
(temporary) dataset, because there might be residual data on that track. 
In the second example, you've at least formatted the track withm a 
single directory block. But by specifying BLKSIZE=80, you've essential 
"set the stage", by overriding what the system can do. I'd be willing to 
wager that if you left the BLKSIZE off that first dataset, it might also 
work just fine.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Scott Rowe]

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:20 AM >>>
Interesting, I tried a temp PDS, and also failed, so I tried
a permanent PDS with a small blksize and it worked ok.

I then tried allocating a temp pds in a previous step and passed it.
This also worked ok. I don't know why it fails if allocated in
the same step.

--
Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html 



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[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 to be true. If I code a blksize on the DDCARD of the passed
temp dataset in the ASM step, it also fails. I guess this means the
system (or assembler) will use the largest blksize at open time if
there is no blksize in any JFCB's. Obviously the system can't override
a blksize coded on a DCB macro.

--
Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

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 time.  I 
>> suspected that it would work this way.
>
>This appears to be true. If I code a blksize on the DDCARD of the passed
>temp dataset in the ASM step, it also fails. I guess this means the
>system (or assembler) will use the largest blksize at open time if
>there is no blksize in any JFCB's. Obviously the system can't override
>a blksize coded on a DCB macro.
>
Thanks.  I'll try not to do that anymore.  I wonder whether the
behavior is properly documented?

But it explains why I've experienced no BLKSIZE problems lately in
concatenations, despite not being very diligent about order or
overrides.

BTW, I noticed post facto that in my successful test I had coded
BLKSIZE=32760.  That's not even a multiple of 80.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Donald Johnson]

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 I run with PDS-2 ahead of PDS-1, it works fine.

If this is no longer an issue, shouldn't IBM's own code work correctly?

Don

On Thu, Aug 6, 2009 at 1:21 PM, 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 long ago did this requirement disappear?
> 2.  Did SMS relax the restriction or did it cover all concatenations?
> 3.  What changed?  Does OPEN find the largest blocksize in the
> concatenation before allocating buffers, or does it simply allocate
> buffers large enough for any blocksize?   Or something else
> altogether?
> 4.  Are there still instances of concatenations with this restriction?
>
> Thanks.
>
> Pat O'Keefe
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

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 get error messages ASMA057E
>Undefined operation code...
>
>When I run with PDS-2 ahead of PDS-1, it works fine.
>
>If this is no longer an issue, shouldn't IBM's own code work correctly?
>
Since you didn't get I/O errors, this appears not to be a BLKSIZE
problem.

o Read the Macro and Copy Summary and verify that the same macros
  were read from the same data sets in both cases.

o Add an overriding BLKSIZE=32720 do PDS-1 and see if the results
  differ.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Rick Fochtman]

--


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 I run with PDS-2 ahead of PDS-1, it works fine.

If this is no longer an issue, shouldn't IBM's own code work correctly?

Don
 


---
Don, the issue you present has nothing to do with BLKSIZE values. 
Somewhere in those two libraries you have a duplicate member name. The 
version in LIB1 has a problem, whereas the version in LIB2 does not. A 
good starting point for your search would be the flagged macro call in 
your source code, then look at the macros called inside other macros 
down that chain. It can be a tough search, but eventually you'll find 
something; trust me cus' I've been down that route more often than I'd 
care to admit.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Donald Johnson]

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  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 get error messages ASMA057E
>> Undefined operation code...
>>
>> When I run with PDS-2 ahead of PDS-1, it works fine.
>>
>> If this is no longer an issue, shouldn't IBM's own code work correctly?
>>
>> Don
>>
>>
> ---
> Don, the issue you present has nothing to do with BLKSIZE values. Somewhere
> in those two libraries you have a duplicate member name. The version in LIB1
> has a problem, whereas the version in LIB2 does not. A good starting point
> for your search would be the flagged macro call in your source code, then
> look at the macros called inside other macros down that chain. It can be a
> tough search, but eventually you'll find something; trust me cus' I've been
> down that route more often than I'd care to admit.
>
> Rick
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Schwarz, Barry A]

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Patrick O'Keefe]

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 said about 
NOTE on Mon, 10 Aug 2009 16:31:31 -0500: regarding my QPAM
question:

"... it's because the definition of the NOTE word has no
provision for specifying the offset of the current record
within a block. "

Or maybe I just misunderstood Gil's comment.  Maybe I don't know
what use of NOTE he was refering to.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Rick Fochtman]

---


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 and has no connection with a specific logical record (in most cases.)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

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.
>
>Doesn't that also argue against what Paul Gilmartin said about
>NOTE on Mon, 10 Aug 2009 16:31:31 -0500: regarding my QPAM
>question:
>
>"... it's because the definition of the NOTE word has no
>provision for specifying the offset of the current record
>within a block. "
>
>Or maybe I just misunderstood Gil's comment.  Maybe I don't know
>what use of NOTE he was refering to.
>
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 the current
  source record relative to that block

o Does a FIND to open the referenced member.

At the end of that member, it reverses the process
with a POINT and displacing to the saved offset.

If the motivation of Q*AM is to make blocking and
unblocking transparent to the program, the putative
QNOTE would need to save both the TTR and the record
offset in an opaque data object.  QPOINT would need
to employ both.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Patrick O'Keefe]

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 the current
>  source record relative to that block
>
>o Does a FIND to open the referenced member.
>
>At the end of that member, it reverses the process
>with a POINT and displacing to the saved offset.
>
>If the motivation of Q*AM is to make blocking and
>unblocking transparent to the program, the putative
>QNOTE would need to save both the TTR and the record
>offset in an opaque data object.  QPOINT would need
>to employ both.
>...

Ok.  I agree.   A Q*AM version of NOTE and POINT would have to
include record number or block offset or some such (just as that 
info has to be added to the NOTE data by a B*AM program).

All those about to submit a formal request for QPAM should take
note (so to speak).

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Binyamin Dissen]

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 mark the current block.

:>>o Saves the NOTE word _and_ the offset of the current
:>>  source record relative to that block

:>>o Does a FIND to open the referenced member.

:>>At the end of that member, it reverses the process
:>>with a POINT and displacing to the saved offset.

:>>If the motivation of Q*AM is to make blocking and
:>>unblocking transparent to the program, the putative
:>>QNOTE would need to save both the TTR and the record
:>>offset in an opaque data object.  QPOINT would need
:>>to employ both.
:>>...

:>Ok.  I agree.   A Q*AM version of NOTE and POINT would have to
:>include record number or block offset or some such (just as that 
:>info has to be added to the NOTE data by a B*AM program).

As most QSAM programs pay not attention to blocks, and that their data files
are more freely available for reblocking, the results of the NOTE would have
to be a relative record number and not a TTR+RecordOffset. The system would
have to calculate a TTR from it - which may require reading the entire dataset
(also for POINT) up to there to make sure there ain't no short blocks.

:>All those about to submit a formal request for QPAM should take
:>note (so to speak).

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html