Adopt Rational Team Concert (RTC) and RTC Enterprise Extensions (RTC EE) faster and better (Part 2/2)

April 8, 2014

This is the second article of series of two dedicated to Enterprise tooling adoption. In the first article, we’ve discussed some core concepts and results borrowed from social psychology field. We’ve noted how familiarity with a new tool is important to minimize resistance to adoption.

In this second article, we provide some supporting material depicting how to keep the right focus when adopting some new Enterprise tooling. First from a general stand-point and then for the specific adoption of:

These latter ones should be seen as extra layers coming on top of the initial layer of Enterprise tooling adoption.

Choice of a radar screen presentation…

The radar screen format is self-explanatory and introduces the intuitive idea of refining cycles and continuous improvement. Which is exactly how adoption should be conducted, i.e. each of the points on the radar should be reviewed on a regular basis.

Intent for me is not to comment on each item of these charts (*) but rather let them “as is”. For now, this rather comes as a “big picture” that you may find of a good support when either discussing with your local IBM team or business partner or when preparing the next steps for making adoption at your company progress.

(*): that would be done in a live meeting between yourself and a subject matter expert (from IBM or a Business Partner).

Note: If you’re looking for something more prescriptive on how to deploy RTC/CLM, please check the Reference links below.

… and how to use it.

Before deployment, you should wonder if there is an action plan against each of the points on your radar. If yes, what will be the impact of each action plan on the resistance to change (R.T.C) ? If no, what will be the impact of this lack on the R.T.C. ?

During deployment, you can make a retrospective of the impact of your actions plans on the R.T.C.

At the end of each deployment iteration, you should perform a retrospective to identify what actions were the most effective for reducing R.T.C.

1. Adoption of Enterprise tooling: radar screen for success


Click to enlarge

Order of adoption: RTC or RTC EE first ?

Shall you start adopting RTC in your distributed or in your mainframe teams ?–> A sound approach is to start with the most critical to you !

2. Adoption of RTC: radar screen for success


Click to enlarge

3. Adoption of RTC EE: radar screen for success


Click to enlarge


Acknowledgement: Thanks to Simon Washbrook for his review and always useful remarks.

3 Things to know for facilitating Enterprise tool adoption (emphasizing the human and change management factors) (Part 1/2)

April 4, 2014

In my recent engagements with mainframe customers (and especially with the project managers in charge of the in-house deployment of Rational tooling), I identified a common pattern where we start speaking in-house processes and numbers (of developers or teams), their IT architecture, etc. but where – at some point of time – we take a step back and start discussing how the adoption of their new Enterprise tooling went so far, how it was implemented and the possible concerns that remains.

A common pattern… and one point which needs to be emphasized.

Innovation is a fact ! As is the resistance to change by end users and the necessity to respect company policies. These are the biggest hindrances to a successful (Enterprise) modernization. To mitigate these risks, an appropriate strategy (including adoption, management of expectations, roll-out, training, etc.) is the key for avoiding shelf-ware or rejection.

 A series of TWO articles…

In the first article, we will discuss some core concepts and results from social psychology field.

In the second article, we will elaborate on how customers could keep the right focus when adopting some new Enterprise tooling. From both a generic perspective and in the context of the specific adoptions of IBM Rational Team Concert (RTC) and IBM Rational Team Concert Enterprise Extensions (RTC EE) respectively.

Core concepts from social psychology

The purpose of this section is to leverage some core concepts and results from social psychology space. We want some valid terminology  clarifying what one could feel to a certain extent… but yet in a fuzzier way ! Note: to this regard, this post shares a common viewpoint with a previous blog post.

The couple of definitions and concepts I found useful to exhibit in the context of an Adoption process are the following:

  • Effort Expectancy (E.E.) aka “perceived ease of use”
  • Performance Expectancy (P.E.) aka “perceived usefulness”
  • Resistance to Change (R.T.C.)

In the context of a Learning process (borrowing from the field of pedagogy), you can think of:

Writer’s note: as you’ve certainly figured out, there is some overlap in acronyms: “RTC” and “EE” could be interpreted in two ways here… To disambiguate, I shall using the orange color for terms coming from social psychology. That way, Rational Team Concert (RTC) and Resistance to Change (R.T.C.) should not be confused. Same thing for EE and E.E. !

Application to Information Science and Technology

Here I’m relaying some previous results from the following source: “Resistance to change and the adoption of digital libraries: an integrative model” [JASIST’2009]

  • «A user’s intention to adopt a new technology is influenced by a variety of beliefs and perceptions
  • «Domain-specific R.T.C. is both a direct and indirect antecedent of users’ E.E. and P.E.»
  • «Understanding the role of R.T.C. in user adoption can help designers and managers create a better fit between systems’ design and their intended users’ personal characteristics.»

Encourage familiarity with the new tool…

  • «To encourage users who are high on R.T.C., new systems should be designed such that they are not perceived to embody a lot of change. This can be done by retaining as many characteristics of older systems, computerized or not.»
  • «Systems’ implementation and users’ training could be better done if users did not perceive a new system as embodying much change.»
  • «When a new system is introduced, familiar aspects of a new system could be highlighted to mitigate users’ resistance.»

… and demonstrate benefits […] in the context that is important to adopters.

  • «Illustrate to users the potential benefits of the system, and how these can be demonstrated.

by using testimonials, by linking resources to course listings,  and in any other way that will enable users to demonstrate the benefits in the context that is important to them. »


The content of this article could appear far from IT space in the first hand. In the second article, we will elaborate on how customers could keep the right focus when adopting some new Enterprise tooling. From both a generic perspective and in the context of the specific adoptions of IBM Rational Team Concert (RTC) and IBM Rational Team Concert Enterprise Extensions (RTC EE) respectively. Keeping in mind the concepts and results from social psychology…

Thumbnail Part2

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 (**) forum, EEBAW workshop labs (p. 63)
   team builds in parallel (>=4.0.3)  1 WI (***)
   team builds in parallel (>=4.0.6)  –  1 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)


RTC EE deployment: where distributed and mainframe developers can work in the same place !

February 19, 2014

Last month, along with my colleague Tim Wilson, I met with a couple of customers in China. I wrote a previous blog post based on this business trip that recalled the importance of using the right terminology for the tool adoption.

Customer under the impression that distributed and mainframe teams required separate CLM / RTC servers (i.e. JTS)

During a discussion with another customer, it came up that the person in charge of SCM administration (for distributed)  was under the impression that distributed and mainframe teams required separate CLM / RTC servers (i.e. JTS).

Since the tool itself does not impose such separation, I made the point this would rather be an organizational decision rather than a technical one. I felt like this was pretty new to the customer.


To clarify things, I initiated a blackboard session to highlight the different options wrt. the deployment topologies, their advantages as well as their implications for the future. Some core messages were:

  • The RTC server(s) can run on a various environments (including Windows, Linux, AIX, Unix, zLinux, z/OS, IBMi, etc.).
  • The fact that RTC EE is used for developing for z/OS does NOT imply that the RTC server shall run on z/OS. This was already stressed in other resources from IBM colleagues,
  • You have the options of using a single JTS or separate JTSes. In both cases, you can associate multiple CCM instances to your JTS(es). Choices should be guided either based on performance considerations or, again, on organizational considerations.
  • When considering options for using multiple JTSes:
    • It’s very important to note that, once separated, they could NOT be merged later.
    • Two separate servers require doubled effort for administration, upgrade, etc.
    • The reporting tools should be adapted accordingly (e.g. Insight/RPE instead of RRDI/RRDG)

At the end, the customer could have a better understanding of the CLM/RTC EE deployment options for his organization.

For the little story, in this customer situation, SCM administrators for both distributed and mainframe developments were supposed to meet with each others after our visit to discuss the best deployment option. Yet another good effect of ‘Enterprise Modernization’  brought by the adoption of the RTC EE tooling !

Note: in this article, I insisted on some aspects of RTC/CLM deployment. For a complete picture, the Deployment wiki is definitely a good read.

RTC / RTC EE: adopt terminology first !

January 24, 2014

Last week,  I was on a business trip to China with a colleague of mine. We met multiple local IBM teams and visited a couple of financial customers.

During our customer-facing sessions, questions raised by the customer were technical in essence which is… fair enough as we’re part of the RETT (Rational Emerging Technologies Team). But some questions revealed:

  • some misconception about the product (RTC / RTC EE)
  • some reluctance of parts of the customer organization for adopting a newer, yet different but more modern tool with safer workflows.

As an illustration, it appeared that the technical lead in charge of the RTC EE adoption at one of these customers still used the terms of checkin/checkout for RTC SCM when discussing with us.


  • RTC does NOT have a concept of checkout (although RTC does support resource locking – currently at the stream-level)
  • Customer organization had started migrating to RTC EE almost 2 years before…

I see multiple drawbacks in this:

  • Sticking to the terminology from a previous tooling in technical discussions about the capabilities of a newer tool is confusing. It basically assumes features that are not present in the product or, at least, not as is… As such this mismatch is a brake for adoption of the new features.
  • Actually, I was even more concerned that this speech was coming from someone in charge of the adoption of our tooling. Assuming that most of developers in the customer organization would share the same terms…

As a result, I decided to clarify and made the point that in RTC, you load projects and components, you checkin change sets, and deliver them to a stream. This change in emphasis made it simpler to discuss business scenarios to be implemented in RTC EE (SCM here) at this customer’s.


A disconnect in terminology is more important than it seems:

  • It introduces a gap compared to the proper concepts, which are basic prerequisites for elaborating the right workflows in RTC to implement a business scenario.
  • It’s a good indicator that trainings and pilot phases missed at least some targets. Basically the “infusion” of the up-to-date concepts that match the tools used by developers on a day-to-day basis.

I came up with the following ideas:

  • Answering customer initial questions is only ONE piece of the solution.
  • Other aspects (not raised by customers) need to be addressed with the same attention:
    • the return over experience in the training area,
    • the return over experience in the pilot projects,
    • the management of the change (from various point of views: organizational, managerial, etc. ),
    • the adoption in general.

Taking the whole combination into consideration is key for success.

In the contrary case, an ultimate bad effect would be that SCM management simply do not trust their developers wrt. their usage of the new tooling. Possibly triggering… a second bad effect : having the SCM management to try enforcing too much process in the tool to substitute the lack of training of their developer. Not the right route anyway…..

As a recap, here are the simple things that should be kept in mind when adopting RTC / RTC EE:

  • Even if adoption is accomplished in a stepwise manner, make sure everyone uses the RTC terminology asap in your organization.
  • If you’re in a team focusing on adoption of RTC, make sure you replace questions/feedback/concerns of your developer in the correct terminology.

Direct access to Redbooks/redpapers on mainframe and z/OS: improve your learning curve!

November 17, 2013

When digging further (or simply jumping) into Mainframe and z/OS world, one faces new terminology, concepts and tooling. Literature is pretty vast in the area and one could spend some time figuring out the right resource to consider…

As far as terminology is concerned, if you just need to understand a term, the “Glossary of z/OS terms and abbreviations” is certainly indicated. For a mainframe concept, you can check this InfoCenter entry  and for a z/OS concept, this other Info Center entry

If you need a broader understanding (e.g. how the pieces articulate with each others, etc.) then the Redbooks/Redpapers targeting Mainframe and z/OS are good starting points.

In my personal experience during the last couple of months, I found the following content very useful. In the following tables,  you’ll be one click away from the right material (in PDF format). While I’ve never taken time to read all of this content (at least not yet), I’ve referred to it in an “on demand” way, with a pre-established topic in mind for which I was interested by getting a clearer idea on.

Adding that “a picture is worth a thousand words“, so they say, I personally found the summary slides and architectural diagrams (generally located at the beginning of sections) particularly handy and enlightening. Enjoy !

[Redbooks] “ABCs of z/OS Systems Programming”

Vol. 1 Intro to z/OS and Storage concepts, TSO/E, ISPF, JCL
Vol. 2 z/OS Implementation and Maintenance 
Vol. 3 Intro to DFSMS and Storage Management
Vol. 4 Communication Server, TCP/IP, and VTAM
Vol. 5 Base and Parallel Sysplex, Logger, GRS, Operations, ARM 
Vol. 6 RACF, PKI, LDAP, Crypto, Kerberos and Firewall
Vol. 7 InfoPrint Server, LE, and SMP/E 
Vol. 8 z/OS Problem Diagnosis
Vol. 9 z/OS, UNIX System Services 
Vol. 10 Intro to Z, LPAR, and HCD 
Vol. 11 Capacity planning, performance management, RMF, and SMF
Vol. 12 WLM
Vol. 13 JES3 

Other Redbooks:

Batch Modernization on z/OS (July 2012)
Introduction to the New Mainframe: z/OS Basics (March 2011)
System z Mean Time to Recovery Best Practices  (Sept 2010)
System z End-to-End Extended Distance Guide (Nov 2013)


Rethink Your Mainframe Applications: Reasons and Approaches for Extension, Transformation, and Growth (May 2013)

RTCz / RTC EE evolutions version-by-version

October 3, 2013

Following the citation “One does not really know a science until one knows its history“, I’ve decided to provide such information for my area of interest: RTC Enterprise Extensions.

The story started in 2009 and I felt like providing such a recap could help both customers (and potentially business partners/colleagues from the field) when questioning a particular features “introduced at some point of time…. but when actually ?

It shall be noted that the following information borrows a lot to a previous blog post from Robin Yehle Bobbitt. Robin covered versions to 3.0.1. I’m extending to versions starting from 4.0 up to 4.0.4 versions.


The following picture is somewhat interactive: you could click any circle in it, consult a specific version and then click back on your browser, etc. Hope you enjoy it !

RTC z evolution line


Follow this link to discover the new feature in the version 3.0 Follow this link to discover the new feature in the version 3.0.1 Follow this link to discover the new feature in the version 3.0.1 Follow this link to discover the new feature in the version 4.0 Follow this link to discover the new feature in the version 4.0.1 Follow this link to discover the new feature in the version 4.0.3 Follow this link to discover the new feature in the version 4.0.4

Version (Q4 2009)

  • z/OS file agent : made it possible to extract files from the SCM to PDS/Es.
  • The mass import tool allowed you to import existing source from data sets into the SCM.
  • Rational Build Agent allowed you to create build definitions that call out to existing host build facilities, or submit JCL.
  • New build type, Antz build, provided full capabilities to build any z/OS related artifacts (via Apache Ant extensions for the z/OS environment).
  • Support for RDz remote projects.
  • Collaborative debugging with RDz and the IBM Debug Tool.
  • Jazz Gateway for System z (now called REST Gateway) to simplify integration with existing host based SCMs.  Allows simple REXX programs or any other exit to programmatically extract information, such as work item status, from the Jazz repository.

(more details) / Back to the “evolution path”

Version 3.0 (Q4 2010)

  • RTCz : not a a separate product anymore. Instead, a “Developer for IBM Enterprise Platforms” license was required for full access to the z and Power capabilities.
  • New “Team Area > Enterprise Extensions” node.
  • ISPF client for “green screen” access to common SCM and build functions.
  • Dependency build capability (for only building programs as necessary, i.e. based on change).
  • Component promotion to move source and build outputs together through the development hierarchy (e.g. Dev->Test->QA->Prod).
  • Shiplist-based packaging and deployment to gather your build outputs and deploy them to another runtime location.

(more details) / Back to the “evolution path”

Version 3.0.1 (Q2 2011)

  • Work-item based promotion, packaging and deployment.
  • Preview capabilities for dependency build and promotion.
  • HFS file system support in the ISPF client.

(more details) / Back to the “evolution path”

Version 4.0 (Q2 2012)

  • Sparse loading in ISPF client.
  • Enhanced view, compare and conflict resolution in ISPF client.
  • IBM i: dependency builds and work-item / component-based promotion and packaging.
  • Dependency build report.
  • More features around packages.
  • Personal deployment.

(more details 1) / Back to the “evolution path”

(more details 2) / Back to the “evolution path”

Version 4.0.1 (Q4 2012)

  • Build management in ISPF client.
  • Builds and source control: patterns to control the naming of translator outputs.

(more details) / Back to the “evolution path”

(more details 2) / Back to the “evolution path”

Version 4.0.3 (Q2 2013)

  • Work-item dissociation in the ISPF client.
  • View/compare file content in the ISPF client.
  • Build subsets configuration and settings.
  • Dependency build automatically rebuilds main programs (when one or more statically linked subprograms are updated).
  • Dependency build tuning and improved performance.

(more details) / Back to the “evolution path”

Version 4.0.4

  • ISPF client: pending changes view.
  • Dependency build and promotion: usability and simulation.

(more details) / Back to the “evolution path”


  • Good summary of enterprise features can be found here on
  • Citation reference “One does not really know a science ….” (and background information) can be found here

Credit / Acknowledgment

Thanks for Robin Y. Bobbitt for letting me reuse some information contained in her previous blog post.

%d bloggers like this: