1. Rational Developer for System z Unit Test Feature
A new feature providing mainframe development flexibility
David Myers
Rational Developer for System z Product Manager

2. 2
Business constraints with mainframe development today Which limits the amount of System z production workload coming online
“My development capacity charge-back is consuming my entire budget. I can’t spend on tools.”
“We don’t have the capital budget to obtain more mainframe test resources for my developers.”
“I can’t even work on Mondays! Production workload kicks me off.”
“It is difficult for my developers to learn the mainframe. Operations controls can prevent experimentation by developers..”
“I can only test my batch applications in offline hours. Online apps consume the 9-5 cycles.”
“Operations tell me it will take two months to get my test system allocated.”
“The Mainframe isn’t cool anymore.”
“I want to try out creating Event Processing and ATOM apps, but my system isn’t scheduled for a CICS/IMS update till 2012.” 2 2

3. Mainframe development environment with RDz and ISPF RDz provides relief…but customers want more
RDz user
ISPF user
RDz user
Modern IDEs like RDz:
Productivity enhancing tooling; more attractive tooling for new developers
Ability to offload some development MIPS usage
Integration with complete application lifecycle tools
But challenges remain:
Business pressures to manage mainframe MIPS usage for development
Unit test delays caused by dependencies on operations team 3

4. Today’s RDz AD development cycle4
Today’s RDz AD development cycle
Application Developer
Wintel
Using tooling like RDz definitely has benefits and still some challenges, especially with testing….
System programming challenges
Gap between the Developers and IT Operations staff
Lack of available System programming skills or delays in getting requests completed
Cross platform application development
Developers don’t have control of non-Intel systems
The ability to easily configure and deploy an application to the target runtime for testing can be a very time-consuming task.
The mainframe development environment is perceived as being more expensive on System z than on other platforms
Actually, there is no differentiation of mip costs between development mips vs test mips vs production mips.
What does this cost companies?
Create
Rational
Developer for
System z
Common
source code
System Programmer
System z
Build
High
Level
language
Java
COBOL
PLI
System z
executable code
OS/390
Test
OS/390
Test
OS/390
Test
The ability to easily configure and deploy an application to the target runtime for testing proves to be very programmer time-consuming task as well as the ability to automatically test the resulting application/service. This is accentuated when considering composite applications consisting of WAS and another platforms’ runtime.
System z
Formal
Test
System z
production
ready code
OS/390
Test
Prod

5. COBOL, PL/I, C++, Java, EGL, Batch, Assembler, Debug Tool
RDz Unit Test Feature The ultimate in modern application development for System z
NEW!
COBOL, PL/I, C++, Java, EGL, Batch, Assembler, Debug Tool
IMS
DB2
CICS
WAS MQ
RDz user
z/OS
RDz user
x86 PC running Linux
RDz user
ISPF user
RDz user
RDz & ISPF user
Liberate developers to rapidly prototype new applications
Develop and test System z applications anywhere, anytime!
Free up mainframe development MIPS for production capacity
Eliminate costly delays by reducing dependencies on operations staff
Note: This Program is licensed only for development and test of applications that run on IBM z/OS. The Program may not be used to run production workloads of any kind, nor more robust development workloads including without limitation production module builds, pre-production testing, stress testing, or performance testing. 5 5 5 5

6. Introducing the RDz Unit Test Environment
Application Developer
Win/Linux
Provides a local test environment for unit testing System z applications
unit test processing on Linux versus mainframe
Can enable companies obtain lower cost for development and unit testing
Gives flexibility to Developers/Teams to accomplish unit tests on the mainframe or off
Provides a local System z development/unit test environment to simplify development investments
Frees up more mainframe capacity to production workload usage
Strengthens development processes through using actual compilers and runtimes in RDz Unit Test
Use compilers for “true” syntax check/compile using Enterprise COBOL/PLI
Use co-processors for IMS/CICS/DB2/Custom to cut down on re-implementation efforts on local platform
Provides flexibility for system programming staff and development
System programmers can define common test images for development teams for some centralization of control, but still provide developers with ability to make changes
Create
Rational Developer
for Systme z and
Unit Test Feature
Common
source code
Build
High
Level
language
Java
COBOL
PLI
Test
System z
executable code
System Programmer
System z
Build
OS/390
Test
OS/390
Test
OS/390
Test
System z
Formal
Test
System z
production
ready code
OS/390
Test
Prod

7. RDz Unit Test Offering Description
The RDz Unit Test Feature consists of:
Unit Test Environment (based on zPDT)
Unit Test Environment can provide a System z development platform on a PC
capable of running z/OS
provides great flexibility to run a customized environment
Software stack provides a choice of IBM middleware test environments
actual middleware software (including z/OS)
actual enterprise compilers
no API simulation
RDz and RTCz agents
packaged for simplification
still need RTC and RDz client license(s) to activate
RDz Unit Test
RTCz Agent
RDz Agent
System z S/W Stack
Debug Tool
CICS DB2 WebSphere/z IMS
Assembler COBOL C/C++ PL/I z/OS
Unit Test Environment
x86 PC running Linux
<USB License Key> 7

8. RDz Unit Test limitations
The RDz UT environment does NOT support all System z function, such as:
Physical Parallel, ESCON®, FCP, FICON® and High Performance FICON channels
Coupling links and coupling facilities
List-directed IPL
External Time Reference (ETR)
Server Time Protocol (STP)
MIDAWs
Logical channel subsystems
HiperSockets™
Multiple I/O paths per device
Not all CHSC functions are supported
Some IBM System z Crypto Express2
Some IBM 3088 CTC device
RDz UT does not produce an environment equal to a larger System z.
Some aspects of a larger system are unlikely to be met in any very small environment.
Inability to verify and enhance the scalability of a program
Inability to run application programs that require hundreds of MIPS.
A UT system is not recommended for very fine-level performance tuning that is sensitive to memory location, cache functions, and pipeline optimization.
In addition, the UT platform does not nearly have the same quality of service as does a mainframe in terms of availability and connectivity.
Anyone needing any of the function outlined above should consider a traditional System z server.

9. How will RDz UT help me?
Are you interested in testing your application changes on your PC/off-mainframe?
RDz Unit Test provides a x86-based environment where you can test z/OS applications on a desktop or server machine
Are your development systems overloaded?
E.g., My development system is so slow! It takes 1 hour to compile!!
E.g., There are not enough resources available for development
RDz Unit Test provides a low cost mechanism to create additional development capacity without mainframe HW upgrades.
Do you have difficulty testing application changes? Is too difficult or takes too much time to make changes to your test environment? Are there too many requests for unique test environments than your ops team can fulfill (catastrophic event testing, system failure, impact analysis, etc)?
RDz Unit Test provides a separate test environment under the development team’s control allowing quick environment changes to be performed by development. The UT environment can be assigned to a small teams for unique test environments allowing more robust testing
Are you being asked to use fewer MIPS for development
RDz Unit Test provides a 0-MIPS development environment, allowing additional development resources to be easily allocated

10. Smarter Testing in the cloud
How do we improve application quality?

11. z/OS Testing Architecture
Testing is organized by application test teams sharing resources with limited automation
z/OS
Application
Test
Team
TEST LPAR
Test AS
Application
Test
Team
Test
Data
Application
Test
Team
Test AS …
Application
Test
Team
Test AS
File Name Here.ppt

12. Vision for the future
Level playing field between mainframe applications and distributed applications
Automated cloud of z/OS testing environments
Readily available
Easy to define, provision, and dispose
Low-cost
Collaborative and Agile
Easy to promote work
Continuous integration
Highly automated
Project or release focused
Small-scale
Time bounded
Isolated and focused

13. Testing Organized for Flexibility – After RDz UT
z/OS
z/OS
Production
Application
Test
Team
z/OS UT
RDz UT
Q/A
Data
Integration Test
Data
Application
Test
Team
RDz UT
Data …
Application
Test
Team
RDz UT
Data
File Name Here.ppt

14. Large Financial Customer - Implementation
Requirement
Provide more responsive System z access for application developers
Reduce application software delivery through faster test cycle
Provide each application group their own unit test facility
RDz-UT Solution
Application developers have use of a uniquely defined RDz UT feature for System z access
RDz UT provides a unique test environment for different application development groups
Supports multiple RDz UT development environments on Intel blade to reduce server hardware
Has reduced application development test time

15. Manage z/OS test resources through RQM - Example

16. Moving towards low-cost z/OS automated testing
Automation takes time and human effort
Provides long term value by building up a test bucket
Test automation can be written as function is added to build up the bucket
Plans should be put in place to build up tests for existing function as well
Integrates well with the use of RQM – start with manual test case steps makes it easier to see what can be automated and allows for building up a library of test scripts.
Start with Automating the interactions done in the manual test cases using RFT or RST
z/OS Application Automated Testing can be divided into several categories in multiple ways:
User Interactive (with multiple user interface technologies)
Service Based testing
Each of these can be broken down farther into:
Online Synchronous, Asynchronous, and Batch.
Batch application testing can be automated with a combination of RQM, RFT and Optim Test Data Management Solution 16

17. Running Test Automation
Test cases run through RQM
Users can run automated test cases to specified execution environments
Test cases run as a specified build from RTC
RTC Build engine can be used to kick off a set of test cases on specified platforms. Multiple builds can be run to run tests on multiple execution environments
Test cases run at the end of an integration build from RTC
Test automation can be integrated into the RTC build, such that after the build completes the tests are automatically run
This is the best practice for integration builds for at least a set of regression tests 17

18. Automated Sub-setting and Testing of Data Results Optim - Relational Compare Facility
RQM
RFT
Optim
COMPARE FILE
SOURCE 1
COMPARE PROCESS
Optim
Compare
REPORT
Typical use is to run a test and then compare the before test image (extract file) to the after test data image (extract file or data in the database)
Can also be pointed at 2 different running database instances or 2 different schemas etc.
Map source 1 to source 2 by using a table map
Eliminate columns from the compare by using a column map
By default, uses primary key as the match key between the sources but you can also edit the match keys if necessary.
Data is compared to data
Source 1 or 2 or both may be:
Optim Access Definition (which selects data from DBMS tables)
List of tables in the database
Optim Extract file
Great for regression testing where you expect no changes –
Verify Test Results
SOURCE 2
Compare the test data before and after exercising the application to validate expected test results and identify anomalies automatically and with pinpoint accuracy.
File Name Here.ppt

19. Benefits of smarter testing: Traceability and Insight Lifecycle traceability helps teams answer the harder questions
Which requirements are addressed in this iteration?
Are we ready to release?
Are all of the requirements tested?
Can we pass an audit?
Product Owner
Scrum Master
What defects were resolved in this release?
What’s the quality of the high priority requirements?
What defects are reported against which requirements?
Analysts
What tradeoffs can we make to release on time?
Traceability isn’t simply one of those “nice to have” capabilities in the software development  lifecycle. Traceability helps you understand what everyone else on the team is doing. For example, while the requirements analyst knows very well what requirements she has written, she still needs to know whether a given requirement will be addressed during a specific development iteration and, if so, which one. Or she wants to know if the implementation of that requirement has been tested and with what result.
An ALM solution that allows for lifecycle artifact traceability helps teams to answer the hard questions about requirements and risk management. By linking related artifacts, teams are better equipped to answer questions such as “which requirements are affected by defects?” and “which work items are ready for test?”
 It is important to understand how requirements, test and development are linked by projects and tasks.
DON’T Do traceability for traceability sake.
Identify a few meaningful questions or set one goal and institute a “just enough” approach for linking related artifacts. For example, link requirements and test cases, link test cases and development work items. Try one and get good at it before doing more.
DON’T Rely on reports that go stale after you’ve created them.
Practice continuous traceability: Leverage a system that shows the traceability links directly on the plan, or that uses queries that identify gaps, such as “Plan items without requirements” and “Plan items without test cases”, and “Defects blocking test.”
DON’T Ignore, hide from or hope to pass regulatory audits
Invest in an ALM solution that makes traceability easy to do, maintain and report against.
DON’T: Work in disconnected project repositories, or cobble together a disparate set of tools.
Seek products built with open interfaces. Seek vendors who understand and support the ALM integration challenges. Invest in tools with a longer-term integration roadmap in mind.
DON’T: Enter links manually after the fact, it’s easy to forget, hard to enforce.
Integrated tools make it easy to establish as the project executes. See image of linked Defect in upcoming slide
DON’T: Build your own integration based on proprietary API’s.
Choose a solution with open services (OSLC) for linking data across the lifecycle.
DON’T: Choose a one-size-fits-no-one solution.
Invest in a loosely coupled, integrated ALM solution that is built to scale and support open and flexible integrations. A single ALM repository will not scale to fit your needs over time. Times change, new products emerge; your ALM solution needs to be flexible enough to move with the times. Do you really want to face that data migration challenge?
Quality Professional
What is the quality of the build?
Developer
What requirements am I implementing?
Release Engineer
What has changed that I need to test?
How can I recreate the last version to do a patch?
What defects have been
addressed since the last build?
What test uncovered this defect, on which environment and what build?
How can I standardize when teams use different tools?
Are build times getting longer or shorter?
What changes occurred overnight?
How can I speed up my builds?
Where are the bottlenecks in our processes? 19 19 19 19

20. Relationship views enable continuous traceability
Find and respond to gaps as they surface through out the project
Tracing through out the project improves regulatory compliance
The image shows a traceability view in Release Plan containing links to requirements and test cases. It also has a column to identify defects affecting the plan items. This demonstrates an integrated plan with traceability reporting. Rather than relying on stale and occasionally run traceability reports, using an integrated plan with a built-in traceability view makes the gaps are obvious and easy to address through out the project. 20 20 20

21. Plan-item Traceability improves quality and predictability
Everyone's work aligns to the requirements and goals of the customer
Team members have transparency to each others work and the “new reality” is always available
All worked is linked and visible giving the team insight into when all work is done
Developers understand the requirements, test results and test criteria
One of the easiest things to do for development teams is to simply focus squarely on accomplishing their work handing only the deliverables between groups when they are ready. A lot of the rework, misunderstandings, etc results from teams not having visibility or coordinating their activities so that the team can work as a whole. Our ALM solution provides them with transparency in the context of the work you’re doing and the ability to go get more information if necessary, its beyond simple linking – its data rich integration and coordination based on the interrelated activities in ALM. We go far beyond simply making sure one file in one product can link to another the way the majority of our competitors do in order to check box an ALM marketing message.
Testers define and execute tests cases with a clear understanding of requirements and
Teams collaborate and clarify the details of requirements 21 21 21 21

22. Defect Collaboration reduces costs and improves quality
Testers execute tests and submit defects found to RTC
4-clicks to submit a defect automatically linked to impacted artifacts
Test results are recorded and linked to test cases, and associated requirements
Test results can be linked to software builds
Everyone has visibility into the defects, their impact, and the action taken to resolve them
The most common ALM sub-cycle is the Development – Test cycle. Developers develop a solution that must be tested – this is an important cycle that takes up a significant amount of the development and ongoing maintenance effort. Our solution was developed in unison to make sure we can automate and improve this cycle as much as possible. Our solution reduces the overhead typical of the development <-> test cycle and improves the transparency so that this cycle can adjust to unforeseen circumstances. Our highly integrated development <-> test solution realized by RTC and RQM enable us to offer a solution that can increase productivity and time to market.
Developers can see the exact test failure without having to ask and remediate it 22 22 22 22

23. Top 5 Questions
1) What is the maximum number of developers a RDz Unit Test server can support?
This can vary depending on the underlying hardware and workload being tested. Desktop/Laptops can typically support 3-5 users. Low end server class machines can support users.   At this time, IBM has not provided a detailed analysis of RDz UT server sizing.
2) How can I get test data for use in RDz Unit Test?
Customers can use existing tools like IDCAMS, DB2/IMS utilities, etc. to extract test data and then download it to the RDz Unit Test machine. RDz Unit Test provides a volume duplication utility that can download an entire 3390 data volume as needed into the UT environment. Facilities such as CICS remote function shipping or DB2 Remote Data Access can also be utilized.
3) Can I run other levels/backlevels of the middleware provided?
Yes, based on existing mainframe entitlement the request can be evaluated and some requests may not be approved. Requires special licensing dispensation from IBM, not automatically entitled with purchase of RDz UT.
4) Can I use other IBM tools in the UT environment?
5) Can I run third party software?
Yes, if the third party license allows this. Customers must work with their software vendor to determine licensing considerations.

24. Additional Questions 6) Does this require system programming skills?
Vanilla configuration ready-to-go out of the box
z/OS does require system programming skills to set up the development and/or testing environments if users want the UT environment to mirror an existing host configuration.
You can usually set up one box/image and transfer the configurations to another box easily (VMWare style).
7) What about security?
RACF is installed, but with minimal configuration.
The sample configuration guide has suggestions for basic security.
Security is a site choice. The ability to customize z/OS on a platform designed for individuals or small teams may:
Provide better testing opportunities
Provide customization for individual productivity gains
Provide opportunities to learn about z/OS fundamentals

25. RDz UT host machine specifications
Underlying Linux host
Red Hat Enterprise Linux 5.3 (RHEL 5.3)
OpenSUSE 10.3, 11.0, and 11.1
Note: IBM does not support installation on other distributions.
Base machine must have:
at least 3 GB of real memory:
1 GB is required for the 64-bit Red Hat or openSUSE Linux
1-2 GB is required for the System z operating system, depending on the size of the development system
at least 80 GB free disk space available after Linux
Note: RDz UT has been tested on:
Lenovo ThinkPad W Series
IBM System x 3500 M1, 3500 M2, 3650 M1, and 3650 M2

26. Summary - Benefits of the RDz Unit Test Feature
Increased application quality using the included IBM runtimes for testing. Provides a high fidelity testing environment.
Functionality and services more accurately reflect the mainframe
Using actual z/OS middleware means less retesting and rework is required when moving from the unit test environment to the quality assurance or pre-production environment.
Developers have an isolated test environment to test application changes that can then be easily merged into the next level of testing
Deployment of the Unit Test feature on a PC lowers development and unit tests costs and allows MIPS to be reallocated for production use.
Executes on an x86 Server (see backup charts for details)
Utilizing zero development MIPS on the production mainframe for initial application change testing
Frees up additional capacity for new workload while reducing line of business development costs and chargeback.
Provides developers in a single or shared user configuration with increased flexibility and control of the test environment, allowing them to be more productive and improving application delivery times.
Can be assigned to a single developer in a laptop configuration, or can support small-scale team environments
Environments can be tailored to a single developer or team's runtime needs without altering mainframe testing environments.
Can provide a greater level of control for developers to implement quick environment changes without having to involve production operations staff.
Developers can perform their first series of tests and regression testing without worrying about causing unexpected errors.