Re: IDCAMS and DF/SORT support for LBI
Tom Harper wrote on 09/14/2006 05:56:24 PM: > Frank, > I have more information than I had earlier. A colleague was trying to > read a VB large block tape data set, and it was failing. Their comment > to me was that LBI did not work with DF/SORT. When I couldn't find > anything (due to the difference in keywords), I posted the question. > What they meant by "didn't work" and what I interpreted it to mean were > two different things. In my mind, I guess, it would not have occurred to > me the DF/SORT would have an error in the code (it is rock-solid, thank > you), so I thought he meant it was not supported. He has since opened an > incident with IBM support. > > So apparently, there is officially support for tape VB LBI for SORTIN > data sets, just at the moment it has a flaw in it. Tom, I was just "consulting" with IBM service on this incident and we believe the problem is a user error that has to do with the LRECL being used, and not with LBI. But we need to confirm this with the customer. Frank Yaeger - DFSORT Team (IBM) Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ -- 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
Re: IDCAMS and DF/SORT support for LBI
On Thu, 14 Sep 2006 22:21:22 -0500, Tom Schmidt misspoke: >On Thu, 14 Sep 2006 18:29:19 -0400, Thompson, Steve (SCI TW) wrote: > >>-Original Message- >>From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On >>Behalf Of Tom Schmidt >>Sent: Thursday, September 14, 2006 5:22 PM >>To: IBM-MAIN@BAMA.UA.EDU >>Subject: Re: IDCAMS and DF/SORT support for LBI >> >> >>LBI is limited to tapes, not DASD. (Too bad - I would like to see the >>3390 geometry disposed of at long last. 3390's track length is getting >>cramped.) >> >> >>The 3390 does not have a problem with LBI. IBM has a problem with DASD >>and LBI. Something about the architecture of a DCB... > >(Is it really the DCB that's the limit? I don't think so.) > >The tapes use DCBs (and only DCBs) and they managed to overcome the 32760 >byte limitation inherent in the original question here. 3390 uses either >DCBs or ACBs (a handy alternative, eh?) and the folks in San Jose have >worked some serious magic recently to mine unused and then underused bytes, >nybbles and bits out of the various I/O control blocks in order to provide >the somewhat recent support for million-plus track files on DASD. > >All I'm asking is: since a 3390-54 is still anchored on 3390 geometry, >isn't it time yet to expand that (virtual) track length to something >vaguely similar to the underlying shark disks? > >Or, better yet, bring out a new DASD architecture. Maybe FBA or maybe (by >now) something better. The "(and only DCBs)" is an overstatement, I think. DCBs and DCBEs might be closer to reality. (And now, back to your regularly scheduled comedians...) -- Tom Schmidt Madison, WI -- 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
Re: IDCAMS and DF/SORT support for LBI
On Thu, 14 Sep 2006 18:29:19 -0400, Thompson, Steve (SCI TW) wrote: >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On >Behalf Of Tom Schmidt >Sent: Thursday, September 14, 2006 5:22 PM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: IDCAMS and DF/SORT support for LBI > > >LBI is limited to tapes, not DASD. (Too bad - I would like to see the >3390 geometry disposed of at long last. 3390's track length is getting >cramped.) > > >The 3390 does not have a problem with LBI. IBM has a problem with DASD >and LBI. Something about the architecture of a DCB... (Is it really the DCB that's the limit? I don't think so.) The tapes use DCBs (and only DCBs) and they managed to overcome the 32760 byte limitation inherent in the original question here. 3390 uses either DCBs or ACBs (a handy alternative, eh?) and the folks in San Jose have worked some serious magic recently to mine unused and then underused bytes, nybbles and bits out of the various I/O control blocks in order to provide the somewhat recent support for million-plus track files on DASD. All I'm asking is: since a 3390-54 is still anchored on 3390 geometry, isn't it time yet to expand that (virtual) track length to something vaguely similar to the underlying shark disks? Or, better yet, bring out a new DASD architecture. Maybe FBA or maybe (by now) something better. -- Tom Schmidt Madison, WI (Every few years I dust off the old gripes... sooner or later maybe...) -- 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
Re: IDCAMS and DF/SORT support for LBI
Frank, Thanks for your response. I will save the link. I have more information than I had earlier. A colleague was trying to read a VB large block tape data set, and it was failing. Their comment to me was that LBI did not work with DF/SORT. When I couldn't find anything (due to the difference in keywords), I posted the question. What they meant by "didn't work" and what I interpreted it to mean were two different things. In my mind, I guess, it would not have occurred to me the DF/SORT would have an error in the code (it is rock-solid, thank you), so I thought he meant it was not supported. He has since opened an incident with IBM support. So apparently, there is officially support for tape VB LBI for SORTIN data sets, just at the moment it has a flaw in it. IEBGENER appears to be able to read the tape without a problem, but curiously, not IDCAMS. Tom Harper -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Frank Yaeger Sent: Thursday, September 14, 2006 5:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IDCAMS and DF/SORT support for LBI Tom Harper wrote on 09/14/2006 03:24:00 PM: > Thanks! I searched using "Large Block Interface" and "LBI", the usually > keywords for this... We refer to it by the function name of "Larger Tape Block Sizes", rather than "LBI" which is the interface name (that is, the way the support is provided). Just kind of an "external" vs "internal" thing. BTW, if you're ever curious about what was supported in DFSORT when, you can find out by checking the pdf at: http://www.ibm.com/servers/storage/support/software/sort/mvs/summary_cha nges/srtmsocc.html Frank Yaeger - DFSORT Team (IBM) Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, Migration -- 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
Re: IDCAMS and DF/SORT support for LBI
Tom Harper wrote on 09/14/2006 03:24:00 PM: > Thanks! I searched using "Large Block Interface" and "LBI", the usually > keywords for this... We refer to it by the function name of "Larger Tape Block Sizes", rather than "LBI" which is the interface name (that is, the way the support is provided). Just kind of an "external" vs "internal" thing. BTW, if you're ever curious about what was supported in DFSORT when, you can find out by checking the pdf at: http://www.ibm.com/servers/storage/support/software/sort/mvs/summary_changes/srtmsocc.html Frank Yaeger - DFSORT Team (IBM) Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ -- 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
Re: IDCAMS and DF/SORT support for LBI
Tom Schmidt wrote: LBI is limited to tapes, not DASD. (Too bad - I would like to see the 3390 geometry disposed of at long last. 3390's track length is getting cramped.) This has nothing to do with 3390 (which has a track size of 56664). The restriction of 32760 is an old one, and is buried in the access methods. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: IDCAMS and DF/SORT support for LBI
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt Sent: Thursday, September 14, 2006 5:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IDCAMS and DF/SORT support for LBI LBI is limited to tapes, not DASD. (Too bad - I would like to see the 3390 geometry disposed of at long last. 3390's track length is getting cramped.) The 3390 does not have a problem with LBI. IBM has a problem with DASD and LBI. Something about the architecture of a DCB... Later, Steve Thompson -- 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
Re: IDCAMS and DF/SORT support for LBI
Tom Harper wrote on 09/14/2006 03:13:39 PM: > It has become apparent to us that the large block interface (LBI) for > tape data sets does not appear to be supported by IDCAMS nor DF/SORT. I > can find no reference in the documentation of these products for it. > > What could be the reasoning behind this? Huh? DFSORT has supported LBI since July, 2000. Here's the Summary of Changes bullet that announced this support back then: ** Larger Tape Block Sizes with OS/390 R10 DFSORT can now use tape data sets with block sizes greater than 32760 bytes for input and output, providing improved performance and tape utilization. DFSORT can now select system-determined optimum block sizes greater than 32760 bytes for tape output data sets, if allowed by the BLKSZLIM value in effect. Installation and run-time options SDB=INPUT (the new IBM-supplied default), SDB=LARGE (new), SDB=YES (or its alias SDB=SMALL) and SDB=NO allow you to control DFSORT's use of system-determined block sizes, including block sizes greater than 32760 bytes for tape output data sets. DFSORT's ICEGENER, like IEBGENER, will use SDB=value parameters you specify. ** See the descriptions of the SDB=LARGE and SDB=INPUT parameters in "z/OS DFSORT Installation and Customization" and "z/OS Application Programming Guide" for additional information. Frank Yaeger - DFSORT Team (IBM) Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ -- 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
Re: IDCAMS and DF/SORT support for LBI
Tom, Thanks! I searched using "Large Block Interface" and "LBI", the usually keywords for this... Tom -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt Sent: Thursday, September 14, 2006 5:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IDCAMS and DF/SORT support for LBI On Thu, 14 Sep 2006 17:13:39 -0500, Tom Harper wrote: >It has become apparent to us that the large block interface (LBI) for >tape data sets does not appear to be supported by IDCAMS nor DF/SORT. I >can find no reference in the documentation of these products for it. Maybe you weren't looking in the right places? PARM = 'SDB=LARGE' LARGE specifies that DFSORT is to use the system-determined optimum block size for an output data set when its block size is zero. SDB=LARGE allows DFSORT to select a block size greater than 32760 bytes for a tape output data set, when appropriate. The above is from the DF/SORT Application Programming Guide for z/OS 1.6 so the support is documented back at least that far. (SyncSort has similar support, by the way; I looked that up for my own purposes earlier this week.) DF/SORT additionall supports SDB=LARGE via OPTION statement. SyncSort also has its similar alternative. LBI is limited to tapes, not DASD. (Too bad - I would like to see the 3390 geometry disposed of at long last. 3390's track length is getting cramped.) -- 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
Re: IDCAMS and DF/SORT support for LBI
On Thu, 14 Sep 2006 17:13:39 -0500, Tom Harper wrote: >It has become apparent to us that the large block interface (LBI) for >tape data sets does not appear to be supported by IDCAMS nor DF/SORT. I >can find no reference in the documentation of these products for it. Maybe you weren't looking in the right places? PARM = 'SDB=LARGE' LARGE specifies that DFSORT is to use the system-determined optimum block size for an output data set when its block size is zero. SDB=LARGE allows DFSORT to select a block size greater than 32760 bytes for a tape output data set, when appropriate. The above is from the DF/SORT Application Programming Guide for z/OS 1.6 so the support is documented back at least that far. (SyncSort has similar support, by the way; I looked that up for my own purposes earlier this week.) DF/SORT additionall supports SDB=LARGE via OPTION statement. SyncSort also has its similar alternative. LBI is limited to tapes, not DASD. (Too bad - I would like to see the 3390 geometry disposed of at long last. 3390's track length is getting cramped.) -- Tom Schmidt Madison, WI -- 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
