This article focuses on the use of IBM’s Rational Asset Analyzer product in CICS and/or IMS TM transaction analysis.

By Ravikanth Chali

You’ve just been assigned to a  new project team … or?  You went to work for a new company… or?  You’ve jumped back into some pool of complex CICS or IMS TM (you remember it as: IMS DC) transaction you once authored programs for – either because you have to pick up support or have to analyze a change.  What’s the first thing you do?

1. Start reading the code – either in ISPF or from listings (Dude… listings?  Really?  Why stop there.  Perhaps  there’s a deck of punch cards lying around…)
2. Phone a friend – sorry, this isn’t “Who wants to be a millionaire” – you are the Subject Matter Expert – no dodging this one
3. Scramble to get your resume up on www.monster.com

If none of the above options appeal to you – or they’re just not viable the current state of software jobs being what it is, allow me to introduce you to Rational Asset Analyzer – IBM’s enterprise static code analysis tooling that will provide a 4^th option for tasks such as this:  Study the semantics of the system top down, following graphic flows and using hyperlinks for navigation.  Sound appealing?  I thought so.  Let’s explore…

 

What is Rational Asset Analyzer?

Rational Asset Analyzer: sometimes called Asset Analyzer or RAA for short – is a classic static code analysis product that was created in response to the Y2K century/date math/Impact Analysis conundrum, circa 1998.

There were about a dozen such tools on the market back then, most of which have gone the way of the

IBM purchased RAA shortly into the 21^st century and they’ve been enhancing it since then – making the product stronger, bigger (more of a z/OS enterprise-quality tool) and injecting the code base with new functionality – including (but not limited to):

• Java/J2EE analysis
• Web Services analysis
• Business Rule Mining
• Code Quality/Code Review

Perhaps in some future Royal Cyber Newsletter(s) we’ll delve into these four topics (let us know what YOU are interested in) – but let’s get back to analyzing online transactions.  BTW – Static Code Analysis is the investigation of application behavior and synthesis of program semantics by reading source code – without  running or debugging programs.

 

How RAA works…

The way you utilize RAA is that, after you’ve installed the RAA server (either on a Wintel server or on z/OS) – you “collect inventory” – by:

• Kicking off a wizard from the RAA front-end (an I.E. / Firefox or Chrome browser at the release and level supported by the version of RAA you’ve installed)
• Pointing at the inventory to be collected – this is comprised of (for MVS Assets**)
  • Source language files:
    • COBOL, PL/I and Assembler are supported.  Primarily ANSI-standard (aka IBM) dialects
    • It should be noted that RAA will find and document languages such as: CA-Easytrieve, XML, etc.  However, these assets are only catalogued in the Repository.  No analytics are performed on them.
  • Copybooks and includes, plus the proper copybook (SYSLIB) path (called “concatenation sets”)
  • JCL – both runstream and Procs
  • Transaction (RDO or IMS GEN) formatted table entries – these are derived from an ISPF panel (part of the RAA installation process) that reads the system tables and creates an extract file
  • DB2 table, view and stored procedures – pulled from the catalog by running an ISPF panel-driven utility

…and scanning/parsing and analyzing the inventory.

Inventory scans produce entries in the RAA repository (a set of ~200 DB2 tables) that contain application “meta-data”.  Meta-data includes: Elements and Relationships among elements about your application derived from the code that you’ve fed into the inventory process – and which constitute a static model of your application available for analysis.  Errors may (well) occur during inventory collection for things such as missing source, unknown elements, etc.  These will most likely need to be resolved – and typically will be by an RAA Admin team that is dedicated to loading and managing the server.

There are – of course – additional steps and procedures necessary to build out a true production-scalable system, including optimizing/tuning the database, setting up security/access to the repository, creating “source-synch” processes for incremental inventory collection tied to application version upgrades, integration with your shop’s source management system, etc.  For information on what we recommend for these aspects of real-life/large-scale RAA utilization contact us: inquires@royalcyber.com

 

Analyzing Online Transactions

Once you’ve gotten the meta-data collected in the repository you can begin doing online transaction analysis.  We’ll talk through the use of RAA for CICS application/transaction work but (almost) the same sets of features exist for IMS TM applications.  The one major difference being that RAA does not capture any meta-data on MFS screens – while it does understand and relate BMS Maps/Mapsets back to Transactions.

Questions you can answer – and assets you can trace from the starting point of an Online Transaction include what are shown in Figure 7.  Essentially you can begin by searching for a given Transaction and from there learn/examine the model of the Transaction’s elements and dependencies.

** Recall that RAA also supports distributed technologies such as: Java/J2EE and Web Services

Figure 7 – Transaction Semantics Captured by RAA and rendered through views of your static code stored in the RAA Repository

So you can see from Figure 7 that:

• Transactions are defined in (they execute in) a given CICS Region
• A Transaction is comprised of one-to-many Run Units.
• A Run Unit is comprised of one-to-many programs
• Each program can interact with:
  • BMS Map/Mapsets
  • TD or TS Queues
  • a VSAM files
  • Databases (DB2 tables/views or IMS segments)
  • And a program can (in turn) launch another Transaction.

Not shown in Figure 7 is that you can also capture what are called “User Defined Relationships” – which are manually-specified relationships between any element in the repository and any other element.  Manual specification is distinguished from the automatic inventory collection that is the primary means of capturing meta-data.

User Defined Relationships (UDRs) are often utilized for defining relationships between (say) an EJB-Jar file with a CICS transaction.  Once defined in the repository RAA automatically associates the UDR with both the EJB and CICS transaction detail pages.  UDRs also participate in RAA’s Impact Analysis – allowing you to uncover say, what impact a change to a Jar file would have on any CICS transactions that service the EJB.

 

Steps…

Starting from the RAA home or landing page, the steps to access CICS Transaction information are:

• From Explore  >  MVS assets  >  CICS online region > Total

4   Select a CICS site

• From the Transactions tab use Search to identify one or more Transactions you are interested in exploring
• Select (click) a Transaction and from CICS transaction details  >  Actions select: Show the CICS transaction diagram, and from the diagram:

Transaction diagrams allow standard GUI mouse actions:

4   Hover (mouse) over the various elements in the diagram – to understand what they represent

4   Discover the relationships among elements:

4   Double-click any of the following, and trace the related assets – studying as much as you are interested of:

• Run Units – an RAA Run Unit is comparable to a composite load module
• Program
• Online files and/or databases
• BMS
• TD (Transient Data) or TS (Temporary Storage) Queues

Let’s take a look at an example.

 

An RAA CICS Transaction Diagram

Figure 8 shows a picture of a single transaction (AC01) – and all of the Run Units potentially invoked, BMS Maps/Mapsets and TD/TS Queues that are used in a Run Unit.

To understand this diagram:

• The Run Units are green: ACCT01, ACCT02, ACCT03

• Transactions are beige:  AC01, AC02, AC03

• Online files are also beige (but have a different icon): ACCTFIL and ACCTIX

• BMS code is shown in red: ACCTMNU, ACCTMSG, ACCTDTL

• TS Queues are mustard yellow colored: ACERLOG, AC0, ACCTLOG

This Transaction diagram looks – on the surface – like quite a complex little drawing but three things about how this?

1. You can collapse individual Run Units down so that the complexity is – to some degree minimized.  We’ve expanded a few Run Units in the Transaction diagram shown in Figure 8, in order to give you a better picture of what RAA is capable of

1. I guarantee that most – if not all of your production transactions are factorially more complicated than this example – which ships as sample/learning application code with RAA

1. Consider the amount of time and effort it would take to piece together the semantics shown here: AC01 invokes ACCT01 – which in turn invokes; ACCT, AC02 and AC03.  Various programs in the ACCT01 Run Unit use BMS maps: ACCTTL, ACCTERR and ACCTMNU.  They also write to: TS queue AC0 (you can tell that it’s a write operation because of arrow direction).  In order to understand the semantics of even a simple transaction like this:

• You would be reading and cross-referencing dozens of files, some of them in RDO table s you might have access to
• You’d be visiting with Subject Matter Experts – expending their cycles
• And at the end of hours-to-potentially-days of) work?  You’d end up with a mental picture that at best matched Figure 8 – which was obtained via a single mouse-click.

Figure 8 – The partially-expanded semantics of a CICS online application beginning from trancode: AC01

 

Drilling to analyze the details

As helpful as Figure 8 obviously is – if all of RAA is an apple, its Transaction diagram is one small piece of the skin.  By single-clicking the ACCT03 Run Unit (highlighted in Figure 8) you drill-down into the details of the Run Unit.  The first screen you would see is the    Run Unit Details page (not shown).  From an Actions combo-box on the Details page, you could generate a Run Unit diagram (Figure 9).

The Run Unit diagram takes your analysis to another level of precision by exposing – in this case – that 5 CICS transactions invoke the ACCT03 Run Unit.  And that the entry-point into the Run Unit is the program ACCT03 – shown in blue and highlighted.  Other details include ACCT03 – the program sends 2 BMS maps, writes to a TS Queue and calls ACCT04, etc.

If you then clicked ACCT03 (the highlighted program in the diagram) you would end up at a Program Details page – which provides an extensive amount of meta-data on the program (copybooks used, Calling/Called programs accessed, DB2 tables/columns referenced, Batch jobs and Online transactions in which the program participates, etc.  There are also 25 Actions including one which describes the logic in the program: a Control Flow diagram (Figure 10).  This diagram (like the same function in Rational Developer for System z) shows the structure of the program’s PROCEDURE DIVISION – and (in the case of ACCT03) exposes little execution miracles such as paragraphs AC05 and AC06 GO TO’ng their paragraph labels recursively (note the boxy arrows that flow from the back of AC06/AC05 to the front of the paragraph).  As an aside, each paragraph is hyper-linked (thus the underlined paragraph name).  If you click a paragraph from a Control Flow diagram the program source opens – and the paragraph highlighted.

Figure 8 – The partially-expanded semantics of a CICS online application beginning from trancode: AC01

Figure 9 – An RAA Run Unit (ACCT03) – showing specific relationships and dependencies

Figure 10 – An RAA Program Control Flow diagram of the ACCT03 program

 

Our view

So, utilizing the technique of drilling down from higher to lower levels allows you to grasp the semantics of: Transactions è Run Units è Program logic at a glance … to understand the dependencies and relationships among various application elements and to hyperlink to any point of interest in the repository from a single mouse click.

It’s funny… as I proofread that sentence after I wrote it, the phrase “… from a single mouse click.” seemed a little “Madison Avenue”, y’ know… just a little too… effusive.  But honestly?  The more we use RAA in our work (and we do… use RAA on Royal Cyber z/OS engagements) the more it seems like RAA is some sort of IBM “best kept secret”.  And in describing RAA’s value to z/OS maintenance and support programmers doing common/every day project work – and in representing what it does with phrases that are a bit over the top … well … it doesn’t exactly seem like a crime.

 

Next steps…

Where can you learn more about RAA…either from us or from IBM.  IBM has also published a few RAA Redbooks with RAA content—such as: http://www.redbooks.ibm.com/abstracts/SG247868.html?Open

However, at Royal Cyber we also do RAA demonstrations – for those of you who might want to see RAA running vs. a few static screen captures (and really… there’s no comparison, static captures/Redbooks do not do RAA justice).

We also consult on RAA.  We bring a 3rd Party objectivity to your projects and our work on them.  And we have the practical/production expertise to help you manage true production projects.  Finally, we offer high-quality RAA training that was built from our customer and personal experience with RAA.

Click to contact us about our RAA service offerings  and request an online/remote demo.  After the demo judge for yourself if this article is “effusive” – or maybe a little understated in its view of RAA’s value to z/OS traditional maintenance, production support and development work.

Ravikanth Chali is a senior technical consultant with Royal Cyber.  He has ten years of experience in Mainframe application/ tools development including Eclipse and RDz plugin-ins.  Ravi is very well versed in the usage and best practices related to RDz and RAA.  He has specialist skills in writing Eclipse plug-ins to RDz.