Re:Re: Computed DBKEY from a SQL Table Procedure

Discussion created by ca.portal.admin on Jun 28, 2007
No, you can't blame CA for TRUNC(BIN); blame IBM. This has
been this way since COBOL II days. In the days of VS COBOL, there were
only two options TRUNC, which meant truncate to the picture size for
binary (COMP) fields, and NOTRUNC, which meant allow the field to hold
the maximum internal size. So, for a PIC S9(8) fields that had TRUNC on
then the maximum would be +/-99,999,999 when TRUNC was on and between
negative 2,147,483,647 and positive 2,147,483,648 if NOTRUNC was on.

Then with COBOL II, IBM came up with TRUNC(BIN) which is roughly
equivalent to NOTRUNC but generates inefficient code; therefore, you
should avoid binary fields for calculations when possible (but you have
no choice for your DBKEY calculation). TRUNC(OPT) means optimize the
code but still truncate. And TRUNC(STD) means the same thing as TRUNC
did in the old days. Why they did this defies both logic and

As for your calculations to translate DBKEYS to line and page,
which is fine as long as the radix is 8. It will NOT work if you change
the radix to something different. If you want something to calculate
the line and page regardless of radix, you can use my program DBX1EX31,
which is on the user contributed library.

Dan Miley
Lockheed Martin