Bringing Knives to Gunfights...

It is always considered wise to use the right tool for the job, and
SyncSort isn't really intended to do data editing.  That said, you could
define the numeric field as several one character fields, and test each
for having a valid character (0 - 9).

I wonder if the speed of Syncsort in data handling can make up for the
l;aborious checking of each byte?

You could also write an E15 exit routine, even doing so in COBOL.
However, if you do so, wouldn't it be easier to just write a COBOL edit
program, and then sort the data that "survives"?  (Maybe not as fast,
but easier.)

Jeff nor Lisa wrote:

> We're using Syncsort OMIT cards to eliminate unwanted records
> from a file.  One of the criteria is non-numeric data in
> certain fields.  I was wondering if there was a "backdoor" way
> to set up a test for that since Syncsort doesn't have an
> explicit test for numeric (like COBOL or DYL280 does).
>
> Since Syncsort allows fields to be defined in a variety
> of ways--binary, zoned decimal, etc., I wonder if there
> was some sort of test to exploit the mainframe structure of numeric
> characters (our numeric fields are strictly unsigned character,
> plain old F7F8F2 means 782.  That is, is there some sort of easy
> way for Syncsort to "split" the byte to test if the left side
> is only "F" and the right side is between 0 and 9?
>
> On S/370, is the right side considered the "zone", or does
> "zone" refer to the top part of a punched card only?
>
> Thanks for your help.
>
> [public replies only, please]