Rational EM products (RTC EE, RDz, RD&T, RAA, …): recommendations and “educated guesses” for limitations

March 20, 2014

In the past couple of years, I’ve helped customers in their adoption and deployments of CLM, RTC, RQM and RRC-DNG. Based on their recurrent questions for correct sizing and scalability handling, I shared some limits / educated guesses for limitations in the blog post “CLM,RTC,RQM,RRC: recommendations and “educated guesses” for limitations“.

RationalEM-TableofLimitsNow that my focus has moved to Rational Team Concert Enterprise Extensions (RTC EE) and the Rational solution for Enterprise Modernization, I want to share similar content for RTC EE, RDz, RAA, … Following the same approach. [Tip for you] if you’re already familiar with my previous post, you may skip straight to the tables below and ignore the two following sections which detail some terminology and purpose aspects.

In the Tables below, there are columns for Limits and Alert zone. Let’s clarify how we define them:

  • Quantified data: the (maximum) number of….
  • Limit: a hard limit of the product. Meaning that you cannot go beyond this value.
  • Alert zone: based on experiences with customers, internal tests and development teams, it’s around these values that we start seeing performance issues. If you’re approaching these values, we’d suggest you monitor your system closely to detect any performance degradation before it becomes critical. WARNING: while provided figures are educated guesses and practical rules of thumbs, you could still find that your environment functions perfectly beyond these limits  (e.g. if your environment is particularly fine-tuned). In a similar way,  some intense usage could show that these recommended values are too optimistic…

As a consequence, it’s important to understand this post is NOT an attempt for replacing existing resources (see the References section) that provide extensive views on CLM performance and tuning topics. We encourage administrators and project managers to read them as they both include finer-grain information and insist on the key aspect of not loosing the “bigger picture”.

What’s the use of the following tables then ?

Answer: they’re here to HELP YOU quickly figure out if you’ve reached some known limitation or if you’re getting close to a threshold  (again: on the basis of a typical/average environment) requiring due monitoring of your environment.  To this regard, these tables are COMPLEMENTARY with existing resources and concentrate information ALREADY available ((but yet disseminated) on multiple medias/sites/forum posts/etc.

Now, let’s go straight to the tables…

Quantified data Limit Educated guess / Alert zone Reference(s)
   Files in a component (<v4.0) 2000 Dev team inputs
   Files in a component (>=v4.0)  –  2000 [Share 2013] (s. 8)
   builds in parallel (*) number of build engines supporting the build definition
   team builds in parallel (<4.0.3)  –  1 (**) Jazz.net forum, EEBAW workshop labs (p. 63)
   team builds in parallel (>=4.0.3)  1 Jazz.net WI (***)
   team builds in parallel (>=4.0.6)  –  1 Jazz.net WI (****)
(*): this includes personal and team builds.
(**): multiple concurrent team builds of your dependency build may result in unnecessary rebuilds of the same program. You should prevent this by only configuring one supporting team build engine. Additional engines may be added for personal builds only. Check referenced EEBAW workshop labs for more details.
(***): from this 4.0.3 version level, when running multiple team builds in parallel, all but the 1st treated of the concurrent build requests will fail and error log will contain the following message: “Found a build “20140319-xxxxxxxxxx” “currently running.  Running concurrent builds is disallowed.
(****): constraint possibly relaxed by both setting the mentioned property and by making sure you use non overlapping subset. Typical use case is (only) for building different programs (a.k.a non-incremental team builds).


Quantified data Limit Educated guess / Alert zone Reference(s)
 – [RDz v9 InfoCenter] Tuning considerations


Quantified data Limit Educated guess / Alert zone Reference(s)
developers supported  –
  • 3-5 per RD&T server (Desktop machine)
  • 15-25 per RD&T server (Server class machine)
[Share 2012] (s. 32)
defined System z CPs (*)
  • 1 (1090-L01 model)
  • 2 (1090-L02 model)
  • 3 (1090-L03 model)
[Redbook] (p.12)
defined System z CPs (*) associated to a single zPDT instance
  • one less than the # of processor cores on the base Linux system (**)
 3-4 (***) [Redbook] (p.12)
zPDT instances  1 (per System z CP) [Redbook] (p.12)
emulated I/O devices  1024 [Redbook] (p.21)
(*): or mixture of CPs, zIIPs, zAAPs, and IFLs.
(**): an exception exists for a single core, which may be used with reduced zPDT (check p.3 of the referred Redbook).
(***): as per the I/O capability of the underlying PC and various “SMP effects”. Check p.12 for more details. Note: for configurations including multiple z1090 tokens, check p. 13 of referenced Redbook.

Reference for functional restrictions and scope exclusions inherent to a RD&T usage (in comparison to a real mainframe):

  • while these topics are not targeted in this document, for you awareness, you could find a consolidated list in the following resource (slide 25).


Quantified data Limit Educated guess /Alert zone Reference(s)
number of levels for impact analysis  100 [WSAA InfoCenter] (p.47)
max. size of a scanned file  5 Mo (*) [devWorks forum]
(*): default value extendable through a property. Check referred forum answer for details.


  1. [Deployment wiki] Performance datasheets and sizing guidelines
  2. Rational Team Concert 4.x sizing report for z/OS
  3. Rational solution for CLM 4.0 performance tuning guide for z/OS  (Oct 2012)
  4. General Link: Rational Developer for System z (RDz)
  5. General Link: Rational Development and Test Environment for System z (RD&Tz)
  6. General Link: Rational Asset Analyzer (RAA)

Acknowledgment/Credit: thanks to the authors of the cited documents above and more generally to the Jazz community who collaboratively provides accurate information through library articles, forums questions & answer, etc..

Value and ROIs of Rational solution for Enterprise Modernization

March 7, 2014

In the RETT team, we are dedicated at helping Enterprise Modernization customers make the jump of taking out their legacy tools and ease their switch for an IBM Rational-based solution. With a special focus on adoptions of Rational Team Concert Enterprise Extensions (RTC EE).

A customer classification… (to be cont’ed)

Customers we assist are likely to have a DECADE-long history in mainframe development and… a LOT of legacy source code to migrate to RTC EE SCM. But wait a second ! This does not always hold true, especially in the Emerging Markets.

A recent business trip I made to China proved it. We met with financial customers who were NEW to mainframe (note: I’ve already shared some lessons-learned about this trip in the previous blog posts: 1, 2). Not a surprising choice as mainframes have evolved along the way while constantly proving their unique value, performance, level of services, etc. Between us, what other technology could compete with this now turning 50 years old success story ?

Be customers either long time engaged or “new to mainframe”, our sales and Client Technical Representatives (CTPs) face questions about the business added-value and the associated return over investment (ROI) coming with the adoption of the Rational solution. Fair enough. So what is the answer here ?


A sound approach is to map the customer classification given above to ROIs with different scopes:

… for guiding ROI content and scope.

  • For a customer bringing new IBM Rational mainframe capabilities into his existing development environment: the ROI should consider productivity, speed, quality, etc.
  • For a customer considering taking out a previous tooling (e.g. a tier SCM tool or an existing collaboration tool, …): we should compare apples and apples. Some key indicators about the tier provided solution should be captured and compared with the new ones and a consolidation should be built on top of this exercise. While making explicit the strength of Rational products (our value proposition).

Well, the good news is that IBM Rational provides a number of such ROI tools for ALM, DevOps, Quality & Requirements and… Enterprise Modernization.

Please note that you could find a complete list of them in the References section below.

First, let’s start by CLM in general:

Rational Collaborative Lifecycle Management (CLM)
ROI Calculator Report Comment
Rational CLM Value Analyzer  – (in Flash)
 – The Total Economic Impact of The IBM Rational Solution for Collaborative Lifecycle Management June 2013 (by Forrester Consulting)

Now, let’s cover the Rational EM tools:

Rational Developer for z (RDz)
ROI Calculator Report Comment
ROI Calculator  – (in Flash)
 – Benchmarking z/OS Development Tasks – Comparing Programmer Productivity using RDz and ISPF May 2012


Rational Development and Test Environment for System z (RD&Tz)
ROI Calculator Report Comment
ROI Calculator  – (in Flash)
 – Benchmarking z/OS Development Tasks – Comparing Programmer Productivity using RDz and ISPF May 2012

What about RTC EE ?

RTC EE provides additional capabilities to RTC for developing and building mainframe programs with a modern IDE. The ISPF client capabilities let you work with green screens if this is a preferred approach. It provides competitive z SCM tools hosting your z source code and, thing to note, wherever you want (see a previous blog post). As building programs on the System z platform can be expensive (per MIPS and time consumption, etc.), it provides some dependency build, promotion (without rebuilding) and deployment mechanisms.

Traditional benefits from RTC EE adoption include:

  • improved compliance and auditability
  • decommissioned legacy SCM systems for mainframe & distributed
  • unification of practices, removal of redundancies
  • improved follow-up on project statuses
  • diminished time for rewriting documentation
  • improved workflows creation and updates,
  • etc.

For examples of returns on adoptions of RTC EE by Enterprise customers, you could refer to:

Rational Team Concert Enterprise Extensions (RTC EE): returns on adoption by customers
Customer Date Comment
CACEIS Case Study (2013) PDF file. First 2 slides are in French but the rest of the presentation is… in English !
IBM Hursley CICS Lab (UK) (2012)

Going even beyond about YOUR expected ROI…

Let’s take a step back and discuss the statement, tools and reports provided above. OK. They give you sound estimates. Good enough. As always, the particular context of your company could impact these figures. If you’re looking for the finest-grain ROI and you are in the process of rolling out the Rational solution, one advice here:  you would consider including this exercise to be part of a post-pilot activity.

And… what if you add Requirements and/or Test in this picture ?

Needs for testing makes no exception for Enterprise Modernization customers.

From a general standpoint and once the initial learning curve of a test automation tool is passed, test design effort for an automated test is generally considered slightly more expensive than a manual test (30 to 40 % rates are commonly cited). But the payback occurs when tests are automatically replayed (in a quicker way, with no human errors, possibly at night, etc). This is particularly the case for tests run frequently (e.g. for regression testing). You should not minimize the cost of their maintenance though.

The corresponding information for Rational Quality Manager (RQM), Rational Requirement Composer (RRC), Doors, Rational Functional Tester (RFT), … is listed in the table below:

Quality management (RQM, RRC, Doors, DNG, RFT, etc.)
ROI Calculator Report Comment
ROI calculator  – (in Flash)


%d bloggers like this: