On 21-Jan-2012 21:08 , John Yeung wrote:
It's interesting to see the solutions people come up with, based to a
very large extent on what they are comfortable with. "When all you
have is a hammer, all your problems start looking like nails" and all
that.
I'm as guilty of this as anyone. But trying to look at this as
objectively as possible, assuming Dennis's "Unixy" solution works
(and I think it does), it seems like the quickest and most
straightforward to me.
By the way, this technique has a name: It's the
decorate-sort-undecorate pattern (or idiom). It's very useful, and
can be applied in various ways in various languages.
Or, the problem might just be a nail. Since the OP was not strict in
defining their problem\scenario, for lack of a script demonstrating the
creation of the "flat file" [STMF, CRTPF, other?] and some sample data,
what the scenario looks like to each reader is influenced by their
perception of what the writer may only have alluded; their having failed
to express very specifically. The OP even failed to suggest where the
data needed to be made available; although mentioning the sorting would
be a "one time effort", does that necessarily imply that the ordered
data must be placed into a similar "flat file", or perhaps just made
available to a program is acceptable.?
If the data is already EBCDIC stored in a database physical "flat"
file, and because all rows need to be processed for "sort" according to
the OP, then the best tool for the job would presumably [and probably
generally] be a tool which acts directly on that data rather than
requiring copying\moving of the data elsewhere before acting on that
data.? Seems that multiple copies [two between EBCDIC and ASCII thus
possibly also changing the 0x1C\IFS\"Interchange File Separator" control
character to and then from the 0x1A\IS4/FS\"Information Separator
Four/File Separator" character] involves a lot of possibly
excessive\unnecessary work.?
Besides that, the OP stated that they wanted to avoid their current
proposed solution that would "create an intermediate file, with the Last
Name as a separate field". And their own solution description which
they apparently have chosen to avoid, seems little different than the
"Unixy" solution that was proposed.?
So while the likely _implementation_ of the SQL to complete the work
would probably be effectively the same as what the OP was thinking to
do, the SQL solution sure would look different from their perspective.
The data could be selected as just the unconverted field-as-row-data
from the file.mbr using a SQL "SELECT * FROM TheFile ORDER BY _Last
Name_ " without the result of the ordering expression that defines "Last
Name" becoming part of, thus no need to be removed from, any
system-generated intermediate copy; i.e. unlike the user-generated
intermediate copy proposed solutions.
Regards, Chuck
midrange.com
