Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
Posted: Wed Jul 07, 2004 12:40 pm Post subject:
Programmer1,
You could use DFSORT's TRAN=ALTSEQ feature and provide your own ALTSEQ table to do the EBCDIC to ASCII translation. There isn't a standard table for that. Code your own chart for the conversion. For example, for an input data set with RECFM=FB and LRECL=80, you could use:
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Wed Jul 07, 2004 2:11 pm Post subject:
Quote:
I hope we can omit the binary part of data by simply using the INREC fields ?
Yes, you can specify DFSORT's p,m,TRAN=ALTSEQ for the fields you want to translate, and just specify p,m for the fields you don't want to translate.
You can use p,m,TRAN=ALTSEQ in the INREC or OUTREC statement, or in the OUTFIL OUTREC parameter. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Tue Jul 20, 2004 1:42 pm Post subject:
Why do you have 1C1C and 1E1E in your ALTSEQ statement? Those don't do anything. The idea of ALTSEQ is to change one character to another. 150A will change X'15' to X'0A'. If you have any X'15' characters in positions 1-30, they will be changed to X'0A' characters. If you didn't get any changes in the dataset, then you don't have any X'15' characters in positions 1-30 of any of your records. Use the appropriate from-to pairs in your ALTSEQ statements to do the changes you want.
If you want to see what's in positions 1-30 of your records in hex, you can use a DFSORT job like this:
_________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Wed Jul 21, 2004 10:18 am Post subject:
Good. Thanks for the feedback. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Is this method of translation an effective one ? We are handling massive files with record length of around 3000 bytes and with over 20,000 records.
Is there a better / more efficient method for this conversion ?
Will writing an Assembler routine help in this scenario ?
Can anyone please help me with this
I wouldn't consider a mainframe file of 60MB as being particually massive. As far as available utilities for converting EBCDIC to ASCII that allow you to limit the conversion to certain fields, this is really the best solution.
Presumably, writing an optimized solution in assembler would PROBABLY be faster, but obvioulsy you would have to perform some benchmark tests to validate any perceived difference.
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Thu Jul 22, 2004 2:46 pm Post subject:
Programmer,
DFSORT is very efficient. Try it. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Frank, I am very happy to use DFSORT because of its simplicity and flexibility. But some architects in my shop want me to get a better solution than this.
I understand that any subroutine (Assembler/ Cobol/ Rexx) would still convert the data byte by byte, in a very similar fasion as DFSORT would do.
Can you please suggest me if my understanding is correct ?
Is there a way, where in we can convert the data in a more efficient way, may be record by record or by using some faster accessible tables ? _________________ Regards,
Programmer
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Thu Jul 22, 2004 3:50 pm Post subject:
Programmer,
I don't understand what you're asking.
I don't understand why your architects think DFSORT is less efficient than some undefined technique. DFSORT uses very optimized I/O and code paths and is very efficient for the copy application we're talking about here.
It's true that as a generalized utility, DFSORT incurs some overhead because it has to handle every possible situation. I imagine that a well-written program optimized to a specific situation could eliminate some of the generalized overhead DFSORT requires. Such a program could probably be more efficient than DFSORT for some small number of records. But unless that program also has very optimized I/O (EXCP access method), it will have a hard time beating DFSORT for a large number of records.
The only way to know for sure would be to write such a program and benchmark it against DFSORT.
BTW, DFSORT does not do the translation byte by byte - it's smarter than that. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
