John, This is a question that has been on my mind for some time now while perusing responses like yours and others from the IBMer's who monitor this list. 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.)
If IBM will only stay in high-margin businesses (repeated many times by company leaders over the decades), and the mainframe software/hardware market is in fact such a business for IBM, then why are IBM's mainframe development resources so terribly constrained that only "this must be done" projects can be developed, but not "it would be really nice if ..." projects? Why are all possible/desired/required projects not staffed properly to develop, test and support all of them (or at least most of them, again FSVO "most")? It seems to me that IBM is cutting off its nose to spite its face by not having a much larger complement of development resources to handle far more of the mainframe customer's needs and wants. If the mainframe margin is high, it should be supportable to significantly increase development resources from the shareholder point of view in order to increase the volume and thus (in the long term) the profit. It would appear that short-term financial gain is still being used to restrict "expenses" like staff in order to maintain/increase short-term profitability at the expense of long-term market growth. Just a question. I don't really expect an answer, since we'd have to engage in an NDA-protected dialog with top management and the company board to get anything approaching a real answer. My real fear is that the mainframe software/hardware market is not one that IBM's management and board sees in its long-term future (FSVO "long"), and that the short-staffing of development resources is a symptom of that failure to see. Peter > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of John Eells > Sent: Tuesday, May 06, 2014 9:43 AM > To: [email protected] > Subject: Re: PFA (Now, an HZR subject) > > Shane Ginnane wrote: > <snip> > > The (HZR) logger dependency starts to look a bit silly on a (non- > sysplex) ring of 5 or 6 MONOPLEX systems. > <snip> > > As many seem to ask for things like this, it raises an interesting > general question. In how many ways should we implement things? > Intuitively speaking, the greater flexibility offered by more choices > always seems good, but... > > Someone I work with uses the metaphor "surface area" to describe much > of the system's componentry. Surface area can allude to both the > number and nature of externals and to internals of various kinds. The > more surface area you design in, the more you need to do, both to > implement a function now or change it later. (Meanwhile, someone else > here has embarked on a rather systematic course of hair removal using > the time-tested grab-and-pull method, in large part because the thing > he's working on changing has "a lot of surface area.") > > I think adding surface area needs some justification beyond, "It would > be nice if...." > > I do get that converting to OPERLOG on systems that run along quite > happily with entrenched SYSLOG-based systems is harder than it might > appear at first glance from our end of it. On the balance, though, it > would have cost more development time to support both SYSLOG and > OPERLOG, added to code complexity and support cost, added to PFA's > documentation, and added more complexity and cost to future changes in > the same area. Would it really have been worth it? If I asked the > same question 10 years from now would the answer change? What > function would you have given up in return? > > Just some food for thought. > -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
