> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Walt Farrell > Sent: Wednesday, April 01, 2009 6:42 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture" > > On Tue, 31 Mar 2009 12:50:16 -0500, Eric Bielefeld <eric- > ibmm...@wi.rr.com> > wrote: > >Thanks for clearing up how the current drives actually work. It just > >seems like IBM could get away from the track and cylinder stuff, which > >artificially restricts the amount of storage you use. If you use short > >blocksizes, or long ones that just go over 1/2 track, you waste an awful > >lot of space. Of course, well written SMS routines can correct that, but > >it still makes things a lot more complicated than it should be. > > Perhaps I don't understand your point, Eric, but from the user perspective > aren't things simple already? Just let the system pick the block size, and > while you're at it allocate the space in terms meaningful to the > user/application: megabytes or records. > > Thus, the only things that -should- be affected by the cylinder/head > architecture are programs, and it's a lot simpler to leave them alone than > it is to have to change them. Remember it's not just IBM code that would > have to change. Many vendors and customers have written code that knows > and depends on the cylinder/head architecture.
The biggest problem is that estimating file size for many production batch applications is mostly or totally dependent on input (perhaps client-supplied) file sizes. And there is no way in JCL to say "this new output file will be about x(percent) or x(times) the size of the input file(s) named A (B, C, ...). Today I may have 1M records and tomorrow I may have 10M records, depending on how active the day's business has been. The only alternative we have today is to allocate for the maximum possible size, which is often a very poor estimate of the actual size. It doesn't really matter that much if one uses records or megabytes or cylinders (though I agree that records/megabytes are probably more application-friendly methods). When the business grows, the original estimates hard-coded into the JCL become too small. This is not, of course, a problem of ECKD vs FBA or some entirely different virtual architecture for storage, but a problem of how poor JCL is as a file specification and control-flow language. REXX or bash scripts are far more flexible for that purpose, but each of those languages has far more onerous problems than JCL (TSO and the bash shell, respectively), not to mention poor to non-existent connection with scheduling software, which is (IMHO, of course) part of why JCL is still almost exclusively used for production batch processing. Burroughs' WFL (Work Flow Language) was always my ideal of a well-integrated and flexible control language. If REXX could be as well integrated as WFL was in the Burroughs MCP system as to become the replacement for JCL, that would be a step in the right direction, IMHO. Not that I ever expect it to happen. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- 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
