Good question. The standard environments for JDE are as follows (using XE environments as an example):
JD - Pristine, uses Pristine Data, Pristine Pathcode
DV - Development, uses Test Data, Development Pathcode
TS - Dev Test, uses Test Data, CRP Pathcode
PY - Prototype, uses CRP Data, PY pathcode
PD - Production, uses Prod data, Prod pathcode
Now - these do NOT need to be set in stone - in fact, there are definately many customers out there that have large numbers of additional environments and data sets for different business requirements. However, lets investigate what would occur if you increased this.
If you increased the data sets - this can be done in two ways. The first would be if you had additional TESTING data sets. This would not increase management too much, and is in fact a recommended practice for automated testing - I actually have a whitepaper on my website that talks about the case for an additional "golden" environment which I set up for a lot of customers that have a healthy amount of development (see "Revised ESU Upgrade Procedures - the Case for QA" on my website downloads section).
If, however, you decide to split your production data - lets say you decide that Manufacturing and Distribution should be seperated OR that you try and run two companies in two different data sets - then you will open up a ton of testing issues. Quite literally, you have an issue where you are testing objects and setup in your DV/TS/PY environment that will only validate against one of your production environments. This is certainly NOT a desired practice.
You MIGHT want to come up with some sort of replication model for branch infrastructures - for example, the data is still contained in a single dataset - but you have additional remote locations that you wish to replicate sets of data to. Before we had Citrix, this was relatively common and JDE does provide internal data replication. HOWEVER - replication is not reliable using JDE, and you open yourself to a certain amount of data integrity issues with your data spread across the network.
So what about Pathcodes ? These are the codebase for JDE. The reason for having multiple codesets would ONLY be for testing purposes. I have had customers try to argue for multiple codesets for different countries or different business uses - but it is easy to explain to the customer why they need to keep a single set of objects. There is NEVER a reason for more than the JDE set except for the "QA" golden testing automated set of objects - again, only for larger development customers.
As for environments - well, using the datasets and pathcodes, you can actually create several additional environments that cross over - remember, environments are POINTERS between data and code. Again, for testing purposes only.
So the moral for this story is think strongly about what you want to run. You ALWAYS want to keep a single set of production objects and production data as MUCH as possible. Creating multiple copies of either will double your testing load since you really should test what your production environment looks like.
Check out my whitepapers on my website :
"OneWorld Xe ESU Update Procedures "
and
"Revised ESU Upgrade Procedures - the Case for QA"
as well as the standard JDE documentation :
"Software Update Installation Guides (ASU/ESU) : ERP Software Update"
and
"Software Update Installation Guides (ASU/ESU) : Xe "
