On 04/13/2013 08:26 PM, Pinnacle wrote:
I'm interested in hearing from everyone about the extended statistics
behavior I just encountered in ISPF. It seems counter-intuitive and
counter-productive to me, but I'd like to know what others think
before I submit a requirement to change it.
I enabled extended statistics a while back, expecting that ISPF would
automatically save extended statistics for new members. What I've
found is that ISPF only saves extended statistics if you enter the
STATS EXT command.
I somehow got members with extended statistics in a library. After
editing them, I would edit other members in the library, and get the
following messages:
==MSG> -CAUTION- Profile changed to STATS ON (from STATS EXT) because
==MSG> extended ISPF statistics do not exist for this member.
I've asked ISPF development and this is by design. They want to
require the user to enter STATS EXT for every member in a library. I
strongly disagree with this design and would like it changed. I feel
that three options of STATS OFF, STATS ON, and STATS EXT is confusing
and unnecessary. Here are the options I'm considering, in my order of
preference.
1. If the site enables extended statistics, then extended statistics
are automatically generated if STATS ON is in effect. There is no
STATS EXT option. I know this takes control of extended statistics
away from the user, but to me extended statistics should be a site
preference. STATS ON does the stats the site selects, either normal
or extended, and STATS OFF does not set stats.
2. Keep STATS EXT, STATS ON, and STATS OFF, but remove this warning.
Do not downgrade STATS from STATS EXT to STATS OFF.
3. Make this an option. Because some sites would have already become
accustomed to this behavior, create an option to determine whether the
site or the user controls extended statistics.
Please let me know what you think of these options, or if you have
another idea.
Regards,
Tom Conley
I definitely don't like the idea of any change that would make
enabling of "STAT EXT" global for all datasets, as one might want to
convert to using "STAT EXT", except for some datasets that already have
huge directories that you don't want to make larger.
My recollection is that even prior to "STAT EXT" there were some
interactions between Edit Profile attributes and member attributes that
required "manual" overrides in some cases to force attribute values that
we that we wanted as our standard. We got around this by always
forcing a REXX Edit Initial Macro (IMACRO) to execute which examined
such things as the dataset name final qualifier and then forced those
attributes that couldn't be consistently forced from our associated
standard locked Edit Profiles. I could see using this same technique
to force "STAT EXT" or "STAT ON" for those cases you need to force some
override from default behavior.
However, our use of IMACRO always seemed a little like a kludge. What I
would almost like to see would be some better way to control attributes
with the Edit Profiles, perhaps by also being able to specify attribute
precedence; for example, be able to indicate whether a locked edit
profile's attribute of "STAT ON", "STAT OFF" or "STAT EXT" should
override or be overridden by the existing attribute of the member being
edited, and perhaps even additionally be able to specify that for some
specific attributes, manual Edit commands to override the attribute
require some special security access for "edit profile administrative
authority" to make it easier to enforce installation standards.
--
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
