17 Troubleshooting

This chapter discusses:

17.1 Using the PORTTEST Checklist

If the PORTTEST program fails to run, use this checklist to diagnose the problem before calling Global Customer Support. Please have the answers to these questions as well as copies of error messages, your Enterprise Server , and any error logs, such as JDE.log or JDE_xx.log.

PORTTEST may fail if replication, security server, or transaction processing have been installed incorrectly. If problems occur after the installation of one or more of these services, check the setup of those services for incorrect parameters.

Additionally, if PORTTEST reports warnings that indicate data dictionary or company constants are invalid, it may be because the F0010 table is empty. As is true with the full JD Edwards EnterpriseOne installation, this is a normal condition in Pristine and Production environments.

General Issues Yes\No
Is the user logged on with administrator privileges?  
Is the JDENET Service starting with a network domain user?  
Is the JDENET Service account included in the local administrator group?  
Are all the environment variables set?  
Is the C compiler installed with Unicode module?  
Can you query the database on the Enterprise Server?  
Is a PostScript or PCL printer connected to this machine?  
Are the printer drivers for this printer installed?  
Is this printer configured as the default printer?  

jde.ini Issues Yes\No
Is your jde.ini located in the correct directory?  
Does your jde.ini have the correct permissions?  
Are the following jde.ini parameters set properly?  
[Network Queue Settings]

Default Printer OUTQ=your printer

 
[UBE]

If you use PostScript, is the correct filter set up?

 
[DB System Settings]

Verify all parameters, especially the following:

Default Env= your default environment

Default Pathcode = your default path code

Server = database server name

 
[JDENET]

serviceNameListen = port number

serviceNameConnect = port number

 
[INSTALL]

E910=your path

 

Communications Issues Yes\No
Do the workstations and server agree on the IP address of the server?  

Other Issues Yes\No
Were your server map tables (F98611 and F986101) edited properly?  
Run the Verify OCM application and verify:  
Do only host databases exist?  
No entries for batch applications exist.  
Are OneWorld tables accessible to the host?  
Can you query the F0902 table?  
Does PORTTEST run without error for each valid path code?  
Does the user name match that of a valid Release 9.1 account? Remember that the user name is case sensitive.  
Is the password valid for the given Release 9.1 account?  
Does the environment name match a valid Release 9.1 environment? Remember that the environment name is case sensitive.  
Does JDENET start and stop properly?  

If you answered no to any of these questions, your batch application might not run. If you answered yes to all the questions, submit a batch application now.

If your batch application does not run correctly, turn on error logging and resubmit the batch. This log helps Global Customer Support diagnose the exact problem.

17.2 Resolving Data Errors

If you are receiving data warnings against the F0010 table in the Pristine or Production environments, the table might be empty. This is how it is delivered. You can ignore these warnings, load demo data, or load your own data.

17.3 Planner Update Special Instructions

The Electronic Software Update (ESU) for the Planner Update Special Instructions was created with special features that updates the Planner pathcode on the Deployment Server. It includes all fixes for Release 9.1 installation and upgrade process.

You must run the specialInstrs.bat file to copy certain table records from the ESU database to the Planner databases on the Deployment server.

  1. On the Deployment server, browse to this directory:

    \JDEdwards\910\Planner\Package\JMxxxxxxx\Scripts

  2. Run the batch file specialInstrs.bat. Note any success or failure messages that appear in the command window.

    Review the SpecialInstrs.log file that is created in the same directory for details.

17.4 Resolving Errors Due to Lack of *ALLOBJ and *JOBCTL Authority

By default the Installation program grants *JOBCTL authority to the ONEWORLD user profile. You may have a temporary requirement to grant *ALLOBJ authority to ONEWORLD. This could be required if ONEWORLD needs to start journaling on a table but does not have OBJMGT rights to that table. For example, when submitting a UBE to the server for the first time, ONEWORLD needs to start journaling on F986111. Symptoms of this problem are errors indicating a transaction was cancelled because a commit cycle could not be start.

Of the multiple ways to grant the *ALLOBJ authority to ONEWORLD, the simplest is to give ONEWORLD rights to all tables using the SETOWAUT tool. Alternatively, you could run the GRTOBJAUT command to give ONEWORLD OBJMGT authority of to all tables in your business data, system, and server map libraries. Note that either method causes locks to be put on tables, which could interfere with other users on your system. In order to avoid that potential interference caused by locks, it may be preferable to temporarily grant *ALLOBJ authority to ONEWORLD, which you can revoke after a short while.

To grant *ALLOBJ authority, from a green screen enter the following command:

CHGUSRPRF USRPRF(ONEWORLD) SPCAUT(*ALLOBJ *JOBCTL) JOBD(*LIBL\ONEWORLD)