Package Build problem in Multiple Foundation Environment

jean_driscoll

jean_driscoll

VIP Member
I am working in a multiple foundation environment, DV7333 PY7333 are Service pack 17.1_E2, PD7333 is still at Service Pack 15. I have had this configuration since Dec 5th. The full parent packages in the DV7333 PY7333 environments were originally built on Service Pack 15. I have been successfully building update packages using the SP 17.1 foundation, against these parent packages since December. Now I'm having a problem building an update package, doing it the same way that I have been building them since December. When I called JDE about the problem, their solution is that I should not have been building update packages with 17.1 against a full package built in SP15. I never read that in the Multiple Foundations documentation. Has anybody else tried this or heard this story?

Jean Driscoll
AS/400 Co-existent Xe SP15+17.1, Update 1/A73Cum12
 
all your logic for the package build is in the system directory, what will happen when you try to build a Package with system for SP17 when you are at SP15 for the build. That was the question I sent to JDE. I got no response. I tried it my way: using the backup directories which I had created. I am switching between these diffrents SP levels to make sure that the objects for SP17 are build with system SP17 and objects which are build for e.g. SP15 are build with system SP15. You only have to make sure that nobody will install a new client during the package build...

bernd
AS/400 V5R1 OW Xe SP17.1
Win2000Adv. Oracle 8.1.7 SP17.1/SP16/SP16.1
 
Referencing another thread, this is a subject for "Best Practices".

My humble opinion is that you should ALWAYS build a new full package whenever you change Service Pack Levels.

Regards,

Larry Jones
[email protected]
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials
 
I haven't followed the entire thread - so I apologize if I walk on
someone...

A fairly sound recommendation would be to build a full package whenever the
number of updates become unmanageable, when there is some form of corruption
or after updates, ESUs or Service Packs.

Remembering, that an installation of JDE to a client must be followed by
each update... to avoid fragmentation - it might be a fairly good practice
to limit the number of updates (great fragmentors) and do more frequent full
builds.



Daniel Bohner
[email protected]
www.existinglight.net
JDE - XE & AS/400
JDE - B7331 & MS SQL 7x
 
The multiple foundations guide tells you to build packages for the new
service pack at a workstation that has been updated to the new service pack.
Switching out the System (+Systemcomp, OneWorld Client Install) directories
on the deployment server should also work, as long as you can keep track.



Jean Driscoll
AS/400 Co-existent Xe SP15+17.1, Update 1/A73Cum12
 
I agree, for Best Practices you should always build a new full package. But
time and resources sometimes rule that you go with what you have. The
documentation for Multiple Foundations has you build an update package with
the new Foundation and use this update package to update the foundation of
clients. It never mentions that you have to build a new full package. I
was just wondering what other people were doing.



Jean Driscoll
AS/400 Co-existent Xe SP15+17.1, Update 1/A73Cum12
 
I understand Good practices and appreciate your advice. Unfortunately I
manage 150 fat clients, with help from 3 pc techs in an emergency. Until I
can talk management into TSE or HTML clients, I'm working way overtime to
keep up. Therefore, I keep the number of full package builds to a minimum,
and send updates only to those users that require them. I will build full
packages for the production implementation, but there was never mention of
the requirement of having a full package built in the Multiple Foundations
paper.



Jean Driscoll
AS/400 Co-existent Xe SP15+17.1, Update 1/A73Cum12
 
Back
Top