I will 'fess up that our own internal guidelines were not followed for the VSAM_INDEX_TRAP check. I'm not sure how or why yet.
The desired behavior, naturally, is to have a check routine look for a recommendation and have that recommendation be the default. That is not always possible, particularly for check routines that are added in the service stream for which we might well choose not to change the default at that time. Our desire is that check routines not flag as exceptions a z/OS "out of the box" system. Towards that end we try to get -- serverpak to produce a system with the value matching what the check routine looks for (I know that not everyone uses serverpak, but that's the best we can do in this regard) -- in the service releases (or even in a current release when there might not have been enough time for a customer to react reasonably to the default change) ship the check as "disabled" (a customer is encouraged to enable the check, and (possibly) set a check parameter, if it is available, so that the check reports on the state the customer feels is right for him) -- in a development release change the default and re-ship the check as enabled. The last two bullets is basically how the VSAM_ALLOWUSERKEYCSA check was processed. It was shipped disabled and in z/OS 1.9 it is being shipped enabled and the default is changing. Peter Relson z/OS COre Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
