Ed Jaffe wrote: >The other platforms live in a byte-stream world. We're the outliers...
No, I'll disagree with that. Yes, the z/OS operating system includes many record-oriented structures that require *some* understanding if you want to transfer them and/or interpret them. The richness and variety of such structures is arguably a unique facet of z/OS(*), but record-oriented structures are still quite common on other platforms -- and you still have to understand them, a bit. First of all, extended attributes, resource forks, ACLs, alternate data streams, and other metadata mean that the humble "file" often has multiple byte streams. Those aspects of file systems are getting more complicated over time, not less. See for example Microsoft's ReFS and Apple's APFS. FTP does not handle these issues. [Given the evolution of the "file," FTP was probably misnamed. It probably should have been called "BSTP" (Byte Stream Transfer Protocol).] OK, now consider this question: how do you FTP the Microsoft Windows Registry...and ensure that it's usable on some other system? The short answer is that you have to know at least a little bit about what you're doing. How about Windows Server's ACLs? A Mac OS X application? Applications on Mac OS X typically include a set of files in a hierarchical directory structure stored in the Applications folder and presented to the user as if it were a singleton, plus metadata hopefully but not always stored in the Library directory. You have to know all that, and sometimes more, in order to FTP an application successfully even between like systems. If the intermediate system is not case retentive then you're quite likely to have problems...unless you use a "packager" to turn the complex structure into a single, sequential stream of bytes. All platforms have record-oriented structures of various kinds. They're often called "databases." The Microsoft Windows Registry is one example. Another example: how do you FTP a Microsoft SQL Server database? The short answer: it requires some level of understanding, and probably also "packager/unpackager" steps. As it happens, on z/OS everything can indeed be reduced down to byte streams, each singular in orientation: the 3390 volumes. VSAM, PDS, PDSE, DB2(**), IMS DB, etc. all sit atop those byte streams. You can dump one or more volumes and FTP those if you wish -- that's another option. You can even designate "transfer" volumes explicitly for this purpose. Also as it happens, that's almost always what software publishers do when they want to distribute Mac applications: they distribute .dmg (disk image) files. Linux operating system distributors almost always use .iso (CD-ROM or DVD-ROM image formats), to pick another example. I can think of one way that z/OS is a bit different: its FTP implementation supports many z/OS record-oriented structures directly. It didn't/doesn't have to. IBM's developers could have written FTP for z/OS such that it only supports QSAM, HFS, zFS, and pipes -- a subset of its current functionality. Then you'd be "forced" to use a packager/unpackager when you want to transfer something else. If you're interested, you can ask IBM via the Request for Enhancement (RFE) process for a parameter to disable z/OS FTP's support for everything except QSAM, HFS, zFS, pipes...and MVSPUT/MVSGET. Then you could shut off the "power user" FTP features. (Maybe there's already a way to do this?) The way other platforms implemented FTP is that they typically didn't attempt to support their record-oriented structures at all. Microsoft's FTP doesn't know what the Windows Registry and Microsoft SQL Server are, in particular. Mac OS X's FTP doesn't really know what to do with an "Application.app" package. Would that same non-approach be preferable, at least as a parameter for z/OS FTP? (*) A major advantage is that the operating system itself, "since forever," provides so many such structures to application programmers. There's a lot to like about that approach, from both development and storage management points of view. (**) The DB2 Analytics Accelerator can be, optionally, "interesting" in storage terms. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA -------------------------------------------------------------------------------------------------------- E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
