C.O. access errors during full package build

gerd_renz3

VIP Member
Hi List,
I´ve got a strange problem and need some expert help. Here´s our setup:

Our PD AS400 server (batch and database) is located in a datacenter, along with the deployment server. Our DV,PY AS400 server (batch and database) is located in my client's office, connected at 1Gb with the datacenter.
Our problem is that DV and PY full packages have errors in them most of the time. The errors show like this in the deployment server's jde.log:

780/1784 Mon Mar 14 16:56:39.500 ODBC_P1.C1942
ODB0000163 - wSQLGetData failure. rc=-1

780/1784 Mon Mar 14 16:56:39.500 ODBC_P1.C1942
ODB0000164 - STMT:00 [HY000][19185] [IBM][iSeries Access ODBC Driver][DB2 UDB]PWS0001 - Function did not complete successfully.

780/1784 Mon Mar 14 16:56:39.500 ODBC_P1.C2016
ODB0000096 - SQLGetData failed. Table F98741, column ESEVSPEC, ODBC DSN Central Objects - PY9.

780/1784 Mon Mar 14 16:56:39.500 jdb_drvm.c1002
JDB9900172 - Failed to execute db fetch

The result is that some NERs get build incomplete and the subsequent compilations error out. When we build update packages with the involved NERs immedeately afterwards, that update packge builds the NERS without errors. When we build PD packages on the same DS (DS and database are in the same datacenter) the build always is ok.

So we think that the problem somehow has to do with the 1GB link. But how, what is wrong? Sometimes the build goes through ok, so there should be no problem with the database (F98741?) itself. What can I do (short of changing the infrastructure) to make it work each time I build a full package? I have the feeling that there may be something wrong with some ODBC settings. Something else we noticed is that when we test full client packages they seem to go through, when we try client/server packages they error out. In other words, when the DS has to build the .pak files as well it may get overburdend. Does that make sense? When we use a WS as a build machine (NOT located in the datacenter) it always builds ok. Our DS is quite strong, W2K, 2x2.8 GHz, 2GB memory, sufficient disk space.

Can anybody help? Thanks in advance, Gerd

We are on E8.9_3, AS400, Central Objects on the AS.
 
I had a similar problem a while back with the F98741 and an AS400.

First question, are you running your package build from the depserver or a workstation? (the dynamics of the network access may be different for each of these scenarios). Whichever you are doing you could try building from the alternative.

The way we addressed this problem in the past is we bumped up the JDENETTimeout (located under the [NETWORK QUEUE SETTINGS key) on the machine that performs the package build. So if you build from a workstation, increase that workstations JDENETTimeout to say 180. Likewise if you build from the Dep server, increase its JDENETTimeout to 180.

Another possibility is the way the ODBC is set up for the F98741.

Cheers,
 
Chris,
thanks for your answer.
We already have 300 for that timeout on our DS (that´s where we build the packages).
What advice could you give me for the ODBC settings?

When we build from a WS (which always works) the build machine and the AS400 server with the COs are in the same LAN. When we build on the DS (problem), they are connected via a 1GB link. So yes, the scenarios are different.

Thanks, Gerd
 
Gerd,

What's strange about the problem you are describing is that the NER generation happens before the .pak file generation. Also, the NER generation occurs for both client and server packages builds (if you build from scratch.) So if you are seeing the errors that you posted, this is occurring during the client portion of the package build (during busbuild.)

Do you always regenerate NER on package builds? Do you run busbuild in parallel with the package build?

If you build a client-only package and you say that works reliably, then the NER will be generated. If you then subsequently build the server package, does this fail? If it does, it won't fail the way you showed, because by that time the NER is already built. So something else must be going on.

NER generation can fail if Data Dictionary items are wrong. What environment do you build on your DS (DEPXXXX?) Is JITI turned on for this environment? It is possible that the NER generation is trying to JITI or fails to JITI certain DD items. Does PD have a different DD from DV and PY? If the two DDs are not in sync, this can break the NER generation.

You could also try these ODBC modifications on your CO datasource...

1. On the "Packages Tab" disable dynamic package support
2. On the "Performance Tab" select "Enable pre-fetch of data for queries"

Also, can you determine if packets are getting dropped on the network...

Cheers,

Chris
 
Hi Chris,
lot of questions, let me try to answer.

We have been building full packages on the DS. We have been building always client and server packages.

For testing reasons only we have been building client only packages, and that´s where we found that the error seems to be occuring only when we build client and server together.
The error happens around an hour into the build, with some (few) N15* and N17* NERs, that is during the client portion of the build. The generated .c code (file) ends abruptly and the compilations errors out due to that.
Yes, we always re-generate NERs (should we not?). BUSBUILD runs in parallel with the spec build. We are now testing if the error occurs when it runs afterwards. We´ll know in a few hours.
I have been thinking about DD errors. We have one DD for DV and PY, another one for PD and HO (which a custom environment/pathcode). It happens in HO as well as PY, that is for two different DDs. But it does not happen for PD, which has the same DD as HO. In other words, it shouldn´t be the DD. I also would get DD-item errors in the building machine´s jde.log, which is not the case.

After our currently runnning test I will try to change the ODBC settings as you suggest. Problem is that each test takes a few hours ...

Thanks for your interest in this case.

Cheers, Gerd
 
Ok, the test went through.
This is what we know so far:

client only package with BUSBUILD in parallel is ok;
client/server package with WAITFORBUSBUILD=Y is ok;
client/server package with BUSBUILD in parallel errors out.

We will still have to test the 3rd option with changed ODBC settings.

Thanks, Gerd
 
Chris,

I applied the ODBC changes you suggested and
1. the package seems to be building faster
2. the errors seem to not occur any more.

Great! However, I found in a JDE document

TUNING RECOMMENDATIONS "J.D. Edwards OneWorld on the IBM AS/400", Last Updated: April 28, 2000

this recommendation:

*Enable Prefetch on Execute – Not Selected
Note – This is a change from previous recommendations (including the J.D. Edwards
OneWorld Implementation for AS/400 Redbook) to prevent possible application problems.
OneWorld is not designed to use the prefetch option.


I do not have the knowledge about ODBC to decide myself if I can or cannot check the "Prefetch" feature. Could anybody please comment on this. I would need this only for the Central Objects datasources and only on the DS.

Thanks, Gerd
 
Because the Package build is a one-way data read, the pre-fetch should be OK.

I could see that perhaps turning this on for normal OW activity (which may require transaction processing and updates) could cause issues. As you observed, you would only make this change to your Dep Server Central Objects ODBC, so you should be good.

By how much did the package build performance improve for you?

Cheers,

Chris
 
Thanks Chris.
We did some more testing and cannot build packages without the ODBC changes you suggested. So we´ll keep them.
That about the performance was an overly hasty and optimistic statement. I take it back. In the end the package did not really complete much faster.

Thanks, Gerd
 
Back
Top