MVSFORUMS.com

[sumithar]

We recently converted from plans to packages (or to be very specific, from using plans that contained DBRMS to using plans that contain packages).

In the past for a given CICS transaction or batch program it was easy to find out which tables were used by that program- I could look in SYSIBM.SYSTABAUTH with a query like

select tcreator,ttname,insertauth,selectauth,
updateauth, deleteauth from sysibm.systabauth where grantee= plan_name

But now we are using a "universal" plan- so I can't use this tack. I guess I could provide the package name in the grantee field but that means I need to know all the subroutines called by my main program and do each one in turn.

Is there some technique to "automate" this? So I can still provide the main program name and get a list of all tables used by it and the called subroutines (we do use dynamic invocation of subroutines for our batch programs btw)

Thanks

[dbzTHEdinosauer]

within the systabauth there must be some column that contains a value unique to applications / someway.

also, i don't care what method you use, plans w/dbrms or plans w/packages.
you should be able to find a module name someplace in systabauth
in the unlikely event that there actually are no module names in systabauth
which means that there are unique package names that relate directly to one and only one module

so you may have to create a cross-reference table

create and populate it with spufi

somewhere, someplace in your site, there is some magnetic media containing this cross-ref either intentially or as-a-result-of such as
A BIND LISTING
and then parse this with a rexx or program

and then run it regularly to stay up-to-date with development/maintenance changes

and then use a JOIN in your SELECT to allow yourself a WHERE clause that equates to your module name.
_________________
Dick Brenholtz
American living in Varel, Germany

[GuyC]

DBRM PLANs needed all DBRMs of main programs and subroutines.
Someone had to maintain this (just to issue the bind statement)
and it was reflected in SYSTABAUTH.
But this doesn't mean that DB2 magically knows which subroutines are used by a program.

[sumithar]

[papadi]

[dbzTHEdinosauer]

you desire a method whereby you can select from sysibm.systabauth the tables a particular module accesses.

ok, fine.
before, the plan name was the same name as a module and the select was easy.

now, there is a different 'plan/package' name that refers to a module.

all i am suggesting is, create a cross reference of 'your module names' and the new 'plan/package names'.

you keep trying to differentiate between module and subroutine. why?

I have no idea what your set-up is like. only you know about your site.

i suggest that you have not investigated enough
i.e. talked to your dba to determine what their naming scheme is.

obviously you do not have a 'global' perspective of your system.
you have to acquire that before you can proceed.
_________________
Dick Brenholtz
American living in Varel, Germany

[papadi]

Hi Dick,

[sumithar]

[papadi]

Most of us understand what you want.

As has already been posted, this will probably take considerable (manual) effort to get the initial "version" of this matrix. After it is built, it will have to be kept current.

Some of the places i've supported have standards that all of this cross-reference material is kept in a separate database. Then a "where used" is simply a matter of running a query. Several of these places support applications on multiple platforms, but use a common repository to track "where-used".

Any time anything new is to be promoted, part of the promotion process is to ensure that any new pieces have been incorporated into the repository.

These organizations spent a lot of time and effort to develop these repository applications and consider them proprietary.
_________________
All the best,

di

[sumithar]