On 06/27/2014 07:11 AM, Elardus Engelbrecht wrote: > Buckton, T. (Theo) wrote: > >> Which process determines the profile of a member in a PDSE (Library) data >> set. >> When one browses the PDSE, views the member and enter PROFILE on the command >> line of the member, it brings up some attributes. How are these attributes >> determined: > These attributes came from different sources: ISPF defaults, ISPF > configuration table, your own profiles, your usage of edit macros (before > edit or during logon) and the of course your own commands as issued by you. > >> ....DECKS (FIXED - 80)....RECOVERY OFF WARN....NUMBER OFF............... >> ....CAPS ON....HEX OFF....NULLS ON STD....TABS OFF...................... >> ....AUTOSAVE ON....AUTONUM OFF....AUTOLIST OFF....STATS ON.............. >> ....PROFILE UNLOCK....IMACRO NONE....PACK OFF....NOTE ON................ >> ....HILITE OFF CURSOR FIND.............................................. > Note some attributes may be overridden/locked by your ISPF configuration > table. For example, I have overridden site wide these attributes: RECOVERY > (make it ON) and STATS (FORCE it ON). > > Groete / Greetings > Elardus Engelbrecht > More explcitly, the default choice of "profile" used by EDIT is based on the data set Low-level qualifier and to a minor extent by the RECFM (VB vs. FB) The number of different profiles that will be saved for a user for ISPF edit is an installation-defined value; and if saving a new profile would exceed that limit, I believe the oldest UNLOCKed user profile is lost. If a new LLQ is encountered in a user edit session, session edit profile attributes are assigned based on installation default profile or ISPF defaults, and when the edit session is normally terminated a modified or new profile will be saved and associated with that LLQ for that user. To help enforce installation standards an installation can set up an installation ISPF table member with default profiles for LLQ's of interest and "LOCK" those profiles, so even if attributes are changed they are not unintentionally re-saved by users in their own profile data set with the new values. If the user does not have his own profile copy for a LLQ, then an installation defined profile for that LLQ will be used, if it exists.
Installations can also define a default installation Initial Macro that will be invoked when ISPF EDIT starts that can either alter the Edit profile used or override some of the profile attributes to counter the effects of users that deliberately UNLOCK a locked installation edit profile and modify it in unacceptable ways (like storing PACKed members in a PDS that everyone else expects to be unpacked). In the worst case scenario each user editing a shared PDS could have their own customized copy of an Edit profile that applied to their edit session on the PDS, and some of their attributes could conflict with other user's usage. You can't eliminate such conflicts, but with proper installation defaults and controls you can at least reduce the likelihood of conflicts happening by accident and reduce the likelihood that temporary EDIT attribute changes are unintentionally preserved. -- 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
