Agile on the Mainframe (and Other Odd Places)

PooleConsulting

Agile on the Mainframe (1/49)© 2007 Charlie Poole. All rights reserved

Agile on the Mainframe

(and Other Odd Places)

How Mainframe Agile TeamsAre (not so) Different

November 8, 2007Charlie Poole

PooleConsulting


Introductions

PooleConsultingAgile on the Mainframe (3/49)© 2007 Charlie Poole. All rights reserved

Charlie PooleWhat I do…

Languages…

Cobol, PLI, Fortran, C, C++, C#, IBM & Intel assembler

Platforms

Mainframe, Windows, .Net, Linux, Mono, Cross-platform

Coaching and Training

XP, Agile, TDD, NUnit

Open Source

NUnit, NUnitLite, VSUnit, Fit


Charlie PooleMy dubious past…

Languages…

Cobol, PLI, Fortran, C, IBM assembly language

Hardware Platforms

Hardware: IBM, Dec, Honeywell, CDC, Univac

Software Environments

CICS, SQL, VM


About Mainframe Programmers Take a card...

Write a word or short phrase that comes to mind when you think of mainframe programmers, who are still doing it today.

Write several if you like. It’s OK to be unfair – we’ll try to be more

reasonable later on.


Discussion – Part I

What sorts of feelings are represented on your cards? Admiration? Respect? Pity? Disdain? Puzzlement?


Discussion – Part II

Have similar words, phrases, feelings been applied to programmers in your own company? By managers? By co-workers? By you?

What does this mean for introducing Agile?

PooleConsulting


A Mainframe Tale

Experiences at Key Bank


Warning Label

This is a story about one of my clients and is included here with their permission, for which I am very grateful.

For obvious reasons, I will not be able to answer every question that pertains specifically to work being done for this client.

I request your understanding in limiting questions as much as possible to the general ideas this story illustrates.


A Mainframe Tale

Key Bank is a very forward-looking company in its software development and has introduced agile approaches company-wide over the past few years.

They have their own internal coaches and bring in other folks from outside as needed.

They have been very successful at it.


A Mainframe Tale

From the preceding, you can see that Key Bank are not amateurs at Agile...

except on the mainframe...

where we are all amateurs.


A Mainframe Tale - Details

Key has LOTS of mainframe work, even as they increase their use of desktop and distributed apps.

Almost everything else depends on the mainframe apps.

The programmer population is getting older.

Conversion is not practical for much of this work.


A Mainframe Tale - Details

Key has introduced Agile development in all technical areas except for the mainframe.

Management likes what Agile does for them, but they aren’t getting it from the mainframe.

Programmers don’t know how to give management what they want.


Interlude: How I Got into This Experience

Mainframe (years back) and Agile coaching

Attitude Respect for Mainframe programmers Like a challenge

Availability Nobody else wanted to do it


A Mainframe Tale - Objectives To support agile in the mainframe environment. In

particular, mainframe development should not appear to be an impediment in the overall flow of technical work.

To be able to prioritize features and deliver them incrementally, rather than waiting for the end of a project.

To shorten final testing times after introducing more reliable testing into the development process.


A Mainframe Tale - Objectives To identify the aspects of agile methodology, which

are relevant to mainframe development – in most cases by actually trying them out.

To be able to estimate projects more aggressively in the future.

To be able to react quickly to problems and changes.

PooleConsulting


Defining Agile

What Do We Want?


Defining Agile - the Wrong Way Agile is sometimes taken to mean practices

Doing Test-Driven Development Using Scrum etc.

Not a satisfactory approach It assumes Agile can be made into a recipe Doesn’t help us move across technologies


Defining Agile Based on Results

“Create real software in an iterative fashion, delivering small functional increments on a

regular basis so that the team and the users can always see real progress”


Top-down Agile – the Wrong Way Tell the programmers to be “agile”

Tell them precisely how to be agile

Make sure they do it


Top-down Agile – the Right Way Tell the programmers why agile is important to the

company.

Tell them what results you want to see.

Ask them to figure out how, providing them the time and support they need to do it.

Identify and remove obstacles.


One Good Thing About the Mainframe We don’t have pre-existing tools and

practices in most cases.

We can’t tell them how to do it.

We are forced to enable the developers to “invent” their own flavor of agile.

PooleConsulting


Mainframe Obstacles


Mainframe Obstacles

Very large file sizes are the norm, leading to long run times for any tests.

Test runs consist of a number of interdependent jobs and it is often not possible to run tests of a single job step.

For many applications, programs are not run directly but are under the control of a third-party application (Hogan) which is widely used in the banking industry.


Mainframe Obstacles

The need to submit jobs and then wait for them to complete makes mainframe development proceed at a much slower pace than desktop work. Developers must either wait or turn their attention to some other task while a test proceeds.

For test runs, job steps must often be staged manually, because automated scheduling is not available. Because of processing demands during the day, this is reported as frequently done by developers working from home.


Mainframe Obstacles

Existing utilities, such as dump analysis and tracing tools are not always used systematically due to unfamiliarity or inconvenience. Practice in this area can differ significantly from developer to developer.

For most applications, there is no standard test bed used to automatically run tests and determine if regressions have occurred. Where such tests exist, manual review is usually required.


Mainframe Obstacles

The verification of test results is often manual, although it may sometimes be assisted through the use of file comparison utilities.

Testing tools, such as exist in the worlds of desktop and distributed development, are not generally available for the mainframe, and would need to be developed locally.

In many cases, separate tools are needed for Hogan and non-Hogan applications.

PooleConsulting


COBTEST

A Low-level Test Framework


Second Warning

This is more interesting than important!


COBTEST : a Prototype Test Framework Works for both Hogan and non-Hogan Cobol

programs.

Tests at a very low level – xUnit style.

Building block for higher level tools.


COBTEST Structure

ProgramUnder Test

Test Program

Test Framework(COBTEST)


Using COBTEST

CALL ‘COBTEST’ USING INIT-ACTION.

PERFORM ACCOUNT-TESTS.

PERFORM TEMPERATURE-TESTS.

PERFORM FRAMEWORK-SELF-TESTS.

CALL ‘COBTEST’ USING TERM-ACTION.


Using COBTEST

TEMPERATURE-TESTS. MOVE ‘BOILING POINT’ TO TEST-NAME’ MOVE 212 to F-TEMP CALL ‘TEMPF2C’ USING TEMPS MOVE 100 TO EXPECTED-PACKED MOVE C-TEMP TO ACTUAL-PACKED CALL CHKPACK …


COBTEST Entry Points

COBTEST Initialization and Termination

CHKEQUAL Compare two alphanumeric fields

CHKPACK Compare two packed fields

CHKBIN Compare two binary fields


TESTSPEC Copy Book77 INIT-ACTION PIC X(4) VALUE 'INIT'.77 TERM-ACTION PIC X(4) VALUE 'TERM'.

01 TEST-SPECIFICATION. 05 TEST-NAME PIC X(50). 05 USER-MESSAGE PIC X(50). 05 EXPECTED-VALUE PIC X(100). 05 EXPECTED-REDEF-1 REDEFINES EXPECTED-VALUE. 10 EXPECTED-PACKED PIC S9(9). 10 FILLER PIC X(91). 05 EXPECTED-REDEF-2 REDEFINES EXPECTED-VALUE. 10 EXPECTED-BINARY PIC 9999 BINARY. 10 FILLER PIC X(98). 05 ACTUAL-VALUE PIC X(100). 05 ACTUAL-REDEF-1 REDEFINES ACTUAL-VALUE. 10 ACTUAL-PACKED PIC S9(9). 10 FILLER PIC X(91). 05 ACTUAL-REDEF-2 REDEFINES ACTUAL-VALUE. 10 ACTUAL-BINARY PIC 9999 BINARY. 10 FILLER PIC X(98).


COBTEST as a Tool

Aimed at tests written by programmers before or during coding. Tests are of individual programs or routines. Test program supplies data, one case at a time.

Can also be used to find out how a routine responds to various inputs.

Need other tools for other purposes.


Potential Extensions of COBTEST Run tests dynamically, based on input

Possibly, separate Hogan and non-Hogan runners

Additional test predicates and data types

Data driven tests Test reads inputs and expected values

Data interception Test is inserted into processing flow


A Major Weakness

COBTEST enables running small, fast tests as you work.

Unfortunately, it can take 20 or 30 minutes to submit the test and get the result.

Two possible solutions… Come up with way to eliminate the wait time. Invent new patterns of working that take the time delays

into account.

PooleConsulting


An Agile Workshop

Engaging Mainframe Developers


An Agile Workshop

Open Space Format

Approximately 70 mainframe developers

Approximately 40 sessions offered around our two-part theme.


Workshop Theme

What would it meanto be agile

on the mainframe?

How can we

make it happen?


An Agile Workshop

Half day introduction to what agile means

Two Days of Open Space

Half day follow-through Session reports and project organization Creation of project backlogs Top-level management acceptance


After the Workshop

Teams are organized as for any project, with a top-level manager as the Product Owner.

Mix of “low-hanging fruit” and projects requiring a long-term effort.

Quarterly two-day workshops will be held.

PooleConsulting


Conclusions and Discussion


Conclusions

Agile on the mainframe has unique problems.

We are forced to rely on the programmers to invent the practices they need.

We hope that doing so will give us a better set of practices.


Meta-Conclusion

This is what we should be doing anyway!


Odd Places…

Are there other “Odd Places”

where this approach

might work?

What about your project?


Thank You


Documents

Agile on the Mainframe (and Other Odd Places)