[email protected] (Ed Gould) writes: > A LONG LONG time ago we had bumped in to the maxsuba of 255. > IBM almost simultaneously came out with a outrageously expensive add > on (memory was $5000 a month) to get rid of it. > My management said NFW to the cost and told me to live with it. We had > to start turning away customers and then the heat started and they > hired a SNA "pro" and he came up with a few suggestions - but mind you > it was a 2 or 3 month buffer before we had no other option. (His $$ > should have gone for bonuses to the networking staff, IMO). > Our people costs were high because it was trying to keep track of SNA > paths (of other users and ours) we finally bought the RTG software > which helped us but was another $100 (?) a month, Overall trying to > keep disparate networks in sync was an utter night mare. > I was/am a fan of SNA until it comes to (large) networks.
note that jes2 had similar problem. the code was brought over from hasp (use to have the characters TUCC in cols 68-71) ... it used left-over entries in the 255 entry hasp psuedo device table ... frequently somewhere around 160, maybe 180 entries. furthermore any traffic coming into jes2 node where either the origin node or the destination node wasn't in the local table ... the traffic was trashed. jes2 network had also jumbled the job control fields and the networking fields in the header ... and jes2 had nasty habit of crashing mvs receiving traffic from a jes2 at a different release level. since the internal network (not sna until well into the late 80s where a very expensive conversion took place requiring a lot more resources) http://www.garlic.com/~lynn/subnetwork.html#internalnet quickly passed 255, any jes2 nodes had to be kept purely on the periphery of the network. The standard network was much more robust and in may ways had internetworking capability ... the internal network was larger than the arpanet/internet from just about the beginning until sometime late 85 or early 86. also because of the issue with jes2 release node incompatibilities tending to bring down mvs ... a large library of release specific jes2 drivers grew up for vnet. basically the vnet jes2 driver would convert the jes2 headers into a canonical form ... and a specific vnet jes2 driver was started that corresponded to the directly connected jes2 system ... which converted from canonical form into form expected by that jes2 system. there was a infamous case at one point where mvs systems in hursely were crashing because of new fields added to the jes2 systems in san jose. the local hursely vnet systems were blamed ... because the necessary changes hadn't been made to keep the hursely jes2 systems from crashing mvs. the original announce for jes2 networking also had big problem ... it had been somewhat developed using methodology that predated the charging for software ... even with a lot of the code being picked up from customer site. the company was under mandate that the price charged had to cover the distribution and maintenance costs ... but also the price times the number of customers had to also cover the upfront development costs ... but because of the expensive process ... there was no price for jes2 networking ... times the expected number of customers (at the price) would meet the criteria to cover all costs. POK had also convinced the corporation to not announce any new vm370 features ... including the vnet networking support used to run the company. The jes2 group got that reversed ... because they could announce a combined jes2+vm370 product ... where the combined sales were able to cover the jes2 costs (since the vm370 product costs were almost negligible) ... aka some creative bookkeeping. The same year that arpanet converted to interworking (starting off with about 255 hosts ... but the internetworking change-over removed an enormous barrier to growth) ... the internal network passed 1000 nodes. some reference to the internal network activity that year. http://www.garlic.com/~lynn/2006k.html#8 sometime after that year ... jes2 networking got around to changing from spare slots in the 255 psuedo device table to 999 entry table ... but it was way too late to help with internal network (that had already passed 1000 nodes). furthermore they still hadn't fixed the release level incompatibility problems that could bring down the receiving mvs system (making sure that jes2/mvs systems still had to be restricted to the network periphery, with special vnet filter/reformatter). misc. past posts mentioning hasp, jes2, and/or jes2 networking http://www.garlic.com/~lynn/submain.html#hasp -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
