Mulltiple databases on AS/400 DB2/400
Nick Palmer
I'm trying to setup a production/test environment on our AS/400 DB2 box and
i'm not sure how to go about this. Basically what I want to have the same
tables and libraries duplicated on one box. In oracle, I would create
another instance, and on MS SQL Server I would just create two different
databases. Can such a thing be done on an AS/400 ?
Thanks in advance.
Nick.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
David Dunfield
that library. Make sure that your production library is not in your job library
list and that your test library is for testing. Very simple to do.
Bob Lepp
library lists to use one or th eother.
You can duplicate an entire library.
Bob
"Nick Palmer" <ni...@kcicorp.com> wrote in message
news:3aa97492$1...@corp.newsfeeds.com...
Tom Liotta
Given the exact way you worded your request ("...tables and libraries
duplicated..."), no, it cannot be done (uh... AFAIK). That is, if you
require two instances of a library named "MyLib", it isn't going to
happen. But I'm not sure that you actually want that.
Further, if you are duplicating SQL collections, you'll run into trouble
with the journal and journal receiver objects, etc., when you attempt
the duplication. For many objects, whether you're talking SQL collection
or not, duplication is a problem issue.
OTOH, for a basic library of physical and logical files, program
objects, most common objects, you can often simply use the CPYLIB
command. That may be the easiest place to start just to see the results
and know what issues you might have. Then ask again about specific
problem details.
Creating production and test environments is a common problem that's
been solved in a number of ways. There're bound to be solutions that'll
fit.
Tom Liotta
--
Tom Liotta
PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone 253-872-7788
Fax 253-872-7904
http://www.400Security.com
Denny Davis
breaks the rules, the your test program can start chewing on your
production files. These rules also permit multiple production
environments (multiple companies) and multiple test environments
(development, education, QC testing).
1. Libraries contain either data or programs. Never both.
Program libraries will be in both the productiion and test library
list. No library list will ever have both production data and test
data in it at the same time.
This rule along with a couple of others allows you to restore a copy
of production data to a test library.
2. Library names are never hard coded in any program.
Allright, I will allow a few exceptions. TEMP and under rare
conditions QGPL. In your backup CL if you only have one environment
to be backed up.
Another exception would be an "initiatior" program. This is a common
entry point that gets you established in an environment. Once it sets
the library list, LEAVE IT ALONE! Do not modify it!
Trust your *LIBL. Do not qualify anything unless it is absolutely
necessary. When you must code a library name, it is in the format of a
variable. The contents of the variable will be retrieved from
something in the libary list, usually a data area. This way, any
program will work correctly in any environment.
3. Logical files are alway in the same library as their physical.
There is a long list of reasons for this rule completely outside the
scope of this thread. For this discussion, the impact is CRTDUPOBJ,
CPYLIB and RSTLIB to a different library that the one saved. All these
commands work perfectly if logicals and physicals are in the same
library. If you do have misplaced logicals, then all kinds of ugly
things begin to happen. The worst is when you have a logical in test
that is attached to data in production. And then you test year end
close.
4. Put everything that contains a library name in to a "control"
library. There will be one of these control libraries for each
environment. Typically this library will containg nothing but JOBDs
that have embeded library lists and data areas containing individual
library names or library lists.
By isolating everything that contains a library name into a
specialized library you avoid the problem of inadvertently restoring
or copying a library name when copying data. It also makes it easy to
create a new envoronment. You duplicate the "control" libary. Put the
new library names in the data areas and JOBDs. Duplicate the data
libraries. You're done!
The control library name is the only library name that your initiatior
program has to know.
5. Decide on a policy for developement libaries.
A test library list can contain a development program libray
preceeding all other program librarys. You may also need one or more
development data libraries in the test library list. This approach
works best when there is a team of programmers working togeather on a
project.
Another approach is for each programmer to have his own private
development libraries.
Watch out for programmers working with a library defined as their
*CURRENT library. You can get an ugly suprise with this.
This is just an overview from 30,000 feet. Hope it helps.
Denny
On Fri, 9 Mar 2001 16:31:14 -0800, "Nick Palmer" <ni...@kcicorp.com>
wrote:
Nick Palmer
Nick.
"Nick Palmer" <ni...@kcicorp.com> wrote in message
news:3aa97492$1...@corp.newsfeeds.com...
Martin Rowe
<ni...@kcicorp.com> wrote:
> Hi all,
>
> I'm trying to setup a production/test environment on our AS/400 DB2 box
> and i'm not sure how to go about this. Basically what I want to have
> the same tables and libraries duplicated on one box. In oracle, I would
> create another instance, and on MS SQL Server I would just create two
> different databases. Can such a thing be done on an AS/400 ?
>
> Thanks in advance. Nick.
You could try my (free) DBG/400 utilities - they were written for just this
situation, particularly if you want tailored environments/data subsets
etc.
Regards, Martin
--
mar...@dbg400.net / jam...@firstlinux.net
http://www.dbg400.net DBG/400 - DataBase Generation utilities
Open Source test environment tools for the AS/400 / iSeries and
miscellaneous database & spooled file management commands.
Jon
wrote:
>Thanks to all that replied. I think I got.
>
>Nick.
A way to help prevent updating live data by accident is...
All test libraries should be created/changed to be *TEST, when you
CRTLIB, CHGLIB you can change to/from *PROD or *TEST.
Prior to running you progams type
STRDBG UPDPROD(*NO)
If a file is opened for update and it resides in a *PROD library then
the program will fall over with a message telling you it cannot open
the file...
This does not prevent all rogue updates (Logicals in *TEST can update
the physical file in *PROD libraries, I seem to recall) and non data
base storage (data areas, data queues...) can still be updated even
with the above inforce.
Finally, just as a last warning, If your test environment produces any
data that is used as output/input to another system then this has to
be thought about.
I've known banks to send data twice because they ran the live and test
systems into the live output stream. (they did catch the error
upstream)
Jon
--
Jonathan Wilson
Phone 07775 638904.
I can only offer advise! No responsibility can be accepted.
All sugestions are provided on a personal basis,
such as would be recieved by talking to a friend.