Unable to convert using EDIT MASKS or predefined patters

grlewycky · Posted: Fri Apr 14, 2006 2:59 am

I'm testing the EDIT MASKS with the upgraded DFSORT (we were behind a few years)

I have a COMP-3 field containing dollars that I am trying to convert so that I can port it to use in ascii on Oracle.

I need to have:
1. the dollar amount without commas
2. amount in cents with a decimal point
3. sign byte if negative value

I have been testing various EDIT MASK patterns (m25, m12, m2)
and even created my own (see below) all with no luck....

Either it abends with S0C7, U011, or I get all zero's !!!!!!

-----------------------------------------------------------
EDIT=(IIIIIIIT.II)) 0C7
EDIT=(IIIIIIIT.II))
EDIT=(IIIIIIIT)) S0C7
EDIT=(IIIIIIIT)) ALL 0

OUTREC FIELDS=(1:290,17,PD,M25) U011
OUTREC FIELDS=(289,20,ZD,EDIT=(IIIIIIIT.II)) 0C7
OUTREC FIELDS=(289,08,FS,EDIT=(IIIIIIIT.II))
OUTREC FIELDS=(289,08,PD,EDIT=(IIIIIIIT)) S0C7
OUTREC FIELDS=(289,08,FS,EDIT=(IIIIIIIT)) ALL 0
OUTREC FIELDS=(1:290,07,ZD,M2)
OUTREC FIELDS=(1:290,20,ZD,M2) S0C7
OUTREC FIELDS=(1:290,20,PD,M2) REFORM FIELD ERROR
OUTREC FIELDS=(1:290,20,PD,M12)
OUTREC FIELDS=(1:290,7,PD,M12)
OUTREC FIELDS=(1:290,7,PD,M12)
0C7 OUTREC FIELDS=(290:7,12,PD,M12)
ALL ZERO OUTREC FIELDS=(290:8,12,FS,M12)
ALL ZERO OUTREC FIELDS=(290,12,FS,EDIT=(IIIIIIIT.II))
0C7 OUTREC FIELDS=(290,7,PD,M11)
0C7 OUTREC FIELDS=(289,7,PD,EDIT=(IIIIIIIT.II))
--------------------------------------------------------------------------

Below is a sample of my data which I'm trying to convert to:
-1671.45 or 1671.45- or 0000001671.45-

Frank Yaeger · Posted: Fri Apr 14, 2006 3:31 am

I can't figure out where your PD value starts or how long it is.

Is it the 9-byte value:

400000615
00000174D

value? Or the 8-byte value:

00000615
0000174D

value? Or what?

From the output you show you want, it appears to be the 8-byte PD value, so why are you show the blank (X'40') before it? Are you mistakenly using the position of the blank as the starting position, or using the wrong length or what?

You need to get the starting position and length right.

Frank Yaeger · Posted: Fri Apr 14, 2006 5:03 am

I just had another thought? Is your input file VB? If so, you need to add 4 to the starting position to account for the RDW.

To show us what your values actually look like in hex, you can run this DFSORT job and post the output:

grlewycky · Posted: Fri Apr 14, 2006 8:07 pm

Frank

I'm sorry for the confusion. I copy & pasted more than was needed, it is the 8-byte value as you suspected.

I was playing around with the length since it wasnt abending but the results werent correct.......

The source is a fixed length flat file than I use DFSORT

Frank what is phase C3 in this message mean? Any significance?
ICE185A 0 DFSORT TERMINATED WITH S0C7 ABEND DURING PHASE C 3

Abend
Code mESSAGE
====== =======================

S0C7 ICE185A 0 DFSORT TERMINATED WITH S0C7 ABEND DURING PHASE C 3

CODE:
SORT FIELDS=(COPY)
INCLUDE COND=(11,2,CH,EQ,C'LD')
OUTREC FIELDS=(289,8,PD,EDIT=(SIIIIIIIT.TT),SIGNS=(-))
------------------------------------------------------------------------------

S0C7 ICE185A 0 DFSORT TERMINATED WITH S0C7 ABEND DURING PHASE C 3

SORT FIELDS=(COPY)
INCLUDE COND=(11,2,CH,EQ,C'LD')
OUTREC FIELDS=(289,8,PD,EDIT=(SIIIIIIIT.TT))

All three variations below keep returning S0C7:

OUTREC FIELDS=(289,8,PD,EDIT=(SIIIIIIIT.TT),SIGNS=(-))
OUTREC FIELDS=(5X,289,8,PD,EDIT=(SIIIIIIIT.TT),SIGNS=(,-))
OUTREC FIELDS=(5X,289,8,PD,EDIT=(SIIIIIIIT.TT),SIGNS=(-))

Thanks alot for your assistance

George

Frank Yaeger · Posted: Fri Apr 14, 2006 8:51 pm

C3 just means the S0C7 was detected in phase 3 of the COPY application.

The S0C7 probably indicates you have an invalid PD value, e.g. a digit of A-F instead of 0-9 somewhere in one of the values. So I'm still guessing you're using the wrong starting position or length for the PD field.

Run the job I showed you as I requested in my previous post, and show me the //SORTOUT output:

Frank Yaeger · Posted: Fri Apr 14, 2006 9:32 pm

Also, you can run this DFSORT/ICETOOL job to identify invalid PD values:

grlewycky · Posted: Fri Apr 14, 2006 9:46 pm

Records 61-63 seem to have some culprits and i show them below...

but i have my disp as new,catlg,catlg so some of these
records should be in the file but the file turns out empty still.....

I omitted those records and the code is working perfect now !!!
Thanks alot Frank !!!!!
This is a fantastic feature of DFSORT !!!!!

George

0VLJF0E5D3D1|000000000026549D00000000
0VLJF0E5D3D1|000000000056312D00000000
0VLJF0E5D3D1|000000000047489D00000000
0VLJF0E5D3D1|000000000047489C00000000
0VLJF0E5D3D1|000000000079059C00000000
0VLJF0E5D3D1|000000000026549C00000000
0VLJF0E5D3D1|000000000056312C00000000
1VJCF1E5D1C3|0CF0C040F040404040404040
1VJCF1E5D1C3|0CF0C040F040404040404040
1VJCF1E5D1C3|0CF0C040F040404040404040
0VLJF0E5D3D1|000000000072880D00000000
0VLJF0E5D3D1|000000000073641D00000000
0VLJF0E5D3D1|000000000089508D00000000
0VLJF0E5D3D1|000000000031567D00000000
0VLJF0E5D3D1|000000000031567D00000000

Frank Yaeger · Posted: Fri Apr 14, 2006 10:19 pm

Yep. That shows up the invalid PD values that were causing the 0C7.

The VERIFY job I showed you would have pinpointed just those records with the invalid values.