|
View previous topic :: View next topic
|
| Author |
Message |
jimsnow
New User
Joined: 20 Feb 2023
Posts: 11
Location: us
|
|
|
|
I am trying to create a DFSORT job to parse the following data example:
| Code: |
----+----1----+----2----+----3----+----4----+----5----+----6
XXXX..JAMES SNOW..1234 OCEAN AVE..CHICAGO IL
EEEE01DCDCE4EDDE02FFFF4DCCCD4CEC13CCCCCCD444444444444444CD
7777A11145202566E11234063515015581389317600000000000000093
|
The length of field one (NAME) is a S9(4) COMP field always stored in the same position (5 in the data example). The X'11' in position 6 indicates the NAME field follows.
The remaining field lengths & field indicators will be in variable locations, depending on the length of the preceding fields. In my data example:
BI length OE (position 17) & ADDRESS indicator X'21' (position 18)
BI length 18 (position 33) & CITY/STATE indicator X'31' (position 34)
My goal is to take the variable length records and build fixed length records, with each of the 3 fields being 25 bytes in length (LRECL=75). The output file will contain the data only (lengths and field indicators will be omitted).
I believe I have a grasp on the parsing concept, but the variable length and positioning is my struggle. I also realize that this can be achieved with a simple, small COBOL program, but am limited to DFSORT. Thank you! |
|
| Back to top |
|
 |
Joerg.Findeisen
Senior Member
Joined: 15 Aug 2015
Posts: 1447
Location: Bamberg, Germany
|
|
|
|
Try this against your sample(s):
| Code: |
OPTION COPY
ALTSEQ CODE=(0040,0140,0240,0340,0440,0540,0640,0740,0840,0940,
0A40,0B40,0C40,0D40,0E40,0F40,1040,1140,1240,1340,
1440,1540,1640,1740,1840,1940,1A40)
INREC PARSE=(%01=(STARTAFT=X'11',ENDBEFR=X'21',FIXLEN=25),
%02=(ENDBEFR=X'31',FIXLEN=25),
%03=(FIXLEN=25)),
BUILD=(%01,TRAN=ALTSEQ,%02,TRAN=ALTSEQ,%03,TRAN=ALTSEQ)
END |
|
|
| Back to top |
|
|
jimsnow
New User
Joined: 20 Feb 2023
Posts: 11
Location: us
|
|
|
|
| This worked great. The ALTSEQ to space out the length got me over the hump. Hugely appreciate the help! |
|
| Back to top |
|
|
Joerg.Findeisen
Senior Member
Joined: 15 Aug 2015
Posts: 1447
Location: Bamberg, Germany
|
|
|
|
| Glad to hear, thanks for the feedback. If your fields are longer than 64 bytes, you need a different technique to trim the fields. However it's not a big issue at all. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2290
Location: USA
|
|
|
|
| jimsnow wrote: |
The length of field one (NAME) is a S9(4) COMP field always stored in the same position (5 in the data example). The X'11' in position 6 indicates the NAME field follows.
The remaining field lengths & field indicators will be in variable locations, depending on the length of the preceding fields. In my data example:
BI length OE (position 17) & ADDRESS indicator X'21' (position 18)
BI length 18 (position 33) & CITY/STATE indicator X'31' (position 34) |
Looks strange that the variable length fields do include both:
- field length prefix, and
- field type indicator byte.
Usually those are mutually exclusive... |
|
| Back to top |
|
|
jimsnow
New User
Joined: 20 Feb 2023
Posts: 11
Location: us
|
|
|
|
| sergeyken wrote: |
| jimsnow wrote: |
The length of field one (NAME) is a S9(4) COMP field always stored in the same position (5 in the data example). The X'11' in position 6 indicates the NAME field follows.
The remaining field lengths & field indicators will be in variable locations, depending on the length of the preceding fields. In my data example:
BI length OE (position 17) & ADDRESS indicator X'21' (position 18)
BI length 18 (position 33) & CITY/STATE indicator X'31' (position 34) |
Looks strange that the variable length fields do include both:
- field length prefix, and
- field type indicator byte.
Usually those are mutually exclusive... |
Understood - definitely not my design. There are fields, though, that are optional (name line 2, address line 2, etc.) that require different field type indicators. |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
