I am writing a REXX program for my requirement and in one part, I will refer the copybook for a starting position, length and datatype of 'some' fields and I need to check in the file whether in the specified position, the value is of the specified datatype. I have no problems in finding out the starting position, length and datatype in copybook. But I am wondering how I can check whether the same is there in file.
This might sound as a strange requirement. But I have started with DATATYPE built in function, later to realize that won't work.
I got your post, I can now handle PACKed values. But I am thinking how can I handle the other two cases
a) PIC S999
b) PIC S9(4) COMP.
In case a), I will get 12E in sequential file for +125 value (which is a valid value), I will have to check whether a similar Builtin function (of C2X) will help to identify this as correct value.
In case b), I will check how I can validate the value in this case.
I can connect to my machine tomorrow and will try.
noo way to check anything for a COMP
a binary is ALWAYS a valid number
Er, Let me explain the full scenario.
Assume that the current layout for a sequential file which is an input to a COBOL program is of LRECL 300. The previous layout of the input file, for ex, could be any of the below cases.
a) LRECL 270
b) LRECL 300 (270 + FILLER X(30)), whereas the current layout is 300 (an ex can be 270 + PIC S9(4) COMP + PIC S9(8) + PIC X(20), or can be any other combination.
Now, we can expect any of the files mentioned in the above cases, can be passed as input to the current version of the program. I will not know the old copybook. The new fields will always get added at last. I need to modify the incoming file to the new layout, for ex, in case b), the last 30 bytes of old file, which has 30 space, should be replaced with zeroes for comp field + zeroes for Zoned decimal field + 20 spaces for alphanumeric field. By this, the program will run successfully.
What I have planned is,
a) determine the layout of the new copybook using FILEAID RLPRINT in batch mode.
b) Determine the LRECL of the incoming file by LISTDSI, check whether the last Numeric (can be Zoned decimal, Binary, Packed decimal) field of the file as per the current layout contains only numeric values(can be Zoned decimal, Binary, Packed decimal), If not, then it is evident that the input file is not the latest one. I will create a SORT control card to insert zeroes of the corresponding data type. I will perform this check (from last field to first field) until the numeric field in the file matches with the Numeric field position mentioned in the layout.
I know this is a weird requirement and I know some of you experts will advice me to check the source of the input file and correct it there. This requirement is for one of my colleague. Since I know Rexx (to some extent), I jumped in for help. The first question I asked him is: "Can't you correct the input file" and it seems they can't. And now I am stuck in how to validate whether a value specified in the file in a particular position of specified length is a valid binary or zoned decimal number.
@Akatsukami, Thanks, I will try out what you suggested.
And sorry for the long post. Any suggestion in alternate approach is also welcome.
Joined: 06 Jun 2008 Posts: 8550 Location: Dubuque, Iowa, USA
A binary field will be 2, 4, or 8 bytes. There is no such thing as an invalid numeric value for a binary field, as you were told earlier, as every bit combination is a valid bit combination and hence represents a valid binary number. For example, X'F7F7' is a 2-byte binary value of 63479 -- but it also could be a 2-digit zoned decimal number with a value of 77.
In fact, if you check the COBOL Language Reference manual, you will find that IF NUMERIC is not valid for binary data -- because the test cannot fail.
Just looking quickly, what compiler sub-option do you have for TRUNC for the program which reads the file?
Can you be more clear about your input file, like "any combination"? If there is data which is not identifiable from "something" on the record, then how is it ever going to be processed? As a once-off you might be able to "guess", but not day-in-day-out.