IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Performance Impact of Collectionid.* usage


IBM Mainframe Forums -> DB2
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
prasun dhara

New User


Joined: 01 Mar 2008
Posts: 49
Location: kolkata

PostPosted: Mon Dec 12, 2011 5:29 pm
Reply with quote

Hi,

What is the performance impact if we use CollectionId.* instead of CollectionId.packagename during bind.


For example :
In the PKLIST
Collectionid.Package1
Collectionid.package2

will serv the purpose but if we use CollectionId.* then also purpose will be served. In this case what is the performance impact if all the packages are bound to a plan.

Thanks

Prasun
Back to top
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania

PostPosted: Mon Dec 12, 2011 6:38 pm
Reply with quote

At our shop we use the construct CollectionId.*

There is no performance impact from what we can tell.

There several thousand packages in the collection.
Back to top
View user's profile Send private message
prasun dhara

New User


Joined: 01 Mar 2008
Posts: 49
Location: kolkata

PostPosted: Tue Dec 13, 2011 10:39 am
Reply with quote

Ok, If there is no performance impact everyone should use collectionid.* . What is the benefit of using collectionid.package1 ?

Thanks
Prasun
Back to top
View user's profile Send private message
Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK

PostPosted: Tue Dec 13, 2011 12:52 pm
Reply with quote

Why not think a bit...

If I gve you a problem bind with collectioid.* and asked you to sort it out wouldn't one of the first things that you would do is find out which packages are involved?

So that is one benefit of explicitly stating the package names.
Back to top
View user's profile Send private message
prasun dhara

New User


Joined: 01 Mar 2008
Posts: 49
Location: kolkata

PostPosted: Tue Dec 13, 2011 1:14 pm
Reply with quote

Even it is bound with COllectionid.* .. During run time error comes like

Ex. -805

Package (Subsytem.collectionid.package.Ctoken ) not found in plan

So it can be found easily for which package the problem is coming.

It will be of great help if you give an example where I can see a problem of using collectionid.*

Thanks
Prasun
Back to top
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania

PostPosted: Tue Dec 13, 2011 6:15 pm
Reply with quote

We see no problem with it at all.

We have over 20,000 Plans that point to a collectionid.*.

In fact it makes things much easier.

Just say you have a batch application that has a driver and 12 subroutines. Do you really want to list each subroutine called in the pklist for the plan? I do not.

If you add a new subroutine, you would have to Bind your plan again.

If subroutine number 10 calls the new subroutine, and number 10 is called from 16 different plans, then each one must be bound again.

I see no advantage to listing each package explicitly.
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Tue Dec 13, 2011 6:25 pm
Reply with quote

Our shop does not use collectionid.*, but that is a security/audit rule not a performance concern. They want to be able to tell at a glance which packages can be executed by a given Plan. It is a minor PITA for developers to remember to rebind the Plan whenever a new package is added to the list, but on the plus side it helps with impact analysis.
Back to top
View user's profile Send private message
prasun dhara

New User


Joined: 01 Mar 2008
Posts: 49
Location: kolkata

PostPosted: Wed Dec 14, 2011 9:15 pm
Reply with quote

thanks don. I have understood the benefit in impact analysis part.but what is the benefit in security/audit?.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Dec 14, 2011 9:32 pm
Reply with quote

don.leahy wrote:
Our shop does not use collectionid.*, but that is a security/audit rule not a performance concern. [Secuirty/Audit People] want to be able to tell at a glance which packages can be executed by a given Plan.
Back to top
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania

PostPosted: Wed Dec 14, 2011 9:38 pm
Reply with quote

don.leahy also wrote:
Quote:
It is a minor PITA for developers to remember to rebind the Plan whenever a new package is added to the list


In our case it is more than a minor pain, it would be a huge pain.

We have over 30,000 packages and 20,000 plans. Keeping track of what runs where (and the success of the system dependent on it) would be a case of the tail wagging the dog.
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Wed Dec 14, 2011 9:57 pm
Reply with quote

It's only a minor pain because we've been doing it that way since packages were first introduced. We have over 200,000 packages and 120,000 Plans in one of our DEV subsystems.

I agree that trying to retrofit this approach in a large shop would be a daunting task. I would never recommend it.

I've worked in shops that use collectionid.* and I much prefer it, even at the cost of losing a convenient impact analysis tool.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Wed Dec 14, 2011 10:25 pm
Reply with quote

Currently, when a SA in my shop runs a test, he binds all packages for the program(s) he is testing and adds them to his personal collection. He then creates a plan consisting of all packages in this collection.

There is pressure to have me change the execs and skeletons fabricating the JCL and control cards to bind all packages using tables in any of the (DB2) data bases that he uses in testing and add them to his personal collection. I'm trying to resist this pressure...
Back to top
View user's profile Send private message
M David Hunter

New User


Joined: 30 Jan 2012
Posts: 6
Location: United States

PostPosted: Mon Feb 06, 2012 10:30 pm
Reply with quote

Quote:
There is pressure to have me change the execs and skeletons fabricating the JCL and control cards to bind all packages using tables in any of the (DB2) data bases that he uses in testing and add them to his personal collection. I'm trying to resist this pressure...


Akatsukami,

My shop is wanting to set up personal collections for each SA. What is required to do this for one collection? How can I estimate the time this process would take for one SA?
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Mon Feb 06, 2012 10:46 pm
Reply with quote

this personal stuff has always left me with a nagging question:
what does it buy you?

you still have to create a 'production' version, which has to be tested.

what do you achieve with this 'personal' approach?

in the last 20 or 25 years,
i have consulted in nearly as many shops,
and no one has ever used this approach.

IMUO, it is a waste of time and resources,
which could be better spent upgrading the skill-sets of your programmers.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Tue Feb 07, 2012 9:47 pm
Reply with quote

M David Hunter wrote:
Quote:
There is pressure to have me change the execs and skeletons fabricating the JCL and control cards to bind all packages using tables in any of the (DB2) data bases that he uses in testing and add them to his personal collection. I'm trying to resist this pressure...


Akatsukami,

My shop is wanting to set up personal collections for each SA. What is required to do this for one collection? How can I estimate the time this process would take for one SA?

To the best of my knowledge, no set-up is necessary; it is sufficient to specify the collection ID on the BIND PACKAGE and BIND PLAN commands.
Back to top
View user's profile Send private message
M David Hunter

New User


Joined: 30 Jan 2012
Posts: 6
Location: United States

PostPosted: Tue Feb 07, 2012 9:50 pm
Reply with quote

Thanks for all the input. Great input.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Wed Feb 08, 2012 3:17 am
Reply with quote

dbzTHEdinosauer wrote:
this personal stuff has always left me with a nagging question:
what does it buy you?

As I may have mentioned before: in my shop any given source module may be being modified by anywhere from two to two hundred programmers, each working independently of the others. Each individual programmer has heesh (<--- note use of non-sexist pronoun) own libraries, data bases, tables, packages, etc. Doing otherwise would make things even more chaotic and less productive than they are now.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Feb 08, 2012 3:31 am
Reply with quote

Akatsukami,

my only response is that it sounds as if the programs are too big.

but, that does not negate the necessity of handling it the way you do.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Wed Feb 08, 2012 3:52 am
Reply with quote

dbzTHEdinosauer wrote:
Akatsukami,

my only response is that it sounds as if the programs are too big.

I agree. And if I'd begun working here in 1974 instead of 2004, I might have stopped them icon_confused.gif

Some programs (not a high proportion, to be sure, but we have over 20,000 main programs; five percent of that is too many) are comprised of dozens or hundreds of source modules; a few of thousands. Every data item access is in a module that does only that (good structured design, right? icon_rolleyes.gif ), and that subroutine is dynamically linked to hundreds of main programs...sometimes at the end of a call chain fifteen or twenty levels deep (every reusable business function is also in a separate dynamically-called subroutine...good structured design, right?)
Back to top
View user's profile Send private message
M David Hunter

New User


Joined: 30 Jan 2012
Posts: 6
Location: United States

PostPosted: Wed Feb 08, 2012 6:32 pm
Reply with quote

Akatsukami wrote:
Each individual programmer has heesh (<--- note use of non-sexist pronoun) own libraries, data bases, tables, packages, etc. Doing otherwise would make things even more chaotic and less productive than they are now.


Akatsukami, my employer thinks we should head in this direction. A consultant told me that to do this I would need to create a collection for each programmer. But I interpret you comments as saying it's much more than this. Instead, if we have three programmers and 5 databases then I would need 15 databases and all the objects within each, and 3x the packages, etc? Is that what you are saying? Thanks for any response you may offer.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Feb 08, 2012 7:17 pm
Reply with quote

M David Hunter,

i would agree that your assumption is correct.

if everybody is to have their own environment,
because coordination of development is something that can not be obtained,
you need an environment for each person.
which is taking unit testing to the ultimate plateau.

there is another thread where a individual had a problem
proving that 'he' did not make a mistake,
after having to copy things from this library to that in order to test.
yes, forcing everyone to use the same libraries,
(most places i have worked have development, systems, qa, prod
and that is it)
means that development must be coordinated.

sites that can not coordinate development,
need to have the 'individual' approach,
which apparently is easier for the 'managers'.
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Wed Feb 08, 2012 8:24 pm
Reply with quote

In my experience, the individualized approach only works when each individual has expert knowledge about the test environment. Even with that, a lot of support from the DBA is required in order to keep the environments current and consistent.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Wed Feb 08, 2012 8:53 pm
Reply with quote

don.leahy wrote:
In my experience, the individualized approach only works when each individual has expert knowledge about the test environment. Even with that, a lot of support from the DBA is required in order to keep the environments current and consistent.

36_11_6.gif

I just got done explaining to a sotfware engineer pretending to be a DBA that my problem was not getting the -803 SQLCODE, but that his exec was returning the message for a -553 SQLCODE.

There are certainly knowledgeable DBAs; I've met some. Most, however, seem to be clueless junior programmers with DBADMIN privilege.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Wed Feb 08, 2012 9:37 pm
Reply with quote

M David Hunter wrote:
Akatsukami wrote:
Each individual programmer has heesh (<--- note use of non-sexist pronoun) own libraries, data bases, tables, packages, etc. Doing otherwise would make things even more chaotic and less productive than they are now.


Akatsukami, my employer thinks we should head in this direction. A consultant told me that to do this I would need to create a collection for each programmer. But I interpret you comments as saying it's much more than this. Instead, if we have three programmers and 5 databases then I would need 15 databases and all the objects within each, and 3x the packages, etc? Is that what you are saying? Thanks for any response you may offer.

In essence, yes. Now, as Messrs. Brenholtz and Leahy indicate, this is not necessarily a good way of doing things, and I'm not claiming that it is; it's just the way things are done here.

When a developer is ready to unit, integrate, or regress test, he runs tools (some written by me, others not) that tell him what DB2 objects, IMS data bases, VSAM data sets, etc. his program uses, create personal copies for him, and load them from (suitably masked) production data. Data sets are generally given HLQs of project-number.TSO-id.

DB2 is messier. Local standards are that data base names must be no more than five characters. A programmer is assigned a "user code" (two arbitrary alphas) and one or more "versions" (arbitrary alphanumerics). The user code/version combo is suffixed to the generic (five-character) data base name, and used to qualify every DB2 object that doesn't need an actual authid. So, every developer essentially has his own environment.

Likewise, when the alpha-null (OK, seldom more than a few dozen) packages needed for his program are bound, they are added to the collection TSO-id. A plan TSO-id is then created from *.TSO-id.* (and a few other collections) and used in conjunction with the program.
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Wed Feb 08, 2012 9:58 pm
Reply with quote

In our shop there are several 'test sets' that are assigned to projects rather than individuals. Each set consists of the same DB2 and IMS definitions, suitably resized, used in the production environment. Naming conventions are used to distinguish between the sets. There are a *lot* of objects in each test set.

It works well, but it requires an entire team of specialists using an elaborate toolkit to keep everything up to date with production changes.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> DB2

 


Similar Topics
Topic Forum Replies
No new posts exploiting Z16 performance PL/I & Assembler 2
No new posts STEM usage in REXX CLIST & REXX 14
No new posts JOIN STATEMENT PERFORMANCE. DFSORT/ICETOOL 12
No new posts z/OS Modules Usage report using SMF 42 DFSORT/ICETOOL 2
No new posts Concatenate 2 fields (usage national)... COBOL Programming 2
Search our Forums:

Back to Top