Yes, we absolutely do still consider requirements valuable, and we DO
use them when prioritizing work for upcoming releases. Buy me a beer at
SCIDS in Denver and I'll tell you what happened with this one.
Clark Kidd wrote:
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
<snip>
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
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
