Paul, my original inspiration for suggesting the "Swiss Army Knife" came
from a project some years ago where I was tasked with cleaning up a DB2
table where support from the database team was not possible for
political reasons. Being hardly the expert (I never learned DB1!) I
posted the question, to which the esteemed Frank Yaeger replied, of "is
is possible for DFSORT to read a DB2 table as SORTIN?" He suggested the
unload utility (I've forgotten the actual commands) via IKJEFT01 to
create a sequential disk file, whereupon the 2nd step would perform the
cleanup via some rather basic DFSORT commands. Fast forward several
years and I'm doing similar data manipulation, not for cleanup purposes,
but to accomodate the requirements of a non-z/OS software. I've become
fond of x'05' having plagiarized the idea from a MS-Access proficient
colleage who was doing the reverse, writing tabbed output so z/OS could
parse it into fixed columns.
I have encountered other characters that trigger MS-excel's column
definition, the " for one, no doubt there are others. I simply
convert them to x'40' via INREC (thanks Sri!). Other offending
characters could be treated likewise. No doubt others of us have
encountered a dataset where some characters we're not expecting would be
troublesome, and depending on the desired final product, various
techniques are available to create output acceptable to its destination.
I differ with Sri only slightly, in that I look for uses for DFSORT for
every imaginable scenario, both for its versatililty and its ease of
coding. Having said that, the several suggestions I have received from
him have proven to be work and time savers. I'm still digesting one
particularly tricky one, for which I refuse to ask for guidance till I
have exhausted my own attempts at understanding.
Flashing backwards to the late 90s and the Y2K fix up madness, I was
working for "company to remain nameless" that hired a large team of
contractors as many other companies did. Having reviewed a large number
of their code (COBOL & PL1) it was a surprise to find how many of those
could have been (and were) replaced by simple DFSORT steps. People were
writing programs to drop duplicate records, perform simple record
selection and output reformatting, and get this, even sorting the
records! That experience made me a DFSORT bigot.
Being in the December of my career I'm still learning things in the APG
that, despite having read it cover to cover many times, are new
discoveries. So if I'm guilty of using a screwdriver to pry open a paint
can, so be it.
On 2/26/2015 11:51 AM, Paul Gilmartin wrote:
On Thu, 26 Feb 2015 08:20:49 -0800, Sri h Kolusu wrote:
Tony suggested the use of Tab (X'05') as delimiter which will avoid the
problem of data already have the common delimiter comma.
I stand by my assertion that lacking a priori knowledge that a character
can not occur in the data the task becomes more difficult; not impossible.
And I can't resist mentioning (again):
http://xkcd.com/327/
This is the second time in this week that you had a comment about DFSORT.
I am a developer of DFSORT and there are many cool things that DFSORT can
do and I am more than willing to show them. However I also believe using
the right utility/program for the right job. I do not suggest to use
DFSORT for every solution I posted here.
My apologies if I offended. I recognize that DFSORT isn't the only tool in your
kit, and I'm aware that you suggest other techniques when appropriate.
Still, since DFSORT appears to be the Swiss Army Knife of z/OS, I can't
resist wondering, idly, whether DFSORT is Turing-complete.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
