Creating Test Environment

doddsf

Member
I am working with a client who has a production environment with custom
files and programs and no JDE test environment. I am looking at the manual
APCS and on menu G9645. I see the tools here, I am just not sure they are
what I need. I need to copy a specified production data library to test
and all it's pieces to a specified test library. I need to copy the program
source and objects to specified libraries also but all of the source is not
registered in SVR. It looks like the F9802 is driving this J/P98102
program. I want the simplest way to copy over all the files and logicals
and programs to test. I looked for a white paper on the Knowledge Garden
site for setting up test libraries and found nothing. Any feedback would be
appreciated.
 
The way I created a test environment was to create CLP do a dspobjd to and
output file were ne PF can add LF
0070.00 DSPOBJD OBJ(LEWDTACNV/*ALL) OBJTYPE(*FILE)
OUTPUT(*OUTFile) OUTFILE(LEWDTACNV/DATA)
0071.00 READAGAIN:

0072.00 RCVF

0073.00 MONMSG MSGID(CPF0864 CPF0000 CPF9999) EXEC(GOTO +

0074.00 CMDLBL(END))

0075.00 CHGVAR VAR(&BASE_FILE) VALUE(&ODOBNM)

0080.00 IF COND(&ODOBNM *EQ 'F42119 ') THEN(GOTO
CMDLBL ( READAGAIN) 0080.01
IF COND(&ODOBNM *EQ 'F4111 ') THEN(GOTO CMDLBL (READAGAIN)
0081.00 IF COND(&ODOBNM *EQ 'F42199 ') THEN(GOTO
CMDLBL (READAGAIN)
0082.00 IF COND(&ODOBNM *EQ 'F4141 ') THEN(GOTO
CMDLBL (READAGAIN)
0082.01 IF COND(&ODOBNM *EQ 'F43199 ') THEN(GOTO
CMDLBL (READAGAIN)
IF COND(&ODOBNM *EQ 'F47123 ')
THEN(GOTO CMDLBL (READAGAIN)
IF COND(&ODOBNM *EQ 'F47123A ')
THEN(GOTO CMDLBL (READAGAIN)
IF COND(&ODOBNM *EQ 'F0911 ')
THEN(GOTO CMDLBL (READAGAIN)
IF COND(&ODOBNM *EQ 'DATA ')
THEN(GOTO CMDLBL (READAGAIN)
CHKOBJ OBJ(LEWDTATST/&BASE_FILE)
OBJTYPE(*FILE)
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(CRTDUP))

CPYF FROMFILE(LEWDTACNV/&BASE_FILE) TOFILE(LEWDTATST
MONMSG MSGID(CPF2816 CPF2817 CPF9999 CPF0000) +
EXEC(GOTO CMDLBL(READAGAIN))
GOTO READAGAIN
CRTDUP:
CRTDUPOBJ OBJ(&BASE_FILE) FROMLIB(LEWDTACNV) OBJTYPE(*FIL
0106.00 /*
*/
0107.00 /* --------- Send File Creation Status Message -----------
*/
0108.00 /*
*/
0109.00 CHGVAR VAR(&MSG) VALUE('J00CRTPF: file' *BCAT +

0110.00 &BASE_FILE *BCAT 'successfully created +

0111.00 in' *BCAT &PROD_LIB)

0112.00 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSG) +

0113.00 TOMSGQ(&PSMSGQ) MSGTYPE(*INFO)

0114.00

0115.00

0116.00 END:

0117.00
/
 
The way I did it was to restore the data and common libraries with a
different name, keeping a common security lib, and then do it all
through separate library lists from option #5, menu g944....works
great...
 
Dodds,

There are several parts to your question and I see that others have given
you very good advice. Generally, creating the environment is the least of
your troubles. Your first step is to map out what exactly it is you are
trying to do. You say they have a production environment with no test. Do
they have a Dev environment? Will you or they want to make changes in Dev,
move to Tst, and then into Prd? Your library list in Tst should look
something like:

QTEMP
EBBLIB - Electronic Burst and Bind
TSTOBJ - Compiled objects to be tested
CLTOBJ - Production Client objects
JDFOBJ - "Pristine" objects
TSTCOM - Test "Common" library
TSTDTA - Data files containing information used in testing
CLTSEC - Client Security information
TSTSRC - Test Source
CLTSRC - Client Source
JDFSRC - "Pristine" Source
QGPL

Your users should have an initial program of J98INITA from JDFOBJ on their
profiles and assigned the required environments in 6/G944. This gives them
the ability to sign into different environments.

The setup isn't too bad, it's the refreshing of the environment that will
cause the problems. Since you have to have a test common environment, when
you refresh the data from production you not only overlay the data but also
any test soft-coding you may have done. That means you have to be careful
about scheduling a refresh because you have to back all of your test
soft-coding back to Dev, do the refresh, then promote it back to test.

As for the SVR, I believe there is a program on the JDEList website that
helps you rebuild from the source you have on the system. We moved our SVR
files (F9801 and F9802) to CLTSEC so that they would be the same across all
environments. (If you look into the archives you should see some further
discussion of what files to move and where.)

It's been over a year and a half since we set this up so I may be forgetting
something but this and other lister comments should give you a good start.

Douglas Belcher
KV Pharmaceutical Inc.
St. Louis MO
Opinions expressed are not necessarily those of my employer





Doug Belcher
St Louis MO
Opinions expressed are not necessarily those of my employer
A7.3c10
 
Douglas had some very good feedback on the test environment layout. The
only area that I would add to it is to create a library for each
environment for custom programs or mods. We have a CLTMOD and CLTMODTST.
Where the programers can create their custom programs in CLTMODTST, run
them against your test data and com libs then compile and save them into
CLTMOD when they are ready to push them out.

When we refresh our environments, these do not get refreshed from prod, but
the data and com libraries do. Other than that though - there were a lot
of good responses.

Thanks,

Kristian
 
Just to add to all who replied (all were great answers). The basic is to
duplicate your current production libraries into test libraries. If you
have any Installation guide or PTF work book you will find a demonstration
of creating an alternate environment which you may use as a shell and add
to it duplication of production object and source libraries.
I do agree with one of the reply, you have to plan and answer some
questions (which vary from client to client):
- Is the test environment for testing only? meaning are you planning to do
development in test?
- Do you have a development environment?
- Do you have a change mgmt control in place?
- How large is the production libraries?
- Do you have enough disk space to duplicate the entire production data
library? (recommended for testing).
- If you don't have enough disk space, do you have a list of which database
to duplicate?
- Do you have any join/logicals files in a different library than their
physical files?

The list goes on and on, it depends on your set-up and type of business.

Last not least, I have not seen a client (for the past 11 years) with a
complete, clean SVR (even JDE ship you with a messy one!). So you need to
write your own CL to accommodate your answers of above questions.

Let us know if you need any help

Emad Banoub
Montgomery Watson
Pasadena, CA
626-568-6529
A7.3 cu 12/X3 - Xe SP 13.0







doddsf <[email protected]>@jdelist.com on 06/19/2001 10:44:46 AM
 
Back
Top