Client full packages

Hi list

Can you settle a dispute that we're having over full and update packages.

We have a full package which we then build updates over every week or so as needed. The question is what happens when I need to install a new fat client machine. Do i just take the full package or do I also have to take each of the updates that relate to it?

I thought that as you do update packages it also updates the full package. So when you need to install that path code on a brand new machine all you have to do is apply the full package.

My colleague seems to remember the opposite of this hance the dispute.

Any efforts to avoid this detoriating into all out war will be appreciated.

Pete

All objects from the update package are merged into the full parent package. See deploy and mods manual (XeET06V1)

Hope this helps!!!

Peter :

If the original full client package isn't compressed then you can install
a brand new PC by just applying the full client package.
In that case, when you submit an update package it will alter full
client package executables, specs and sources; this way, full package is
always updated with the latest changes.

But, if the original full client package is compressed, then you'll have
to recompress it before installing it on a new machine.
In this case, update packages will alter sources, specs and executables
but NOT the .CAB files!

Sebastian Sajaroff

You're both right in a way.

When you build an update package you select a parent package. When you
re-install that parent package on a new workstation it only includes the
update packages IF the parent package was compressed. IF you didn't compress
the parent package then your update packages will not be included when you
re-install the parent package.


Colin

My understanding is all objects from the update package are merged into
the full parent package. However, if you are using package compression,
the modifications are not included in the installation because the .cab
files do not have the changes even though they are in the path code.
You have to recompress the parent package in order to pick up all the
changes.

No compression - Changes are merged so just install the Full Client.
Compression On - Changes are merged, recompress the Full Package,
install Full Client
Compression On - Changes are merged, don't recompress, Install Full
client plus any updates.

We have compression on here so clarification on using no compression
from others would be helpful.

ENT: AS400 V4R5 OW Xe SP16.1
DEP: NT 6a SQL 7 SP3
JAS: Win2000

Hi listCan you settle a dispute that we're having over full and update
packages.We have a full package which we then build updates over every
week or so as needed. The question is what happens when I need to
install a new fat client machine. Do i just take the full package or do
I also have to take each of the updates that relate to it?I thought that
as you do update packages it also updates the full package. So when you
need to install that path code on a brand new machine all you have to do
is apply the full package. My colleague seems to remember the opposite
of this hance the dispute.Any efforts to avoid this detoriating into all
out war will be appreciated. Pete
--------------------------
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=OW&Number=32806

+ - - - - - - - - - - - - - - - - - - - - - - - -+
This is the JDEList One World« / XE mailing list / forum.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found on the JDEList Forum at
http://www.JDEList.com

JDEList is not affiliated with JDEdwards«

+ - - - - - - - - - - - - - - - - - - - - - - - -+



AS400 V4R5 Coexist CO-NT Xe SP16.1
Websphere 3.5.4 on AS400 JAS SP16.1

It my understanding that, unless you compress the full package, the update
package is not included in the CAB file. You would need to first install the
full package on the fat client, then deploy the update packages to the
workstation. This is how we install (reinstall) fat clients.



Xe, SP 17.1_E1, Update 2, ES=AS/400 V5R1, CO=AS/400, Thick & Citrix Clients

Pete,

I believe I can set the issue straight for you.

When you apply an update it does update the parent specs, however, if you
are installing clients using compressed packages you must recompress the
parent before installing a parent on a "new' client workstation will get
you all updated specs. If you don't recompress the parent after installing
an update, on a "new" client you must install the parent and all subsequent
updates individually. If you are not doing compression (you should be)
then you do not need to recompress the parent or build a new full package
as you will be taking your installation directly from the parent specs.
Sounds kind of confusing doesn't it.

Let me go through the steps here using a recompressed parent to install on
a "new" client:

1. Build parent package with compression
2. Build update package(s)
3. Recompress parent
4. Install parent on "new" client (will include all update package
specs)

Scenario without recompressing parent for "new" client:

1. Build parent package with compression
2. Build update package(s)
3. Don't recompress parent
4. Install parent on "new" client
5. Install each(all) update package(s) since parent was built

One last scenario which would be used when not compressing your parent when
built (always a good idea to compress the parent as it speeds up the
install process):

1. Build parent package without compression
2. Build update package(s)
3. Install parent on "new" client

Hope this keeps the fists from flying.

James A. Wilson
Technical - CNC

Peter,

when you install a full package you install from the compressed CAB
files. Update packages update the parent package´s spec and bin32
folders. You need to recompress these folders to actually include the
changes in your full package.
To achieve this you may rerun the package build, checking the compress
option only. Or you can use system/bin32/JdeCompress.exe .

Hope this helped. Gerd

That depends upon if you are compressing/re-compressing your packages. An update package will update the non-compressed portion of your parent package when it is built. However if you do not choose the re-compress option it will not update the .cab files. The .cab files are where the full client installation comes from (unless you aren't compressing at all then it installs from the real files).

If you choose to re-compress during your update package build then it will take longer (has to recreate the .cab files) but you will not have to apply the individual updates to fresh client installs. However you then have no fallback if your update package objects are bad or have an error short of restoring the full package directories from a backup. Or going back to an old package you haven't deleted yet.

HTH
Jeff

Hi Pete

You are both right so you can put the weapons away now. I think I understand how your dispute came about. The update package does update the Parent package but not fully. Let me explain further:
An update package updates the folders of the full (parent) package, but does not update the .CABs of the full package. Therefore, the Full Package folders contains the latest specs, but the associated .CABs do not. The CABs are used by the client install process (unless compression is turned off) which means the client does not get the specs updated by the Update Package.

At our site, a full Client Package takes 40hrs, so we build update packages, and then run a Full Package build (configured to compress only). Periodically, we run a Full package build that will build everything.

Let me know if I can help further.

Kind regards
Terry

Colin,

You said:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

You're both right in a way.

When you build an update package you select a parent package. When you
re-install that parent package on a new workstation it only includes the
update packages IF the parent package was compressed. IF you didn't
compress
the parent package then your update packages will not be included when you
re-install the parent package.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I would only have the following to comment on. Where you mentioned that
"it only includes the update packages IF the parent package was
compressed", I believe you wanted to say re-compressed. A parent package
will not contain subsequent update package updates unless it is
re-compressed.

This can be very confusing to someone that is relatively new to this
process that is the only reason I wanted to clarify. I am not being
critical for critical's sake.

FWIW


James A. Wilson
Technical - CNC





To: James A. Wilson@ANDERSEN WO
cc:
[email protected] Date: 04/17/2002 09:09 AM
Sent by: Subject: RE: Client full packages
[email protected]


Message Mailed On Behalf Of ---> [email protected]


Please respond to jdelist








You're both right in a way.

When you build an update package you select a parent package. When you
re-install that parent package on a new workstation it only includes the
update packages IF the parent package was compressed. IF you didn't
compress
the parent package then your update packages will not be included when you
re-install the parent package.


Colin
--------------------------

Terry,

Does the 40 hours to build a full client package bother you? Why does it
take 40 hours? What does your OW environment look like (ES, clients,
etc.)?

Just curious.

James A. Wilson
Technical - CNC

James,

You made the comment, "If you are not doing compression (you should be)...", but offered no explanation. We stopped using compression when we upgraded to B7332. The world has been a whole lot easier since. We are constantly creating and deploying update packages. Critical ESUs and our own internal development don't give us any other choice. Could you please explain to everyone why we should be using compression?

Terry,

You stated that a full package build takes you 40 hours. We are not an AS/400 shop so my comments may be irrelevant. Our full package builds, Client and Server combined, take approximately 5½ hours. We do not compress our packages. This saves some time but certainly does not account for the huge time difference. Do you have any idea why your builds take so long?

Hi Ray,

The only use of package compression is for faster client deployment. I did the test. Without compression, client installation took 45 minutes per client and with compression, 20 minutes. This test was done with B733.2.

Hi James

Thanks for the interest. Our OW system is pretty slow in general, although full package builds is where we notice it the most (it used to take 7 days until we changed an ODBC setting).

We have a 170 AS400 with 512mb of memory, but a dual-processor Deployment Server with 512mb. I believe our AS400 is the bottle-neck but since we don't generally run server-side jobs and 99% of our OW workload is development, the performance isn't a big deal. I've seen other companies with worse interactive performance than us. It hasn't become a big enough issue for us to get serious about solving it yet.

If you do have any performance improving suggestions (short of upgrading hardware), I would appreciate the input.

Thanks
Terry

Adrian,

I'm sure there is a time difference between compressed and uncompressed packages but I have never had a full package take anywhere near 45 minutes to install. However, one big advantage is that when you install an uncompressed full package, you are done. You don't have to redeploy and install numerous small update packages. Having to do this would probably increase your total install time to more than 45 minutes. Additionally, the necessity of keeping track of the packages you created after the last full package build is completely eliminated.

Hello Terry,

...just being curious over here. You mentioned that don't generally run server side jobs and that 99% of your OneWorld workload is development. Is your company on the smaller side? Are your needs for OneWorld extremely specialized?

Also, with regard to your package build. Is there any particular part of it that takes the greatest amount of time? This may help pin point where re-conifguration will be helpful.

Good luck

We did an uncompressed package once because our guy forgot to check the box during the full package build. Our installation time went from 10 minutes per client to about 30. So there definitely is a difference.

As for not having to redeploy packages being a benefit of uncompressed full packages; if you choose the recompress option on your update builds then you still have this benefit as it gets added into your full package .cab files for new/re installations. The time savings depends upon how many fat clients you have v/s how long it takes to recompress the .cabs with every update package. For us 20 minutes extra per client (~40) is more costly than the extra 45 minutes it takes to recompress with every update package.

Now that being said we don't do very many re-deployments and so we have quit doing the re-compress because it was costing us more time than the very rare redeployment that we have to do.

HTH
Jeff

We compress our packages as we have space issues on the Deployment box. How
do you re-compress the full packages? Do you have to re-build?

Thanks,

Crawford

7332 SP11.1, NT, SQL7

Terry,

Are your Central Objects on the Enterprise Server or on the Deployment
Server? Are you using DB2/400, UDB or Oracle? Do you have a LARGE number
of modifications in your system? What does your network infrastructure
consist of? How is the hardware in your Deployment Server configured (swap
files, RAID, etc..).

It sounds like things would be extremely painful around there is someone
was looking to have a "change" put into production.

Let me know the answers to the above questions and I will see what I can do
to help.

Thanks,
James A. Wilson
Technical - CNC





To: James A. Wilson@ANDERSEN WO
cc:
[email protected] Date: 04/17/2002 11:34 AM
Sent by: Subject: Re: Client full packages
[email protected]


Message Mailed On Behalf Of ---> [email protected]


Please respond to jdelist








Hi James

Thanks for the interest. Our OW system is pretty slow in general, although
full package builds is where we notice it the most (it used to take 7 days
until we changed an ODBC setting).

We have a 170 AS400 with 512mb of memory, but a dual-processor Deployment
Server with 512mb. I believe our AS400 is the bottle-neck but since we
don't generally run server-side jobs and 99% of our OW workload is
development, the performance isn't a big deal. I've seen other companies
with worse interactive performance than us. It hasn't become a big enough
issue for us to get serious about solving it yet.

If you do have any performance improving suggestions (short of upgrading
hardware), I would appreciate the input.

Thanks
Terry
--------------------------
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=OW&Number=32867
+ - - - - - - - - - - - - - - - - - - - - - - - -+
This is the JDEList One World® / XE mailing list / forum.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found on the JDEList Forum at
http://www.JDEList.com

JDEList is not affiliated with JDEdwards®

+ - - - - - - - - - - - - - - - - - - - - - - - -+