CNC Guidelines

I've done a few installations of OneWorld Xe (three, to be exact). Along the way I have discovered a few little rules that make things go smoother (like don't create packages for environments signed into JDEPLAN (ayi, what a mess), or always create server packages when you create packages (oh how I wish I had known that when I started)).

I'm convinced that the guidelines necessary to be a reasonably good CNC tech would probably occupy four typewritten pages. Obviously it couldn't cover every eventuality (store and forward client, etc). And it wouldn't replace the Fine Manuals provided by JDE. But it would be useful to have a simple document with the "rules" for installing, creating and deploying packages, etc-- the basic bread and butter that takes up 90% of the day for a CNC tech. Let's say 100 points that begin with "Always...", "Never...", "Usually...", "It's a good idea to..."

Does a document of this type exist? Cuz I'd give my eye teeth to get my hands on it.

Thanks in advance.

Tim,

You're right, that would be a handy document. Here's a challenge to the CNCs out there, what are your top ten issues? I'm sure that there is enough collective knowledge out there to get a document together. Any one up for the challenge?

Praxair CNC Guy

Okay, I'll contribute my 10. I have to say that I'm not 100% sure of these-- I've learned them through trial and error more than anything:

Tim Allen's top 10 issues:
1. Always build packages signed into the environment the package is for.

2. When you create a package, always create it so it can be applied to the Enterprise Server. Otherwise, you may not be able to, for example, run UBEs using the Enterprise Server.

3. Consultants who are working in PY7333 should have their default projects set to status 26. This avoids problems later of not being able to check-in their versions.

4. OCM mappings for user overrides are wrong out of the box at least up to Update 6/SP19.1. ott-01-0107 shows how to fix them.

5. An update package which includes a UBE version should also include its base UBE, even if the base UBE is a standard UBE. We found that a lot of times the package won't build otherwise.

6. When you install an ESU or Update, be sure to read the document that comes with it and do the special instructions.

7. If a user can't seem to check in a UBE version from the OMW, include the base UBE in the package and check to see if the base UBE is in the path code that you are trying to check in to. We often had the problem that the base UBE would be in DV and the version would be in PY until we started changing the status of the default OMW project to 26.

8. Be sure to set a default printer for the WinClient host. If not, you will get lots of errors in your JDE.LOG.

9. Be sure to assign an address book number to all the users who will use OMW or do builds, especially JDE.

10. If a package build fails, go to Build History and check the logs. If it looks like you have fixed everything, you can restart the build from there instead of starting again from zero. When it asks if you want to generate NER, say no (unless you're sure you didn't generate NER in the first place).

Here are my 10 golden tips (Hopefully):

1) ALWAYS change the Oneworld "JDE" password & Oracle user passwords - its easy to do - dont listen to JDEdwards.

2) If you have more than one production environment with more than one path code e.g:
Env PD7333 PathCode PD7333
Env PD27333 Pathcode PD27333
Share the path code - if the code is the same then you can remove the extra files from the servers and get easier control of your deployments.

3) PERFORMACE - take your JDEdwards installation off your database server - run it on another server and have it point to the database. Your database will have more free memory and your UBE's will run faster.

4) ALWAYS check your tables for fragmentation. We got a new DBA recently and he pointed this out to us - you can use table F986115 to specify the correct oracle sizing. We increased out performance by 45% accross the board. If in doubt ask your Oracle DBA to check the number of "Extents" on the F0911 or F42199 table. Any more than around 30 is bad news performance wise.

5) ALWAYS protect you night batch jobs. We deploy to our production environment and users used to run the night versions with data selections, and when the scheduler comes to run the job that night it either errors or runs blank becuase of the screwed up specs. We stopped this by running a script once installed to production to change the user ID to something odd like "SCHEDULE", and the security mode to be 2, so people could copy this version but not change it. Becuase we do it after deployment, the developers can still change the version in PY7333 under their own user ID no problems.

6) NEVER give developers access to OCM's / Database data sources e.t.c. If they can get in their they will try to do their own mappings e.t.c.

7) ALWAYS use the table caching program - P98613 to increase performance.

8) ALWAYS delete the entry for the F0101 n the P98613 or you may have interesting results.....

9) ALWAYS be sure your databse driver connectors are up to date - if you have moved from Oracle 8.05 - Oracle 8I ensure your connectors say "JDBOCI81.DLL" not "JDBOCI80.DLL". You will need to change this in the jde.ini files as well as d/b data sources.

10) Dont be afraid to have more than one business data owner. We have 3 for one of our environments and it allows us to use localls managed tablespace (Ask you DBA today about locally managed tablespaces and extent management). This means you can store Business Data - PDSMALL / MEDIUM / LARGE e.t.c.

11) PERFORMANCE - goto P98MOQUE and change the machine name to I.P. address - works much faster.

Hope this helps!

Frankly, I do not like this "rules" idea:

Any kind of rules is always is a simplification and can lead to problems
unless supported by underlying solid knowledge of the system. Some of these
rules can have an opposite effect in certain situations and I specifically
disagree with the rule #3 below - in my tests an AB report that was taking 1
min to run on a busy and slow server with the DB on it was taking 2 min on a
separate faster server with no users just because of the network in between
- this would translate into another rule: Whatever you do, benchmark it
before and after and have a backup handy in any case...

My opinion is that if such rules are to be compiled they should be more
generic and very few. Specific rules are often implementation-specific and
should be applied with caution and only after careful consideration.

Regards,
Alexander Pastuhov

Stuart

We are on Oracle 8.1.6 and I have the driver set to JDBOCI80.DLL. Is this correct?

Patty

Re: RE: CNC Guidelines

I agree, Rather calling it rules I would call is tips and tricks and any one who uses this should have some common sense to apply these changes after throughly understanding his environment. I bevlive every installation of one world is different and some thing which work at one place may not work at another b/c of various variable involved. But I certainly did like the idea of sharing these info... with the current set of JDE techs support from JDE this will become better alternative to solve your jde issues.

I agree with most of the recommendations. The details of your comments show that you have experience and knowledge in adminstering OneWorld.

I would amend your rule about OCM, however. I would agree that developers should not be able to create '*PUBLIC' OCM mappings. But you should allow any OW user to create private OCM mappings (i.e. mappings where the System Role field is something other than "*PUBLIC".) You will seriously curtail a developer's effectiveness if you secure them out of OCM altogether.

JDE uses the above policy in-house and it works great for their considerable number of development and production environments:

1. Only admins can add/modify '*PUBLIC' OCMs
2. Any OW user may add a user-specific OCM.

Cheers.

Most of the "tricks & tips" are already in my list. Here are a few of mine:

1) Always recompress the parent package after an update package has been built.

2) We took smorrison's #1 suggestion one step further. Don't even reference "JDE" in the AS400 JDE.INI file. If somebody unsuccessfully logs on (more than trhee time) using JDE, the user profile is disabled and you are out of business.

3) Set your AS400 "system user" password to not expire. This saves a lot of time & headaches.

Up to SP20 (?) they were identical, but no, it should be '81'...

Regards,
Alexander Pastuhov

Hi Tim Allen
Can you please elaborate the point # 8.
8.Be sure to set a default printer for the WinClient host. If not, you will get lots of errors in your JDE.LOG.

Thanks

> 1. Always build packages signed into the environment the package is for.

I would amend this one to say "Always ASSEMBLE packages signed into the environment the package is for."

When building a package, you can be signed into any environment, and there are some specific performance enhancements by building a package from the deployment server, signed into DEP7333. Usually the deployment server and enterprise server are on the same switch, and the network traffic is less.

>> 1. Always build packages signed into the environment the package is for.

>I would amend this one to say "Always ASSEMBLE packages signed into the environment the package is for."

> When building a package, you can be signed into any environment, and there are some specific performance enhancements by building a package from the deployment server, signed into DEP7333. Usually the deployment server and enterprise server are on the same switch, and the network traffic is less.

Hi Kenneth,
That's a good point. Actually, I just found out that you SHOULDN'T build the package from the environment you are building the package for from the deployment server, or you'll get an error when it tries to over-write the BIN32 directory (because you would have some of the files in the BIN32 in use!) So the correct way is as you say-- 1) From the Deployment Server and 2) from DEP7333 environment.

Cheers.

Patty,

JDEwards would tell you to move to JDBOCI81.DLL but they cannot tell you why as they dont know. I would reiterate one thing.

If you do change this then you need to change the client & server jde.ini's as well as the F98611. If these are different (one is 80.dll and the other is 81.dll) it opens double the connections to Oracle i.e.
2 Connections just for logging on
2 Connections for UTB e.t.c.

We made this change a couple of months ago and things have got a little faster, but its barely noticable.

Stuart

Thats good - we have also changed the users in the server & client jde.ini's - we have four companies connecting to our database and wanted to see load via Oracle by company, and give more resources to the high revenue generators. To acheive this we changed their Oracle user in their user security profiles, their client jde.ini's to be Oracle user "2USR" for example, their server jde.ini's to connect as "2SVR" e.t.c.

Now we can tell who is hogging memory and connections in the server, and where they are coming from.

"2. Any OW user may add a user-specific OCM. "

I would disagree with that any OW User.
First of all it are users and most of them won't know what to do with that ocm stuff and might screw up a thing or 2. So only CNC people and maybe some developers may add OCM's is my point of view.

About build packages:
Either build it in the DEP7333 on the deployment server or on a fat client in the environment your building it for.

I personally make them on the deployment server, then at least that one does some work sometimes and not standing still

What difference does it make what environment you are on from a FAT client? The only time I care is when I am rebuilding GLBLTBL, otherwise I assemble, build and deploy update packages from DV7333 on my FAT client.

Tom

I used to do all builds from any environment also. But then I noticed in the Build* logs that the environment that I was building from was referenced in places I didn't think were correct. You want to make sure that the CRP specs are built into your CRP update package and PROD specs are built into your PROD update package. I'm not sure I ever experienced any problems from building a package from a different environment, but when I asked JDE about the references, they told me that a package should be built from the environment that the package is for.

Jean,
I agree that building packages in the environment they are intended for is the best way to do it on a fat client but to clarify again, on the Deployment server you must be in the deployment environment. And, if you do build packages on the Deployment server, I find that you often do not get all of the versions that may reside on your fat client.
Dave