PACKAGE VS PLAN ?
Moderators: Kalicharan, Moderator Group
-
- Member
- Posts: 14
- Joined: Fri Apr 06, 2007 11:22 pm
PACKAGE VS PLAN ?
I know that while executing a DB2 program plan is used. But Packages are preferred over plan when you are binding a program for various advantages over Plan. What I did not understand is if packages are preferred but we still need to bind the package into a plan in order to make the package executable. Then where is the question of packages being better than plans? Can somebody explan this please.
Regards,
Chandra
Regards,
Chandra
Chandra,
Wish this helps.
packages being better than plans ???
Assume that we have 500 pgms which are bind at the package level,and eventually these pakcage list will be part of the superset called PLAN.
When we change say 5 pgms out of these 500 pgms we can rebind only those 5 pgms to the respective packages and then the PLAN will pick the latest LOAD modules for execution.SO when when the PLAN picks the latest LOAD componenets here we are only re-evaluating the access-paths of only those 5 newly changed components.
Assume the same scenario with the 500 pgms bind at the PLAN level, even though there is a change in 5 pgms all the 500 pgms ACCESS PATHS need to be re-evaluated.
During the BIND process the transaction or transactions become unavailable and results in OUTAGE, the OUTAGE when the components are BIND at the PACKAGE LEVEL is negligable where as considerable latency time will be taken for the DB2 transactions/subsystem when the components are BIND at the PLAN level.
NOTE : SOME SYSTEM ADMIN WILL ABLE TO GIVE THE RIGHT PERSPECTIVE IN TERMS OF THE OUTAGE,LATENCY TIME or THE AVAILABILITY OF THE DB2 transactions.
we still need to bind the package into a plan in order to make the package executable.
Yes this is ineviatable as the ACCESS-PATHS can be derived only thru PLAN..to excute the QUERY on DB2 subsystems.
Thanks,
Veera
Wish this helps.
packages being better than plans ???
Assume that we have 500 pgms which are bind at the package level,and eventually these pakcage list will be part of the superset called PLAN.
When we change say 5 pgms out of these 500 pgms we can rebind only those 5 pgms to the respective packages and then the PLAN will pick the latest LOAD modules for execution.SO when when the PLAN picks the latest LOAD componenets here we are only re-evaluating the access-paths of only those 5 newly changed components.
Assume the same scenario with the 500 pgms bind at the PLAN level, even though there is a change in 5 pgms all the 500 pgms ACCESS PATHS need to be re-evaluated.
During the BIND process the transaction or transactions become unavailable and results in OUTAGE, the OUTAGE when the components are BIND at the PACKAGE LEVEL is negligable where as considerable latency time will be taken for the DB2 transactions/subsystem when the components are BIND at the PLAN level.
NOTE : SOME SYSTEM ADMIN WILL ABLE TO GIVE THE RIGHT PERSPECTIVE IN TERMS OF THE OUTAGE,LATENCY TIME or THE AVAILABILITY OF THE DB2 transactions.
we still need to bind the package into a plan in order to make the package executable.
Yes this is ineviatable as the ACCESS-PATHS can be derived only thru PLAN..to excute the QUERY on DB2 subsystems.
Thanks,
Veera
-
- Member
- Posts: 14
- Joined: Fri Apr 06, 2007 11:22 pm
When you say bind package into a plan to make packages executable, only those executable gets stored in a plan.
Can I have some programs directly bound into a plan and some programs bound into the same plan via package?
Another questions - if you have mulitple programs bound directly into a plan, why can't bind happen only on those programs which are changed and not everthing in the plan?
Can I have some programs directly bound into a plan and some programs bound into the same plan via package?
Another questions - if you have mulitple programs bound directly into a plan, why can't bind happen only on those programs which are changed and not everthing in the plan?
-
- Member
- Posts: 14
- Joined: Fri Apr 06, 2007 11:22 pm
When you say bind package into a plan to make packages executable, only those executable gets stored in a plan.
Can I have some programs directly bound into a plan and some programs bound into the same plan via package?
Another questions - if you have mulitple programs bound directly into a plan, why can't bind happen only on those programs which are changed and not everthing in the plan?
Can I have some programs directly bound into a plan and some programs bound into the same plan via package?
Another questions - if you have mulitple programs bound directly into a plan, why can't bind happen only on those programs which are changed and not everthing in the plan?
-
- Member
- Posts: 14
- Joined: Fri Apr 06, 2007 11:22 pm
When you say bind package into a plan to make packages executable, only those executable gets stored in a plan.
Can I have some programs directly bound into a plan and some programs bound into the same plan via package?
Another questions - if you have mulitple programs bound directly into a plan, why can't bind happen only on those programs which are changed and not everthing in the plan?
Can I have some programs directly bound into a plan and some programs bound into the same plan via package?
Another questions - if you have mulitple programs bound directly into a plan, why can't bind happen only on those programs which are changed and not everthing in the plan?
-
- Member
- Posts: 14
- Joined: Fri Apr 06, 2007 11:22 pm
When you say bind package into a plan to make packages executable, only those executable gets stored in a plan.
Can I have some programs directly bound into a plan and some programs bound into the same plan via package?
Another questions - if you have mulitple programs bound directly into a plan, why can't bind happen only on those programs which are changed and not everthing in the plan?
Can I have some programs directly bound into a plan and some programs bound into the same plan via package?
Another questions - if you have mulitple programs bound directly into a plan, why can't bind happen only on those programs which are changed and not everthing in the plan?
Chandra,
When you say bind package into a plan to make packages executable, only those executable gets stored in a plan.
Can I have some programs directly bound into a plan and someprograms bound into the same plan via package?
Another questions - if you have mulitple programs bound directly into a plan, why can't bind happen only on those programs which are changed and not everthing in the plan?
Thanks,
Veera.
When you say bind package into a plan to make packages executable, only those executable gets stored in a plan.
Code: Select all
only those executable gets refreshed and stored in a plan apart from the other executables without any change. I mean it has all the executables old and latest for which updations are done.
Code: Select all
YES, you can use a combination of both methods.
Code: Select all
WHEN WE SAY BIND @ PLAN IT MEANS FOR ALL. ( ITS THE DESIGN)
Since PLAN is a superset it tries to refersh/BIND the entire listing including the packages,As per the hierarchy i do not think the PLAN will have reference or handle at each program level bound thru package, but it has @ the package level.
So even though if the programs are BOUND directly as you have mentioned it tries to BIND all since it can/may have other pakcages in which few programs are changed. WHEN WE SAY BIND @ PLAN IT MEANS FOR ALL. ( ITS THE DESIGN)
What i mean to say is the HIERARCHY and the architetural design is built to design ur application @ modular level.
So that is the reason why we build PAKCAGES for some set of PROGRAMS for a region/application.
And the BIND/REBIND depends on the significance of the values we use for RELEASE/ACQUIRE Keywords/options.
If you were dealing with a plan that had DBRMs bound into it directly as you mentioned then you could choose ACQUIRE(ALLOCATE), which tells DB2 to acquire all the resources for all the SQL statements in all the DBRMs bound into that plan when the plan?s thread is allocated. This is in a way advantage as you have everything at once and also
a kind of disadvantage as from the list PLAN may not execute few at all.
NOTE :EVEN IF WE USE ACQUIRE(USE) IT GETS EVERYTHING AT THE TIME OF EXECUTION BUT IT MEANS FOR ALL THE PROGRAMS,
PAKCAGES. NORMALLY THIS IS THE BEHAVIOR OF THE PACKAGE ACQUIRE(USE) WE CANT OVERRIDE IT.
When binding a plan, ACQUIRE(ALLOCATE) must always be paired with RELEASE(DEALLOCATE).Since from the entire listing of PGMS or PACKAGES few may never be executed in a particular plan execution. So RELEASE(DEALLOCATE) will improve the performance,but RELEASE(COMMIT) is normally used any DB2-CICS threads are long conversational and there?s probably only a single piece of work being executed anyway.
Veera.
-
- Member
- Posts: 1
- Joined: Sun Jun 05, 2011 2:49 pm
FREE TUTORIALS
Tutorials
Free tutorials from mainframegurukul
- JCL Tutorial
Covers all important JCL concepts. - Cobol Tutorial
This tutorials covers all Cobol Topics from STRING to COMP-3. - DB2 Tutorial
DB2 Tutorial focuses on DB2 COBOL Programming. - SORT Tutorial
This Tutorial covers all important aspects of DFSORT with examples - CICS Tutorial
This CICS tutorial covers CICS concepts and CICS Basics, CICS COBOL Programming.
Interview
Mainframe Interview questions
- Cobol Interview Questions
50+ Interview Questions - JCL Interview Questions
50+ Interview Questions - DB2 Interview Questions
100+ Interview Questions - CICS Interview Questions
70+ Interview Questions - VSAM Interview Questions
27 Interview Questions
Other References
Mainframe Tools and others
- XPEDITER Reference
Explains how we can debug a program - FILEAID Reference
Explains how to browse , edit and delete datasets - Change Man Reference
Quick Start tutorial on Changeman - Abend Reference
Important Abend codes explained - FaceBook Page
MainframeGurukul FaceBook Page - LinkedIn Page
MainframeGurkul Linkedin Page