Full Package lifespan

I'll probably take a lot of jabs for bringing this up, but I am interested in how long people run on a full package before they create a new full package. I spoke with someone at JDE the other day and she recommended every 1-2 months to build a new full package, given that we have a moderate number of update packages (one every week or two).

We've been running on our current Prototype full package since May 24, 2001 (over 8 months), and on our current Production full package since July 3, 2001 (over 6 months).

We're planning on a new full package as soon as SP18.1 comes out, but I am curious about the "lifespan" of your full packages. We're running all fat clients, so a new full package means redeploying to 150+ PC's, which is very time-consuming.

Anyway, this is partly for fun, and partly just to see if anyone else is in the same ballpark as us for package "lifespan".

Don Sauve
Wagstaff, Inc.
OW XE, Update 1, SP15.1, HP-UX 11.0, Oracle 8.1.6

Don,

we only run Partial packages on Production workstations and generally run
them on clients for 3 - 4 months before reinstalling all the clients (300
FAT via SMS and 2 Citrix servers manually takes 1 day). I generally rebuild
the Full packages and Partial packages every 3 -4 months or when 'I get
half-way through the Alphabet' - I sequentially append a letter to the
update package name (starting at PRODB733UA) when I get to 'M' it's time to
rebuild the Full & Partial. So I guess my frequency really depends on the
number of ESU's and report changes.

If I were running FULL packages (~1.3 GB) on FAT clients without a SMS I
don't think I'd ever want to reinstall 150+ machines. Actually in my
situation it would take a week or more. Do you script a silent installs for
your clients or watch the fun interactively?


Colin


B733.2 SP17.1_F1
Intel/NT/Oracle 8.1.7.1

Hi Don,

During an implementation project with heavy development (Versions, ESUs, and customizations) once or twice a months.

During normal business with HEAVY ESU'S (which is almost normal) or versions creation, once a month.

**** Note if the ESU is a big one - 30 or more objects, then automatically build a full package.

During normal business with very little ESU's or versions, once every 3 months.


I have resolved problems by simply building a full package because the package had been built 6-9 months earlier.

Adrian Valentim
Valmatrix Consulting Inc.

Don,

I follow the JDE recommendation of building a new full every 1 to 2 months for every environment. While I'm sure many other companies wait much longer and still avoid problems, I have found that this schedule works quite well for me.

Regards

Ryan Hunt
OneWorld XE; Update2; SP17.1_B1
AS400; V4R5
DS: Win2k SP2, SQL 7.0 SP3
TSE's: Win2k(SP2) & NT4.0(SP6a) with Metaframe 1.8

We build a full package about every 2 months. We build weekly updates for new UBES and minor patches. This works very well for us. Our environment is comprised of 6 FAT clients and 4 Terminal Servers.

B733.2, SP 15, Oracle 8.1.6, HP 9000
Win2K, Citrix 1.8, NFuse

Don,

I will put in another reason in support of the every 4 to 8 week full package build schedule -- to detect spec corruption. I think of the full package build as a way to give the F98741 a full health check. I have had a number of clients who have survived on update packages for many months, sometimes over a year, who then build a full package and find that they have some spec corruption or that there have been changes to the system config that cause full packages to fail.

I like to go for a full package build every month or so even if the package will not be deployed. I build them if for no other reason than to make sure the full builds still work and the specs are healthy.

Regards,



Justin Miller
Teamspot Oy
[email protected]

working with B7332 and XE on AS/400, NT, Solaris and AIX

We are currently running 65 Thick (Fat) Clients and a 7 Server Citrix Farm,
supporting 150+ users. We are still doing a lot of changes to UBEs, so we
do update packages every week. First to DV7333 then promote to PY7333 test
and then promote and build for PD7333.

Then once a month, between payroll periods we run a Full Package Build for
all three Environments. We use the Mandatory Push and stager the pushes.

When we lay down an ESU with more than 20 objects, or more than one ESU, we
build Full Packages. We save the ESU(s) for the week when Full Packages are
scheduled to be built. So far this schedule has been working out well for
us.

Joy Fernandez, JDE CNC & System Administrator
Pedernales Electric Cooperative, Inc.
830-868-5035
[email protected]

Re: RE: Full Package lifespan

Don,
We build a new full package once it starts taking over two hours to install JDE on a new PC.
First you install the full package then you install each subsequent update.
As soon as you get tired of watching little CDs rising out of a drawer while you are installing your way up the list, then you just "do the build".
We then have to deploy it to over 500+ fat clients, 3 Citrix boxes.
It works out to about every three months.
My current full build time is about 16 hours.

*JDE CNC, CMA
AS400@V4R5, Xe SP16.1 XU3/A73 CUME11, CoExist, NT4.0 (SP6a), NT4.0 Citrix, Win2k Citrix XPe
500 mixed clients

Re: RE: Full Package lifespan

Bob,

Based on your full package schedule, you may want to look into recompressing your parent package after each update. This will recreate your *.cab's based on the parent directories.

Result: You will see a lot less CD's rising out of the drawer...and a quicker install time too.

Good Luck

Ryan Hunt
OneWorld XE; Update2; SP17.1_B1
AS400; V4R5
DS: Win2k SP2, SQL 7.0 SP3
TSE's: Win2k(SP2) & NT4.0(SP6a) with Metaframe 1.8

Re: RE: Full Package lifespan

Bob,

I'll tag onto Ryan's post about recompressing your full package. We currently do NOT use compression, and so when we create update packages, the new specs are automatically included in the full package. In this way, we don't have to go through a "recompress" process, nor do we have to load all the update packages individually on new installs.

I know I have a lot to learn about compression, so could you or any other Listers explain why one should use compression? For us, all our clients are on our LAN, with ample bandwidth. Our current full package load time is about 15 minutes, which we have automated with a .bat file.

Don Sauve
Wagstaff, Inc.
OW XE, Update 1, SP15.1, HP-UX 11.0, Oracle 8.1.6

Re: RE: Full Package lifespan

Don,

I believe the only two advantages to compressing the package is reduced network traffic and faster install times for the client.

My current full production package uncompressed is about 2.03GB. Compressed, the *cab's are 240mb. The decrease in install time is not as dramatic as there is a decompression time involved with the *cab's. I believe compressed install time is about 30% less.

Regards

Ryan Hunt
OneWorld XE; Update2; SP17.1_C1
AS400; V4R5
DS: Win2k SP2, SQL 7.0 SP3
TSE's: Win2k(SP2) & NT4.0(SP6a) with Metaframe 1.8

hmmmm.....Justin, I'm glad to hear that there are others out there. I just
got bit by this on Friday. Last FULL build was Aug 6th. My tape backups only
go to November. What are some solutions for fixing the spec corruptions? We
are looking at copying PROD to CRP and doing a FULL build there and having
all the users test their stuff. Any help would be appreciated.

What is telling you that you have spec corruption? Are you getting error messages in log files or do you have applications/ube's that were working yesterday but are now misbehaving.

Are you seeing messages in package builds like?:

ERROR: Could not add record to Pack file GBRSPEC. Record:
evseq: 27, ESEVSK: 8afea32a-3068-13d2-ae66-0000f5683c6b

The error above usually relates to an "orphaned" record in the F98741 central objects table. This happens when there is an event rule record sitting in the F98741 that is no longer associated with any object. In the case of orphaned records, you can simply remove it from the F98741 using database commands and the error will go away, no harm done. In other cases (unfortunately) this record is not an orphan but is actually associated with an active object. In that case you have no choice but to try to restore the object from another path code or recreate it. Take at look at document OTM-01-0021 on the knowledge garden for more info on this problem.

If you are not getting the message above, are you getting other messages?

Before I could give good advice I would need to understand more about your situation. In most cases, only a few individual objects get corrupted. I wouldn't jump into copying PROD to CRP just yet. If it is just a few objects you may find that you can recover from another path code, or retrieve them from a FAT client that has a good copies. (There are techniques to do this even when the object is not checked out)

Give me a little more detail on the symptoms and I will try to give a better answer.

By the way, what is your system configuration (version, etc.)

Regards,


Justin Miller
Teamspot Oy
[email protected]

working with B7332 and XE on AS/400, NT, Solaris and AIX

B7332, SP17.1_E1, SQL7.0, NT4

We discovered our problem last Friday when I built an update package for
PROD with just R46171 and all of its versions (about 20 of them). After
deploying this package to the Enterprise server and to two workstations, we
realized there was a problem. Only 4 of the 20 versions worked. Any others
gave the error message:

Error: Version not available to Client

or something very close to that. JDE Support Line says we're getting that
becasue the version specs for R46171 are missing. I looked in the
PROBB733.F98761 table and sure enough, only those four versions showed up.
Even the XJDE versions were gone. Missing in DEV too. Had to copy the XJDE's
from PRIST to PROD to get those back. Will end up re-creating the individual
custom versions, but that's no big deal.

Our concern is that it may not be limited to R46171. I only found that one
because I built an update package. We wonder what else is fouled up in the
PRODB733 database.

I was able to make things work again by restoring the SPEC and BIN32
directories for PROD on ENTERPRISE from Thursday night's tape backup and by
copying the SPEC and BIN32 directories from a workstation that didn't take
the package to the two that did.

Where I am now is kind of a Limbo-Land. My R46171 is working now, but I know
as soon as I build a package (Update or Full) with it in there, it'll get
hosed again. Besides that, there'e no telling what other specs are messed
up.

Any thoughts? Guiding lights of wisdom?

KJ :

I've had the same problem. Update packages that include UBE Versions should
be built from
a developer workstation. It's curious but full packages include all
versions! (not just XJDEs).

Sebastian

What do you mean by 'Developer Workstation'?
I have the development objects on my workstation along with C++.