CNC Issue with AS/400 LPARs

[Bill Dotson]

We are attempting to configure a new iSeries 520 with 2 LPARs, one for PD7333 and the other for all other environments. When trying to promote an object to PD7333 through OMW, we get the message "General error in method" and the JDE.LOG shows the following:
1388/1068 Thu Feb 17 10:52:35 2005 JDBODBC.C2148 ODB0000183 - SQLExecute failed

1388/1068 Thu Feb 17 10:52:35 2005 JDBODBC.C2148 [IBM][Client Access Express ODBC Driver (32-bit)][DB2/400 SQL]SQL7008 - F98762 in COPD7333 not valid for operation. - SQLSTATE: S1000

1388/1068 Thu Feb 17 10:52:35 2005 jdb_drvm.c938 JDB9900401 - Failed to execute db request

1388/1068 Thu Feb 17 10:52:35 2005 jdb_exet.c5224 JDB3400009 - Failed to perform Insert for F98762

We plan to put this system into production in 2 weeks, so this problem is urgent. I have verified that the table F98762 is journaled, yet we get the SQL7008 error.

Has anyone else configured an AS/400 in this way? Did you have any problems such as this? Any help will be forever appreciated.

 

[sashton]

Hi Bilby, we have our AS/400 confgiured almost exactly like this. We have two partitions, JDETEST and JDEPROD. DV and PY paths reside on Test and QA and PD paths reside on PROD. Let me look into your issue a little more and see if I can tell what your problem is.

 

[sashton]

Standard default OneWorld doesn't recongize multiple partition so be sure to verify that your ODBC connection is pointing to the prod side and not the test side of your 400.

 

[Bill Dotson]

I have verified the ODBC data sources point to the correct partitions. The problem seems to be related to Central Objects PD7333 tables, but for the life of me I can't figure it out. PSFT isn't much help so far, but they're still working on it (in India, I think).

 

[JDEPrincess]

In most scenarios, this type of error is related to journaling. However, you stated that is not an issue here.

The best way to tell for sure what the issue is to look at the 400 joblog and retrieve the message details for error SQL7008. This will specify the reason code for the failure. As there are 14 possible reason codes for the error, there are at least that many possible resolutions.

 

[Bill Dotson]

Perhaps I've stumbled on something here. Should I be able to run porttest on one LPAR, using an environment on the other LPAR? Shouldn't these two things be able to talk to each other?

 

[kastanek]

Are your JDE.INI files on all LPAR's all configured to use the same
Listening port?? (6011 or whatever you are using)






Bilby
<bdotson@crownpac
k.com> To
Sent by: [email protected]
jdelist-bounces@j cc
delist.com
Subject
Re: CNC Issue with AS/400 LPARs
02/18/2005 11:30
AM


Please respond to
JD Edwards®
EnterpriseOne






Perhaps I've stumbled on something here. Should I be able to run porttest
on one LPAR, using an environment on the other LPAR? Shouldn't these two
things be able to talk to each other?


OneWorld XE SP18.1 AS/400 V5R1 Enterprise Windows 2000/Citrix

 

[Bill Dotson]

Yes, they use the same port (6009).

 

[SSAJAROFF]

Hi,

Check that the table is journalized on the AS/400 and that Commit Mode (on the client Side =3D Control Panel - ODBC - <Your Data Source> - ODBC Settings -
Servers tab - Advanced Button) for that ODBC DS is set to *NONE.I had the same problem on LPAR V5R3M0.

Regards, Sebastian Sajaroff

 

[jjarnot]

Some items for you....
-Are you trying to set-up both LPARs with their own foundation? If so, you may want to review some of the papers for setting up a logic server. I pasted some text below from a PSFT KG article that notes where to go and what to do.

If you plan on having two 'enterprise servers' each with their own foundation on each box. You may have two foundations running JDENEt_Ks but you'll only have one SYS7333 OL7333 and some others on the Enterprise Server. (Boy, it's been awhile since I did this).

Here is a PSFT tip
200814403 SETUP AN AS/400 DATA SERVER TO AS/400 ENT SERVER - A: A>
Client did not add the AS/400 data server to the existing OneWorld configuration - using the Add on Server Plan. See the OneWorld Installation Guide for adding a server to an existing configuration (12-41). Once you have completed this, make sure that the datasources that will be accessing this server have be modified with the new server name and that it is using the DBDR to connect AS/400 to AS/400, this includes both within OneWorld and within the ODBC datasources that reside on all FAT clients,

I think there is a concept called JDBNET DLL that will need to be inplace between the two devices vial the Logical DataSources. At least in mine there is a type 'A' LDS with the JDBNET.DLL type.
Also- I think there is the part you need in the JDE.INI? anyone remember if you do or not?


Did you setup the LPAR w/ a new install plan? Also check the P9654a app. There is a environemnts 'Form exit' that you need to set what env. for what Ent/Logic server. Just like multi-foundation.

anyway, just some thoughts and maybe a lead or two for ya.
JJout





Do you have both LPARs listed in the P9654A app, and are all the enviroments (from the form exit) setup to run on the right server.

 

[Bill Dotson]

Regarding the journaling problem, thanks to all who posted suggestions (all of which I tried). I was finally able to resolve the problem, and here's my theory and solution, just in case this weird problem should come up in your world:

Since the JDEDEBUG logs indicated that DELETE worked on F98762 but INSERT did not, I began to wonder if there was somehow a mismatch between F98762 and its associated logical files. Seems like DELETE would work because if the record didn't exist in the logical file, then there was no problem (no harm, no foul). However, INSERT would fail when attempting to update one of the mismatched logicals, since all of those are update *IMMED (if my theory is correct). How the physical file and logical files got mismatched is another question.

To fix:

1. Create a SAVF and save F98762 and its indexes (this is just a precaution, in case my theory is full of holes) in COPD7333.
2. Make a copy of COPD7333/F98762 in a different library.
3. Delete F98762 indexes and then F98762 physical file from COPD7333.
4. Restore F98762 and indexes from a known working environment (DV7333, in my case). Restore them to COPD7333.
5. Using interactive SQL, delete all of the records from the restored F98762.
6. Use interactive SQL, insert all of the records from the F98762 copy (from step 2) into the restored F98762.

Voila, the problem is gone!

I still have a small problem, though. Jobs submitted on our test LPAR don't show up in Work Submitted Jobs on the production LPAR. I thought this worked correctly before, but now it's hosed up somehow. I'm not sure if this is an incorrect data source (from the perspective of the test LPAR) or a missing OCM mapping.

Again, thanks to everyone for your help!