On Mon, 15 Apr 2013 21:29:13 -0700 Jon Perryman <[email protected]> wrote:
:>It's nearly impossible to justify this implementation with $$ unless it's :>something truly needed. We actually use this method for a few necessary :>features. Instructions are only the tip of this iceberg. We have this same :>problem with new features, versioned IBM macro's and interfacing with various :>products. :>On the surface, 2 modules from the same source does not seem to cost much. But :>removing obsolete code is much more difficult and riskier than waiting for :>instructions to be available on supported hardware. It can quickly increase to 4 :>or 5 modules for a single source. If multiple products are involved, then good :>luck in getting approval from those groups. PTF sizes increase. QA time :>increases with each module. Support must be trained on why, how and where. We :>can't do this for every instruction so how do we choose which instructions to :>implement? :>In the specific case of TRTE, TRT works fine and it would save less than 2K :>storage which is insignificant. Most uses are against variable length buffers :>that 90% of the time are less than 256 bytes. Of the remaining 10%, very rarely :>do they exceed 1024 which is a 4 pass loop using TRT. In this situation, TRTE :> is not worth the extra work, That is, of course, only if your mission is to provide good customer support. On the other hand, if your mission is to try to force your customers to dispose of what you believe to be obsolete hardware and buy new hardware ...... :>----- Original Message ---- :>> From: John Ehrman <[email protected]> :>> :>> (2) Knowing the properties of the end-user's system means you can ship a :>> version of the application with a simple reassembly that accounts for the :>> presence or not of the new instruction. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
