In 4e4e55bc.20...@us.ibm.com, on 08/19/2011
at 08:23 AM, John Eells ee...@us.ibm.com said:
Wow. How long ago was *that*?
I believe that the reblocking was added in OS/VS (both OS/VS1 and
SVS). There were mods to allow the OS/VS version to run under OS/360,
and I'm pretty sure that it was
In 9237906067168226.wa.paulgboulderaim@bama.ua.edu, on
08/19/2011
at 09:09 AM, Paul Gilmartin paulgboul...@aim.com said:
Colorado Interstate Gas?
Formally, Characters In Gap; informally we used a shorter word
beginning with C.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO
In 4e4e7773.20...@acm.org, on 08/19/2011
at 09:47 AM, Joel C. Ewing jcew...@acm.org said:
The requirement was that a physical block not be less than 18 bytes.
Yes, and the requirement was not universal. I no longer recall the
densities and recording modes for which there was an 18-byte CIG
In 5655398806710785.wa.paulgboulderaim@bama.ua.edu, on
08/19/2011
at 10:57 AM, Paul Gilmartin paulgboul...@aim.com said:
Does QSAM generate null segments as needed?
No, AFAIK.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see
In 4e4eb806.1060...@us.ibm.com, on 08/19/2011
at 03:22 PM, John Eells ee...@us.ibm.com said:
(for Shmuel, that's x'1C' ;-)
Shirley '34'8 ;-(
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see http://patriot.net/~shmuel/resume/brief.html
We don't care. We don't have
--snip-
The requirement was that a physical block not be less than 18 bytes.
Yes, and the requirement was not universal. I no longer recall the
densities and recording modes for which there was an 18-byte CIG
issue.
---snip
Does QSAM generate null segments as needed?
--unsnip-
Nope...
Rick
--
For IBM-MAIN
In
1240651948-1313637071-cardhu_decombobulator_blackberry.rim.net-95694995-@b12.c1.bise6.blackberry,
on 08/18/2011
at 03:11 AM, Ted MacNEIL eamacn...@yahoo.ca said:
I thought there was a minimum of 18 bytes for LRECL.
No.
CIG
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO
In p06240804ca73962f3742@[192.168.1.11], on 08/19/2011
at 12:30 AM, Robert A. Rosenberg hal9...@panix.com said:
If you use QSAM (as opposed to BSAM) you would not have access to
this information and I do not think QSAM is smart enough to monitor
the track balance and write short blocks to
Shmuel Metz , Seymour J. wrote:
With accompanying copy utilities. For load libraries IEBCOPY now knows
how to reblock, even though long ago in a galaxy far away it didn't.
Wow. How long ago was *that*?
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com
On Fri, 19 Aug 2011 07:48:19 -0400, Shmuel Metz (Seymour J.) wrote:
In
1240651948-1313637071-cardhu_decombobulator_blackberry.rim.net-95694995-@b12.c1.bise6.blackberry,
on 08/18/2011
at 03:11 AM, Ted MacNEIL said:
I thought there was a minimum of 18 bytes for LRECL.
No.
CIG
Colorado
The requirement was that a physical block not be less than 18 bytes.
Older tape technology could not distinguish blocks shorter than 18 bytes
from tape noise.
Since an FB dataset with LRECL 18 could easily end up with a final
block containing only 1 record (possibly even in the middle of the
On Fri, 19 Aug 2011 09:47:15 -0500, Joel C. Ewing wrote:
The requirement was that a physical block not be less than 18 bytes.
Older tape technology could not distinguish blocks shorter than 18 bytes
from tape noise.
..l.
Similar considerations would also apply to VB files after taking the BDW
and
https://www-304.ibm.com/support/docview.wss?uid=isg1IO00992
2005 Request a setting controlling use of COPY or COPYMOD (reblocks
load modules).
On Fri, Aug 19, 2011 at 7:23 AM, John Eells ee...@us.ibm.com wrote:
Shmuel Metz , Seymour J. wrote:
With accompanying copy utilities. For load
I should know better than to post something obscurely humorous on a Friday.
Some years ago, I drove the original requirements inside IBM against
SMP/E to support the use of COPYMOD, and the corresponding support in
IEBCOPY for PARM=SPCLCMOD to provide RC0 when members are successfully
copied
In 4e4c0066.3070...@us.ibm.com, on 08/17/2011
at 01:54 PM, John Eells ee...@us.ibm.com said:
That really depends on the RECFM and, for variable blocked RECFMs,
the distribution of block sizes. For RECFM=U, 32760 is indeed
optimum
Only for load libraries.
--
Shmuel (Seymour J.)
In 6088519130094044.wa.paulgboulderaim@bama.ua.edu, on
08/17/2011
at 07:43 PM, Paul Gilmartin paulgboul...@aim.com said:
A 32K blocksize is not optimal for 3390
Except for load libraries, which have small control, rld, etc.,
records between the text records and truncated text blocks.
--
Joel's right, of course, that I meant RECFM=U, when used for load
modules. (I must say, though nothing prohibits using RECFM=U for some
other purpose, that I have yet to see it actually done!)
Joel C. Ewing wrote:
Knowing John's background, I would suspect he may have intended to state
For
On Thu, 18 Aug 2011 08:47:10 -0400, Shmuel Metz (Seymour J.) wrote:
on 08/17/2011 at 07:43 PM, Paul Gilmartin said:
A 32K blocksize is not optimal for 3390
(I believe I was quoting Ed G.)
Except for load libraries, which have small control, rld, etc.,
records between the text records and
Seymour's comment about 32K BLKSIZE= values for load libraries needs
qualification. It is on the mark for traditional PDSs containing load modules.
It is off the mark by a factor of 8 for PDSEs containing program objects.
They have an imposed block size of 4K, which should not be/need not be
On Thu, 18 Aug 2011 17:16:36 +, john gilmore wrote:
Seymour's comment about 32K BLKSIZE= values for load libraries needs
qualification. It is on the mark for traditional PDSs containing load
modules. It is off the mark by a factor of 8 for PDSEs containing program
objects. They have an
On 8/18/2011 1:16 PM, john gilmore wrote:
Seymour's comment about 32K BLKSIZE= values for load
libraries needs qualification. It is on the mark for
traditional PDSs containing load modules. It is off the mark
by a factor of 8 for PDSEs containing program objects. They
have an imposed block
snip---
I thought there was a minimum of 18 bytes for LRECL. At least, there was
in 1981, when I learned JCL.
unsnip
Not the LRECL but rather the BLKSIZE.
In snt113-w44b32192034574a3d14da9c6...@phx.gbl, on 08/18/2011
at 05:16 PM, john gilmore john_w_gilm...@msn.com said:
Seymour's comment about 32K BLKSIZE= values for load libraries
needs qualification.
That depends on whether you construe load libraries as libraries
containing load modules. If
In 8816555250779528.wa.paulgboulderaim@bama.ua.edu, on
08/18/2011
at 11:12 AM, Paul Gilmartin paulgboul...@aim.com said:
... or any application sophisticated enough to exploit track
balances.
With accompanying copy utilities. For load libraries IEBCOPY now knows
how to reblock, even
z/OS MVS Program Management User's Guide and Reference, SA22-7643-10, page 39:
| The binder always assigns a block size of 4KB to a program object.
This is unequivocal and confirmned in my now considerable experience with PDSEs
and program objects. This is the z/OS 1.12 edition of this
On Thu, 18 Aug 2011 22:33:30 +, john gilmore wrote:
z/OS MVS Program Management User's Guide and Reference, SA22-7643-10, page 39:
| The binder always assigns a block size of 4KB to a program object.
This is unequivocal and confirmned in my now considerable experience with
PDSEs and
A PDSE is a LINEAR VSAM dataset with 4KB control interval. LINEAR
datasets are also used for DB2 databases.
On Thu, Aug 18, 2011 at 8:20 PM, Paul Gilmartin paulgboul...@aim.com wrote:
On Thu, 18 Aug 2011 22:33:30 +, john gilmore wrote:
z/OS MVS Program Management User's Guide and
At 11:12 -0500 on 08/18/2011, Paul Gilmartin wrote about Re: ABEND - 637-04:
Except for load libraries, which have small control, rld, etc.,
records between the text records and truncated text blocks.
... or any application sophisticated enough to exploit track
balances.
If you use QSAM
the blocksize, if so call the
vendor.
Ed
From: Hal Merritt hmerr...@jackhenry.com
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, August 16, 2011 2:06 PM
Subject: Re: ABEND - 637-04
I would offer a third option: check to see that you are using the maximum
permissible block
-MAIN@bama.ua.edu
Subject: Re: ABEND - 637-04
Hal:
A 32K blocksize is not optimal for 3390 . IIRC it would be 1 block per track
(track size being 48K) Half track blocking or 24K is probably the best, IMO. My
memory is drawing a blank for 3380 (but 36K maybe right) so 18K. Best to use
blksize=0
That really depends on the RECFM and, for variable blocked RECFMs, the
distribution of block sizes. For RECFM=U, 32760 is indeed optimum
(search the archives for why), and for some (not necessarily common)
distributions of variable blocks it might well use space better than
half track
On Wed, 17 Aug 2011 13:54:46 -0400, John Eells wrote:
... Anything that writes a combination of long and
short blocks can yield surprising results. (We found that z/OS fonts,
for example, use the least space at a counterintuitive block size.)
For plain old sequential FB data, though, it's
Knowing John's background, I would suspect he may have intended to state
For RECFM=U, 32760 MAY indeed BE optimum, or perhaps intended to
restrict the remark just to load libraries. I believe all the arguments
in the archives for using block size 32760 with RECFM=U on 3390 were
specifically
--snip
Hal:
A 32K blocksize is not optimal for 3390 . IIRC it would be 1 block per track
(track size being 48K) Half track blocking or 24K is probably the best, IMO. My
memory is drawing a blank for 3380 (but 36K maybe right) so 18K.
27998 and 23476 IIRC, but I believe the OP was talking about copying tapes.
On Wed, Aug 17, 2011 at 6:20 PM, Rick Fochtman rfocht...@ync.net wrote:
--**snip**
Hal:
A 32K blocksize is not optimal for 3390 . IIRC it would be 1 block
On Wed, 17 Aug 2011 09:17:40 -0700, Ed Gould wrote:
A 32K blocksize is not optimal for 3390 . IIRC it would be 1 block per track
(track size being 48K) Half track blocking or 24K is probably the best, IMO. My
memory is drawing a blank for 3380 (but 36K maybe right) so 18K. Best to use
Around 27K for 3390, around 24K for 3380, Ed. Don't know the exact numbers
right off the top of my head.
It depends on the LRECL.
'Full track' is:
47476 for 3380
56664 for 3390
The inter-blocks also contribute.
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
Ted,
Thanks my grey hair is rotting the memory cells:(
Ed
--
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
Gil,
IBM if the product is supported IBM should at least fix it. If it#39;s not
then...
I have only worked with IBM supported products and they fixed issues with SDB
without a squawk.
Ed
--
For IBM-MAIN subscribe / signoff /
: Wed, 17 Aug 2011 19:43:19
To: IBM-MAIN@bama.ua.edu
Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
Subject: Re: ABEND - 637-04
On Wed, 17 Aug 2011 09:17:40 -0700, Ed Gould wrote:
A 32K blocksize is not optimal for 3390 . IIRC it would be 1 block per track
(track size being 48K
On Thu, 18 Aug 2011 03:11:13 +, Ted MacNEIL wrote:
I thought there was a minimum of 18 bytes for LRECL.
At least, there was in 1981, when I learned JCL.
That was for tape, not DASD. And it applied to BLKSIZE, not LRECL.
I just allocated:
Device type . . . . : 3390
Data class . . . .
This is consistent with reaching to volume count limit of 255 volume/dataset
(on tape).
On DASD, the limit id 59 volumes
Check the JCL manual or Using Datasets for more detail.
You have 2 options:
1) Move the file to higher density media. E.g. 3490 --- 3590
2) logically split the file into 2
@bama.ua.edu
Subject: Re: ABEND - 637-04
This is consistent with reaching to volume count limit of 255 volume/dataset
(on tape).
On DASD, the limit id 59 volumes
Check the JCL manual or Using Datasets for more detail.
You have 2 options:
1) Move the file to higher density media. E.g. 3490
Hi all,
I am receiving a message IEC026I during the volumes copies, at the
point of 255 volumes.
Does the volume limits to be copied is 255 ??? What ABEND should be
returned when 255 copies volumes is reached ???
Help is welcome
Many Thanks
Jorge Campos
4Bears Technologies
You would get an abend 837-08 when hitting the volume limit.
Date: Mon, 15 Aug 2011 22:35:26 -0300
From: arue...@gmail.com
Subject: ABEND - 637-04
To: IBM-MAIN@bama.ua.edu
Hi all,
I am receiving a message IEC026I during the volumes copies, at the
point of 255 volumes.
Does
I am receiving a message IEC026I during the volumes copies, at the point of
255
volumes.
Does the volume limits to be copied is 255 ??? What ABEND should be returned
when
255 copies volumes is reached ???
Help is welcome
Many Thanks
What are you using to copy the files/ What
47 matches
Mail list logo
