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, Jon Perryman ----- 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.
