Probably the biggest customer of this type is the US Government, which includes all of the branches of the Military. Usually, funds are allocated to setup a new system that cover (1) the initial cost of the equipment and software and (2) an (adjustable) maintenance budget for both thereafter. Unfortunately, it's difficult, say for a particular Army base running a personnel system and maybe a few other local applications, to go back in a few years to the Pentagon/Congress to get additional funding to upgrade their hardware (even if it makes better sense in terms of the cost of the hardware maintenance). So, they may have to run for 15 or 20 years with the hardware they got as part of the initial procurement. Now, we could say that as ISVs that supplied software for this system, we'll support what they have, but we won't upgrade them to new releases when they're available. (This way we can avoid having to support the old hardware when we no longer want to.) The problem is, after many years of selling software into this market, you find yourself having to support 47 (or so) different versions of your product. So, instead, if you want to exploit a facility such as PLO in a new version, you take the trouble to dual-path where necessary, and you encourage you customers to stay current with the latest releases. This way, your technical support staff really only needs to be knowledgeable about the most recent few versions. (It takes a little extra effort to test both paths, but as suggested by my code example, it can be made pretty painless with just an enabling bit in a control structure. Moreover, having an alternate path available can be extremely useful in certain troubleshooting scenarios.) This outlines one reason why it can make sound business sense to dual- path. There are others, but perhaps I've already given away too much to those potential competitors out there <grin>.
--Art Celestini At 01:36 PM 5/28/2005, Craddock, Chris wrote: >> It depends on how backleveled your customers are (might be), and >> how will your products react to an 0C1? > >PLO is now older than dirt. Your "customer" would have to be on an >ECL machine, or a 1st generation CMOS. PLO came in with G2 CMOS. >I seriously doubt there are ANY production systems in use today >that do NOT have PLO. Dual-pathing is vastly more prone to error >than simply placing a stick in the sand and saying; this is the >minimum function level required for this software. > >I am constantly amazed at the gymnastics some people will go through >to "support" back back back level "customers". One thing you can >say for sure about customers who are not on reasonably current >hardware and software... they aren't spending any money! Why would >anyone go to that amount of trouble when there's no revenue in it >anyway? Charity? > >CC ================================================== Art Celestini Celestini Development Services Phone: 201-670-1674 Wyckoff, NJ ============= http://celestini.com ============= Mail sent to the "From" address used in this post will be rejected by our server. Please send off- list email to: ibmmain<at-sign>celestini<dot>com. ================================================== ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
