Farley, Peter x23353 wrote:
<snip>
The consistent message seems to be that mainframe development resources are very
constrained, so only the most important/most useful/most justified projects (FSVO most)
can be undertaken. (E.G., "functional stability" for the TSO and ISPF and Rexx
components, among many others.)
<snip>
I'm not sure how you got from what I wrote to "very constrained."
Development resource has never been infinite. It's simply a fact that
many of yesterday's decisions (made with all the best motives, to be
sure) in different components somewhat slow today's pace of development.
I'd hope that would not surprise anyone who does software development.
I can recall similar internal discussions about what was then "MVS"
taking place on IBM's internal conferencing systems as far back as the
1980's!
It's an aerodynamic principle that you can't get lift without drag, but
you can certainly have drag without lift. We need to avoid that.
That's really all I was trying to say. (It would be good, while we were
at it, if we could also reduce the drag.)
But while we're on the topic...the timing of your statement strikes me
as a bit odd because it seems to me that we've really accomplished a lot
over the past few years.
While TSO/E and TSO/E REXX development might not have provided the
amount of new function you would like to see in them, we actually did
provide updated TSO/E REXX functions in z/OS V2.1. And, look at what
we've done for *other* z/OS programming APIs over the z/OS V1.13-V2.1
timeframe. We've done improvements in Java, C/C++, SYSREXX, z/OSMF's
REST APIs, the Batch Run Time Environment, Language Environment, and
BCPii to name some. In z/OSMF, we provided browser-based access to ISPF
(which uses a TSO/E back-end, by the way) and now to SDSF, in addition
to the other z/OSMF applications for network configuration and software
management, WLM, RMF, and others. Would you prefer we'd spent all this
effort on TSO/E and REXX?
There's a *lot* there that's new, and I've hardly scratched the surface
for z/OS V2.1. Moreover, the ISPF team, among a number of other things
I didn't list here, offered these improvements in this latest release:
Edit support for Unicode data
Edit support for an expandable command field
Edit HILITE command to highlight the invalid lowercase JCL characters
Edit support for regular expressions in FIND and CHANGE commands
Support for dynamically allocated data sets using XTIOTs for EDIT,
BROWSE, LMINIT, and LIBDEF
Improved enhanced member list function
ISPF directory list display for z/OS UNIX, UDLIST, DIRLIST support for a
SRCHFOR function
Support for multiple logical screens on ISPF entry, and multi-screen
exit when ending ISPF
Path name mask support in the z/OS UNIX Directory List Utility
Support in OPT3.4 for a “free” line command for multivolume data sets
Support in UDLIST lower-case path names
I wouldn't personally characterize that component, at least, as
"functionally stabilized" based on recent history. We did lots more,
too, in many other components, that we announced and talked about at
SHARE, GSE, and so on.
Then there's all the stuff we do "under the covers" and rarely talk much
about. New machines with new cache structures require HiperDispatch
updates. There are constant RAS improvements, countless tweaks to
diagnostic data collection, serviceability improvements, a slew of
small--but significant in aggregate--performance improvements that show
up in the LSPR, any number of hardware support items, and infrastructure
items for which, while "someone else takes credit for them," we actually
provide the fundamental capabilities. (Operating systems are a lot like
plumbing. It's the appliances that get all the glory.)
I'd likewise hope it will surprise nobody that z/OS Development is part
of a business, and that it does require justification to get work done.
This isn't new, either. It's been true for as long as I can remember.
I think excessive "surface area" is not in our mutual best interest.
I've thought that for quite some time. Though my coworker might have
found a cool way to express it that helps make the point, like many of
those above, it's not a new one.
--
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: INFO IBM-MAIN
