AS400 JDEKrnl.ddb File Corrupted

Hi All, is anyone experienced JDEKrnl.ddb file corrupted in AS400?

May I know:-
1. What are the possibilities this file can be corrupted
2. How to prevent it

Thank you.

Yes, we have corrupted ours. How we managed to do it was by changing a 'kernel' dd item in a W environment. Any tables that are used by kernel processes have what we have now classified as 'special' dd items. Ie security tables, ocms, etc. Using the W environment for P92001 was NOT a good plan as it executed the bsfns on the 400 and totally corrupted the kernel tam files. Thankfully we still had the temp lib from the last SP to copy them back from.
It has not happened since.
We have had issues with other tam files and backups. We have had to move the spec directory out of our regular nightly backups because 'save while active' does not seem to work if some process (UBE or BSFN) is trying to use the tam file while it is being backed up. The UBE fails and as a bonus corrupts the tam files.

Hope this helps.

Sue

Xe SP22Q1 iSeries V5R2 coexistent

If you are referring to the jdekrnl.ddb and jdekrnl.xdb in the IFS, you can simply copy them to your deployment server or a workstation (use Operations Navigator or ftp). If they become corrupted, restore them the same way you copied them.

Another way to corrupt them that I have seen is to submit R98CRTGL to the 400.

Thank for your valueable informations. May I know your W environment is it referred to Windows environment and if it is, what OS?

Thank you.

This is how you restore krnlspec on the 400. Log in as OneWorld and make sure it has allobj and jobctl.

From the command line:

call krnlspec parm(jde jde dv7333) Assuming jde has the pw jde. If not use the right password. You can run this for any release.

I'm responding to a 2004 post, but wanted to add my two cents for history's sake.

We corrupted our JDEKRNL.DDB and JDEKRNL.XDB files in the iSeries IFS when we errantly submitted R98403/XJDE0019 to the default location instead of changing it to LOCAL. The job *appeared* to run and then displayed a PDF report saying it completed the task successfully. Within ten minutes we had calls from all over the company asking why their jobs were at a Waiting status; we looked at QBATCH and found nothing running. Also, none of the regularly-used job queues had anything in them. The JDE.LOG showed no useful error messages.

Because this had also happened last Fall, we already had our JDEKRNL.DDB and JDEKRNL.XDB files backed up on a network drive. (Originally, I had to extract the files from the original SP 15.1 CD! I don't remember the exact process or commands to do this, but I could dig them back up in a pinch.) We restored them and restarted the OneWorld services and everything was fine.

Should anyone else encounter such uglies, here are the steps I used to fix:

***It would be wise to make a backup of these files RIGHT NOW, so you can easily restore them later. See step 3 for the path.

Notify users that the OneWorld system is being shut down for 15 minutes.

End the OneWorld services on the iSeries server.

Copy JDEKRNL.DDB and JDEKRNL.XDB to /b7333sys on the iSeries server:
- Run and log into AS/400 Operations Navigator
- Navigate to YourServerName > File Systems > Integrated File System > Root, then click on B733xSYS to display its contents.
- Note that JDEKRNL.DDB is 0 KB.
- Drag into this window the replacement files from your backup folder.

Start OneWorld services and test.

Notify your users, and rest.



P.S. When I originally reported the problem to JDE/PeopleSoft/Oracle support, they denied that accidentally submitting a job to the server when it should have been LOCAL would corrupt these files. Regardless, here is a link to the knowledge article they provided me during the mess:

http://customer.peoplesoft.com/CPPRD/psft/V78994767/oti-01-0096.htm