I don't understand what you are saying here. For IBM mainframes, they have
COBOL compilers, test data generators, interactive editors, profilers, code
repository systems, etc. Some or all of these ar used by the aformentioned
hypothetical COBOL programmer. It is hard to see how they could do their
job without them.
Think back to the 1970s. As the Wheelers can witness, most of those
were not available under MVS (or, at least, were hopeless), and CMS
was extensively used for developing for MVS. Yet IBM classified CMS
as a system for scientific/technical use rather than for business/
commercial (though it wasn't that simple).
[ IBM's standard TSO editor was like an interactive version of IEBUPDTE,
to give just one horrible example. ]
And, again, in the mid-1980s. IBM's plans for SAA were that the
development of MVS applications would be done on OS/2, and that many
of those tools would not be available at all on MVS. Seriously.
So your claim is that debugging facilities were developed exclusivly for
scientific/technical environments and any use by commercial programmers was
a "happy accident"? I find that an odd belief, especially from a company
whoose middle name is "Business".
Sigh. No. Please don't think that IBM has a single corporate mind,
let alone a consistent plan. It hasn't had since 1955, to my certain
knowledge. Think of it this way.
IBM had and has a collection of products, which are used together by
the technical staff and customers in complicated ways. For marketing
and administrative purposes, these are divided rather arbitrarily
into segments - of which two are the ones we are talking about. For
several good and bad reasons, most systems intended for developing
conventional programs (and I am including software, here) ended up
in the scientific/technical even when the final product was in the
business/commercial. Not a major problem.
Where the issue became a problem is when some head-in-the-clouds
executive looked at the books, and decided to cut back on the less
profitable segment without considering the consequences, or imposed
a new structure that broke the ad-hoc links across segments that kept
them vaguely in step. It happened many times in IBM, and I have seen
it happen with other vendors.
Perhaps we have a different definition of a commercial environment and of
development tools. I regard a typical commercial environment as say a bank
where the programmers write COBOL programs using such environmental tools as
CICS and DB2 (or their equivalents from other vendors) to accomplish the
primary business of the bank (managing accounts). The tools, such as the
ones I mentioned above, support that.
Yes. One of the reasons that the above does not apply in the way that
it used to to MVS (sorry, zOS) as OS/400 (what is it, now?) is that
there AREN'T any corresponding "scientific/technical" environments to
develop on. But I can assure you that the mindset remains.
And, while it was extremely well developed in IBM, it is fairly common
in other organisations. It remains less visible because few or none
have gone as far down the line of separate product ranges for the two
segments as IBM did. But I can assure you that it is there, as it is
an artificial barrier that I trip across regularly!
An aspect that has never concerned me directly, but I have observed
several times with several vendors, is that the fancy development
tools (especially debuggers) often work with Fortran and C, but not
Cobol, even when they run on the same system. This often has the
effect that the Cobol system ships with its own set of debugging
tools, and debugging Cobol+Fortran codes becomes a nightmare.
One of the more common problems I hit is that parallel support (e.g.
MPI), batch schedulers etc. are classed as "scientific/technical"
and "high-RAS" products (whether management environments, automated
log management or high-RAS file systems) as "business/commercial".
Are they validated/tested together? Don't be silly. Do they work
together? Only in demonstrations. This IS improving, as more of the
commercial customers start to use the parallel tools and schedulers,
but is still a problem.
Regards,
Nick Maclaren.
