How to purchase RDi

There are a number of differences in how these two infrastructures work based on their origins.  PPA was designed for fulfilling software products, which tend to “evolve in place” over time and are typically sold as perpetual licenses.  AAS was designed for fulfilling hardware, where periodically new models come along that may be purchased to replacing aging machines, such that there is no continuity of ownership of a specific product over the long haul.

These are the key differences that may be of interest to you as you interact with IBM:

Customer and Entitlement Identification:  (If you transact through both PPA and AAS you may have different IBM Customer Number (ICN) for each system)

• AAS: entitlements in the AAS system are always bound to the serial number of a Power system.  If you have multiple machines, thus multiple serial numbers, subsets of your Rational software entitlements might be bound to each serial number
• PPA: if your organization is decentralized regarding development tool purchases, you may have multiple Site IDs associated with your enterprise’s entitlements where the Site ID reflects and is associated to purchases made by part of your organization, and possibly a specific purchase event

Available License Metrics and License Fulfillment

§DEFINITION: A license talisman refers to any mechanism that is used to unlock a product for production (i.e. non-evaluation) usage.  Example: “floating keys” are the talismans used to activate products sold by the Floating User metric; “desktop activation kits” are the talismans used to activate desktop products sold by the Authorized User metric.  For more information about license metrics, talismans, and other related issues see the Licensing FAQ

§PPA: PPA has a linkage to the Rational License Key Center (RLKC), which is always used to fulfill talismans (such as floating keys or tokens) that are imprinted with customer identifiers and/or expiration dates and therefore cannot be packaged with product install images.  Thus PPA is able to support the sale of distributed software products with Floating User, Floating User Single Install, and Token license metrics.  PPA also supports the sale of products with metrics such as PVU or Concurrent that do not utilize a talisman.  (NOTE: most multi-product bundles are not offered with Floating options.  No multi-product bundles are offered with Token option).  PPA also supports the sale of products that use “desktop activation kit” talismans corresponding to the Authorized User metric, but in this case is not dependent upon the RLKC for delivery of the talismans because, they are included as part of the product install image so that the RLKC can be bypassed.  Note: Talismans for new product versions become available in RLKC automatically, provided your S&S agreement is current/active.  Desktop activation kits for new product versions will be part of the product install image

§AAS: AAS has no connection to the Rational License Key Center. As a consequence, the only license metrics supported by AAS for distributed software are: Authorized User (for which the talisman, i.e. the AU activation kit, is packaged with the software install image) and metrics that do not involve use of a talisman (such as the Concurrent metric used by the XL compilers for AIX and Linux).  Note: desktop activation kits are shipped with the product install images, which themselves may not be visible to you until you have “purchased” the no-charge upgrade to the new Version

§For RDi in particular: the desktop activation kits for Authorized User licenses are packaged with the product installation image, whether through PPA or AAS.  All Floating license keys must be obtained from the RLKC

Product Maintenance Agreements

· Different terminology is used to refer to maintenance agreements.  For distributed software products the term is “Service and Support” (S&S).  For systems software the term is SoftWare Maintenance Agreement (SWMA).  When a distributed software product such as Rational Developer for i is sold through AAS, the systems terminology i.e. SWMA, tends to prevail in most discussions

·Different terminology is used to refer to reinstatement of lapsed maintenance agreements.  For distributed software products in PPA the term is “reinstatement”.  For systems software the term is “after license”.  When a distributed software product such as Rational Developer for i is sold through AAS, the systems terminology i.e. “after license”, tends to prevail in most discussions

·PPA: S&S renewal reminders are issued automatically starting ~ 90 days prior to the expiration of the current term; only 1 year renewals are offered

·AAS:  no reminders are issued (an AAS system limitation); 1 year and 3 year SWMA agreement and renewals are offered

Product Identifiers and Structures

PPA and AAS both use Product Identifiers (PIDs) as top-level product structure identifiers.  However, the formats of PPA and AAS PIDs are different, and the kinds of underlying structures that they define are also different (see tables below).   

PPA:

• PIDs are version-agnostic (i.e. they remain the same for lifetime of the product, at least until such time as the product is re-named in a way that reflects a change of its market positioning)
• because the PIDs representing your entitlements are “perpetual”, you need take no particular action as new product releases are introduced
• provides part numbers only for 1-year S&S renewal and reinstatement

• PIDs that are used to support software license purchases are required to change whenever a new major Version of the product is introduced.  (This refers to “Version” in the framework of IBM’s V.R.M.F version numbering conventions – for more information about this see Understanding IBM Software Product Versioning).   The license purchase PIDs for older versions are removed as those versions reach End of Service (in other words they not removed immediately as new-version PIDs are introduced.  And, as we tend to release new Versions more frequently than the typical 5 year minimum per-Version service lifetime, the number of active and visible AAS license PIDs for the same software product tends to grow over time.  PIDs used for purchasing and renewing SWMA (S&S) are not required to change as the product evolves – they typically span multiple Versions of a product.
• because PIDs are Version-specific, you must take action to “purchase” a no-charge “upgrade” to evolve your entitlement to the new Version, and thus be able to gain access to the product images and license activation kits for the new Version
• provides PIDs for both 1-year and 3-year SWMA (S&S) renewal and “after-license” (reinstatements)

This table summarizes the way product structures are defined in PPA and AAS respectively.  The next table will show concrete example using Rational Developer for i v9.x: