|
View previous topic :: View next topic
|
| Author |
Message |
MichaelKBS
New User
Joined: 10 Jan 2006
Posts: 24
Location: Germany
|
|
|
|
In my shop we have to convert our files from EBCDIC to ASCII regarding of binary length-fields that must not be converted. This works fine with DFSORT and ALTSEQ CODE=(..,..,...) using OUTREC FIELDS.
f.e.: OUTREC FIELDS=(1,4,
5,76,TRAN=ALTSEQ)
means that position 1-4 is not to be converted while 5-76 is to be converted to ASCII.
NOW MY QUESTION:
-----------------------
Some of our files contain binary lengths in variable positions framed by x'FF' (=High Value, appears as '.')
That looks like:
Harry*Hirsch.0009.Something.000C.123456789012
Florence*Fisher.000D.SomethingElse.000E.12345678911234
Is it possible to convert these records and preserve the length-fields?
Thank you for your answers!
Mike |
|
| Back to top |
|
 |
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
It's not clear what you mean. When you say you have binary lengths in variable positions framed by X'FF', do you mean something like:
X'FF0003FF' for a 3-byte length? Or do you mean something else?
Or do you just mean you have X'FF' bytes as delimiters between the fields?
Please show an example of the input records in hex that shows what the input records really look like, and what you want for output. |
|
| Back to top |
|
|
MichaelKBS
New User
Joined: 10 Jan 2006
Posts: 24
Location: Germany
|
|
|
|
| Frank Yaeger wrote: |
It's not clear what you mean. When you say you have binary lengths in variable positions framed by X'FF', do you mean something like:
X'FF0003FF' for a 3-byte length? Or do you mean something else?
Or do you just mean you have X'FF' bytes as delimiters between the fields?
Please show an example of the input records in hex that shows what the input records really look like, and what you want for output. |
Hi Frank,
the data in our file is compressed by a program to decrease the usage of storage. For instance: 10 spaces are compressed to 1 preceeded by a length-field X'FF000AFF'.
The X'FF'-bytes are only used as begin and end delimiters to identify the length-fiedls in the records.
That means when X'FF000AFF' appears, the first X'FF' tells us, that now a binary length-field begins. The actual length is X'000A'. The second X'FF' indicates the end of the length-field.
Cause the length-fields are not at fixed positions, they are in between x'FF'-bytes to be easily identified. These X'FF....FF'-fields must not be converted to ASCII by ALTSEQ=TRAN, otherwise we would loose the lengh-information.
What I need is something like:
OUTREC FIELDS (1,4,
5,ALTSEQ=TRAN)
but: without translating the X'FF....FF'- fields!
The problem is, I can't give fixed positions for them. They can stand on various positions.
Can we combine PARSE-Option with ALTSEQ=TRAN ? |
|
| Back to top |
|
|
MichaelKBS
New User
Joined: 10 Jan 2006
Posts: 24
Location: Germany
|
|
|
|
This is how the conversion is to be made:
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----10---+----11---+----12---+----13---+...
Input data:
1 : ----ebcdic-code----FF0003FF--------ebcdic-code-------FF003AFF--ebcdic-code...
2 : -------ebcdic-code--------FF0003FF----ebcdic-code---FF003AFFebcdic-codeFF0011FF-------------ebcdic-code-------------
3 : ...
Output data:
1 : -----ascii-code-----FF0003FF--------ascii-code---------FF003AFF--ascii-code...
2 : --------ascii-code---------FF0003FF-----ascii-code----FF003AFF-ascii-code-FF0011FF-------------ascii-code-------------
3 : ... |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
If the values between X'FF' pairs are NOT found in any of the EBCDIC values, then you could just not change those values with ALTSEQ. For example, if the largest repetition factor is 20, so the X'FF' fields vary from X'FF0001FF' to X'FF0014FF', and X'00'-X'14' and X'FF' do NOT appear in the ebcdic values, then you could use TRAN=ALTSEQ on the entire record providing you didn't change X'00'-X'14' and X'FF' with the ALTSEQ table.
Otherwise, you'd have to PARSE the record to separate the fields so you'd have to know the maximum number of separate fields in a record and the maximum length of a field. Then you'd have to use IFTHEN clauses to find the resulting fields that don't start with X'FF' and use TRAN=ALTSEQ on them. Then you'd have to SQZ the fields back together again. This could be quite tricky depending on what the ebcdic fields actually look like (for example, whether or not they have blanks that need to be kept), the maximum number of fields per record, the maximum length of each field, etc. You might actually be better off writing a program or exit with appropriate logic in this case. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
supposing you are going to transfer things to a different platform
it would be better to remember the issue of endiannes ( for the halfword representing a length )
not always what You see is what You get
here is a c snippet to show the endianness
| Code: |
// endian.c
//
// test to show "endian-ness".
//
#include <stdio.h>
int main(int argc, char *argv[]) {
int i;
union {
unsigned short int bin;
unsigned char hex[2];
} halfword;
union {
unsigned int bin;
unsigned char hex[4];
} fullword;
halfword.bin = 0x1234;
printf("halfword.bin = %04x, ", halfword.bin);
printf("halfword.hex = %02x%02x\n", halfword.hex[0], halfword.hex[1]);
fullword.bin = 0x12345678;
printf("fullword.bin = %08x, fullword.hex = ", fullword.bin);
for (i = 0; i < 4; i++) {
printf("%02x", fullword.hex[i]);
}
printf("\n");
if (halfword.hex[0] == 0x34) {
printf("Your machine is little endian. (e.g., x86....)\n");
}
else {
printf("Your machine is big endian. (e.g., S370...)\n");
}
return 0;
}
|
|
|
| Back to top |
|
|
MichaelKBS
New User
Joined: 10 Jan 2006
Posts: 24
Location: Germany
|
|
|
|
Thank you Frank and Enrico,
my problem seems to be a bit too special for DFSORT. I think I'm going to try with REXX's translate function. However, I love using DFSORT for it's so damn fast working and a very powerful tool.
Regards,
Michael |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| it's so damn fast working |
If the file contains a high volume of data, you will most likely not be happy with the performance of rexx. . . |
|
| Back to top |
|
|
|
|
