DB2 Load error on missing resource that I can't identify

John Poulakos · Posted: Sat Aug 04, 2012 2:38 am

I am getting this message:

DSNUGBAC - RESOURCE UNAVAILABLE

REASON 00C9008A
TYPE 00000240
NAME TAPIVP03

TAPIVP03 is defined as:

VALIDPROC TAPIVP03

in the table definition.

Where would it exist?

don.leahy · Posted: Sat Aug 04, 2012 3:26 am

I have never used one, or even seen one in the wild, but a VALIDPROC is a program. I suggest you ask your DBA where the TAPIVP03 load module lives.

Pandora-Box · Posted: Sat Aug 04, 2012 11:07 am

Is your tablespace in RW ?

dbzTHEdinosauer · Posted: Sat Aug 04, 2012 12:00 pm

Coding Rules for Validation Procedures can be found here.

you will notice that this is a db2 vsn7 reference.

if you are working in an environment with WLM, who knows where the stuff is.

since these libraries are not 'accessable' to programmers,
follow Don's advise and talk to your DBA.

This has nothing to do with the Table Status.
If the Table Status was RW
(or anything else that would preclude access of the table)
the processing would not have made it to the invocation of the VALIDPROC,
as VALIDPROC's are exit routines to executing SQL.

Pandora-Box · Posted: Sat Aug 04, 2012 12:04 pm

Thanks Dick for correcting my understanding

Apologies to all

John Poulakos · Posted: Sun Aug 05, 2012 1:35 am

Thanks guys. Let me ask if I could live without this module by dropping and recreating the table? My problem is I am trying to recreate a database to use for testing on another machine. The table definitions and unloads are all I have.

Anuj Dhawan · Posted: Sun Aug 05, 2012 2:16 am

DSNUGBAC should have been accompanied with DSNT500I. Said that, I'll vote in for dropping and recreating the tables.

dbzTHEdinosauer · Posted: Sun Aug 05, 2012 2:38 am

DSNUGBAC is the module reporting the error - so, I imagine that it is there.

HLASM TAPIVP03 is a validation procedure that enabled
the business to implement ?
that went beyond the capabilities of Triggers and Restrictions.
most often EDITPROCs/VALIDPROCs are written,
because the implementation of business rules in the application code are
beyond the capabilities of application programmers - or it is just too hard
e.g. many many modules doing INSERTs/UPDATEs
and like triggers EDITPROCs/VALIDPROCs are invoked based on the action of the SQL on the table.

triggers are bypassed during loads. don't know about E/V-procs.

If the results of your testing on the other machine
are supposed to duplicate that of your existing machine,
you may not achieve your goal.

you can always find the HLASM source, port it to the new machine,
and create the VALIDPROC there,
but then you would have to drop/create/load your table.

sounds as if you are at the mercy of a very poor analysis and implementation plan.

John Poulakos · Posted: Mon Aug 06, 2012 8:57 pm

I blame marketing for trying to rush something through, but that's another story. I was able to contact the person responsible for the original database and he told me TAPIVP03 was used to link to a statistics package and I didn't need it any more. So, thank you gentlemen and on to the next exciting "discovery".

Anuj Dhawan · Posted: Tue Aug 07, 2012 1:32 pm

Thanks for the feedback. However, what is the next step you take to get out of this mess?

John Poulakos · Posted: Tue Aug 07, 2012 9:36 pm

I dropped and redefined the tablespace and table without the VALIDPROC TAPIVP03 clause in the create table step.

Before doing this, I had to end the outstanding Load utility (it was still hanging from the error that started this problem).

-TERM UTIL(TEMP)

dbzTHEdinosauer · Posted: Tue Aug 07, 2012 10:28 pm

welcome to the world of dba ojl (on-the-job-self-learning)
you have done well, good performance and
thx for continually getting back to us. learned a lot.

Anuj Dhawan · Posted: Tue Aug 07, 2012 11:19 pm

Yes, Thanks for the feedback, this helps.