Today's email brings notice of several IBM responses to SHARE requirements. Many of these were rejected, including this one:
SOMVSE85160 Title: TSO/E - Allow Multi-Level PREFIX Values Status: RJ-Rejected Text: IBM does not intend to provide a solution to this request for the following reason: Reject Reason : Business Justification Reject Explanation : We have not been able to implement this in twenty years. The odds are that it will not be implemented. External Response : Response Date: 19951108 Response: DATE------RESPONSE 8603 Long Range Consideration. Response entered on 19951108 at 16:15:58 RECOGNIZED Some 20+ years ago, I was working for an organization that wanted to do this, so that a separate catalog alias would not have to be established for each new TSO user. Some research showed that if the TSO PROFILE command would allow values such as PREFIX(SYS.CLK), we could implement a system where a catalog alias would only have to be established for the group (SYS), and not for the individual users within the group. Experimentation showed that the PROFILE command would not accept such a value, because of the way the PREFIX parameter was defined in the PARSE list. But a quick look at the source code (this was prior to OCO), showed that a small ZAP could be used to change the definition of the parameter so that a period was a accepted as a valid character. So one small USERMOD accomplished what we wanted to do. This does not mean the implementation was perfect. A new user would have to remember to change their PREFIX the first time they signed on, or they would not be able to create new data sets - this was eventually automated as part of LOGON processing. There were also 2-3 minor TSO commands that just would not work well with the prefix, and required special handling. And the prefix was still limited to a total of 7 characters. But for the most part, the USERMOD worked well, and accomplished what (I think) the writer of this requirement also wanted. So I had to chuckle when I read that IBM (with all of its resources) has not been able to figure this out for the past 20 years! I would be happy to share the USERMOD, but it was probably thrown out with my last box of punched cards. Also, based on this latest group of responses (4 out of 7 rejected), I'm wondering if IBM still considers requirements to be anything valuable, or whether they are just another annoyance that needs to be buried in paperwork for a decade and then rejected. It used to be that the requirements process was a valuable tool for setting future product direction, and I hope that will still be the case. Clark ---------------------------------------------------------------------- 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
