Joined: 07 Oct 2014 Posts: 8 Topics: 4 Location: HYDERABAD
Posted: Fri Jan 30, 2015 11:49 am Post subject: Input File Declaration in Easytrive
Hi,
I have an input flat file (INFILE) with reclen 80 passing to Easytrive as Sequential Read by giving JOB INPUT INFILE and trying to copy the data to another file OUTFILE
in the Easytrive i have the below Input file declaration
Code:
FILE INFILE
IN-REC 1 80 A
IN-F1 1 5 N
IN-F2 7 4 A
My input file has the below data
Code:
0T410 5678
12341 1223
0E345 7890
even though the input (pos-1 to 5) is having the alphanumeric value and the declaration is NUMERIC, the job is not getting abbend
i am trying to move the values to output file. i am getting different value in the output file i.e. T is getting as 3 and E is getting as 5
Code:
03410 5678
12341 1223
05345 7890
can any one help in knowing why this is getting different values instead of getting abbend.
Joined: 26 Nov 2002 Posts: 12370 Topics: 75 Location: San Jose
Posted: Fri Jan 30, 2015 12:18 pm Post subject:
pawan.konduru,
You need to understand how unsigned zoned decimal values are processed.
A field to be tested for numerics in zoned decimal format looks like this in hexadecimal:
Code:
zdzd...sd
The field is considered to be zoned decimal numeric if every z is F, every d is 0-9, and s is C, D or F. Otherwise, the field is considered to be zoned decimal non-numeric. For example, '1234' (X'F1F2F3F4'), '123D' (X'F1F2F3C4') and '123M' (X'F1F2F3D4') are all considered to be zoned decimal numeric, whereas 'A234' (X'C1F2F3F4'), '12.3' (X'F1F24BF3') and '123X' (X'F1F2F3E7') are all considered to be zoned decimal non-numeric.
Now look at the hex values for your input data.
Code:
0T410 5678
FEFFF4FFFF
0341005678
Define your IN-F1 as follows and re-run your job
Code:
IN-F1 1 5 N 0
_________________ Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Joined: 31 May 2004 Posts: 391 Topics: 4 Location: Richfield, MN, USA
Posted: Fri Jan 30, 2015 1:26 pm Post subject:
If I remember correctly, Easytrieve MOVE statements act differently than COBOL MOVE statements. It had something to do with not converting during the MOVE. I'd try using the ASSIGN statement to accomplish moves, e.g., OUT-F1 = IN-F1. _________________ ....Terry
As with COBOL or anything else, just having a value which *you* know is not numeric is not a sufficient condition for a data-exception (S0C7).
Try replacing your final byte with, for instance, a full-stop/period.
What you need to do is *test* for NUMERIC if you want an abend if it is not numeric. The abend you'll have to arrange yourself.
Code:
IF NOT ( silly-meaningless-name NUMERIC )
do some stuff to make an abend, site specific
END-IF
For an unsigned field, your definition is correct (1 5 N). 1 5 N 0 would give you a signed field with zero decimal places. Specifying decimal places (even zero) makes the field signed.
MOVE does indeed do moves without conversion. Except for files, or when you need it, use assignments not MOVE.
However, if the T has become a 3, you are already using an assignment.
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
