Extension Crossovers: PLUSV Collisions, Nuclear's Anomaly & When Products Share DNA
🎯 Who this is for: Upgrade architects who need to know why a "clean" prefix scan is hiding a collision, admins running (or inheriting) Nuclear or HSE environments, and anyone who has been asked "can't we just use the permit module from the other product?" in a scoping meeting.
Series: Part 7 of 7 — MAS Java Extensions | Read time: 22 minutes
You Thought PLUSG Was the Weird One
In Part 4 you learned that HSE and Oil & Gas are technically the same product — one PLUSG prefix, one set of 263 objects, differentiated only by application visibility. And you learned why Aviation conflicts with almost everything: it is a composite that installs ~930 objects across five prefixes.
Here is the uncomfortable truth: those are only two of five crossover types. The prefix registry you memorized in Part 2 looks like a tidy one-letter-per-product system, but the real map has products sharing code, products containing other products, one prefix meaning two unrelated things depending on the decade, one product that ignores the naming convention entirely, and five business concepts that got implemented three or four separate times across the portfolio.
"We scanned MAXOBJECT, saw PLUSV, and assumed Civil Infrastructure was already installed."
That assumption, on a database upgraded from 7.6, can cost you weeks. Let's build the full map.
🗺️ The Five Crossover Types
| Type | Pattern | Example | Covered |
|---|---|---|---|
| 1. Shared codebase | Same prefix → multiple products | PLUSG = HSE + Oil & Gas | Part 4 |
| 2. Composite product | One product → multiple prefixes | Aviation installs PLUSA/G/P/T/M | Part 4 |
| 3. Prefix reuse | Same prefix → different products, different eras | PLUSV = Primavera Adapter or Civil Infrastructure | This part |
| 4. Non-standard pattern | Product ignores the convention | Nuclear = "PLUS" (no letter), cloned apps | This part |
| 5. Independent implementations | Same concept → separate code in each product | Permits, crews, config management, quals, regs | This part |
Types 1 and 2 are code-level crossovers — shared Java, shared MAXOBJECT rows. Types 3–5 are the sneakier kind: they look related on the surface and share nothing underneath. Treating them as related is exactly how upgrade plans go wrong.
<aside> 💡 Key insight: Types 1–2 are one codebase wearing multiple badges. Types 3–5 are multiple codebases wearing one badge — a prefix, an application name, or a business term — and the badge is lying to you. </aside>
🔀 Type 3 — PLUSV: One Prefix, Two Unrelated Products
The PLUSV prefix was assigned twice, to products that have nothing to do with each other:
| Era | PLUSV Used By | Purpose |
|---|---|---|
| Legacy (Maximo 7.x) | Primavera Adapter | Integration with Oracle Primavera P6 project scheduling |
| Current (MAS 8.x/9.x) | Civil Infrastructure | Road, bridge, and infrastructure condition assessment |
This is not a PLUSG situation. There is no shared Java package, no shared schema, no migration path baked into the product. Two different engineering teams, years apart, drew the same letter from the prefix pool. Different object names, different table structures — a pure namespace collision.
Why This Bites Upgrade Teams
If your 7.6 environment ever ran the Primavera Adapter, your database contains legacy PLUSV objects. MAS 9's Civil Infrastructure also creates PLUSV objects. Activate Civil Infrastructure on top of the legacy leftovers and you get object-name collisions on tables the installer expects to create fresh.
The sequence that keeps you safe:
- Inventory before you activate. Any 7.6-origin database gets a PLUSV audit as part of upgrade discovery — even if nobody remembers using Primavera. Integrations outlive institutional memory.
- Classify what you find. The two products' objects describe themselves clearly (next section).
- Clean up legacy objects first. Primavera Adapter remnants must be removed before Civil Infrastructure activation — and if you actually need both P6 integration and Civil Infrastructure, that is an IBM Support conversation, not a DIY migration.
The Diagnostic Query
-- Which PLUSV do I have?
SELECT OBJECTNAME, DESCRIPTION, CLASSNAME
FROM MAXOBJECT
WHERE OBJECTNAME LIKE 'PLUSV%'
ORDER BY OBJECTNAME;Read the descriptions:
| You see objects about... | You have |
|---|---|
| Projects, schedules, activities | Legacy Primavera Adapter — clean up before activating Civil Infrastructure |
| Inspections, conditions, assessments | Civil Infrastructure — current product, you are fine |
| Both patterns | A collision in progress — stop and involve IBM Support |
<aside> 💡 Key insight: A prefix is an identifier, not an identity. MAXOBJECT tells you a PLUSV object exists; only the object's description tells you which product put it there. </aside>
☢️ Type 4 — Nuclear: The Anomaly of the PLUS Family
Every product in Part 2's registry follows the same rules: unique letter, psdi.plusX.* packages, pure extension of core MBOs. Nuclear breaks all three.
First anomaly — the prefix itself. Older IBM references (including IBM Support document swg21650645) list Nuclear as just "PLUS" — no trailing letter. The MAS 9 deployment component is simply nuclear. The tidy PLUSN designation you would expect is largely aspirational; on disk and in older docs, Nuclear predates the convention it now nominally belongs to.
Second anomaly — clones instead of extensions. Where Transportation extends Work Order Tracking through the inheritance chain, Nuclear cloned 13 core applications and gave them a (Nuc) suffix:
| Cloned Application | Original |
|---|---|
| Organizations (Nuc) | Organizations |
| Assets (Nuc) | Assets |
| Locations (Nuc) | Locations |
| Item Master (Nuc) | Item Master |
| Work Order Tracking (Nuc) | Work Order Tracking |
| Purchase Requisitions (Nuc) | Purchase Requisitions |
| Purchase Orders (Nuc) | Purchase Orders |
| Job Plans (Nuc) | Job Plans |
| Preventive Maintenance (Nuc) | Preventive Maintenance |
| Routes (Nuc) | Routes |
| Service Requests (Nuc) | Service Requests |
| Quick Locations (Nuc) | (new — simplified location creation) |
| Quick Assets (Nuc) | (new — simplified asset creation) |
On top of the clones sit nine applications that exist nowhere else in Maximo:
| Application | Purpose |
|---|---|
| Clearances | Lockout/tagout with tag sharing and conflict checking across multiple clearances |
| Lineups | Valve/switch position tracking for operational configurations |
| Surveillance Testing | Regulatory-frequency test scheduling tied to Tech Specs and Plant Modes |
| Condition Reports | Non-conformance management with corrective action control and trending |
| Configuration Change Designer | Engineering change control for attributes under configuration control |
| Changes (Nuc) | Engineering changes with release/revision lifecycle |
| Releases (Nuc) | Groups changes for execution during outages |
| Tech Specs | Technical Specifications — LCO tracking, applicability, surveillance requirements |
| Commitment Tracking | Regulatory commitment management |
A third view — IBM's licensing module grouping. MAS 9's industry-solution module table doesn't list 13 clones and 9 unique apps at all; it groups Nuclear into four licensing modules: Configuration Change (Nuc), Operation Management (Nuc), Permits (Nuc), and Condition Report (Nuc). This isn't a contradiction — it's a different altitude. The 22-application list is what a customization audit walks object by object; the four-module list is what AppPoints allocation and license entitlement reference. Roughly: Configuration Change (Nuc) = Configuration Change Designer + Changes/Releases (Nuc); Operation Management (Nuc) = the clone applications + Lineups + Surveillance Testing; Permits (Nuc) = Clearances; Condition Report (Nuc) = Condition Reports. Map your customization inventory to this grouping before a license renewal conversation — IBM Support speaks in modules, not application names.
Why you should care even if you never touch a nuclear plant: the clone approach is a masterclass in long-term customization cost. Because Nuclear duplicated applications rather than extending them, a customization inventory has to check both the (Nuc) clone and any extensions layered on the clone. Every rule you learned in Part 3 about tracing one inheritance chain becomes two parallel investigations. If you are ever tempted to clone a core application instead of extending it — this is what your upgrade team inherits.
A second naming wrinkle worth flagging. MAXOBJECT count references in circulation (including the one in our own DOC6 knowledge base) label Nuclear's line item `PLUSN` with roughly 30 objects — a tidy, conventionally-lettered prefix that contradicts the bare "PLUS" designation in swg21650645 and the nuclear deployment component name. Neither is necessarily wrong so much as inconsistent, because Nuclear's object prefixes were never fully standardized. Trust what MAXOBJECT rows say over what any prefix table — including this one — predicts:
-- Nuclear objects rarely announce themselves with one consistent prefix.
-- Search by application group instead of assuming PLUSN or PLUS.
SELECT OBJECTNAME, DESCRIPTION, CLASSNAME
FROM MAXOBJECT
WHERE OBJECTNAME LIKE 'PLUSN%'
OR OBJECTNAME LIKE 'NUC%'
OR CLASSNAME LIKE '%nuclear%'
ORDER BY OBJECTNAME;Upgrading Nuclear Environments: The Clone-Aware Checklist
IBM's standard pre-upgrade checklist for moving to Maximo Manage in MAS covers the same ground for every add-on: back up, run Integrity Checker, disable custom triggers, build a customization archive, deploy, activate, validate. Three of those generic steps carry extra weight on a Nuclear environment because of the clone architecture:
- Customization archive scope must name both the clone and its extensions. An archive built against
WorkOrderalone misses anything layered onWorkOrderNuc. MAS 9 supports multiple customization archives per activation — introduced specifically because single-archive configurations were losing track of exactly this kind of split-surface customization. Treat "core WO customizations" and "Nuc WO customizations" as two archives, even if the same team wrote both. - Integrity Checker findings need a second read for `(Nuc)` objects. The checker validates against the object it's pointed at — it does not cross-reference a clone against its original. An orphaned reference on
AssetNucwill not surface as a problem withAsset; a clean run on core objects says nothing about the clone side. - product.xml completeness is doubly important. Part 3 covered why incomplete product.xml coverage (many customer environments cover only 20–30% of their actual custom classes) breaks silently during upgrades. On Nuclear, an incomplete product.xml can leave the clone's customizations undeclared while the original application's file looks complete — passing a surface audit while the real gap sits one table away.
Run the MAXOBJECT/NUC audit query above before building the customization archive — let the object inventory drive what gets archived, not the other way around.
Clearances vs Permit to Work: Same Problem, Different Engineering
Nuclear's Clearances and HSE's Permit to Work both answer "how do we make this work safe to execute?" — with completely independent implementations:
| Feature | HSE Permit to Work (PLUSG) | Nuclear Clearances |
|---|---|---|
| Database object | PLUSGPERMITWORK | Separate clearance objects |
| Tag management | Basic | Advanced — tag sharing, conflict checking across clearances |
| Integration | Links to work orders | Full integration with WOs, PMs, and Lineups |
| Regulatory basis | General safety (ISO 45001) | NRC nuclear regulations (10 CFR) |
| Complexity | Medium | Very high — multi-clearance conflict resolution |
The line that matters for scoping: Clearances performs conflict checking across multiple simultaneous clearances — if two isolation boundaries want the same tag point in incompatible states, the application catches it. Permit to Work has no equivalent, because general industrial practice doesn't demand it. Neither module is "better"; they are engineered to different regulatory ceilings.
<aside> 💡 Key insight: When two products implement the same concept, the complexity difference is regulatory, not accidental. You cannot configure Permit to Work up to Clearances, and you should not pay Clearances complexity for a bottling plant. </aside>
🧬 Type 5 — Same Concept, Independent Implementations
The Permit-to-Work/Clearances pair is one row of a bigger pattern. Five business concepts appear in multiple products as fully independent implementations — different database objects, different Java classes, different UI:
| Business Concept | Implementations | The Technical Difference |
|---|---|---|
| Permits / Safe Work | PLUSG (Permit to Work) · Nuclear (Clearances) | Different DB objects, workflows, and complexity ceilings (see above) |
| Configuration Management | PLUSA (ACM) · Nuclear (Configuration Change Designer) | ACM tracks as-maintained vs as-designed physical builds via the BDI engine; Nuclear governs engineering approval of changes to regulated attributes |
| Crew Management | PLUSD (Utilities T&D crew options) · Core Manage (Scheduler Crew Types/Crews) | Utilities extends the Organizations app with T&D options controlling compatible-unit labor factors; core ships standalone Crew Type/Crew apps |
| Qualification Tracking | Nuclear (enhanced vendor quals + labor certs) · PLUSD (labor skill certs) · Core (basic Qualifications app) | Each layers industry requirements on the same idea; Nuclear adds qualified-vendor control for safety-critical procurement |
| Regulatory Compliance | PLUSG (regulations, audits) · PLUSD (NERC/CIP) · Nuclear (Tech Specs, NRC commitments) · PLUSV (infrastructure regulations) | Same verb — "track what the regulator requires" — four disjoint data models for four regulators |
The Quiet Sixth Pattern: Shared Capability Add-Ons
One more relationship hides inside the dependency map from Part 4: Linear (PLUSL) and Spatial (PLUSS) are consumed as capabilities by the industry solutions. Transportation and Utilities both typically deploy Linear (route/network measures) and Spatial (map layers); Civil Infrastructure leans on both. This is not a Type 5 duplication — the industry solutions genuinely use PLUSL/PLUSS objects rather than re-implementing them — but it matters for the same reason: activate Transportation and your extension chains on Asset and Work Order may include PlusL and PlusS layers you never explicitly asked for, and your PLUSL/PLUSS custom code now lives inside multiple products' chains.
Two practical consequences:
- Nothing migrates between them. Moving from HSE permits to Nuclear clearances (or between any Type 5 pair) is a re-implementation with data conversion, not a toggle. Budget accordingly.
- Integration code must pick one. If your MIF interfaces or automation scripts reference
PLUSGPERMITWORK, they know nothing about clearance objects, and vice versa. A site that runs both products (rare, but Aviation environments contain ~10% of PLUSG) needs its integrations to be explicit about which implementation is authoritative.
Choosing When Modules Overlap
The decision rules that survive contact with licensing reality:
- Follow your licensed industry solution. The overlapping module you already own beats the marginally better one you don't.
- Follow your regulator. NRC oversight → Clearances/Tech Specs. ISO 45001-style safety program → Permit to Work. NERC/CIP → Utilities' compliance tracking.
- Never add an industry solution for one module. As Part 4's compatibility matrix showed, each industry solution drags its full extension chain, database footprint, and compatibility restrictions into your environment. Borrowing one app is never worth it.
- For genuinely core needs, prefer core. Crew Types/Crews in Scheduler cover most crew management outside of compatible-unit utilities work — without touching a PLUS prefix at all.
Worked Example: Scoping Configuration Management for a Mixed Fleet Utility
A worked example makes the decision rules concrete. Say a transmission-and-distribution utility runs core Manage plus PLUSD (Utilities), and an engineering lead asks: "We need configuration management for our substation assets — can we just turn on ACM?"
Walk it through the Type 5 lens instead of the feature-request lens:
- What does "configuration management" mean here? ACM (PLUSA) answers "what does this asset's physical build actually look like right now, and does it match what engineering designed?" — serial-numbered components, build positions, baselines, drift detection via the BDI engine. Nuclear's Configuration Change Designer answers a different question: "has this regulated attribute's proposed change been through engineering approval?" Neither is a generic "config management" toggle; they're two different questions wearing the same label.
- Which question is the utility actually asking? Substation equipment with serialized, swappable components (breakers, relays, transformers with tap-changer assemblies) that needs physical-build tracking against an as-designed baseline is an ACM question, not a Configuration Change Designer question — the utility has no NRC-style engineering-change-approval requirement driving the ask.
- What does turning on ACM actually cost? Per Part 4's dependency map, PLUSA is a 293-object industry solution — the single largest object footprint in the entire PLUS family. It is not "borrowing one app"; it is the app. This is the one Type 5 case where the answer legitimately is "add the industry solution," because the utility's actual need matches ACM's actual design center.
- The counter-scenario: if the same utility instead asked for "an approval workflow before we let anyone change a protection-relay setpoint," that's an engineering-change-approval question — closer to what Nuclear's Configuration Change Designer solves, but licensing Nuclear for one workflow pattern fails rule 3 above. The right move there is a custom workflow built on core Manage's change/approval primitives, not an industry solution license.
The diagnostic query for step 1 in a real environment — confirm what's actually installed before the conversation goes further:
-- Which configuration-management implementation(s) exist in this environment?
SELECT OBJECTNAME, DESCRIPTION FROM MAXOBJECT
WHERE OBJECTNAME LIKE 'PLUSA%'
OR OBJECTNAME LIKE '%CONFIGCHANGE%'
OR OBJECTNAME LIKE '%CFGCHANGE%'
ORDER BY OBJECTNAME;🔍 Auditing Crossovers in Your Own Environment
Extend Part 4's environment audit with three crossover checks:
-- 1. PLUSV era check (Type 3)
SELECT OBJECTNAME, DESCRIPTION FROM MAXOBJECT
WHERE OBJECTNAME LIKE 'PLUSV%' ORDER BY OBJECTNAME;
-- 2. Nuclear presence and clone inventory (Type 4)
SELECT APP, DESCRIPTION FROM MAXAPPS
WHERE DESCRIPTION LIKE '%(Nuc)%' OR APP IN ('CLEARANCE','LINEUP','TECHSPEC')
ORDER BY APP;
-- 3. Duplicate-concept exposure (Type 5) — which permit implementations exist?
SELECT OBJECTNAME, DESCRIPTION FROM MAXOBJECT
WHERE OBJECTNAME LIKE 'PLUSGPERMIT%' OR OBJECTNAME LIKE '%CLEARANCE%'
ORDER BY OBJECTNAME;If check 1 returns both eras, or check 3 returns both implementations, you have a crossover situation that belongs in your upgrade risk register — before anyone runs updatedb.
🛠️ Troubleshooting Crossover Symptoms
The crossover types above describe the cause. In practice you rarely start there — you start with a broken chain, a missing customization, or a schema conflict, and have to work backward. Three symptom patterns cover most crossover-related incidents.
| Symptom | Likely Cause | Fix |
|---|---|---|
| Application won't open, or Eclipse crashes on decompile | A circular extension loop from a misused product.xml tag — <class> where <mbo> belongs can chain an object back to itself: YYYWOSet → PlusSWOSet → PlusGWOSet → TloamWOSet → PlusPWOSet → XXXWOSet → TloamWOSet (LOOP!). This is build-time: bytecode injection assembled the loop during updatedb, so source files compile clean and show no error. Crossover-heavy environments (Aviation's five prefixes, Nuclear's clone-plus-original surface) have more chain links and more chances for a tag mistake to close one. | Audit product.xml tag usage first, not the Java source — the loop lives in the XML. |
| Customizations "disappeared" after installing a new add-on | Missing or incomplete <depends> tags in the customer's product.xml. When a new add-on installs (HSE onto a base environment, Civil Infrastructure onto a database with PLUSV-adjacent customizations), Maximo places customizations by declared dependency. No <depends> tag naming the new add-on can leave a customization below it in the chain instead of above — the add-on's default silently overrides it. Looks like data loss; the cause is chain ordering. | Name the file z_customer.xml and declare <depends> tags for every IBM product in the environment — on a composite like Aviation, that means the full five-prefix list, not just the prefix your code extends. |
| Clean Integrity Checker run, but Nuclear clone data is still broken | The Type 4-specific version of the incomplete-audit problem. Integrity Checker validates the object it's pointed at — it has no concept of "this is a clone, check both." A clean run against WorkOrder says nothing about WorkOrderNuc; a single pass on a Nuclear environment validates roughly half the object surface. | Run Integrity Checker scoped explicitly to (Nuc)-suffixed objects as a second, separate pass — a distinct checklist line item, not a sub-case of the standard run. |
| Upgrade testing passes, production migration breaks | product.xml coverage gaps. IBM's field data puts typical customer coverage at 20–30% of actual custom classes; the rest rely on undeclared direct MAXOBJECT.CLASSNAME manipulation. A test database built from a production duplicate hides this — the undeclared classes are already present in compiled bytecode, and the gap only surfaces when updatedb re-processes the chain from product.xml during the real upgrade run. | Before building the customization archive, cross-reference MAXOBJECT.CLASSNAME against every class declared in product.xml — declare gaps, don't discover them in production. |
The Complete Map, Assembled
Across Parts 4 and 7, the full crossover picture:
- Type 1 — Shared codebase: PLUSG serves HSE and Oil & Gas from one set of 263 objects (Part 4)
- Type 2 — Composite: Aviation installs ~930 objects across five prefixes; Complex Assets is Aviation with renamed labels (Part 4)
- Type 3 — Prefix reuse: PLUSV meant Primavera Adapter in 7.x and means Civil Infrastructure in MAS 9 — audit before activating
- Type 4 — Non-standard: Nuclear uses bare "PLUS," 13 cloned
(Nuc)apps, and 9 unique applications engineered for NRC oversight - Type 5 — Independent implementations: permits, config management, crews, qualifications, and regulatory tracking each exist multiple times with zero shared code
And the troubleshooting patterns that follow from all five types share one root cause worth carrying forward: crossovers turn one-inheritance-chain problems into two-or-more-chain problems. A circular loop, a lost customization, a clean-but-incomplete Integrity Checker pass — every one of them is a standard Maximo extension failure mode that gets harder to catch precisely because a crossover-heavy environment (Aviation's five prefixes, Nuclear's dual clone-and-original surface) has more chains for the same mistake to hide in.
Seven parts in, you can now read an environment the way IBM's own build engineers do: prefix by prefix, chain by chain, crossover by crossover — and predict the conflict before it predicts you.
Key Takeaways
- PLUSV is a collision, not a codebase — classify legacy Primavera objects vs Civil Infrastructure objects with a MAXOBJECT description scan before any activation
- Nuclear breaks every PLUS convention — bare "PLUS" prefix, 13 cloned
(Nuc)applications, and nine unique apps make it the hardest product to inventory for upgrades - Clearances out-engineers Permit to Work deliberately — multi-clearance tag conflict checking exists because 10 CFR demands it, not because HSE's module is deficient
- Five business concepts ship as independent implementations — nothing migrates between them, and integrations must name which one is authoritative
- Choose overlapping modules by license and regulator — and never onboard a whole industry solution to borrow one application
- Every crossover troubleshooting symptom traces to chain complexity — circular loops, lost customizations, and incomplete Integrity Checker passes all get harder to catch when an environment has more prefix chains for the same mistake to hide in
References
- IBM Support — Industry solution and add-on prefixes (swg21650645)
- Maximo Manage requirements — Compatibility Matrix (IBM Documentation)
- IBM Maximo Application Suite Documentation
- IBM Maximo for Nuclear Power documentation
- IBM Maximo Health, Safety and Environment Manager documentation
- IBM Maximo Civil Infrastructure documentation
- IBM Maximo Nuclear overview — Continuous Delivery documentation
- Maximo Technical and Functional Concepts — Industry Solutions Prefix and Java Versions
- Naviam — IBM Maximo Application Suite 9.2: What to Expect
- TheMaximoGuys knowledge base — MAS 9 Java Extensions Hierarchy Technical Guide (DOC6), §8.5, §6.2, §7
- TheMaximoGuys knowledge base — IBM Maximo Application Suite user guide, "Upgrade checklist" and "Multiple customization archives for Maximo Manage configuration" (via SearchMaximo sweep)
Series Navigation
| Previous: | Part 6 — Java 17, Java 25, and the Future of Maximo Extensions |
|---|---|
| Series Index: | MAS 9 Java Extensions Series |
About TheMaximoGuys: We help Maximo developers and teams navigate the MAS transformation with practitioner-grade technical guidance.
Venkat Achanta
