|
>Al says- >IMHO, the guys at IBM that figured out multi-membered files were having an >off day. Furthermore, the users that relied on such a thing were >snuckedered down the primrose path. True. Multi-membering just doesn't scale. The object locking and contention issues are brutal as these applications take on more data, users, and job streams. Before we moved to a 740 12-way I thought I had seen every stinkin' ADDPFM, ADDLFM, RMVM error there was to see. A whole bunch of new problems cropped up on the new server -- things that seemed to suggest that the server was faster than the member handling code. Finding that we couldn't perform incremental backups was the icing on the cake. >With the exception of manufacturing packages, the multi-membering of data >files really never took off... I've seen it used extensively in Island Pacific (retail/merchandising package) and Lawson (Financials - pseudo ERP package). >The remainder of the System/38-AS/400-iSeries architecture never recognized >it's existence, and in logical form, SAVCHGOBJ was not a good solution for >a multi-membered environment. I think it's one of those techniques that seems really cool when you're designing and coding it, but really sucks when you're supporting it. -Jim James Damato Manager - Technical Administration Dollar General Corporation <mailto:jdamato@dollargeneral.com>
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.