DB2 Catalog/Directory question

Joseph Morelli

DB2 Catalog/Directory question
Hi all,
DB2 OS/390 V7

We are in the process of implementing package versioning in db2 and I have
some concerns. Currently, our SYSPKAGE catalog tablespace is 715 CYLs
(3390-3). We are anticipating that we will have up to 5 versions of a
package in this environment = 3575CYLs > 2G (non-SMS), assuming a linear
increase. As for the SPT01 directory space, it is currently 1179 CYLs and
may grow to 5895 > 2G CYLs with a assuming a linear increase.

Questions:
1.) Is it reasonable to assume that, if we have 5 times the number of
packages, these two objects may require up to 5 times the DASD (also assumed
is the allocated space is used space i.e. we need 715 cyls for 1 version of
each package)?

2.) If number 1 is true (even if its not, assume it is), then how do I
overcome the 2G size limit for non-SMS managed space, given that the catalog
spaces are user managed? Do I allocate 2 datasets up front when I resize?
If I do, how does DB2 know that it has these 2 datasets and not just the
1st?

I searched the archives and couldn't come up with any info on how to handle
user managed catalog objects > 2G.

Thanks in advance for your help!!

Joe Morelli
DBA
Erie Insurance Group




Disclaimer: This message (and any attachments) is confidential and is
intended only for the addressee(s). This message may contain information
that is protected by one or more legally recognized privileges. If the
reader of this message is not the intended recipient, I did not intend to
waive, and I do not waive, any legal privilege or the confidentiality of the
message. If you receive this message in error, please notify me immediately
by return e-mail and delete this message from your computer and network
without saving it in any manner. The unauthorized use, dissemination,
distribution, or reproduction of this message, including attachments, is
prohibited and may be unlawful.



Michael Ebert

Re: DB2 Catalog/Directory question
(in response to Joseph Morelli)
1.) If you keep 5 versions of a package where you currently have only one,
I'd also assume that you'll need 5 times the space.
2.) Simply create another dataset with a .A002 (.A003,...) suffix for the
necessary additional space when the existing one(s) are about to become
full. In one of our subsystems, SPT01 currently consists of 2 datasets. If
DB2 needs the second dataset, it will simply use it when it exists or
complain when it doesn't.

Dr. Michael Ebert
DB2 Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany



Hi all,
DB2 OS/390 V7
We are in the process of implementing package versioning in db2 and I have
some concerns. Currently, our SYSPKAGE catalog tablespace is 715 CYLs
(3390-3). We are anticipating that we will have up to 5 versions of a
package in this environment = 3575CYLs > 2G (non-SMS), assuming a linear
increase. As for the SPT01 directory space, it is currently 1179 CYLs and
may grow to 5895 > 2G CYLs with a assuming a linear increase.
Questions:
1.) Is it reasonable to assume that, if we have 5 times the number of
packages, these two objects may require up to 5 times the DASD (also
assumed is the allocated space is used space i.e. we need 715 cyls for 1
version of each package)?
2.) If number 1 is true (even if its not, assume it is), then how do I
overcome the 2G size limit for non-SMS managed space, given that the
catalog spaces are user managed? Do I allocate 2 datasets up front when I
resize? If I do, how does DB2 know that it has these 2 datasets and not
just the 1st?
I searched the archives and couldn't come up with any info on how to
handle user managed catalog objects > 2G.
Thanks in advance for your help!!
Joe Morelli
DBA
Erie Insurance Group




Dale Smock

Re: DB2 Catalog/Directory question
(in response to Michael Ebert)
I have not done this for a catalog table, but if it works the same as for
non-catalog tables with user defined datasets, you can define additional
datasets with IDCAMS Define using A002, A003, A004, etc. for the last node
and DB2 will use it when it needs it.

That you will need up to 5 times the current space for 5 versions sounds
like a reasonable assumption. Since version is in the syspackage and
syspackstmt tables, most of the space used in this tablespace will be
duplicated by each version of the package.

Dale Smock
Bertelsmann

-----Original Message-----
From: Morelli, Joseph [mailto:[login to unmask email]
Sent: Wednesday, September 24, 2003 2:52 PM
To: [login to unmask email]
Subject: DB2 Catalog/Directory question



Hi all,
DB2 OS/390 V7

We are in the process of implementing package versioning in db2 and I have
some concerns. Currently, our SYSPKAGE catalog tablespace is 715 CYLs
(3390-3). We are anticipating that we will have up to 5 versions of a
package in this environment = 3575CYLs > 2G (non-SMS), assuming a linear
increase. As for the SPT01 directory space, it is currently 1179 CYLs and
may grow to 5895 > 2G CYLs with a assuming a linear increase.

Questions:
1.) Is it reasonable to assume that, if we have 5 times the number of
packages, these two objects may require up to 5 times the DASD (also assumed
is the allocated space is used space i.e. we need 715 cyls for 1 version of
each package)?

2.) If number 1 is true (even if its not, assume it is), then how do I
overcome the 2G size limit for non-SMS managed space, given that the catalog
spaces are user managed? Do I allocate 2 datasets up front when I resize?
If I do, how does DB2 know that it has these 2 datasets and not just the
1st?

I searched the archives and couldn't come up with any info on how to handle
user managed catalog objects > 2G.

Thanks in advance for your help!!

Joe Morelli
DBA
Erie Insurance Group




Disclaimer: This message (and any attachments) is confidential and is
intended only for the addressee(s). This message may contain information
that is protected by one or more legally recognized privileges. If the
reader of this message is not the intended recipient, I did not intend to
waive, and I do not waive, any legal privilege or the confidentiality of the
message. If you receive this message in error, please notify me immediately
by return e-mail and delete this message from your computer and network
without saving it in any manner. The unauthorized use, dissemination,
distribution, or reproduction of this message, including attachments, is
prohibited and may be unlawful.

To change your subscription

http://listserv.ylassoc.com. The owners of the list can be reached at
[login to unmask email]




michael bell

Re: DB2 Catalog/Directory question
(in response to Dale Smock)
DB2 Catalog/Directory questionEasy answers first
1. User managed dataset just requires the dataset be allocated when DB2
gets to the point it needs it. Just like SMS managed you have to be certain
that the primary+255 Secondary will get you to 2GB. When DB2 has filled the
A001 dataset, it will attempt to allocate the A002 dataset and proceed on.
Then the A003, etc.
2.You are responsible for the number of volumes specified in the DEFINE
CLUSTER so the dataset can go multiple volumes if required to get the 2GB.
You have to be carefull because sometimes the install excluded the DB2
catalog from normal SMS processing. The normal vol(* * * * *) may not work
if the catalog was guaranteed space SMS rule
3. A package will only use space in SPT01 if it is valid. If you make
table/sql changes that invalidate a package version, the only information is
in SYSPACKAGE and SYSPACKSTMT.
4. There are products available that will bypass the creation of a new
version of a DBRM if the SQL has not been changed. This can greatly reduce
the number of package versions you create. Yes, we have one of them.

Mike Bell
HLS Technologies


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003



Alexandros Papadopoulos

Re: DB2 Catalog/Directory question
(in response to michael bell)
Hello Joseph,



Just a couple of simple questions over your questions:



1) Maybe I misunderstood your 1st question, but why do you have to assume
that accocated space is the used space? What is the HI-U-RBA reported by
LISTC in your SYSPKAGE and SPT01 ts Datasets? Is it close to the 715 and
1179 cyls respectively? (In our installation, we prefer to waste some disk
space by overallocating TSs in Catalog and Directory just to avoid
reorgs). Apart from that, what is the number of rows in your SYSPACKAGE,
and when it was reorged for the last time?



2) Do you plan to have 5 versions in ALL the packages included in your
SYSPKAGE? Some (occasionally many) of them might be just 'imported'
packages from tools, monitors, utilities or whatever.


As everybody else said, it is not a problem to have a preallocated A002.
It will be used when needed.



hth

Alekos



David Palmer

Re: DB2 Catalog/Directory question
(in response to Alexandros Papadopoulos)
Joe,
You said, "We are anticipating that we will have up to 5 versions of a
package in this environment" and then asked about space for the packages.

I'm wondering about the basic assumptions and the implications (Have gone
through this before)....

1. Why do you need 5 generation of packages? I have yet to see a case that
going back 5 generation was even an desired. When I asked my developer how
often they update production it was about ever 3 months. So 3 month times 5
generations are 15 months. Do you think that they will want to fall back to
code that old?

2. Is someone going to keep 5 generation of Load modules? Without the Load
modules the Package are pretty worthless. Most shops aren't prepared to do
this. 5 Load libraries and keeping in sync with the catalog will most likely
require some type of automation. Who is going to write and support that?

3. Is there a procedure in place to handle fall back? If the programmers
aren't going to use the packages there is no point. Here is what may happen...
You run into a production problem in a single module that went in last
month. The decision is to fall back. No problem you have the load modules
and package, just move the old module in to production. But wait, wasn't
that module dependent on 4 others and 2 of those needed table and data
changes? Ok we can handle that, we can undo the table and data changes and
fall back the other 4 modules. Uh oh, there are 27 other programs dependent
the table and data changes. Never mind just fix the code and go forward.

IMHO: Don't worry about the space. Clean up your SYSPKAGE (from my
experience there is probably a fair amount of garbage there). Create a job
that deletes old packages and run it once a week until someone can figure a
good way to handle the


Good Luck
David



Joseph Morelli

Re: DB2 Catalog/Directory question
(in response to David Palmer)
David,
This is a development environment where we have 7 instances of an
application for parallel/wave development. We already have over 22000
packages in this environment. (3150 * 7). And it looks like I was finally
able to convince the CA Endevor (our change management software) guys that
the collections we have in this subsystem will handle most of their
versioning requirements in this case. I will still have to make the
catalog/directory spaces bigger, just not that much bigger.

The way it was first explained to me was we would have (7 * 3150) * 5
versions = 110000 packages. I wanted to ask the question just in case we
would actually be required to accommodate this much in this region without
needing to resize the tablespace in the near future. Outages in our dev
region are not tolerated since we are paying hundreds of consults to work in
those regions. I wanted to be sure I could size these spaces, so that if it
needed to go beyond 4 G it could.

In production, there will only be 3 versions required by the new Endevor
process: one for current version, one backup version and one emergency
version.

Thanks to everyone who responded.

Joe
-----Original Message-----
From: David Palmer [mailto:[login to unmask email]
Sent: Thursday, September 25, 2003 10:22 AM
To: [login to unmask email]; Joe Morelli
Subject: Re: DB2 Catalog/Directory question


Joe,
You said, "We are anticipating that we will have up to 5 versions of a
package in this environment" and then asked about space for the packages.

I'm wondering about the basic assumptions and the implications (Have gone
through this before)....

1. Why do you need 5 generation of packages? I have yet to see a case that
going back 5 generation was even an desired. When I asked my developer how
often they update production it was about ever 3 months. So 3 month times 5
generations are 15 months. Do you think that they will want to fall back to
code that old?

2. Is someone going to keep 5 generation of Load modules? Without the Load
modules the Package are pretty worthless. Most shops aren't prepared to do
this. 5 Load libraries and keeping in sync with the catalog will most likely
require some type of automation. Who is going to write and support that?

3. Is there a procedure in place to handle fall back? If the programmers
aren't going to use the packages there is no point. Here is what may
happen...
You run into a production problem in a single module that went in last
month. The decision is to fall back. No problem you have the load modules
and package, just move the old module in to production. But wait, wasn't
that module dependent on 4 others and 2 of those needed table and data
changes? Ok we can handle that, we can undo the table and data changes and
fall back the other 4 modules. Uh oh, there are 27 other programs dependent
the table and data changes. Never mind just fix the code and go forward.

IMHO: Don't worry about the space. Clean up your SYSPKAGE (from my
experience there is probably a fair amount of garbage there). Create a job
that deletes old packages and run it once a week until someone can figure a
good way to handle the


Good Luck
David



Disclaimer: This message (and any attachments) is confidential and is
intended only for the addressee(s). This message may contain information
that is protected by one or more legally recognized privileges. If the
reader of this message is not the intended recipient, I did not intend to
waive, and I do not waive, any legal privilege or the confidentiality of the
message. If you receive this message in error, please notify me immediately
by return e-mail and delete this message from your computer and network
without saving it in any manner. The unauthorized use, dissemination,
distribution, or reproduction of this message, including attachments, is
prohibited and may be unlawful.



David S Waugh

Re: DB2 Catalog/Directory question
(in response to Joseph Morelli)
Joe:

I agree with David. Though you might think it's necessary to be able to keep 5 versions around "just in case", it's probably going to be impractical to fall back to anything other than the last one or two.

I especially agree about cleaning up any garbage in SYSPKAGE tables first -- I usually find customers have a lot of junk & crap & stuff in their Catalog tables in general, SYSPLAN and SYSPKAGE in particular. Cleaning up the garbage (followed by REORG and RUNSTATS) can save quite a bit of space, improve access times, reduce confusion, etc. Well worth the time spent, IMO.

Last but not least (though you've probably already thought of this): Don't forget that if you increase the sizes of SYSPKAGE n-fold, you'll also need to increase the sizes of the indexes of the tables therein as well (doubtful that any of them will reach >2GB, but they'll still grow quite large, go into mega-extents, fill up DASD vols, etc.):

TABLESPACE DATABASE TABLENAME TBCREATR INDEXNAME
---------- -------- --------- -------- ---------SYSPKAGE DSNDB06
SYSPACKAGE SYSIBM
DSNKKX01
DSNKKX02
SYSPACKAUTH SYSIBM
DSNKAX01
DSNKAX02
DSNKAX03
SYSPACKDEP SYSIBM
DSNKDX01
DSNKDX02
DSNKDX03
SYSPACKLIST SYSIBM
DSNKLX01
DSNKLX02
SYSPACKSTMT SYSIBM
DSNKSX01
SYSPKSYSTEM SYSIBM
DSNKYX01
SYSPLSYSTEM SYSIBM
DSNKPX01
SYSPROCEDURES SYSIBM
DSNKCX01

Hope this helps...

David Waugh, NCW
DSW Consulting & Services
Former DB2 Sysprog, now clueless DB2 UDB Win/NT DBA
===
Murphy's Laws (and other handy sayings):
===
"In order for something to become clean, something else must become dirty.
...but you can get everything dirty without getting anything clean."


-- David Palmer <[login to unmask email]> wrote:
Joe,
You said, "We are anticipating that we will have up to 5 versions of a
package in this environment" and then asked about space for the packages.

I'm wondering about the basic assumptions and the implications (Have gone
through this before)....

1. Why do you need 5 generation of packages? I have yet to see a case that
going back 5 generation was even an desired. When I asked my developer how
often they update production it was about ever 3 months. So 3 month times 5
generations are 15 months. Do you think that they will want to fall back to
code that old?

2. Is someone going to keep 5 generation of Load modules? Without the Load
modules the Package are pretty worthless. Most shops aren't prepared to do
this. 5 Load libraries and keeping in sync with the catalog will most likely
require some type of automation. Who is going to write and support that?

3. Is there a procedure in place to handle fall back? If the programmers
aren't going to use the packages there is no point. Here is what may happen...
You run into a production problem in a single module that went in last
month. The decision is to fall back. No problem you have the load modules
and package, just move the old module in to production. But wait, wasn't
that module dependent on 4 others and 2 of those needed table and data
changes? Ok we can handle that, we can undo the table and data changes and
fall back the other 4 modules. Uh oh, there are 27 other programs dependent
the table and data changes. Never mind just fix the code and go forward.

IMHO: Don't worry about the space. Clean up your SYSPKAGE (from my
experience there is probably a fair amount of garbage there). Create a job
that deletes old packages and run it once a week until someone can figure a
good way to handle the


Good Luck
David






Scott Hodgin

DB2 log question
(in response to David S Waugh)
What happens when you exceed the maximum log rba in DB2. I just looked at
our production log rba and it is at 01C8B0D13883. W'eve only been under DB2
for about 5 years. This number already seems close to the edge to me. Are
there any other shops close to the maximum log rba?

Scott Hodgin, Database Administrator
South Carolina Farm Bureau Insurance Company
Phone: (803) 936-4311 Fax: (803) 936-4629
[login to unmask email]

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Gregory Palgrave

Re: DB2 log question
(in response to Scott Hodgin)
I have to admit I don't know exactly what happens when your log reaches FFFFFFFFFFFF, but by my rough calculations you only have another 712.5 years or so until your log space runs out and you find out. Make sure you post to the list and let us know what happens. :)

I vaguely recall this being discussed some time ago - check the archives as there may be something in there.

Cheers,

Greg Palgrave

The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our consent. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it.



-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Hodgin, Scott
Sent: Sunday, 7 December 2003 7:47 AM
To: [login to unmask email]
Subject: DB2 log question


What happens when you exceed the maximum log rba in DB2. I just looked at
our production log rba and it is at 01C8B0D13883. W'eve only been under DB2
for about 5 years. This number already seems close to the edge to me. Are
there any other shops close to the maximum log rba?

Scott Hodgin, Database Administrator
South Carolina Farm Bureau Insurance Company
Phone: (803) 936-4311 Fax: (803) 936-4629
[login to unmask email]

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Venkat Srinivasan

Re: DB2 log question
(in response to Gregory Palgrave)
Create a Crestart coldstart request with a startrba = FFFFFFFFFFF1 and
endrba = (same) and bring up the system. Run some update statements. Let us
know how it worked?..

You still have 2795135 Gigs of log records to go.

But a possible solution would be a coldstart followed by recovery!!.
Someone will make avlbl a utility to zap PGLOGRBA in headers!!!.

Regards,
Venkat

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Wayne Driscoll

Re: DB2 log question
(in response to Venkat Srinivasan)
Scott,
One method to avoid log rba wrapping would be to convert the system to
data sharing, which would then use an LRSN which is based on the system
TOD clock, rather than using RBA.
Wayne Driscoll
Sr. Software Developer
Quest Software
[login to unmask email]
NOTE: All opinions are strictly my own. EMail Address in sig must be
modified.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Hodgin, Scott
Sent: Saturday, December 06, 2003 5:47 PM
To: [login to unmask email]
Subject: [DB2-L] DB2 log question


What happens when you exceed the maximum log rba in DB2. I just looked
at our production log rba and it is at 01C8B0D13883. W'eve only been
under DB2 for about 5 years. This number already seems close to the
edge to me. Are there any other shops close to the maximum log rba?

Scott Hodgin, Database Administrator
South Carolina Farm Bureau Insurance Company
Phone: (803) 936-4311 Fax: (803) 936-4629
[login to unmask email]

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". If you will be out of the office,
send the SET DB2-L NO MAIL command to [login to unmask email] The
IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Michael Ebert

Re: DB2 log question
(in response to Wayne Driscoll)
Possibly a bad move. LRSNs will wrap around in 17SEP2042, 23:53:47. I
don't think IBM has started thinking about that yet. Also it seems to me
that LRSNs can't handle more than 60.000 log records/second, which is not
a completely unthinkable rate...

Dr. Michael Ebert
DB2 Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany



Scott,
One method to avoid log rba wrapping would be to convert the system to
data sharing, which would then use an LRSN which is based on the system
TOD clock, rather than using RBA.
Wayne Driscoll
Sr. Software Developer
Quest Software
[login to unmask email]
NOTE: All opinions are strictly my own. EMail Address in sig must be
modified.

-----Original Message-----
>From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Hodgin, Scott
>Sent: Saturday, December 06, 2003 5:47 PM
>To: [login to unmask email]
Subject: [DB2-L] DB2 log question


What happens when you exceed the maximum log rba in DB2. I just looked
at our production log rba and it is at 01C8B0D13883. W'eve only been
under DB2 for about 5 years. This number already seems close to the
edge to me. Are there any other shops close to the maximum log rba?

Scott Hodgin, Database Administrator
South Carolina Farm Bureau Insurance Company
Phone: (803) 936-4311 Fax: (803) 936-4629
[login to unmask email]


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Tony Clark

Re: DB2 log question
(in response to Michael Ebert)
I was in an IBM class once where this question came up, and there were some
IBMers in the class as well. One idea that was tossed out is that IBM might
come up with an installation job that would be run as part
of the installation of a future release that would reset all of the
RBAs to 000000000001 in all tablespaces, logs, etc. and the RBA count would
then start with this value as the highest RBA. Haven't heard anything
authoritative from IBM, though. These were just speculations......

Tony Clark
Texas Workforce Commission

----- Original Message -----
From: "Hodgin, Scott" <[login to unmask email]>
Newsgroups: bit.listserv.db2-l
To: <[login to unmask email]>
Sent: Saturday, December 06, 2003 5:46 PM
Subject: DB2 log question


> What happens when you exceed the maximum log rba in DB2. I just looked at
> our production log rba and it is at 01C8B0D13883. W'eve only been under
DB2
> for about 5 years. This number already seems close to the edge to me.
Are
> there any other shops close to the maximum log rba?
>
> Scott Hodgin, Database Administrator
> South Carolina Farm Bureau Insurance Company
> Phone: (803) 936-4311 Fax: (803) 936-4629
> [login to unmask email]
>
> --------------------------------------------------------------------------
-------
> Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". If you will be out of the office, send the
SET DB2-L NO MAIL command to [login to unmask email] The IDUG List
Admins can be reached at [login to unmask email] Find out the
latest on IDUG conferences at http://conferences.idug.org/index.cfm
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Tom Flesher

Re: DB2 log question
(in response to Tony Clark)
Notwithstanding that data sharing uses LRSNs for many purposes, each member
of a data sharing group still has a unique log space managed using
old-fashioned relative byte address log RBAs.... and it is possible in a
data sharing environment that multiple log records form different members
may have identical LRSNs!

Tom Flesher
E-Net Corporation
[login to unmask email]




Wayne Driscoll
<wayne.driscoll@Q
UEST.COM> To
Sent by: DB2 Data [login to unmask email]
Base Discussion cc
List
<[login to unmask email] Subject
ORG> Re: DB2 log question


12/06/2003 08:31
PM


Please respond to
DB2 Database
Discussion list
at IDUG
<[login to unmask email]
2-L.ORG>






Scott,
One method to avoid log rba wrapping would be to convert the system to
data sharing, which would then use an LRSN which is based on the system
TOD clock, rather than using RBA.
Wayne Driscoll
Sr. Software Developer
Quest Software
[login to unmask email]
NOTE: All opinions are strictly my own. EMail Address in sig must be
modified.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Hodgin, Scott
Sent: Saturday, December 06, 2003 5:47 PM
To: [login to unmask email]
Subject: [DB2-L] DB2 log question


What happens when you exceed the maximum log rba in DB2. I just looked
at our production log rba and it is at 01C8B0D13883. W'eve only been
under DB2 for about 5 years. This number already seems close to the
edge to me. Are there any other shops close to the maximum log rba?

Scott Hodgin, Database Administrator
South Carolina Farm Bureau Insurance Company
Phone: (803) 936-4311 Fax: (803) 936-4629
[login to unmask email]

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". If you will be out of the office,
send the SET DB2-L NO MAIL command to [login to unmask email] The
IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------

Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". If you will be out of the office, send the SET
DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins
can be reached at [login to unmask email] Find out the latest on
IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Aurora Dellanno

Re: DB2 log question
(in response to Tom Flesher)
Scott,

Once you've hit the dreaded high values, the log RBA wraps around. By the
looks of where you are now, it looks like this will happen to you quite
soon, that is in around 40 years or so (maybe less if your systems is on the
grow). How long do you keep logs for? ;-)

ciao!

Aurora Emanuela Dell'Anno
Database Analyst
Data Services Group - Bank of America
tel. 66192
ext. 0208 760 6192
[login to unmask email]

* std. disclaimer * MY OPINIONS ARE MY OWN AND NOT THOSE OF MY EMPLOYER

no trees were killed in sending this message. However, a large number of
electrons were seriously inconvenienced :-)

-----Original Message-----
From: Hodgin, Scott [mailto:[login to unmask email]
Sent: 06 December 2003 23:47
To: [login to unmask email]
Subject: DB2 log question


What happens when you exceed the maximum log rba in DB2. I just looked at
our production log rba and it is at 01C8B0D13883. W'eve only been under DB2
for about 5 years. This number already seems close to the edge to me. Are
there any other shops close to the maximum log rba?

Scott Hodgin, Database Administrator
South Carolina Farm Bureau Insurance Company
Phone: (803) 936-4311 Fax: (803) 936-4629
[login to unmask email]

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". If you will be out of the office, send the SET
DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins
can be reached at [login to unmask email] Find out the latest on
IDUG conferences at http://conferences.idug.org/index.cfm

Notice to recipient:
The information in this internet e-mail and any attachments is confidential
and may be privileged. It is intended solely for the addressee. If you are
not the intended addressee please notify the sender immediately by
telephone. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful.
When addressed to external clients any opinions or advice contained in this
internet e-mail are subject to the terms and conditions expressed in any
applicable governing terms of business or client engagement letter issued by
the pertinent Bank of America group entity.
If this email originates from the U.K. please note that Bank of America,
N.A., London Branch, Banc of America Securities Limited and Banc of America
Futures Incorporated are regulated by the Financial Services Authority.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Michael Ebert

Re: DB2 log question
(in response to Aurora Dellanno)
Aurora,

I think you miscalculated by about a factor of 20... that's assuming that
DB2 treats the RBA as an unsigned value, which I wouldn't bet too heavily
on (otherwise it's about one order of magnitude).
In any case, having used about one percent of a limited resource isn't all
that close to the edge.

Dr. Michael Ebert
DB2 Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany



Scott,

Once you've hit the dreaded high values, the log RBA wraps around. By the
looks of where you are now, it looks like this will happen to you quite
soon, that is in around 40 years or so (maybe less if your systems is on
the
grow). How long do you keep logs for? ;-)

ciao!

Aurora Emanuela Dell'Anno
Database Analyst
Data Services Group - Bank of America
tel. 66192
ext. 0208 760 6192
[login to unmask email]

* std. disclaimer * MY OPINIONS ARE MY OWN AND NOT THOSE OF MY EMPLOYER

no trees were killed in sending this message. However, a large number of
electrons were seriously inconvenienced :-)

-----Original Message-----
>From: Hodgin, Scott [mailto:[login to unmask email]
>Sent: 06 December 2003 23:47
>To: [login to unmask email]
Subject: DB2 log question


What happens when you exceed the maximum log rba in DB2. I just looked at
our production log rba and it is at 01C8B0D13883. W'eve only been under
DB2
for about 5 years. This number already seems close to the edge to me. Are
there any other shops close to the maximum log rba?

Scott Hodgin, Database Administrator
South Carolina Farm Bureau Insurance Company
Phone: (803) 936-4311 Fax: (803) 936-4629
[login to unmask email]


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm