Results 1 to 7 of 7

Thread: DB2 package

  1. #1
    Join Date
    Oct 2008
    Location
    India
    Posts
    40

    DB2 package

    Can anyone clear my doubt regarding the package.

    As far as i know we can BIND the instructions for the SQL that is in the DBRM into a PLAN or We can BIND the instructions into a PACKAGE.
    Since package is non executable,we are creating a plan to incorporate the package to execute it.

    In case of a stand alone program,we can directly use the plan or package to execute it.Can anyone tell me why we are executing bind through packages? I would also like to know the steps involved.

  2. #2
    Join Date
    Oct 2004
    Location
    DELHI INDIA
    Posts
    338
    may be not able to understand your question correctly. It will be good if you can give some practical scenario where you have faced issue. then may be everyone will be able to help you. Please don't forget to mention the Database Version and OS.

  3. #3
    Join Date
    Jan 2007
    Location
    Jena, Germany
    Posts
    2,721
    Plans exist on DB2 z/OS - not on DB2 LUW.

    I haven't really gotten behind the concept of plans myself. May understanding so far is this:
    You bind a DBRM and create a package (BIND PACKAGE statement). Then you group all the packages into a plan. You can then start a programm through DB2 using the RUN PLAN command.

    Now, you can also bind a DBRM directly to a plan using a BIND PLAN statement. I cannot tell you what the benefits are there. Maybe this is just syntactical sugar, which avoids an additional BIND PACKAGE step. I really don't know, and so far we have been doing what I outlined above.
    Knut Stolze
    IBM DB2 Analytics Accelerator
    IBM Germany Research & Development

  4. #4
    Join Date
    May 2003
    Location
    USA
    Posts
    5,734
    Let me give some history on this. In the original versions of DB2 (V1 and V2) for MVS (now called z/OS) there were only DB2 Plans (no packages). Each program had its own plan (which is the compiled DBRM). However, when using CICS (on-line transaction processing monitor), if you wanted to go from one screen (program) to another screen with CICS XCTL, then both DBRM's for each program had to be in the same plan. XCTL is the preferred and most efficient way of going from one CICS program to another. That meant that every screen (program) in your application had to have its DBRM bound in the same plan, which made for very large plans and was very cumbersome to manage. You had to do a CICS Start Trans to execute a new program with a different plan, which is not very efficient.

    When IBM released DB2 3.1 for MVS (around 1990, if I recall) they came up with packages, where you could have multiple packages within a plan, so each CICS program could use a different package without having to rebind all the DBRM's in an application into a single plan all over again each time you added a CICS program.

    There is not as much benefit to using packages with batch programs, where many people use one DBRM per plan (CICS issues don't apply). Some people now use packages always, even when not using CICS, but that is a matter of personal preference and company standards. There are certain security advantages to packages, since you can grant authority to only create a package in a particular plan.

    Please note that my explanation may be a bit crude for those who are experts in DB2 for z/OS, since I don't use it as much as I once did.
    Last edited by Marcus_A; 11-28-08 at 13:03.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  5. #5
    Join Date
    Oct 2008
    Location
    India
    Posts
    40

    DB2 Package

    Thanks a lot for all your responses..Now i got to know more about plan and packages.

  6. #6
    Join Date
    Dec 2007
    Location
    Richmond, VA
    Posts
    1,085
    Take a llok in the archives of the DB2 Magazine. Several years ago Bonnie Baker ran a three part series that really explains plans/packages and binds quite thoroughly.

  7. #7
    Join Date
    Dec 2009
    Posts
    2

    Version vs Consistency token

    It is said that both the version and Consistency token are mutualy exclusive and created at the precompiler time . Also both the version and consistency token are unique across the package .

    Then why do we need the Version(keword) to maintain different versions of packages . Why not we could use consistency token to maintain different versions of the packages.

    Thanks.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •