Mainframe Linux Mythbusting Was: Using Java in batch on zOS 3815

Ted MacNEIL

there were some amount of dirty tricks ... not all that can be repeated in polite company.

with respect to the previous post about running sna thru a real (peer-to-peer) infrastructure (Was: Using Java in batch on z-OS?)

and eliminating the communication groups whole 37xx business .... the obvious reaction was to get corporate to make sure all of my funding was cut.

the couldn't actually kill the project because it came out of another organization and most of the work was going to be subcontracted to the original (RBOC) implementers.

so showing a little ingenuity ... we went to one of the largest SNA customers. they had a huge annual budget devoted to operational and infrastructure things to compensate for SNA shortcomings. we showed that the fully funded costs for development, ship, and support of this other thing ... plus the hardware costs replacing all the 37xx boxes ... was less than their first year savings on all the add-on stuff that they could now eliminate (i.e. the customer would fund the total product development and product ship costs ... because they would easily recover that within the first year of operation).

getting that part stop required other measures.

so there was an early mainframe tcp-ip implementation. in the late 80s, it would get about 44kbyte-sec aggregate thruput and consume just about a whole 3090 processor. i added rfc 1044 support to the implementation and in some tuning tests at cray research between a 4341 (clone) and a cray machine was able to show sustained effective thruput of approx. 1mbyte-sec using only a modest amount of the 4341 processor (limited to the controller hardware interface to the 4341 channel); i.e. about 25 times the thruput for maybe 1-10th the pathlength.

was somehow able to sneak out rfc 1044 support in the product when nobody was looking. misc. past posts mentioning rfc 1044 support:

the communication division finally came out and said that even tho sna and OSI were strategic (govs. and large insbreastutions and organizations were all publicly claiming that all that internetworking stuff was going to be eliminated and replaced by osi)

... that they were doing a tcp-ip implementation support in vtam. there was an organization in palo alto sq (corner of page mill and el camino) that was sometimes referred to as communication "west". they got the job of subcontracting the vtam implementation to a contractor.

the first-original (vtam) implementation had tcp-ip thruput significantly higher than lu6.2. it was then explained to the contractor that all protocol analysis have shown that lu6.2 has higher thruput than tcp-ip ... and therefor any tcp-ip implementation that benchmarked tcp-ip with substantially higher thruput than lu6.2 was incorrect ... and the company wasn't going to pay for an incorrect tcp-ip implementation. so what did the contractor do?

in that time-frame there was some analysis of NFS implementation running on top of typical tcp-ip ... common bsd tahoe-reno workstation implementation. there was a range of implementations from a low of 5k instruction pathlength (and five buffer copies) to something like 40k instruction pathlength ... to do a typical NFS operation.

in some detailed comparisons, it was claimed that somewhat equivalent mainframe function (not NFS, but the closest that SAA had to NFS capability) implemented on top of LU6.2 required 160k instructions and 15 buffer copies. Also, at the time, one of the issues in doing an 8kbyte buffer copy (involved in a NFS equivalent operation) was that 15 8k buffer copies could add more processor cycles than executing the 160k instructions.