AS400 - Build Package

[arrabbiato]
Hi,
I have just installed EnterpriseOne 8.9 SP2 OneOff G1 on AS400 Platform. I tried to build a client full package. IT'S VERY VERY SLOW, after 14 hours it had built a few spec files (for example FDASPEC 10 hours). I have rebuilt indexes on all Central Object tables and I restart built but nothing is changed.
Please help me!!!
Thanks in advance
Gigi

Configuration
AS400 V5R2 - Model 825 - EnterpriseOne 8.9 SP2 OneOff G1
Cum C3252520 + SF99519
AS400 Client Access SI09809
DB2 SF99502 Level 11
Client Iseries Access SI10914

Deployment Server Windows 2003 - EnterpriseOne 8.9 SP2 OneOff G1

My client full package build on EO89 was equally slow compared to an ERP8
client full package build on exactly the same kit



Andy Smith
Whitehouse Consultants
Win2K SQLServer7 Xe

Gigi,
Here's one thing that may help. The upgrade manual discusses creating a custom QAQQINI file in QUSRSYS and adding the following parameter:
LOB_LOCATOR_THRESHOLD 10000
Without the parameter, OS/400 will allow up to 250,000 open LOB locators. With the parameter OS/400 will free up the locators and the associated memory for the lob data when the threshold is reached.

Clark Scholten

Thanks Clark,
but I've already setted this parameter. other ideas?
Gigi

Buon giorno Gigi,

Silly question, but do you have virus scan running on your deployment server, or where ever it is that you are building your client package? If so, have you set it to NOT scan CAB files? I seem to remember going through that pain a few years ago when I first brought up my deployment server.

Abbia un giorno piacevole.

Gregg Larkin
Praxair, Inc.
North American PeopleSoft
Enterprise One System Administrator

Buongiorno Greg,
No I haven't active antivirus on deployment server
Thanks Gigi

Gigi,

What sort of spec is your Deployment Server (memory, CPU etc.). What sort of LAN connection does it have?

Best Regards,

Sanjeev

Our deployment configuration is

Windows 2003 , 2 CPU 2.8 GHz , 2 G of RAM
ISeries Acces - same PTF level of AS400 ISeries Access
Disk on EMC2 Symmetrics

Also AS400 disks are on EMC2 Symmetrics. AS400 arcitecture is:
One AS400 Model 825 with 3 CPU, 8 G of RAM divided in 3 Partition

First Partition - DB2 and PeopleSoft services
2 CPU allocated
6,5 G of RAM
CPW Interative 0
CPW Batch 1800

Second Partition - PeopleSoft services
0,8 CPU allocated
1 G of RAM

Third Partition - Backup
0,2 CPU allocated
0,5 G of RAM

Thanks gigi

So this is the client build that is slow, not the server package build?

Are the Central Objects on the As/400? If so, can you run the DBMON against it and see if any new indices need to be built?

Gigi, can you post the buildError.txt of your slow build?

One dumb question: Debug isn´t turned on for your build machine?

Gerd

Re: RE: AS400 - Build Package

Andy,
How many times to build your package?

yes jdedebug is turned off
Attach builderror of one stopped package
Gigi

Gigi, we have EO8.9 as well with almost identical hardware setup, same AS400 machine. Our packages run in 6 hours for the client part and another 3.5 hours for the server part.
It should not E8.9 specific. Something must be wrong with your setup.
I noticed that your DS copied the source and include directories in less then one minute each. That´s fast. It seems to get slow when your DS retrieves data from your AS. Could it be something with the ODBC connections?
Have you tried another pathcode yet?
Gerd

Have you checked your ODBC setup. Make sure they are set correctly. At one
client we change the ODBC and gained 8 hours on a package build

Gerd, you are correct
I tried to change ODBC parameter like Lob Limits to 16000, record to 512, but it didn't change performance.
Which are your Connecting and ODB configuration?
Gigi

Gigi,
our client access driver is 9.00.06.00. We have data compression on, 512k record block size, large objects threshhold 32k.
My local AS400 guru is telling me that you should make sure to apply the latest client access PTFs . (Thats what those AS400 guys always say.)

Gerd

About AS400 PTF we are OK. OUR client Access ODBC driver are same of yours. Only diversity is Large objects threshold parameter where we have setted 16M. I'll try to change this value.
Thanks
Gigi

Just a thought but have you checked to ensure that the NIC in the iseries is
set too 100MB and full (not half) duplex?

Also, you can do a "5 work with job" on the Qdzaonit ODBC that is in
question while the build is running then a 10 to work with joblog and see
(while the job is active) if there are any obvious issues! A while I had a
client in Western Canada where my ASU kept "hanging" and by working with the
Qzdaonit that was "touching" Central Objects I was able to determine that
there was a memory leak. IBM created a PTF for this and that fixed our
issue.

Not saying you have the same issue but you might find something interesting
if you look!

Michael

Hi Gigi, two thoughts both of which you've probably already looked but just in case.

One, have you checked to ensure that the NIC in the iseries is set too 100MB and full (not half) duplex?

Also, you can do a "5 work with job" on the Qdzaonit ODBC that is "touching Central Objects" while the build is running then a 10 to work with joblog (while the job is active) if there are any issues!

A while I had a client in Western Canada where my ASU kept "hanging" and by working with the Qzdaonit that was "touching" Central Objects I was able to determine that there was a memory leak. IBM created a PTF for this and that fixed our issue.

Might find something if you haven't already looked!

Michael in Toronto!

Gigi,

What about the connectivity between your Deployment Server and AS/400? Is it capable of full duplex? If so, is your AS/400 and Deployment Server explicitly set to xxxMbps full duplex mode (not auto configuration/negotiation)?

Best Regards,

Sanjeev