What Does Normal Mean Anyway?
tfeeney 1200005AKR Visits (1209)
quote from Forrest Gump! I was reminded of it on a recent trip to Minneapolis where we ate out at Bubba Gump Shrimp Co., a restaurant themed after the Tom Hanks movie. The title of this blog was to be "Mainframe's not so scary after all", however, I liked the movie quote so much I wanted to find a way to use it.
I've been using Rational Team Concert (RTC) and supporting customers evaluating or adopting it since before it was released five years ago. In my world of RTC, 'normal' meant using RTC for Eclipse-based development then later expanded to include Visual Studio. However, this was all in the context of supporting development of distributed systems on operating systems like Windows and Linux. We soon added support for System z and i, however, when opportunities came up in those domains, I deftly (and desperately) delegated them to someone else as I could only spell the 'z' in 'System z'. I thought that environment was so outside my 'normal', so different and such a mystery to me, I couldn't possibly speak the language of mainframers let alone support our products there.
As more and more of my enterprise customers are building multiplatform systems and as RTC and other Rational products have grown in their support for mainframe, I've had a change of heart, an epiphany of sorts. Mainframe is here to stay and for me to be more effective supporting my customers, I need to redefine my 'normal'.
So I have ventured into the mainframe world and have been pleasantly surprised to find it isn't so different from what I knew after all. Yes the terms are different and mainframers do think a little differently, but it all does really relate to the distributed foundation I'd already built.
When we talk to mainframe customers about RTC, we talk about Build, Promotion, Packaging and Deployment. Okay, so Build and even Deployment to some extent sound familiar, but what about Promotion and Packaging? Well, all of these processes are built on the foundational RTC concepts and structures of Components, Streams, Repository Workspaces, Sandboxes, Change sets and Build Definitions.
Let's explore some of these further.
Core RTC terms:
Component: Collection of related artifacts under source control. For example, all of the source for an application or particular product feature or that can be compiled to build a deliverable; all of the documents making up the content for a website might be collected together in a single component.
Stream: Collection of one or more components at a given state. This is where artifacts are shared between team members. A stream can include at most one version of any component. By using multiple streams, a development organization can work on projects that use different versions of the same components.
Repository workspace: Mechanism by which individual developers can isolate and backup their changes until ready to share with rest of team. Repository workspaces are usually created for development and build purposes.
Sandbox: File area where resources can be created, edited, and refactored. This is outside of the repository. Examples: eclipse workspace, PDS on MVS
Change set: Modifications made to one or more files within a component. Fundamental unit of change in RTC source control.
Build Definition: Identifies a particular build and its characteristics such as property values, location of versioned source, schedule, build script, etc.
RTC for mainframe terms
Language Definition: Defines a distinct language type that has its own set of build configuration information. Examples: COBOL, COBOL_CICS, COBOL_DB2. You can think of Language Definitions as kind of like JCL defined to build certain kinds of source.
Translator: Defines the steps required to build source for a specific language. One or more translators are associated with language definitions. You can think of Translators like job steps in JCL.
Data Set Definition: Defines a data set used during a build and include the typical characteristics related to allocating a PDS.
Promotion Definition: Defines the promotion specifications for a source stream to a target stream and where to move the build deliverables on the host.
Package Definition: Defines specification for packaging an application in preparation for deployment
Deployment Definition: Defines specification for deploying a package to a target environment.
Language Definitions, Translators and Data Set Definitions form what we call the System Definitions. These are the building blocks that, once defined, one can use to create Dependency Build, Promotion, Package and Deployment definitions. Though these all vary in content, they are all similar in structure to the 'normal' build definitions used on the distributed side. In fact, when submitting a dependency build, promotion, package or deployment request, it is all handled by the same Jazz Team Build infrastructure that we already know. For building on z/OS, instead of using the Jazz Build Engine, you use the Rational Build Agent which supports the dependency build, promotion, packaging, and deployment definitions.
Just as we do in distributed environments, a stream structure is created that often mirrors the various test or quality level environments a system/application must pass through on its way to production. It is common to have Development, Integration, QA and Production streams. Dependency builds, which are smarter in that they only build what needs to be built based on what has changed, are typically performed against a development stream. There are also 'personal' dependency builds, much like the 'normal' personal builds, whose goal is to ensure a developer doesn't break the team build by executing the team build against the developer's changes before they get delivered to the development stream.
Once the software has reached a certain level of maturity and has been sufficiently tested, it is time to begin promoting the changes through the development hierarchy. This involves moving source changes from one stream to the next in the hierarchy AS WELL AS the build deliverables between data sets on the host. The goal here is to maintain consistency between levels, minimize rebuilds and reduce the risk of introducing an error and invalidating the test results achieved at lower levels. On the distributed side, similar activities occur, however, it is done so through explicit stream to stream deliveries, rebuilds at each level, and manual and/or scripted movement of build outputs.
To help with the transition to concepts and thinking in the mainframe world, check out these useful resoInt
z/OS basic skills information center
While I've compiled a vast network of RTC experts, it's now expanding to include those passionate about and very knowledgeable in my new 'normal' world inclusive of System z. For IBMers venturing into RTC for mainframe, these are the people to know. For customers, pay attention to blogs, articles, forum posts and conference presentations by these folks. With their help, hopefully soon I'll be included in someone's similar list.
Now if only I can find a way to use 'Stupid is as stupid does'.....