I would like to add some personal views to this discussion. First I must admit that I have no experience with LINUX-390. But I worked for years with VM and CMS. At this shop there were always two or three production VSE guests with CICS and SAP R/2 and some DB2/VSE (former SQL/DS) guests running and lots of CMS users. We never had any performance problems. We had also capacity left on the same machine to convert HPGL graphic files coming from some workstations to a graphics metafile format called GKS and then plotting them on a large Calcomp Plotter, with self-written PASCAL routines to optimize the paper usage by shifting the pictures. And these were not the big boxes from IBM; I don't remember the numbers exactly but I think the first was a 4381/12 and then came a 3083 and so on. I think that virtualization in VM is done in such a perfect way (with hardware support etc.), that you cannot call that "emulation". Emulation in my opinion means, that some hardware "emulates" another hardware. That's slow, of course, but this has nothing to do with VM.
And for some other topic: as mentioned earlier, PL/1 "close to the hardware" is complete nonsense. I did much benchmarking in the past with PL/1 and C/370, and I found that C/370 performs very well (better than PL/1), and I don't see any performance problems with C on the mainframe. It depends on the quality of the compiler, and I think, the GNU compiler will generate very fast code on the mainframe also, cause most optimization is done before the code generation steps. If there were problems, you simply would have to do some work in the code generation for the mainframe. But that's all. It could easily be done. In a large project in the past, we developed the same software (mathematical calculations for an insurance) in C with targets OS/390, OS/2, WIN NT and 98, and (last months) Sun Solaris, consisting of several million lines of source code. The same software runs on the mainframe and on the laptops of the insurance agents, no difference. And we never had performance problems on the mainframe, although the software is used as part of database transactions with IMS/DC and used in parallel by many people. But on the PC, there were heavy performance problems; we almost didn't match our service criteria. We had to do lots of advanced things, for example multithreading on the laptops, although these are single user machines. My personal experience is: forget about performance issues on the mainframe, it will probably work, no worry. But the same is not always true for PCs. Best regards Bernd Oppolzer > > One statement struck me as clearly incorrect is the following: > > "In contrast, most mainframe control environments, including loadable > libraries and related systems level applications, are written and maintained > very close to the hardware -- usually in PL/1 or assembler but often with > handwritten or at least > "tweaked" object code -- to use far fewer cycles than their C language Unix > equivalents. > > This statement is wrong on two separate counts: > > 1) most mainframe programming (well above 50%) is still done in COBOL, with > PL/I, Assembler, Fortran, etc. splitting the rest. > 2) PL/I is lots of things, but "close to the hardware" ain't one of them. > :-) >
