Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
Why do we go for a package, as it is better to have one plan

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> Mainframe Interview Questions
View previous topic :: :: View next topic  
Author Message
sangeetha guduru

New User


Joined: 21 Feb 2008
Posts: 2
Location: Bangalore

PostPosted: Fri Feb 22, 2008 3:24 pm    Post subject: Why do we go for a package, as it is better to have one plan
Reply with quote

I have created a cobol-db2 program, when I compiled it , a plan was automatically created. I use the same plan to execute the program. My doubt is , why do we go for a package, as it is better to have one plan for each program. Can anybody pls clarify my doubt??
Back to top
View user's profile Send private message

nbalajibe
Warnings : 1

New User


Joined: 28 Nov 2006
Posts: 75
Location: India

PostPosted: Fri Feb 22, 2008 4:54 pm    Post subject:
Reply with quote

Hi,

Your query is well explained in the below link,

http://ibmmainframes.com/viewtopic.php?t=23965
Back to top
View user's profile Send private message
Gnanas N

Active Member


Joined: 06 Sep 2007
Posts: 788
Location: Chennai, India

PostPosted: Fri Feb 22, 2008 4:58 pm    Post subject:
Reply with quote

I got this from IBM library.

Question

Should I use packages or bind directly to the plan?

Answer

Use packages. Plans containing a DBRM are currently deprecated. Using packages has the following advantages:

1. When you change one SQL statement, you do not need to bind the entire plan again. You need to bind only the package that is associated with the changed SQL statement.

2. Binding packages into package collections enables you to add packages to an existing application plan without having to bind the entire plan again.

3. Maintaining several versions of a plan without using packages requires a separate plan for each version, and therefore separate plan names and run commands. Isolating separate versions of a program into packages requires only one plan and simplifies program migration and fallback for separate development, test, and production levels of a program.

For plans that are bound with only one DBRM, packages still offer the advantage of versioning. However, for plans that use multiple DBRMs, you should probably bind each DBRM into a package, and then bind the packages into the plan.

Plans containing DBRMs and the BIND ACQUIRE(ALLOCATE) option are still included in DB2 9, but may be removed from future versions. Use packages and ACQUIRE(USE) to replace the existing function. We expect to deliver some help in migration, but packages are the strong recommendation.
Back to top
View user's profile Send private message
sangeetha guduru

New User


Joined: 21 Feb 2008
Posts: 2
Location: Bangalore

PostPosted: Wed Feb 27, 2008 2:06 pm    Post subject: Reply to: Why do we go for a package, as it is better to hav
Reply with quote

Hi,
You all have very explained the cause
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> Mainframe Interview Questions All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Why myself doing Package Bind always ... Susanta DB2 5 Thu Mar 02, 2017 10:47 pm
No new posts Bind plan as a member to another bind... rexx77 DB2 0 Thu Feb 16, 2017 2:02 am
No new posts JCL to delete component in a package sundaram.naveen Compuware & Other Tools 14 Tue Nov 29, 2016 6:21 pm
No new posts Program and its corresponding plan vickey_dw DB2 4 Thu Apr 07, 2016 9:27 pm
No new posts Should we Rebind Plan if no SQL changes sappy_mf DB2 2 Thu Mar 03, 2016 2:13 pm

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us