SHARE Tuesday -- Vendors
"Twelve or thirteen hundred attendees," says the cynical vendor with a wry smile. "Take away the vendors, that's about 800 left. Take away the speakers, that's about 700. Take away the IBM employees and there's about 300 attendees here."
Cynicism is the residue of irony gone sour, and the irony of the Big Iron is that it's a Small World, though as Steven Wright pointed out, you still wouldn't want to have to paint it.
The mainframe programming model is sophisticated beyond anything on the desktop. So why aren't we all doing mainframe programming? Because the sophistication is there mostly to insure that we're not needed in large numbers.
A few, a very few, a noticeably aging demographic of specialists keep the rail cars rolling, the entitlement checks mailing, the insurance policies renewing, the bank accounts balanced in America and around the world by doing the minimum amount of programming to accomplish these tasks.
Where are the heirs? These systems are not going away, but formal mainframe programming education is an anomaly in academia where it exists at all. Besides, the economy of using gargantuan shared systems coupled with the downturn in the global economy puts unprecedented pressure on IT that the most be done with the least. The reader may or may not find the problem domain interesting, but as a model of economy of means, mainframe programming is, in some dimensions, unsurpassed.
Enter the Vendors. The vendors of software and services at SHARE are in some ways familiar to the workstation programmer and in some ways different. A pretty typical example is PKWare, the good ol' PKZip folks supporting midranges and mainframes with products customized for those environments. Like many vendors, they are about tools because tools can still be written by small vendors competitively. Packages, portmanteau suites of application suites like those produced by the larger vendors, are huge and scale in effort required away from the scope of small vendors in much steeper curve than occurs in the workstation world.
The small vendors are much more interesting, because their efforts are so revealing of what programming is like in a Small World. One vendor's tool does Catalog management, maintenance and repair. Catalog management is a problem domain within record-based computing nearly inexplicable to those who live entirely in stream-based computing complete where nearly nothing can be expressed about persistent storage outside journalling hierarchical file systems. What workstation programmers think are "files" on z/OS are more like directories. In the OLE era when Microsoft went on and on about compound documents, well, those are what Data Sets found on volumes of DASD in z/OS really are. You can manipulate these Data Sets, these "files", at your pleasure via volume access, but if you're looking for them somewhere in the hundreds and thousands of volumes on your acres of storage units, you hope there's a healthy Catalog on your system.
Another vendor provides performance measurement tools. If you are compelled by the scale of your live data requirements to spend five to six million dollars on a single computer and its associated storage and peripheral I/O, you certainly will have to evaluate its usage and performance.
Another role of the vendors is that they are a means by which the Small World copes with the existential reality that mainframes, having outlived many of their creators, detractors, designers, programmers, hackers, devotees, historians and night-shift operators, have taken on a life of their own. z/VM and z/OS are what they are not entirely because of the absolute control of legal ownership by the IBM Corporation. From time to time in certain circumstances it becomes blindingly obvious that Big Blue has no idea how to address a given need. Then a vendor will step in and provide solutions that keep the world turning for one more day. Sometimes IBM subsequently deals in its own way with whatever gap in the offering spawned the vendor's entrepreneurial opportunity. Sometimes, oftimes, IBM does not step in and the vendor's solution becomes the defacto standard.
In any case, one of the most striking differences between the vendor/user relationship in mainframing and the vendor/user relationship in personal computing was pointed out in the first paragraph of this blog entry. The difference is that the community of the vendors in mainframing nearly outnumbers the community of users.