No downtime, middle of the day full serialized objects generation.
When CNC admins have time to sleep they dream of getting more sleep. They imagine that there is the possibility of performing administrative tasks at some time of the day other than during The Maintenance Window.
Again, the concept is that *PUBLIC will be using one set of serialized objects tables while EGEN will be using another set during the generation. When the full gen is done, you will have a completely populated set of serialized objects tables waiting to be used while the other set continued to be used during the full generation. An OCM swap and a cache flush will put the newly generated tables into use without interrupting users.Generating a full set of serialized objects is not as critical as it was prior to Dynamic Web Generation and Auto Package Discovery, both introduced in the 8.96/8.12 release, but if you are on a Tools Release prior to 8.96 or simply wish to generate a full set of serialized objects without disrupting your users or possibly your social life, try using two sets of the serialized objects tables (F989998/F989999).
The concept is that *PUBLIC will be using one set of serialized objects tables while an EGEN user will be using another set during the full generation.
Setup
Create an E1 user EGEN with associated security record, role membership, etc. Ensure the EGEN user has access to the J* environments.
Using OMW, generate the F989998 and F989999 serialized objects tables in the Business Data datasource for each environment.
Create copies of System OCM's for F989998 and F989999 for all J* environments so that you have OCM's for both tables for both Central Objects and Business Data for both *PUBLIC and EGEN, one active and one inactive.
The easiest way to get the OCM's copied correctly is to copy the existing F989998 and F989999 OCM for Central Objects, changing the Data Source to Business Data and the System Role to EGEN during the copy and then make those OCM's active. Then copy all J* environment F989998/F989999 OCM's, changing only the System Role from *PUBLIC to EGEN or from EGEN to *PUBLIC during the copy. This step will create the proper inactive OCM's.
You should end up with something that looks like this:
Environment | Object Name | Object Type | Primary Data Source | System Role | Object Status |
JDV812 | F989998 | TBLE | Central Objects - DV812 | EGEN | NA |
JDV812 | F989998 | TBLE | Business Data - TEST | *PUBLIC | NA |
JDV812 | F989998 | TBLE | Business Data - TEST | EGEN | AV |
JDV812 | F989998 | TBLE | Central Objects - DV812 | *PUBLIC | AV |
JDV812 | F989999 | TBLE | Business Data - TEST | EGEN | AV |
JDV812 | F989999 | TBLE | Central Objects - DV812 | *PUBLIC | AV |
JDV812 | F989999 | TBLE | Central Objects - DV812 | EGEN | NA |
JDV812 | F989999 | TBLE | Business Data - TEST | *PUBLIC | NA |
JPD812 | F989998 | TBLE | Central Objects - PD812 | EGEN | NA |
JPD812 | F989998 | TBLE | Central Objects - PD812 | *PUBLIC | AV |
JPD812 | F989998 | TBLE | Business Data - PROD | EGEN | AV |
JPD812 | F989998 | TBLE | Business Data - PROD | *PUBLIC | NA |
JPD812 | F989999 | TBLE | Business Data - PROD | EGEN | AV |
JPD812 | F989999 | TBLE | Central Objects - PD812 | *PUBLIC | AV |
JPD812 | F989999 | TBLE | Business Data - PROD | *PUBLIC | NA |
JPD812 | F989999 | TBLE | Central Objects - PD812 | EGEN | NA |
JPY812 | F989998 | TBLE | Central Objects - PY812 | EGEN | NA |
JPY812 | F989998 | TBLE | Central Objects - PY812 | *PUBLIC | AV |
JPY812 | F989998 | TBLE | Business Data - CRP | *PUBLIC | NA |
JPY812 | F989998 | TBLE | Business Data - CRP | EGEN | AV |
JPY812 | F989999 | TBLE | Business Data - CRP | EGEN | AV |
JPY812 | F989999 | TBLE | Central Objects - PY812 | *PUBLIC | AV |
JPY812 | F989999 | TBLE | Central Objects - PY812 | EGEN | NA |
JPY812 | F989999 | TBLE | Business Data - CRP | *PUBLIC | NA |
Execution
Update (10/25/2009): Starting with release 8.12 you must generate a package manifest for auto-package discovery to work when you deploy update (or full) packages. This package manifest exists as a record in the serialized objects tables so if you truncate the F989998/9 tables prior to a full generation, the auto-package discovery functionality will be broken. Since this impacts our method I have added a step to account for this functionality.
Steps for 8.12/8.96 and greater:
Steps prior to 8.12/8.96:
Steps for 8.12/8.96 and greater:
- Truncate the serialized tables that are actively OCM mapped to the EGEN E1 user
- Comment out the [JDBJ-SPEC DATA SOURCE] stanza in jdbj.ini to use the WebDev machine for egeneration (Thanks to John Bassett for this tip.)
- Log into egenerator using the EGEN E1 user
- Generate manifest
- Generate core objects
- Login to the web client once using the EGEN E1 user
- If you wish to pre-generate serialized objects, perform a full generation
- Rebuild the indexes for the F989998 and F989999 tables
- Perform an OCM swap for *PUBLIC and EGEN
- Flush the OCM and serialized objects caches
Steps prior to 8.12/8.96:
- Truncate the serialized tables that are actively OCM mapped to the EGEN E1 user
- Comment out the [JDBJ-SPEC DATA SOURCE] stanza in jdbj.ini to use the WebDev machine for egeneration (Thanks to John Bassett for this tip.)
- Log into egenerator using the EGEN E1 user
- Generate core objects
- Login to the web client once using the EGEN E1 user
- If you wish to pre-generate a full set of serialized objects, perform a full generation
- Rebuild the indexes for the F989998 and F989999 tables
- Perform an OCM swap for *PUBLIC and EGEN
- Flush the OCM and serialized objects caches
The OCM swap will make the "alternate" serialized objects tables active for *PUBLIC and inactive for EGEN and will make the "original" serialized objects tables inactive for *PUBLIC and active for EGEN, ready for the next full gen and swap.
Example
Before:
Environment | Object Name | Object Type | Primary Data Source | System Role | Object Status |
JDV812 | F989998 | TBLE | Central Objects - DV812 | EGEN | NA |
JDV812 | F989998 | TBLE | Business Data - TEST | *PUBLIC | NA |
JDV812 | F989998 | TBLE | Business Data - TEST | EGEN | AV |
JDV812 | F989998 | TBLE | Central Objects - DV812 | *PUBLIC | AV |
JDV812 | F989999 | TBLE | Business Data - TEST | EGEN | AV |
JDV812 | F989999 | TBLE | Central Objects - DV812 | *PUBLIC | AV |
JDV812 | F989999 | TBLE | Central Objects - DV812 | EGEN | NA |
JDV812 | F989999 | TBLE | Business Data - TEST | *PUBLIC | NA |
After:
Environment | Object Name | Object Type | Primary Data Source | System Role | Object Status |
JDV812 | F989998 | TBLE | Central Objects - DV812 | EGEN | AV |
JDV812 | F989998 | TBLE | Business Data - TEST | *PUBLIC | AV |
JDV812 | F989998 | TBLE | Business Data - TEST | EGEN | NA |
JDV812 | F989998 | TBLE | Central Objects - DV812 | *PUBLIC | NA |
JDV812 | F989999 | TBLE | Business Data - TEST | EGEN | NA |
JDV812 | F989999 | TBLE | Central Objects - DV812 | *PUBLIC | NA |
JDV812 | F989999 | TBLE | Central Objects - DV812 | EGEN | AV |
JDV812 | F989999 | TBLE | Business Data - TEST | *PUBLIC | AV |
Now go dream about getting more sleep.
5 comments:
Nice post Jeff!!
Love the concept of having two sets of serialized objects table. Will try and implement this and let you as well as the list know about the feedback.
Certainly would love an extra hour of sleep!!
Just one question. What about deploying the build to the ent server. we have to do it in the maint window so why not egen at the same time?
Deepster, that's a very good point you bring up.
Unless an enterprise server is very busy with UBE's, I generally deploy the package during the day. Once submitted, the deploy will place incoming UBE's on hold until all running UBE's have processed, then perform the deployment. Usually I monitor the queue(s) until I see no running UBE's then submit the deployment.
I can understand why, on a busy server, one would wait until off-hours. You can still gen the objects to the alternate tables and have them waiting so that during your maintenance window all you have to do is deploy, OCM swap and clear the caches.
Your organization's balance of risk vs. admin burnout will usually determine your approach.
Hi Jeff,
We have been doing something similar for quite some time now, only difference being, we have created a separate custom generation library with custom F989999 & F989998 tables on our AS400 box.
We make our .ini to point to this custom generation libray while doing a full generation.
Post generation we just back up and detele the contents of the original serialized tables and copy the contents of custom serialized tables to the original ones.
Regards,
Ashish
CNC Admin
We're taking a similar approach at Roseburg Forest Products. Keith Simon KeithSi@rfpco.com
Post a Comment