ca.portal.admin

Re:Re: Computed DBKEY from a SQL Table Procedure

Discussion created by ca.portal.admin on Jun 26, 2007
Joe,

This is only happening on dbkeys with very high page
numbers. Right? When the page number is greater than
8,388,607 (x'7fffff'), the high order bit in the dbkey
is on, so it is a negative number.

Rich Kurzawski
--- ""Cates, Joe"" <Joe_Cates@MCPSMD.ORG> wrote:
I have written a number of COBOL Table Procedures
over the past several
years to help with data migration to a relational
database. These Table
Procedures use EDBC and have performed well. There
is now a need to
include the DBKEY, in a decimal format, as an
additional column. There
is an unusual situation with the computed key in
that the page number is
correct but the line isn't. For example, a DBKEY
that should compute to
page 1234 and line 56 gives 1234 for the page and
944 for the line. Line
57 computes to 943, 58 to 942 etc. The work around
is to subtract the
line number from 1000 to get the correct result. I
have an open issue
with CA and was given some instructions to create a
version of CEEUOPT
and link it with my program to allow for TRAP=OFF.
The program was
altered to do a zero divide to cause an ABEND. The
job is to run locally
to produce a SYSMDUMP. The systems programmer
followed those
instructions but we are unable to produce the
required dump. The other
frustrating situation is we are unable to get the
CEEUOPT to resolve via
an INCLUDE. Any suggestions??



Thanks,



Joe S Cates, Database Analyst II

Systems Architecture and Operations
Database Management/Unix Administration

Montgomery County Public Schools

Rockville, MD 20850

301-279-3697

joe_cates@mcpsmd.org






________________________________________________________________________
____________Ready for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
UOWID analysis - CA-IDMS enhancement submitted
"Hello,

CA-IDMS customers interested in performing detail-level IDMS transaction correlation to associated
transactions (for example with CICS, DB2, and WebSphere MQ, for a given business transaction) may
consider helping the cause for a CA-IDMS enhancement. CA must add the NETNAME/UOWID information
(from FMH5) similar to how these other subsystems that capture this information, and then add data
to the CA-IDMS SMF record (PMAM task section). Once a pending DAR is accepted by CA internally, it
will go out for USER GROUP voting.

Sincerely,

Scott Barry
SBBWorks, Inc.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Computed DBKEY from a SQL Table Procedure
"
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
imagination.

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

Outcomes