Making package builds go faster

Hello list,

Does anyone have any suggestions to make the package build process go faster? Ours takes anything between 12-13 hours overnight.

Thanks in advance,
Philip

are you building full package or an update package

Sorry, I should nave been more specific. We're building a FULL package on the Deployment Server in DEP7333 environment (as per JDE recommendations).

The spec and BSFN part on the DS takes about 6 hours to complete. The pack file ftp, spec and BSFN build on ES takes another 6-7 hours, which BTW runs on AS/400 V5R1M0. We're not yet live so there are very few overnight jobs running at the same time.

Hope this clears some things up.
/Philip

Have checked jde.ini for
[BSFN BUILD]
SimultaneousBuilds=5

may be this would help
NOTE : I do not any experience of AS400

Hi Sunnyind,

Thanks for that tip. As it happens the SimultaneousBuilds value to 0. Is there something else I could consider?

Thanks again,
/Philip

My builds take about the same. Sometimes even longer. I have read something in another thread on this board it may help if your JOBQ is multi-thread. I have not made this change yet. My boss is weary about a multi-thread JOBQ. "What if somebody moves a job to that JOBQ that shouldn't run there?" I have to look at lot of "what if" questions to convince him it will be worthwhile.

Tom

I have successfully implemented Multi-threaded job queues on the 400.
All you need to do is give the JDE profile on the 400 access to a
multi-threaded job queue. This will help. The other option is to
babysit the build and when it hits the 400 start moving the jobs into
other job queues and let them run simultaneous. I noticed it does cut
my build time down quite a bit otherwise I would run about the same
build time as you. Hope this helps.

Thanks.

Joanna
OW XE svc pk 20 Up 4
Co-existent
World A7.3 Cume 12X3

A multi-threaded package build queue will help you if you have the CPU capacity. If you have a 1 or 2 CPU machine and there will be other processes executing, such as UBE's, while you are compiling the business function then you probably want to leave things be. On low spec machines I tend to run my builds in a single threaded queue and then depending on current workload I move the jobs myself to other queues. (Obviously not very handy if the BSFN compile is running over night).

As far as a multi-threaded queue being inherently dangerous because someone might move jobs to it... I would say hand them a hot poker and tell them not to stick themselves with it. They will promptly stick it in their eye and then be too busy writhing in pain to moves jobs to a queue that they have no business in.

So in terms of what ifs I would say do the multi-threaded queue if:

1. You have available CPU capacity
2. You can trust people who have the access to this new queue to leave it alone.

On the AS400 you can run multiple BSFN builds at once. This can be accomplished through the use of a multithreaded job queue or simply by moving some of the submited jobs to another queue. Depending on the number of processors in your machine you can easily cut your BSFN build time by 60% or more.

Sunny,

The setting "SimultaneousBuilds=5" is actually for Windows machines not AS400. I was told by GSS in Denver that for the AS400, "SimultaneousBuilds=0" actually means unlimited. I would suggest to keep it at that.

I recently went throught the process of speeding up my build process on the AS400 myself. My builds were taking 18 hours!!! Now, they finish just a little under 8 hours... without any hardware changes. First of all, we need a little more information on your part. Where are your Central Objects located ? on the AS/400 or on the deployment server? What are the specs of your AS400? What are the specs of your deployment server. What's your network speed ? Is it switched ? Full duplex ?

Below are tips I gattered from the list (great source of knowledgable people... thanks guys) and elsewhere :

1) If Central Objects are on the AS400, activate compression on the
Central Objects datasources on the deployment server. In my case,
this saved me about 3 hours.

2) By default, for my installation anyway, builds are processed in
QBATCH, not the subsystem but the queue. All other jobs are
processed in QB7333. QBATCH is single threaded. I made mine
multi-threaded. Again, I saved about 5-6 hours doing this.

3) Fragmentation is often overlooked. Have you defragmented you
deployment server lately ? I defrag my deployement server about
2 times a month. By defragmenting my disks, I saved 1 hour.

NOTE: I am by no means an AS400 person. I am still on the deeeeep
learning curve.

Hope this helps,

Jim.

ES : AS/400 - 2 processors, 4GB RAM and 550GB disk space
Central Objects
DS : Intel - 1 x 1400 Mhz processor, 1 GB RAM, 73 GB disk space
Network: 100Mpbs Switched

Try turning off Anti-virus software on the DS (I'm guessing that you are running the build from the DS) and then running your build. Speeds things up tremedously.

Could you explain #1. Is that compression during the build or is it a
setup somewhere? Our last full build took about 20 hours, so I am
interested in making whatever changes that can be made by this weekend!

Hi Philip,

SimultaneousBuilds value must be set to 0 on the AS/400 and set to 5 on NT.

You should tell your boss that multi- threaded building queue's is the
way to go. And if you set it up in a different subsystem (other than
QBATCH), very unlikely any user would ever get anything into this queue.

Some tips from my current client site where we are averaging 2 hour full
package builds on the AS/400...

1. Deployment server and AS/400 on same switch
2. Deployment server NIC set to highest speed full duplex (not
auto-negotiate)
3. Set block size on CO ODBC's on DEPLOYMENT SERVER ONLY to 512K
4. Create multi- threaded package build queue on AS/400 (we're currently
running 3 threads) in subsystem other than QBATCH
5. NO virus protection on deployment server during build
6. Make sure logging is off on deployment server whilst building

There are some other things we're doing here on the switch itself, but
I'm sure that is very hardware and switch usage dependant, so I don't
think they would apply to a wide number of other folks.

Jim

AS/400 4 way, 8GB RAM, V5R2, OW XE SP 20 Update 6, Gigabit Ethernet
Switch between deployment and AS/400 servers

On Tue, 11 Feb 2003 05:00:02 -0800 (PST) tgore <[email protected]>
writes:

Tom

________________________________________________________________
Sign Up for Juno Platinum Internet Access Today
Only $9.95 per month!
Visit www.juno.com

Under the [BSFN BUILD] section in the server .ini use
QNAME='job queue name'.

Then you can thread that queue as much as the machine
can handle, and it is outside of production.

--- jpayne <[email protected]> wrote:
http://www.jdelist.com/ubb/showflat.php?Cat=&Board=OW&Number=49567


=====
Dan Eppich
The Anschutz Corporation
B7332 Coexistant, V4R5 w/central objects
INS Card deployment server
SP16.1
Optio DCS 6.3.2
Fat and Citrix ICA Web Client

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

Re: RE: Making package builds go faster

Libbi,

it's a setup. I'm talking about compression for the Central Objects datasources. On the deployment server, go to Control Panel, Administrative Tools, Data Sources (ODBC), System DSN, for each Central Objects datasource, click Configure, goto Performance tab and check Enable data compression. That's the compression I'm talking about.

Jim.

If your DS is a 1-CPU box it could benefit fromt the WaitForBusbuild=Y line in the DS jde.ini

RE: RE: Making package builds go faster

OH OKAY! I have already set that up from a previous call to JDE during a 20
hour build. Thanx!

Re: RE: RE: Making package builds go faster

Thanks to all for the tips... there were some excellent suggestions.
Once I've made the changes, I'll report back the results.

Havagoodweegend!
/Philip