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 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

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

Today’s RDz AD development cycle 4 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

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

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

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

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.

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

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

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

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

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

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

Manage z/OS test resources through RQM - Example

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

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

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

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

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

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

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

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 15-30 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.

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

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

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.