On Mon, 5 May 2008 12:06:22 -0700, Schwarz, Barry A wrote: >I really have to question whether reading or writing a file is that much >easier than dealing with a dataset. In fact, one of the selling points >used to be that DD names made your program device independent. A
At one time, that was pretty much true. I'd conclude it was part of the original design philosophy of OS/360. Well, you couldn't have a PDS on a card reader. But such restrictions were rationally motivated. >sequential file could be stand-alone or a member of a PDS. It could be >on cards, tape, disk, drum, cell, display terminal/keyboard, and now >file system. > Nowadays, there are numerous unnecessary restrictions in both directions. Consider AMATERSE. AMATERSE won't accept a DD name referring to a UNIX file as its archive data set, notwithstanding that many customers promptly copy the Terse archive to a UNIX file (or Windows file) for transmission to tech support. And, why does ISPF require me to copy a UNIX file to a Legacy (sic!) data set in order to LMDEF that for input to LMCOPY? And I can cheat a UNIX directory as a member of my SYSEXEC concatenation, but not if it's the first catenand. "Using Data Sets" documents it; Rexx support says it's not supported. Where did we lose device independence? I understand that resource constraints may preclude DFSMS providing device drivers for all functions for all "device" types. I'm far less sympathetic to higher layers that don't perform conventional I/O (at least as a fallback) to devices that DFSMS supports. >Why would compressing a file be that much different than compressing a >dataset? > Out-of-band record boundaries. AMATERSE knows how to deal with them; pax.Z doesn't. -- gil ---------------------------------------------------------------------- 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
