"A portion of an overflow record that is written on one track is called a record segment. The write special count, key, and data CCW is used for formatting all segments of an overflow record except the last segment. The last segment is written by the normal write count, key, and data CCW."
IBM System/360 Component Descriptions - 2841 and Associated DASD (PDF) (Eighth ed.), IBM, December 1969, GA26-5988-7 <http://www.bitsavers.org/pdf/ibm/2841/GA26-5988-7_2841_DASD_Component_Descr_Dec69.pdf> Consecutive. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Radoslaw Skorupka <[email protected]> Sent: Friday, August 29, 2025 5:01 AM To: [email protected] <[email protected]> Subject: Re: 256 heads in iebcopy External Message: Use Caution AFAIK the track overflow feature is no longer supported. For years. Actually it is one of the things I have never met in real world but it was mentioned in the documentation. Like CVOL. Regarding track overflow - does it mean the following? 1. Block is being written to track. However the block is too long, so the remaining part is written on another track. 2. The tracks have to be consecutive (or not?) 3. The block can occupy one, two or more tracks. Or only one or two? 4. Track space after last part of the block cannot be used by any other block, that means it remain unused. BTW: Is there any (historical) documentation about track overflow? Just curious, obviously it has no practical meaning nowadays. ;-) -- Radoslaw Skorupka Lodz, Poland W dniu 28.08.2025 o 23:32, Mike Schwab pisze: > Devices with blocksizes under 32K have a feature called track overflow. > When it reaches the end of track the block is continued on the next track, > and the remainder after the last partial block is unused. > > Linkage editors will determine the remaining space on a track and write the > highest multiple of 1K that will fit. Compress in place object modules > reblock to 1KB multiples. > > I assume VB/FB members are reblocked by compress in place, but not sure. > > On Tue, Aug 26, 2025 at 7:22 AM Paul Edwards < > [email protected]> wrote: > >> On Tue, 26 Aug 2025 12:16:06 +0000, Seymour J Metz <[email protected]> wrote: >> >>> My recollection is that COPYMOD is only valid for DASD-DASD. >> I only need DASD to DASD. I only need to transport a single >> load module. >> >> And I (basically) have control over the linker (pdld) that will >> directly produce IEBCOPY (basically) format (artificially >> produce an unloaded load module). >> >> Load modules only exist in DASD, so that's not a problem. >> >> It will look like it has been unloaded from a DASD - but the >> type of DASD is up for grabs. >> >> Note that this already exists, but we're trying to clarify what >> the device characteristics should ideally be for general >> purpose use. I was thinking 1 record per track, 1 head and >> up to 65536 cylinders giving a maximum load module size >> of 384 MiB (with 6144-byte blocks), which is plenty. >> >> But the IEBCOPY manual has a different artificial device. >> But they have a different objective than transporting a >> single load module. >> >> BFN. Paul. >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
