Combine Lionel's and Chuck's points about "support" with "every time someone has been looking at a problem for three days and arrived nowhere, they're going to blame the compression/decompression/(depression), just because they can't find out for real why something isn't working".
Why is anything being done before it is known to be an issue? It may be, as the server-people won't be used to trailing blanks in fixed-width fields, but they probably have several possible compression options before anyone need consider the Micro Focus options, which, as you suspect, should be waaaaayyyyyy ahead of home-grown solutions, especially those solutions desperately in search of a problem. It is a, bad, idea. If someone was paying me to do it, I'd expect to more than earn my pay by arguing against it. If decompression is already written, it can at be used to quantify the issue in various ways (totals, averages, losses from no-compression vs gains from no control information, per record, file sub-system, system) so that everything is ready for a meeting with the storage admin people. The programmer needs to learn something from this. Even if some benefit can be extracted from their efforts, this time, knowing when not to do something, and when to do something else instead, is a knack worth developing, as it will repay over and over again. I really like the idea that "blanks" are involved in a "space issue" :-) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
