Re: Need help about an OCL

Mark,

There's no concept of a field in FMTDTA (nee #GSORT!)

I know that (which is the major disadvantage to FMTDTA), but it is more like
comparing a "field" than it is a constant in the sort specs as is the case
with having a C.

and the "C"haracter type of request does allow more than one character to
be compared, IIRC.

Oh yes it could.  For example:

   I P 152 155NEC0000000

would check to see if a packed field in 152-155 was not zero.  Or in another
OCL which I just looked at, there is:

    I U 110 114GEC?1?                 INCLUDE WITHIN 5-DIGIT ZIP CODE
    IAU 110 114LEC?2?                   BEG/END LIMITS

which dynamically compares the zip codes to begin/end limits passed in
parameter values or taken from a // PROMPT.  Of course, FMTDTA doesn't
support variable substitution in the same way though.  Either OPNQRYF or SQL
would be a better fit now.

Typically you used constants for the comparison values, but the F meant to
compare to other bytes within the input record.  My mneumonic for that was
"field", but maybe the actual defintion was something else (fixed format)?

If #GSORT treated the F as a C in that byte, it would attempt to compare the
input value to the actual numbers listed after the NEF in the sort spec.
And then it probably wouldn't include very many records at all.  :)

Doug