ca.portal.admin

Re:Debugging database procedures

Discussion created by ca.portal.admin on Mar 29, 2007
What techniques are available for debugging database
procedures? I am talking here about the kind that are tied to
a record via the schema description.

We are getting D003 errors when trying to use DEBUG. Is DEBUG
supposed to work with database procedures?

My personal favorite technique for debugging online programs is
""displaying"" to the log via the WTL command. But you are not
supposed to make DML calls from a database procedure.

Any suggestions would be most welcome.

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Debugging database procedures
"I should probably be hauling out and reviewing my almost 20-year-old copy of
""Customizing IDMS/R Software: Database Procedures, Map Edit Modules, and
User Exits"" before I go running off on ancient memories, dealing with things
that may have changed in the intervening epochs again, but for what it's
worth...

When IDMS (DC or DB) needs to call a module that could be written either in
system or user mode, it needs to know before it makes the call which
convention to use.

One is allowed to create both numbered exits and DB procedures in either
system or user mode, therefore the invoking code needs to know how to
construct the call. DBMS has separate code expansions to allow calls into
DB procedures using user mode (sometimes referred to as IBM calling
conventions) or system mode calling conventions. Ditto those areas of DC
where calls can be of either flavor (numbered exits).

DBMS uses inspection of entrypoint logic to determine which is appropriate,
then issues a call in the correct format. It has to do this as there is no
other mechanism, especially in local mode, to signal to DBMS code which it
is to use. If it sees what appears to be a #START expansion, it goes down
the system mode calling path.

For numbered exits, RHDCUXIT provides in the exit table (customized by the
site) the information needed to determine whether the exit is
resident/linked, or dynamically loaded... and what calling conventions to
use in invoking the exit. For dynamically loaded exits, if I recall
correctly, the calling mode is always user and of course a PDE is required.
For the former, the UXIT table specifies the calling protocol to be used,
and no PDE is involved.

I dimly recall map edit modules always run in system mode and have to be
linked with the map, but then again see opening paragraph regarding
infrequently used neural pathways.

Caveat lector: read current documentation carefully before building such any
such beasties.

One final note on this string: If you use the #WTL suggestion below (my
favorite), make absolutely sure you include the ""MSGDICT=NO,"" line in Pete's
example, to prevent IDMS from trying to read message information from the
dictionary (way too heavyweight an operation for this exercise).

Don Casey

Outcomes