... I remember trying to help customers move > their > >> applications from > >> TOPS-20 to VMS, back in the early 1980s, and > finding > >> that the VMS I/O > >> capabilities were really badly lacking. > >> > > > > Funny how that works: when you're not familiar > with something, you often mistake your own ignorance > for actual deficiencies. Of course, the TOPS-20 > crowd was extremely unhappy at being forced to > migrate at all, and this hardly improved their > perception of the situation. > > > > If you'd like to provide specifics about exactly > what was supposedly lacking, it would be possible to > evaluate the accuracy of your recollection. > > > > I've played this game before, and it's off-topic and > too much work to be > worth it.
In other words, you've got nothing, but you'd like people to believe it's something. The phrase "Put up or shut up" comes to mind. Researching exactly when specific features > were released into > VMS RMS from this distance would be a total pain, I wasn't asking for anything like that: I was simply asking for specific examples of the "VMS I/O capabilities" that you allegedly 'found' "were really badly lacking" "in the early 1980s". Even if the porting efforts you were involved in predated the pivotal cancellation of Jupiter in 1983, that was still close enough to the VMS cluster release that most VMS development effort had turned in that direction (i.e., the single-system VMS I/O subsystem had pretty well reached maturity), so there won't be any need to quibble about what shipped when. Surely if you had a sufficiently strong recollection to be willing to make such a definitive assertion you can remember *something* specific. and > then we'd argue > about which ones were beneficial for which > situations, which people > didin't much agree about then or since. No, no, no: you're reading far more generality into this than I ever suggested. I'm not asking you to judge what was useful, and I couldn't care less whether you thought the features that VMS had and TOPS lacked were valuable: I'm just asking you to be specific about what "VMS I/O capabilities" you claim were seriously deficient. My > experience at the time was > that RMS was another layer of abstraction and > performance loss between > the application and the OS, Ah - your 'experience'. So you actually measured RMS's effect on performance, rather than just SWAGged that adding a layer that you found unappealing in a product that your customers were angry about having to move to Must Be A Bad Idea? What was the quantitative result of that measurement, and how was RMS configured for the relevant workload? After all, the extra layer wasn't introduced just to give you something to complain about: it was there to provide additional features and configuration flexibility (much of it performance-related), as described above. If you didn't take advantage of those facilities, that could be a legitimate *complexity* knock against the environment but it's not a legitimate *capability* or *performance* knock (rather the opposite, in fact). and it made it harder to > do things If you were using the RMS API itself rather than accessing RMS through a higher-level language that provided simple I/O handling for simple I/O needs, that was undoubtedly the case: as I observed above, that's a price that VMS was happy to pay for providing complete control to applications that wanted it. RMS was designed from the start to provide that alternative with the understanding that access via higher-level language mechanisms would usually be used by those people who didn't need the low-level control that the native RMS API provided. and it > made them slower That's the second time you've claimed that, so you'll really at least have to describe *how* you measured this even if the detailed results of those measurements may be lost in the mists of time. and it made files less > interchangeable between > applications; That would have been some trick, given that RMS supported pure byte-stream files as well as its many more structured types (and I'm pretty sure that the C run-time system took this approach, using RMS direct I/O and doing its own deblocking to ensure that some of the more idiomatic C activities like single-character reads and writes would not inadvertently perform poorly). So at worst you could have used precisely the same in-file formats that were being used in the TOPS-20 environment and achieved the same degree of portability (unless you were actually encountering peculiarities in language access rather than in RMS itself: I'm considerably less familiar with that end of the environment). but I'm not interested in trying to > defend this position > for weeks based on 25-year-old memories. So far you don't really have much of a position to defend at all: rather, you sound like a lot of the disgruntled TOPS users of that era. Not that they didn't have good reasons to feel disgruntled - but they frequently weren't very careful about aiming their ire accurately. Given that RMS really was *capable* of coming very close to the performance capabilities of the underlying hardware, your allegations just don't ring true. Not being able to jump into VMS with little preparation and get the same performance you were used to in the TOPS-20 environment is quite believable, but not the suggestion that it was not *possible* to achieve at least equal performance had you been well-versed in the VMS environment. Decent *default* behavior is one of the things that VMS should have learned more from Unix about - especially as the years went by and decreasing memory prices made use of a central system file cache (which IIRC VMS didn't acquire until the late '80s) much more feasible (even in relatively low-end systems) than was the case in the '70s when VMS was designed. RMS's default application buffer size of 8 KB didn't get increased for another decade or more after that: sure, you could increase that size explicitly, and use multiple larger buffers, and even stream data through them using transparent asynchronous multi-buffering, but the *default* became ridiculous. So it seems a lot more likely to me that you got bitten by default behavior tuned for small-system environments than by actual hard limitations - which was my initial observation to your original post. - bill This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
