Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
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'.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
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.
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
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.
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.
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
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.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
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.
