On 12/29/2014 10:39 PM, Paul Gilmartin wrote: > On Mon, 29 Dec 2014 17:13:30 -0600, Joel Ewing wrote: >> >> "SWITCH IT OFF" may not be a trivial thing to do if you are talking >> about a PDS used by multiple users. The edit default for "PACKED", like >> a number of ISPF edit parameters, is not maintained in one place but in >> potentially-dataset-unique, potentially-user-unique edit profiles based >> on the low-level qualifier of the dataset. ... >> > Terrible design; inexcusable! That information should exist (also) in > metadata describing the file. Couldn't ISPF have spent one bit of user > info in the directory entry to indicate packed/unpacked status of the > member? Such a metadatum should govern opening of the member, > regardless of the user's ISPF parameters, and be updated when a user > SAVEs. A library with a mixture of PACKED and UNPACKED members > would then be entirely practical and largely transparent (opaque to > users of non-ISPF editors). > > Or, "magic" numbers? > > -- gil
I'm not particularly fond of the design either, but more because there is no easy way to enforce installation conventions on a data set level when there are valid reasons to do so. The problem is not that you can't already recognize on a member-by-member level whether or not data is PACKED. A PACKED member starts with a easily recognizable byte sequence that would not otherwise be valid in an EBCDIC text file. The problem is that the code for converting a PACKED member back to normal text records is not built into PDS access methods, so that there is no way to make the PACKED state of a member transparent to all programs that expect normal text records. And presumably you would want similar output capability built-in if you wanted to force a consistent format when other uilities create new members. A PDS with a mix of PACKED and UNPACKED members is currently possible (although more likely an accident than deliberate), but it is only transparent if all your access is via the ISPF Editor. I suspect IBM has little incentive to enhance ISPF style PACKED data. I think they were actually on the verge of eliminating it a decade back until it was pointed out that at the time it was the only way available to circumvent size restrictions on some large text PDS files, and that its simplistic compression was fairly effective on typical programming language source and much less processor intensive than hardware compression at the time. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
