Syncsort--numeric class test?

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]

Use exit E15, it is ideal for all kinds of input data filtering.
Extremely simple to code too, preferably in assembly language
(much easier that coding it in COBOL!).

I am sorry I do not have any of my own E15 source modules
any more, but I believe you can find good samples in the
documentation for any SORT program.

Your "problem" would be solved by simply setting up a
translate and test table and perform the TRT instruction
on the field you require to be numeric. The entire source
should require less than 20 lines of effective code.

regards Sven

"Jeff nor Lisa" <hancock4@bbs.cpcn.com> wrote in message
news:de64863b.0310291142.71379cdb@posting.google.com...
> 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]

hancock4@bbs.cpcn.com (Jeff nor Lisa) wrote

> 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?

After I made the post, someone suggested I test _each_ byte
of the field as binary to see if it is between 240 and 249--
the binary equivalents of F0 to F9.  Note that in my file
the fields are defined as alpha-numeric so I don't have to
worry about a sign overpunch in the last digit as in true
zoned decimal.

It's been so long since I worked with internal representations
of data that I forgot about the stuff.


WAY, WAY OFF TOPIC:  Speaking of internal representation, I read
that on the PC x86 instruction set, it does support "packed"
decimal fields for numbers, but I don't think they are needed
for arithmetic calculations; and aren't used in the PC world.

"Jeff nor Lisa" <hancock4@bbs.cpcn.com> wrote in message
news:de64863b.0310300759.44437258@posting.google.com...

>
> It's been so long since I worked with internal representations
> of data that I forgot about the stuff.
>
>
> WAY, WAY OFF TOPIC:  Speaking of internal representation, I read
> that on the PC x86 instruction set, it does support "packed"
> decimal fields for numbers, but I don't think they are needed
> for arithmetic calculations; and aren't used in the PC world.

I believe there is add/subtract in packed or zoned, one byte at a time, and
multiply/divide in zoned only, again one byte at a time.   It would take
some work to do real code with them.

-- glen

Jeff nor Lisa wrote:
> hancock4@bbs.cpcn.com (Jeff nor Lisa) wrote
> After I made the post, someone suggested I test _each_ byte
> of the field as binary to see if it is between 240 and 249--
> the binary equivalents of F0 to F9.  Note that in my file
> the fields are defined as alpha-numeric so I don't have to
> worry about a sign overpunch in the last digit as in true
> zoned decimal.

See the following "Smart DFSORT Trick" for an easier way to
do this.  I suspect it will work with Syncsort as well.

Frank Yaeger - DFSORT Team  (IBM) - yaeger@us.ibm.com
Specialties: ICETOOL, OUTFIL, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

Frank Yaeger wrote:

> See the following "Smart DFSORT Trick" for an easier way to
> do this.  I suspect it will work with Syncsort as well.

Oops.  Forgot to put in the URL - here it is:

http://www.storage.ibm.com/software...tmtrck.html#a01

Frank Yaeger - DFSORT Team  (IBM) - yaeger@us.ibm.com
Specialties: ICETOOL, OUTFIL, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

Frank Yaeger <yaeger@us.ibm.com> wrote

> Oops.  Forgot to put in the URL - here it is:
>
> http://www.storage.ibm.com/software...tmtrck.html#a01

Thanks for the post!  Interesting stuff.