IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> wrote on 03/24/2008 07:41:38 PM:
> I dug into the doc once again for more info on Mark's reference to > 'striping'. I find this comment in Diagnosis: Tools and Service Aids: > > "Extended format data sets are supported by z/OS V1R6 and later releases. > Extended format sequential data sets can hold 16,777,215 blocks. If you use > a maximum block size, 29120 bytes, approximately 488 GB can fit. You cannot > use striping or compression options for extended format sequential data > sets. You must use the guaranteed free space option to require DFSMS to > reserve space at the time that the data set is created." > > On the other hand: > > "Large format data sets are supported by z/OS V1R7 and later releases. > Large format (DSNTYPE=LARGE) data sets can span 16,777,215 tracks. If you > use a maximum block size, 29120 bytes, approximately 768 GB can fit. " > > I have two Mod-9 volumes with SYS1.SADMP spanning both as DSNTYPE=LARGE for > a total of 20,032 cylinders. I use the AMDSADDD REXX utility to enable SAD > to write data to both volumes in a way I understood as 'logical striping' > (my term). > > Is there a better option? SADMP uses a blocksize of 24960 for 3390 geometry, not 29120. So that works out to about 383 GB for Extended Sequential, and 766 GB for DSNTYPE=LARGE (assuming the quoted number of blocks and number of tracks limits are correct). We avoid using the term 'Striping' for SADMP data sets, because the way SADMP dumps in parallel to a multi-volume data set is different than what DFSMS does with an Extended Format Sequential data set which has more than one stripe. You can use multi-volume with Extended Format, DSNTYPE=LARGE, or ordinary sequential. SADMP performance-wise, it shouldn't make any significant difference. If you are trying to optimize the dumping speed, for a DS8000 with Ficon channels on a z9 processor, I would use more than two volumes. Using z/OS 1.9 on a z9 with 3 volumes (spread across 3 different DS8000s, although I don't know how relevant that is), I was able to get a data rate of a bit over 300MB per second while dumping real storage, at which point the dumping process became CPU bound. z/OS 1.10 may be a little better - I removed some unnecessary zeroing of I/O buffers in that release - but I haven't gotten around to measuring it yet. A z10 processor should also be better, but I haven't measured that yet either. For slower DASD or channels, a larger number of volumes might be beneficial. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
