Hi All,

I have a two part question regarding the use of versioning of DB2 packages (DB2 V9 for z/os) in a production environment.

Part 1 of my question is:

I was wondering if someone can help me understand why we would need to maintain versions of packages in the production. I can see why one might need different versions in a test environment. But in production, its always the current one that would be needed. Should there be a need for a previous version, all we would need to do is recompile the previous version of the application code. So what are the real benefits/purpose of having mulitple versions of the packages in production.

and Part 2 of the question is;

In case, package versionng is deemed necessary, what kind of package maintenance strategy would be needed in place? How many versions should one want to retain ?

 

Thanks.

Anil

 

Hi Anil

One reason for having more than one package-version in production: You use subroutines, which are not dynamically called but instead linked into your main-program. If you don't use versions, you must link-edit all the main-programs using that particular subroutine. This can be very expensive and if you have a bug in your subroutine, all main-programs will suffer.

Mit freundlichen Grüßen
Walter Janißen

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Technische Anwendungsarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]<mailto:[login to unmask email]>

ITERGO Informationstechnologie GmbH
Vorsitzender des Aufsichtsrats: Christian Diedrich
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Lothar Engelke, Ina Kirchhof, Dr. Christian Nymphius, Dr. Michael Regauer
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf HRB 37996


________________________________
Von: Anil Kale [mailto:[login to unmask email]
Gesendet: Mittwoch, 22. Februar 2012 15:49
An: [login to unmask email]
Betreff: [DB2-L] - Package Versions


Hi All,

I have a two part question regarding the use of versioning of DB2 packages (DB2 V9 for z/os) in a production environment.

Part 1 of my question is:

I was wondering if someone can help me understand why we would need to maintain versions of packages in the production. I can see why one might need different versions in a test environment. But in production, its always the current one that would be needed. Should there be a need for a previous version, all we would need to do is recompile the previous version of the application code. So what are the real benefits/purpose of having mulitple versions of the packages in production.

and Part 2 of the question is;

In case, package versionng is deemed necessary, what kind of package maintenance strategy would be needed in place? How many versions should one want to retain ?



Thanks.

Anil



-----End Original Message-----

I have used versioning in production for fallback. If the developer
needs to back out changes they place the old load module back out there
and it still works with no recompiling or binding. We had a custom
written REXX routine that cleaned up all but the last few versions on a
weekly basis.




________________________________________________________________________
______
David Simpson | Senior Technical Advisor | Themis Education
123 South Avenue E, Westfield NJ, 07090 | phone 908-233-8900 |
[login to unmask email] <mailto:[login to unmask email]>

For more information about Themis, visit www.themisinc.com
http://www.themisinc.com



From: Anil Kale [mailto:[login to unmask email]
Sent: Wednesday, February 22, 2012 8:49 AM
To: [login to unmask email]
Subject: [DB2-L] - Package Versions



Hi All,

I have a two part question regarding the use of versioning of DB2
packages (DB2 V9 for z/os) in a production environment.

Part 1 of my question is:

I was wondering if someone can help me understand why we would need to
maintain versions of packages in the production. I can see why one might
need different versions in a test environment. But in production, its
always the current one that would be needed. Should there be a need for
a previous version, all we would need to do is recompile the previous
version of the application code. So what are the real benefits/purpose
of having mulitple versions of the packages in production.

and Part 2 of the question is;

In case, package versionng is deemed necessary, what kind of package
maintenance strategy would be needed in place? How many versions should
one want to retain ?



Thanks.

Anil





-----End Original Message-----

Hi Anil the main reason that I set this up that way was for application backout without DBA involvement. Using package versions, if the application moves into production, lets say 50 programs were promoted aqnd there is an error where the application needs to backout, then endevor can easily back out the program changes and the load modules are restored and the DBA does not have to be called to do rebinds.

Sent from Lotus Traveler

Anil Kale --- [DB2-L] - Package Versions ---
From:"Anil Kale" <[login to unmask email]>[login to unmask email]:Wed, Feb 22, 2012 09:49Subject[DB2-L] - Package Versions

Hi All,
I have a two part question regarding the use of versioning of DB2 packages (DB2 V9 for z/os) in a production environment.
Part 1 of my question is:
I was wondering if someone can help me understand why we would need to maintain versions of packages in the production. I can see why one might need different versions in a test environment. But in production, its always the current one that would be needed. Should there be a need for a previous version, all we would need to do is recompile the previous version of the application code. So what are the real benefits/purpose of having mulitple versions of the packages in production.
and Part 2 of the question is;
In case, package versionng is deemed necessary, what kind of package maintenance strategy would be needed in place? How many versions should one want to retain ?

Thanks.
Anil

>Site Links: View post online   View mailing list online   Send new post via email   Unsubscribe from this mailing list   Manage your subscription  

Use of this email content is governed by the terms of service at:
http://www.idug.org/p/cm/ld/fid=2>

With package versioning in production, you may do a rebind after statistics, upgrade, etc. After the rebind, the access path is degraded. With versioning, you can switch it back to the previous version without having to do opthints or anything. The number of versions is shop dependent. If you do a lot of rebinds, I would think that you would want the max to be on the safe side.


Wayne Stevens
334-353-7482
888-535-1552 Cell
888-535-1554 FAX
[login to unmask email]<mailto:[login to unmask email]>

From: Howard S Hirsch [mailto:[login to unmask email]
Sent: Wednesday, February 22, 2012 9:43 AM
To: [login to unmask email]
Subject: [DB2-L] - RE:Package Versions

Hi Anil the main reason that I set this up that way was for application backout without DBA involvement. Using package versions, if the application moves into production, lets say 50 programs were promoted aqnd there is an error where the application needs to backout, then endevor can easily back out the program changes and the load modules are restored and the DBA does not have to be called to do rebinds.

Sent from Lotus Traveler
Anil Kale --- [DB2-L] - Package Versions ---

From:

"Anil Kale" <[login to unmask email]<mailto:[login to unmask email]>>

To

[login to unmask email]<mailto:[login to unmask email]>

Date:

Wed, Feb 22, 2012 09:49

Subject

[DB2-L] - Package Versions

________________________________


Hi All,

I have a two part question regarding the use of versioning of DB2 packages (DB2 V9 for z/os) in a production environment.

Part 1 of my question is:

I was wondering if someone can help me understand why we would need to maintain versions of packages in the production. I can see why one might need different versions in a test environment. But in production, its always the current one that would be needed. Should there be a need for a previous version, all we would need to do is recompile the previous version of the application code. So what are the real benefits/purpose of having mulitple versions of the packages in production.

and Part 2 of the question is;

In case, package versionng is deemed necessary, what kind of package maintenance strategy would be needed in place? How many versions should one want to retain ?



Thanks.

Anil



-----End Original Message-----

-----End Original Message-----

You can't switch to an old version. The version and the associated contoken has to match the contoken of the load module. I think, you mean different copies of one version. Then you can do a REBIND SWITCH. And the number of copies is limited to at most 3: original, orevious and current

Mit freundlichen Grüßen
Walter Janißen

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Technische Anwendungsarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]<mailto:[login to unmask email]>

ITERGO Informationstechnologie GmbH
Vorsitzender des Aufsichtsrats: Christian Diedrich
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Lothar Engelke, Ina Kirchhof, Dr. Christian Nymphius, Dr. Michael Regauer
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf HRB 37996



________________________________
Von: Stevens, Wayne [mailto:[login to unmask email]
Gesendet: Mittwoch, 22. Februar 2012 17:00
An: '[login to unmask email]'
Betreff: [DB2-L] - RE: Package Versions

With package versioning in production, you may do a rebind after statistics, upgrade, etc. After the rebind, the access path is degraded. With versioning, you can switch it back to the previous version without having to do opthints or anything. The number of versions is shop dependent. If you do a lot of rebinds, I would think that you would want the max to be on the safe side.


Wayne Stevens
334-353-7482
888-535-1552 Cell
888-535-1554 FAX
[login to unmask email]<mailto:[login to unmask email]>

From: Howard S Hirsch [mailto:[login to unmask email]
Sent: Wednesday, February 22, 2012 9:43 AM
To: [login to unmask email]
Subject: [DB2-L] - RE:Package Versions

Hi Anil the main reason that I set this up that way was for application backout without DBA involvement. Using package versions, if the application moves into production, lets say 50 programs were promoted aqnd there is an error where the application needs to backout, then endevor can easily back out the program changes and the load modules are restored and the DBA does not have to be called to do rebinds.

Sent from Lotus Traveler
Anil Kale --- [DB2-L] - Package Versions ---

From:

"Anil Kale" <[login to unmask email]<mailto:[login to unmask email]>>

To

[login to unmask email]<mailto:[login to unmask email]>

Date:

Wed, Feb 22, 2012 09:49

Subject

[DB2-L] - Package Versions

________________________________


Hi All,

I have a two part question regarding the use of versioning of DB2 packages (DB2 V9 for z/os) in a production environment.

Part 1 of my question is:

I was wondering if someone can help me understand why we would need to maintain versions of packages in the production. I can see why one might need different versions in a test environment. But in production, its always the current one that would be needed. Should there be a need for a previous version, all we would need to do is recompile the previous version of the application code. So what are the real benefits/purpose of having mulitple versions of the packages in production.

and Part 2 of the question is;

In case, package versionng is deemed necessary, what kind of package maintenance strategy would be needed in place? How many versions should one want to retain ?



Thanks.

Anil



-----End Original Message-----

-----End Original Message-----

-----End Original Message-----

We keep two versions of every package in all environments - the current
'active' version and the most recent previous version.

In addition to what others have said, we do this primarily for our
CICS-related packages so that the application team can better coordinate
the required NEWCOPYs; however, we've applied this to all packages for
consistency in source management. Since our source change management
system works one element at a time, if you had many, related packages in
one turnover, and if the NEWCOPYs were done element by element as part of
the turnover, you would have periods of potentially incompatible programs
running. By having two versions, the existing programs can run without
issue until your turnovers are completed successfully and you decide to
switch to the new version with all the necessary NEWCOPYs being done at
once. The copying of existing versions to previous versions is all done
via customized REXX routines in our source change management system.

We've found the above scheme also works well for distributed SQLJ
packages. The SQLJ components can be built with the necessary BINDs until
the front-end code is actually deployed to use the new version.

Hope this helps.


Dave.





From: Anil Kale <[login to unmask email]>
To: [login to unmask email]
Date: 02/22/2012 09:49 AM
Subject: [DB2-L] - Package Versions



Hi All,
I have a two part question regarding the use of versioning of DB2 packages
(DB2 V9 for z/os) in a production environment.
Part 1 of my question is:
I was wondering if someone can help me understand why we would need to
maintain versions of packages in the production. I can see why one might
need different versions in a test environment. But in production, its
always the current one that would be needed. Should there be a need for a
previous version, all we would need to do is recompile the previous
version of the application code. So what are the real benefits/purpose of
having mulitple versions of the packages in production.
and Part 2 of the question is;
In case, package versionng is deemed necessary, what kind of package
maintenance strategy would be needed in place? How many versions should
one want to retain ?

Thanks.
Anil



Site Links: View post online View mailing list online Send new post
via email Unsubscribe from this mailing list Manage your subscription

Use of this email content is governed by the terms of service at:
http://www.idug.org/p/cm/ld/fid=2



******************************************************
IMPORTANT: Any information contained in this communication is intended for the use of the named individual or entity. All information contained in this communication is not intended or construed as an offer, solicitation, or a recommendation to purchase any security. Advice, suggestions or views presented in this communication are not necessarily those of Pershing LLC nor do they warrant a complete or accurate statement.

If you are not an intended party to this communication, please notify the sender and delete/destroy any and all copies of this communication. Unintended recipients shall not review, reproduce, disseminate nor disclose any information contained in this communication. Pershing LLC reserves the right to monitor and retain all incoming and outgoing communications as permitted by applicable law.

Email communications may contain viruses or other defects. Pershing LLC does not accept liability nor does it warrant that email communications are virus or defect free.
******************************************************

Actually you can switch to a different version.  I can have (and do ) have different PACKAGE Version names with the associated contokens.  And I don't have to do a rebind switch or anything.  I can just rollback the "load" module (and NEWCOPY if necessary).  We've done this for years.

There seems to be some confusion here on this thread between Package versioning and Access Path versioning.    Access path versioning allows for different access paths to be kept on the same Package VERSION.  So theoretically I could have say three package versions and each one could have three different access paths associated with it.

I do a REBIND Switch to switch to a different Access path version.  To switch to a different Package version, I just execute the package from a different load library which has the different "older" or newer package load module in it.  Different things entirely.

Myron


________________________________
From: "Walter Jani&#223;en" <[login to unmask email]>
To: [login to unmask email]
Sent: Wednesday, February 22, 2012 11:19 AM
Subject: [DB2-L] - AW: RE: Package Versions



You can't switch to an old version. The version and the
associated contoken has to match the contoken of the load module. I think, you
mean different copies of one version. Then you can do a REBIND SWITCH. And the
number of copies is limited to at most 3: original, orevious and
current 
Mit freundlichen Grüßen
Walter
Janißen
 
ITERGO Informationstechnologie
GmbH
Anwendungsentwicklung
Technische
Anwendungsarchitektur
Victoriaplatz 2
D-40198
Düsseldorf
[login to unmask email]

ITERGO Informationstechnologie GmbH
Vorsitzender des Aufsichtsrats:
Christian Diedrich
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Lothar Engelke, Ina
Kirchhof, Dr. Christian Nymphius, Dr. Michael Regauer
Sitz: Düsseldorf, Handelsregister:
Amtsgericht Düsseldorf HRB 37996
 


________________________________
Von: Stevens, Wayne
[mailto:[login to unmask email]
Gesendet: Mittwoch, 22.
Februar 2012 17:00
An: '[login to unmask email]'
Betreff: [DB2-L] - RE: Package Versions


With
package versioning in production, you may do a rebind after statistics, upgrade,
etc.  After the rebind, the access path is degraded.  With versioning,
you can switch it back to the previous version without having to do opthints or
anything. The number of versions is shop dependent.  If you do a lot of
rebinds, I would think that you would want the max to be on the safe
side.
 
 
Wayne
Stevens
334-353-7482
888-535-1552
Cell
888-535-1554
FAX
[login to unmask email]
 
From:Howard S Hirsch
[mailto:[login to unmask email]
Sent: Wednesday, February 22, 2012 9:43
AM
To: [login to unmask email]
Subject: [DB2-L] - RE:Package
Versions
 
Hi Anil the main reason that I set
this up that way was for application backout without DBA involvement. Using
package versions, if the application moves into production, lets say 50 programs
were promoted aqnd there is an error where the application needs to backout,
then endevor can easily back out the program changes and the load modules are
restored and the DBA does not have to be called to do rebinds.

Sent from
Lotus Traveler
Anil Kale --- [DB2-L] - Package Versions ---
 
From: "Anil Kale" <[login to unmask email]>
To [login to unmask email]
Date: Wed, Feb 22, 2012 09:49
Subject [DB2-L] - Package Versions

________________________________

 
Hi All,
I have a two part question regarding the use of versioning of DB2 packages
(DB2 V9 for z/os) in a production environment.
Part 1 of my question is:
I was wondering if someone can help me understand why we would need to
maintain versions of packages in the production. I can see why one might need
different versions in a test environment. But in production, its always the
current one that would be needed. Should there be a need for a previous version,
all we would need to do is recompile the previous version of the application
code. So what are the real benefits/purpose of having mulitple versions of the
packages in production.
and Part 2 of the question is;
In case, package versionng is deemed necessary, what kind of package
maintenance strategy would be needed in place? How many versions should one want
to retain ?
 
Thanks.
Anil
 
 
-----End Original Message-----
 
-----End Original Message-----

-----End Original Message-----
-----End Original Message-----