On 12/29/2014 03:54 AM, R.S. wrote: > W dniu 2014-12-29 o 07:50, mf db pisze: >> What happens internally when this feature is ON ? Instructions wise any >> change happens internally ? >> > > PACK ON means some kind of text compression. It is transparent to the > ISPF editor (you always see unpacked content), but it cannot be > recognized by other tools. > So, any PARMLIB members, JCL not submitted from editor, etc. etc. cannot > be PACKed. > > My advice: SWITCH IT OFF and forget. DASD space savings are not worth > the risk of pack misuse. > > > BTW: if you really want to see internal structure of PACKed member then > use DITTO, File Manager or just IEBGENER (copy from member to sysout). > > HTH > "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. An installation can attempt to enforce standards by establishing default profiles in an update-restricted ISPF table library for common low-level qualifiers (like PARMLIB, COBOL, or ASM) and even "LOCK" those profiles to make them difficult to change accidentally, but if there is no specific default profile, or the profile is not LOCKed, or if a user deliberately unLOCKs the profile and makes a change, that user can save his own unique ISPF edit profile for PDSs with that low-level qualifier. There is a limit on how many different edit profiles are maintained for each user (before least-recently-used is discarded). I think the default limit used to be around 15, but our installation raised that limit. So, if you want to attempt a global change after a period of non-enforcement, you could potentially need to alter or at least examine a large number of edit profiles for a large number of users.
Once a user somehow saves his own unique copy of an ISPF edit profile, there are no obvious clues in a later edit session to alert him that he is no longer using an installation default Edit profile. As a fail safe, we set up a global default ISPF EDIT initial Site edit macro which would get control after an ISPF Edit Profile had been chosen which would override (force to different values) certain ISPF edit parameters if user edit profile values somehow got set to values that were unacceptable by our installation standards for that PDS name (like PACKED for a PARMLIB or compilation code source libraries). A user determined to trash things could still override the settings within the edit session, but at some point after you've made unintentional errors difficult enough you have to rely on user education and common sense to do the rest. Back when DASD 3390 volumes were more size-restricted, we had archived source PDS libraries that wouldn't fit on a single volume unless members were PACKED. Since a PDS is still restricted to single volume and below 64 Ki tracks, even with DASD much cheaper there are still some contexts in which PACKED members may be the best choice. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
