How To Find The Plan For A Program

[OppThumb]

Hi,

I've been searching this newsgroup for an answer to my question, and
the closest I've come asks my question, but in reverse ("How to figure
out the program from plan/package"). I've -- shall we say, inherited?
-- a COBOL program with very little documentation that I've recompiled
for debugging purposes. The compile/link/bind have all been done, but
nothing in the output tells me what plan the program has been bound to,

so I can't execute until I know. I imagine that somewhere in the SYSIBM

tables I can find the information, but so far I haven't found the right

table.
Any help would be appreciated.
Thanks,
John

P.S. I previously posted this request in 'bit.*listserv.*db2-l'. I
should have cross-posted, so if you get this twice, sorry 'bout that...

[Gert van der Kooij]

In article <11*********************@f1g2000cwa.googlegroups.c om>,
ca******@gmail.com says...

Hi,

I've been searching this newsgroup for an answer to my question, and
the closest I've come asks my question, but in reverse ("How to figure
out the program from plan/package"). I've -- shall we say, inherited?
-- a COBOL program with very little documentation that I've recompiled
for debugging purposes. The compile/link/bind have all been done, but
nothing in the output tells me what plan the program has been bound to,

so I can't execute until I know. I imagine that somewhere in the SYSIBM

tables I can find the information, but so far I haven't found the right

table.
Any help would be appreciated.
Thanks,
John

P.S. I previously posted this request in 'bit.*listserv.*db2-l'. I
should have cross-posted, so if you get this twice, sorry 'bout that...

Which DB2 version on which OS are you using?

[OppThumb]

....

Which DB2 version on which OS are you using?

....

I'm using DB2V7 on z/OS 1.05.00. Is this something that would be
release-dependent?

[Robert]

OppThumb wrote:

...

Which DB2 version on which OS are you using?

...

I'm using DB2V7 on z/OS 1.05.00. Is this something that would be
release-dependent?

Try asking the question on the DB2-L listserve email newsgroup, this
group is primarily for Windows and Linux

In 1994, I sent the following email to li******@www.idugdb2-l.org
<li******@www.idugdb2-l.org

with db2-l list application in the title

and

subscribe db2-l Larry Ludwig

in the body of the message (all on its own)
I heve including the following message that I got when subscribing,
which should provide additional help. If the details have changed
since I subscribed then a web search should dig up the necessary info.

++++++++++++++++++++++++++++++++++++++++++++++++++ +++

Your subscription to the DB2-L list (DB2 Database Discussion list
at
IDUG) has been accepted.

Please save this message for future reference, especially if this is
the
first time you are subscribing to an electronic mailing list. If you
ever
need to leave the list, you will find the necessary instructions
below.
Perhaps more importantly, saving a copy of this message (and of
all
future subscription notices from other mailing lists) in a special
mail
folder will give you instant access to the list of mailing lists that
you
are subscribed to. This may prove very useful the next time you go
on
vacation and need to leave the lists temporarily so as not to fill
up
your mailbox while you are away! You should also save the
"welcome
messages" from the list owners that you will occasionally receive
after
subscribing to a new list.

To send a message to all the people currently subscribed to the
list,
just send mail to DB***@WWW.IDUGDB2-L.ORG. This is called "sending
mail
to the list," because you send mail to a single address and
LISTSERV
makes copies for all the people who have subscribed. This
address
(DB***@WWW.IDUGDB2-L.ORG) is also called the "list address." You
must
never try to send any command to that address, as it would be
distributed
to all the people who have subscribed. All commands must be sent to
the
"LISTSERV address," LI******@WWW.IDUGDB2-L.ORG. It is very important
to
understand the difference between the two, but fortunately it is
not
complicated. The LISTSERV address is like a FAX number that connects
you
to a machine, whereas the list address is like a normal voice
line
connecting you to a person. If you make a mistake and dial the FAX
number
when you wanted to talk to someone on the phone, you will quickly
realize
that you used the wrong number and call again. No harm will have
been
done. If on the other hand you accidentally make your FAX call
someone's
voice line, the person receiving the call will be
inconvenienced,
especially if your FAX then re-dials every 5 minutes. The fact that
most
people will eventually connect the FAX machine to the voice line to
allow
the FAX to go through and make the calls stop does not mean that
you
should continue to send FAXes to the voice number. People would just
get
mad at you. It works pretty much the same way with mailing lists,
with
the difference that you are calling hundreds or thousands of people
at
the same time, and consequently you can expect a lot of people to
get
upset if you consistently send commands to the list address.

You may leave the list at any time by sending a "SIGNOFF DB2-L"
command
to LI******@WWW.IDUGDB2-L.ORG. You can also tell LISTSERV how you want
it
to confirm the receipt of messages you send to the list. If you do
not
trust the system, send a "SET DB2-L REPRO" command and LISTSERV will
send
you a copy of your own messages, so that you can see that the message
was
distributed and did not get damaged on the way. After a while you
may
find that this is getting annoying, especially if your mail program
does
not tell you that the message is from you when it informs you that
new
mail has arrived from DB2-L. If you send a "SET DB2-L ACK
NOREPRO"
command, LISTSERV will mail you a short acknowledgement instead,
which
will look different in your mailbox directory. With most mail
programs
you will know immediately that this is an acknowledgement you can
read
later. Finally, you can turn off acknowledgements completely with
"SET
DB2-L NOACK NOREPRO".

Contributions sent to this list are automatically archived. You can get
a
list of the available archive files by sending an "INDEX DB2-L"
command
to LI******@WWW.IDUGDB2-L.ORG. You can then order these files with a
"GET
DB2-L LOGxxxx" command, or using LISTSERV's database search
facilities.
Send an "INFO DATABASE" command for more information on the latter.

This list is available in digest form. If you wish to receive
the
digested version of the postings, just issue a SET DB2-L DIGEST
command.

More information on LISTSERV commands can be found in the
LISTSERV
reference card, which you can retrieve by sending an "INFO
REFCARD"
command to LI******@WWW.IDUGDB2-L.ORG.

[Phil Sherman]

Did you check the output of the bind? The plan name (or package name) is
defined in the bind step SYSIN DD statement. If you can't find the
output, check the JCL stream for the BIND statement.

Phil Sherman

OppThumb wrote:

Hi,

I've been searching this newsgroup for an answer to my question, and
the closest I've come asks my question, but in reverse ("How to figure
out the program from plan/package"). I've -- shall we say, inherited?
-- a COBOL program with very little documentation that I've recompiled
for debugging purposes. The compile/link/bind have all been done, but
nothing in the output tells me what plan the program has been bound to,

so I can't execute until I know. I imagine that somewhere in the SYSIBM

tables I can find the information, but so far I haven't found the right

table.
Any help would be appreciated.
Thanks,
John

P.S. I previously posted this request in 'bit.*listserv.*db2-l'. I
should have cross-posted, so if you get this twice, sorry 'bout that...

[Mark A]

OppThumb wrote:

Hi,

I've been searching this newsgroup for an answer to my question, and
the closest I've come asks my question, but in reverse ("How to figure
out the program from plan/package"). I've -- shall we say, inherited?
-- a COBOL program with very little documentation that I've recompiled
for debugging purposes. The compile/link/bind have all been done, but
nothing in the output tells me what plan the program has been bound to,

so I can't execute until I know. I imagine that somewhere in the SYSIBM

tables I can find the information, but so far I haven't found the right

table.
Any help would be appreciated.
Thanks,
John

P.S. I previously posted this request in 'bit.*listserv.*db2-l'. I
should have cross-posted, so if you get this twice, sorry 'bout that...

If you rebind the plan with EXPLAIN=YES and the look in the table
called PLAN_TABLE there is column called PROGNAME. There may be an
easier way, but I don't know offhand what it is.

[Ven Ilagan]

Sorry Mark as this won't work as he doesn't know his plan-name so what will
he rebind?

Phil was right in that he should look at the held output job he used to
re-compile/link/bind and do an SJ there so he can see the sysin which shows
the planname. If the held output is not there anymore, then query
SYSIBM.SYSPLAN and look for the timestamp having the same time as when he
did his recompile and that should be the associated plan.

HTH,
Ven

"Mark A" <m0****@yahoo.comwrote in message
news:11*********************@16g2000cwy.googlegrou ps.com...

OppThumb wrote:

Hi,

I've been searching this newsgroup for an answer to my question, and
the closest I've come asks my question, but in reverse ("How to figure
out the program from plan/package"). I've -- shall we say, inherited?
-- a COBOL program with very little documentation that I've recompiled
for debugging purposes. The compile/link/bind have all been done, but
nothing in the output tells me what plan the program has been bound to,

so I can't execute until I know. I imagine that somewhere in the SYSIBM

tables I can find the information, but so far I haven't found the right

table.
Any help would be appreciated.
Thanks,
John

P.S. I previously posted this request in 'bit.*listserv.*db2-l'. I
should have cross-posted, so if you get this twice, sorry 'bout that...

If you rebind the plan with EXPLAIN=YES and the look in the table
called PLAN_TABLE there is column called PROGNAME. There may be an
easier way, but I don't know offhand what it is.

[Mark A]

"Ven Ilagan" <vc******@optusnet.com.auwrote in message
news:45**********************@news.optusnet.com.au ...

Sorry Mark as this won't work as he doesn't know his plan-name so what
will he rebind?

Phil was right in that he should look at the held output job he used to
re-compile/link/bind and do an SJ there so he can see the sysin which
shows the planname. If the held output is not there anymore, then query
SYSIBM.SYSPLAN and look for the timestamp having the same time as when he
did his recompile and that should be the associated plan.

HTH,
Ven

I agree that one should be able to see easily see the plan name in the
compile/link/bind job output, but one of the questions he asked was how do
you get the program name if you know the plan name.

One can easily create a script to rebind all plans. I have often done this
to put all the explains in the plan_table for analysis.

[OppThumb]

Thanks for all the input, everyone, but I ended up taking a WAG (Wild
A$$ Guess, if you never heard that before) that worked. I'm not sure
WHY it worked, though, so maybe someone can explain that one.

The plan name was not listed in the job output of the BIND, and there
was no SYSIN DD statement. I found the COLLID, however, so I decided to
go back over to DB2, and in SYSIBM.SYSPACKLIST I found all the rows
with matching COLLIDs. From there, I looked to see if any values in the
NAME column matched my program name.

I got no matches, but there was a row that had a wildcard ('*') value,
so following this trail, I used the PLANNAME value from this row, and
it worked. I suppose my final question, then, is this -- did I just get
lucky, or could this be considered a valid process to get this kind of
information in the future?

Thanks,

John

[Norm]

There are two different methods of binding on DB2 for z/OS.

The older method is used when you statically link many COBOL
sub-programs into one giant load module. In this case, you would bind
all the associated DBRMs (database request modules) into one big plan.
If this is the case, you can look in SYSIBM.SYSDBRM to see the plan
associated with the program. The DBRM name is the same as your COBOL
program name.

The new method is to bind a package with each COBOL program (main or
sub-program). The package is identified by location, collection id,
name, and version. Unlike DB2 for LUW, a plan is always required for
DB2 for z/OS. A plan is bound with to include package lists. This
allows a sub-program to be run under multiple plans. To find which
plan to use at execution time, you would query SYSIBM.SYSPACKLIST to
find the list(s) that qualify your package. You may end up with
multiple plans. The correct plan to run usually depends on security
requirements that are implemented by different plans.

The newer method is almost always used for new applications. It
reduces catalog contention during rebinds and has a closer matching of
load modules to packages reducing "Package not found" or "Consistency
token mis-matches".

Hope this clears things up a bit.

Norm

OppThumb wrote:

Thanks for all the input, everyone, but I ended up taking a WAG (Wild
A$$ Guess, if you never heard that before) that worked. I'm not sure
WHY it worked, though, so maybe someone can explain that one.

The plan name was not listed in the job output of the BIND, and there
was no SYSIN DD statement. I found the COLLID, however, so I decided to
go back over to DB2, and in SYSIBM.SYSPACKLIST I found all the rows
with matching COLLIDs. From there, I looked to see if any values in the
NAME column matched my program name.

I got no matches, but there was a row that had a wildcard ('*') value,
so following this trail, I used the PLANNAME value from this row, and
it worked. I suppose my final question, then, is this -- did I just get
lucky, or could this be considered a valid process to get this kind of
information in the future?

Thanks,

John

[Mark A]

"Norm" <w_******@hotmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...

There are two different methods of binding on DB2 for z/OS.

The older method is used when you statically link many COBOL
sub-programs into one giant load module. In this case, you would bind
all the associated DBRMs (database request modules) into one big plan.
If this is the case, you can look in SYSIBM.SYSDBRM to see the plan
associated with the program. The DBRM name is the same as your COBOL
program name.

The new method is to bind a package with each COBOL program (main or
sub-program). The package is identified by location, collection id,
name, and version. Unlike DB2 for LUW, a plan is always required for
DB2 for z/OS. A plan is bound with to include package lists. This
allows a sub-program to be run under multiple plans. To find which
plan to use at execution time, you would query SYSIBM.SYSPACKLIST to
find the list(s) that qualify your package. You may end up with
multiple plans. The correct plan to run usually depends on security
requirements that are implemented by different plans.

The newer method is almost always used for new applications. It
reduces catalog contention during rebinds and has a closer matching of
load modules to packages reducing "Package not found" or "Consistency
token mis-matches".

Hope this clears things up a bit.

Norm

Using plans (without packages) instead of packages is only problem for CICS
programs. It is not a problem for batch programs, and many people still use
plans for batch programs (one program per plan). Some people do use packages
for batch programs, but there is no serious advantage to it.

The reason for the problem of plans with CICS is that you cannot switch
plans when you XCTL to another CICS program, so that when using plans, all
the DBRMs for every program in an application had to be bound in the same
plan. You can switch plans with a CICS Start Transaction, but that is a very
expensive operation. That is why packages were introduced in DB2 for MVS
3.1.