S424. Soa Mainframe Practices Best And Worst

S424. Mainframe Service
Architecture and Enablement
Best and Worst Practices

• Michael Erichsen,
Chief Consultant, CSC
• Stockholm, 8 June 2011

CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 0

Main points

• Why are we doing this?
– We have done integration projects in decades
– Service orientation can be a qualitative improvement
– The new aspect is open, standardized, loosely coupled interfaces
• Best practices are mostly found in the technicalities of service
enablement
– Case studies of seven different ways of doing it
• Best and worst practices are found in the service modelling and in the
implementation of models and architectures
– Some principles and patterns based on best practices
– Worst practices illustrated by ”anti-patterns” and research in what can go wrong
and how


A Conceptual, Technical View of Service Enablement


A Conceptual, Modelling View of Service Enablement


SOA Mainframe Practices – Best and Worst

To Begin with the
Conclusion


Why are we doing this?
Which problems are we trying to solve?

• The world is fast and messy
• Businesses and authorities need to
adapt very quickly to survive
• IT systems are generally
heterogeneous
• It is a mess - and it will remain so
• Service interfaces hope to remove
some of the mess – but also
introduce new kinds of mess


Reuse?
Oh no, not again!

• Software reuse is the process of
creating software systems from
existing software rather than
building software systems from
scratch
• First proposed in 1968
• Four dimensions:
– Abstraction
– Selection
• Classification
• Retrieval
• Exposition
– Specialization
– Integration


Reuse?
Promises, promises, promises…

• Over time
– Component Libraries with automated
customization
– Cut and paste of COBOL code
– Application Generators
– Object orientation
– Frameworks
– Service interfaces
• Reuse is not a technology, but a
culture
– Why not reward for reuse and
reusability?
• Otherwise a vendor might earn more
money by not reusing


Overarchitecting and Overengineering

• You need an enterprise
architecture, an enterprise data
model and good business process
descriptions to get the full business
and economic advantage of such a
project
• Reuse depends on a higher level
of abstraction
– But too many levels of abstraction
could mean that you can’t use it at all
in the first place


Extending or replacing Mainframe systems?

• The mainframe platform is
continuously under siege
– IBM's monopoly makes it difficult to
forge alliances
– The only practical solution to the age
problems seems to be offshoring
– The best way to protect the big
investments in mainframe systems is
to open them as equal partners in
modern architectures
• Not COBOL or Java/.Net, but strategy
and interfaces
– Using zSeries for SOA Infrastructure
interesting, but not unproblematic


The real economy of zIIP’s and zAAP's

• MIPS come cheaper, but they are
certainly not free
– Processor costs
– Other operation costs
• Investment in real storage
– Much more expensive than other
memory hardware
– Java Virtual Machines need very
large heap sizes for many
applications, including SOA
infrastructure like ESB’s and
BPMS’es
– Memory overcommit perhaps only
1,5 on new workloads?
• Calculate economy very carefully
to compare with other platforms


Lewis et al, SEI-CMM:
SMART: The Service-
Oriented Migration and
Reuse Technique


SMART: Defining a service

• A service is a coarse-grained, discoverable, and self-contained
software entity that interacts with applications and other services through
a loosely coupled, often asynchronous, message-based communication
model
– Quoted from Brown et al, Rational: Using Service-Oriented Architecture and
Component-Based Development to Build Web Service Applications


SMART: Defining a SOA

– A SOA is a collection of services with well-defined interfaces and a shared
communications model. A system or application is designed and implemented
to make use of these services
• 1. Service interfaces are added to existing enterprise information systems for
applications to use, while these systems remain unchanged for internal users
• 2. Service-specific code is written to provide functionality for applications to use
• 3. Services written by third parties and deployed elsewhere are used within applications.
– SOAs also offer the promise of enabling existing legacy systems to
expose their functionality as services, without making significant changes
to the legacy systems themselves
• This is one of the most attractive features of SOA to many organizations that do
not wish – and cannot afford – to walk away from their investment in legacy
systems or redevelop the same capabilities as services from scratch



Technical Best Practices:
Seven Case Studies


Seven Case Studies

1. A Tactical Service Enablement
2. A Tactical Service Enablement Evolving into Strategy
3. COBOL IMS in a large Scale SOA Environment
4. International, multilateral, heterogeneous and data replicating
5. XML Services over MQ
6. WebSphere ESB on z
7. Service Enablement of a Legacy Application Generator System


Case #1: A Tactical Service Enablement

• Back end system
– VSE, CICS, a 4GL and a non-relational data base
• The business need
– Update requests from business partners used in nightly batch runs
• No requirement for online updates of the mainframe system
• Web Services a mandatory protocol for communication
– Security required using TLS and X.509 certificates
– Not a general interface to the entire system, but a tactical solution for a single
demand
• Technical challenges
• VSE native SOAP and XML features did not really work for us
• No cryptographic hardware on the VSE box


Case #1: The Solution

The easiest solution was to
use a WebSphere
Application Server on
Windows
Daily updating Web Service
requests from partners
Weekly master data extracts
from mainframe for each
partner
Quarterly and semi-annually
control data extracted by
mainframe


Case #2: A Tactical Service Enablement
Evolving into a Strategic Solution after a successful
Proof-of-Concept
• Back end system
– An ”i-Case” tool generating COBOL in CICS at the back end and a fat Java
client at the front end with required runtimes and a proprietary communication
layer
– A generic callable interface to the application was already in place
– Online updates from business partners’ own systems
– Web Services a mandatory protocol
– Operation and field names had to be mediated between existing WSDL-
standard and COBOL restrictions


Case #2: Technical
Solution

CICS Web Support (now superseded
by Web Services for CICS)
An existing COBOL adapter to the
case tool generated code had to be
modified to a dynamic wrapper
Mapping definitions hand crafted


Case #2: A Proof of Concept

• A Proof of Concept was designed to explore possible problems like how
does
– Complexity and verbosity of the mandatory XML dialect fit with the tools
available?
– Internal security fit with this channel of connections?
– Digital certificates work in real life in this configuration?
– Service Enablement tools fit with exiting interfaces?
– Data from different parts of the back end system match to build a meaningful
response?
• The customer provided the XSD-definitions
• CSC built the adapter modules based on these and on the existing
structures in the legacy system


Case #2: Interface Design

• Discrepancies between XML data concepts and COBOL data concepts
had to be solved
• In real life it seems that no interface contract is perfect
• Data was defined in DB2, in COBOL, and in XML
• Optional and Variable Fields (0..1) (0..n) (0..*)
• Strings


Case #2: COBOL and XML Definitions

Type COBOL XML
String PIC X() String
Float COMP-1 Float

Double COMP-2 Double
Packed decimal COMP-3 Decimal
Binary COMP-4 Long, short, int
Date PIC X(10) in the application, 2000-01-12
Content: 20061016 2000-01-12T12:13:14Z
2000-03-04T23:00:00+03:00


Case #2: COBOL and XML Field Examples

Field COBOL XML
a 9(8) Date
b S9(5) unsignedInt totalDigits value="5"
c S9(11) COMP-3 Decimal totalDigits value="11"
fractionDigits value="2"
d S9(10) Double maxInclusive value="9999999999"
e x(30) String maxLength value="30"
f S9(8) unsignedInt totalDigits value="8"
g S9(4) String pattern value="[0-9]{4}"
h S9(10) Double maxInclusive value="9999999999"


Case #2 Version 2:
Back End Modernized,
Interface Simplified
Ongoing project to migrate case
tool to runtime-free COBOL and
Java to be maintained in Rational
Developer for z (RDz)
Back end web service interface
created bottom-up from
generated COBOL code using
RDz
Proprietary client communication
code changed to Web Services
for CICS
Front end client communication
using Web Services over HTTPS
with generated communication
code adapted to the WS4C
format


Case #3: COBOL IMS in a large scale
SOA Environment

– Back end system
• Large IMS COBOL system
– The business need
• Modernizing the entire heterogeneous enterprise portfolio based on SOA integration and
supporting a large number of protocols and formats
• Service enabling IMS systems with DB2 data bases
– Technical challenges
• Reusing existing web enablement skills and technology
• The new enterprise architecture regards all components on all platforms as both service
providers and service providers
– Must support both ingoing and outgoing Web Services requests



Simple interface to IMS
applications
Reusing large application
”motors”
OTMA (Open Transaction
Manager Access)
IMS Connect
WebSphere Application
Server with the AXIS
framework
Also coding new, outgoing
Web Services requests from
IMS COBOL applications


Case #3: The challenges

– There are limits on the protocol of 400.000-500.000 bytes
– Legacy applications used screen oriented logic
• Handled by adding new logic on top of legacy applications
– Existing web enablement coded in Visual Age for Java using the now obsolete
Record Framework
– Advantages
• The continuing existence of many skilled programmers and designers with deep
business knowledge
• Experience from an existing, well performing, and very successful web interface to the
IMS and DB2 systems


Case #4: International, Multilateral,
Heterogeneous and Data Replicating

• Back end system
– An IMS DB2 MQ system
– International, multilateral exchange of data, going from data base replication to
a service oriented architecture
– Many different data types with big variances
– Large binary data items
– Consistency checking between central and national data bases


Case #4: The Original
Solution

A Web Services Gateway
implemented as a simple
servlet on WebSphere
Application Server on z
MQ communication with IMS
COBOL programs handling
XML and Unicode, storing
data in DB2
Consistency checks became
too complicated and too
difficult to make well
performing
Local data base solution
superseded by direct service
requests to the central
system


Case #4: Taming the CPU Hog

• Technical Challenges
– IMS COBOL XML Unicode program was originally coded only for functionality
using XML PARSE, not for performance
– It used vast amounts of CPU
– A code review did not show anything unsound
– Transactions were profiled using Compuware STROBE to split CPU-usage into
handling of MQ, XML, Unicode and DB2


Case #4: Untuned system
0.50 CPU-second per transaction

MODULE SECTION
NAME NAME PROCEDURE/FUNCTION NAME CPU TIME Interpretation
Runtime Storage
.LELIB CEEBINIT CEEVGTSI GET A STACK INCREMENT 51.91 allocation
IGZCHXP COBOL LIBRARY
.COBLIB IGZCPAC SUBROUTIN 31.69 XML
CEEVOGTS XTND USR STK/DSA Runtime Storage
.LELIB CEEBINIT OPLINK 7.10 allocation

CUNMUNI 1.64 Unicode

.SVC SVC 228 USER SVC 1.64 IMS
CEEVOGSX XTND USR STK/DSA Runtime Storage

RPS000 .55 The Program

RPS000 .55 The Program
System Storage
.SVC SVC 120 GETMAIN/FREEMAIN .55 allocation

.SVC SVC 013 TERMINATION .55 System


Case #4: COBOL Working Storage Reduced
1M to 100K
0.06 CPU-second per transaction
MODULE SECTION CPU
NAME NAME PROCEDURE/FUNCTION NAME TIME Interpretation
CEEVGTSI GET A STACK Runtime Storage
.LELIB CEEBINIT INCREMENT 36.17 allocation
.COBLIB IGZCPAC SUBROUTINE 31.91 XML
CEEVOGTS XTND USR STK/DSA Runtime Storage

.XES IXLR1ALR ALTER W/RECORD REQUEST 4.26 SysPlex Services (DB2)
System Storage
.SVC SVC 120 GETMAIN/FREEMAIN 4.26 allocation

.SVC SVC 013 TERMINATION 2.13 System

.NUCLEUS CSVEXPR CONTENTS SUPERVISION 2.13 System
CEEVOGSX XTND USR STK/DSA Runtime Storage

.DB2 DSNIDM DATA MANAGEMENT DRIVER 2.13 DB2

.COBLIB IGZCPAC IGZCVMO VARIABLE LENGTH MOVE 2.13 COBOL Move


Case #4: Further tuning of LE/370
Measurements from the LE/370 Storage Report

Before After
• The important parameter is
“Number of segments allocated:”,
Initial stack size: 131072 1048576 which should be 0 or 1
Increment stack size: 131072 102400
• Used parameters after tuning:
Largest used by any thread: 1010896 1007944
Number of segments
•ALL31=(ON),
allocated: 3 1 STACK=(1M,100K,ANYWHERE,
KEEP,512K,128K),
Initial heap size: 32768 921600
HEAP=(900K,128K,ANYWHERE,
Increment heap size: 32768 131072 KEEP,512K,128K),
Total heap storage used
(sugg. initial size): 818184 818152
ANYHEAP=(32K,8K,ANYWHERE,
Number of segments KEEP),
allocated: 2 1 STORAGE=(NONE,NONE,NONE,
Initial anyheap size: 16384 32768 0K)
Increment anyheap size: 8192 8192
Total heap storage used
(sugg. initial size): 25648 26456
Number of segments
allocated: 2 1

Case #4: Language Environment Parameters Tuned
0,03 CPU-second per transaction

MODULE SECTION
NAME NAME PROCEDURE/FUNCTION NAME CPU TIME Interpretation
.COBLIB IGZCPAC SUBROUTINE 46.15 XML

.COMMON .COMMONX EXTENDED COMMON AREA 7.69 System
CSQQSTUB QUIESCE AFT SYS LOG
RPS000 .MQSRIES ERR 5.13 MQ

CUNMUNI 00D1C0 5.13 Unicode

.SVC SVC 013 TERMINATION 5.13 System

.DB2 DSNXGRDS RDS ACCESS MODULE GENER 5.13 DB2

.DB2 DSNIDM DATA MANAGEMENT DRIVER 5.13 DB2

.DB2 DSNGEDM DATA MGT DBD/SKCT RTNS 5.13 DB2

RPS000 RPS000 00B380 2.56 The Program

.SVC SVC 228 USER SVC 2.56 System


Case #5: XML services over MQ

• Back end system
– A merger has created a heterogeneous environment with CICS systems, IMS
systems and Wintel systems
– A very big SOA program aims at having a new midrange industry system as the
front end and gradually replacing the legacy systems
– Service enabling CICS systems
– Generic callable interfaces to CICS and IMS systems are already in place
– MQ has been the integration channel for CICS and IMS for a number of years
– The enterprise service bus is implemented as Microsoft Biztalk
• Tools do not support SOAP over MQ, but SOAP over HTTP and XML over MQ



A modified Web Services for
CICS implementation
Reuse existing Biztalk tooling
Use RDz tooling to generate
WSBIND files for the existing
callable interface


Case #5: Pipeline Config File

<?xml version="1.0" encoding="EBCDIC-CP-DK"?>
<provider_pipeline xmlns="http://www.ibm.com/software/htp/cics/pipeline"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/software/htp/cics/pipeline
provider.xsd ">
<service>
<service_handler_list>
<handler>
<program>CSCHDL01</program>
<handler_parameter_list />
</handler>
</service_handler_list>
<terminal_handler>
<cics_soap_1.1_handler/>
</terminal_handler>
</service>
<apphandler>DFHPITP</apphandler>
</provider_pipeline>


Case #5: Dummy SOAP Header Handler Program

GET CONTAINER(PI-DFHFUNCTION)
IF PI-RECEIVE-REQUEST THEN
GET CONTAINER(PI-DFHREQUEST)
Remove existing <?XML tag
Add a dummy SOAP envelope around the payload
PUT CONTAINER(PI-DFHREQUEST)
DELETE CONTAINER(PI-DFHRESPONSE)
ELSE IF PI-SEND-RESPONSE THEN
GET CONTAINER(PI-DFHRESPONSE)
add <?XML tag
Test each tag in Response-Data to find if it starts with <soap or
</soap and then remove
PUT CONTAINER(PI-DFHRESPONSE)
Move "text/xml" to MEDIATYPE-DATA
PUT CONTAINER('DFHMEDIATYPE')


Case #6: WebSphere ESB on z

• Back end system
– An IMS COBOL MQ system
– Integration between applications on z, Oracle/Unix and Wintel using Web
Services and MQ
– The need for real storage is much larger for JVM’s than for traditional workload
– Recycling JVM’s costs hundreds of MIPS in quite extended periods
• Even though most of it is offloaded to z**P processors
• Z**P processors are not free either


Case #6: WebSphere
ESB on z Challenges

After a long quiet night the
first transactions in the
morning could take minutes
causing client timeouts
Difficult to monitor –
compared to CICS, IMS, MQ
etc.
Workload Manager policies
quite complicated


Case #7: Service Enablement of a Legacy
Application Generator System

• Back end system
– CICS, DB2, originally coded in the 4GL CSP
– A 20 year old legacy application still represents the core of the business and a
long-term investment
– Back office and staff can use web and cloud applications, which need access to
the core system and its data, both inquiries and updates
– The application was coded in CSP and still has a 3270 user interface



Web Services for CICS
developed using EGL tooling
in Rational Business
Developer (RBD) and RDz
The first service was used by
a web form



developed using EGL tooling
in Rational Business
Developer (RBD) and RDz
The first service was used by
a web form
The second service was
used by a Salesforce cloud
application
The integration from
Salesforce was done using
a Cast Iron SOA appliance



• The first service with a single operation just updated a single field in the
core data base
– The front end is a simple web form, which calls a web service
– Very easy to implement – took 20 minutes to code and generate
• The second service with half a dozen operations ran into all kinds of
technical problems


Case #7: Modelling the Service

• Describe the existing user interaction with the 3270 application
• Model this as a business process
• Describe the operations needed in the new service to support this
process
• Define the programs needed to implement the operations and the
interface as message structures


Case #7: Restrictions when developing

• If you need to have a structure as a response from an EGL Web Service
for CICS the request must be the same structure (Input == output)
• A configuration file called the “deployment descriptor” must not have the
same name as any EGL program
– RBD will quietly generate a COBOL program with the name of the deployment
descriptor to overwrite the legitimate program just in case you also wanted to
have an outgoing web services request
• The predecessors to EGL were COBOL-like in their structures and
culture, while EGL is java-like in its structures and culture

– This difference can lead to great difficulties when service enabling legacy
programs


• Do you have arrays in the externally exposed structure definition in the
service programs?
– Then the structure needs to be an unstructured record to have arrays generated
correctly into the WSDL document
– The field definitions must not be preceded by level numbers
• Otherwise the array will be “flattened” with all occurrences of each subfield
• {a1 a2 a3 b1 b2 b3 c1 c2 c3} in stead of {a1 b1 c1 a2 b2 c2 a3 b3 c3}

– Note that unstructured records are dynamic
• If you do not allocate them yourself they will be empty or even null



• A static array like this:
01 MYARRAY ARRAYRECORD[10];
Is allocated in storage like a COBOL program would
• A dynamic array, distinguished by not having level numbers:
myArray arrayRecord[10];
Is not allocated, but must be explicitly defined to avoid null pointers
• EGL generation for COBOL does not support multidimensional, dynamic
arrays
• All this is not considered an error, but a design, by IBM, even
though it is deeply unintuitive for a legacy programmer


Summing up the case studies

• Mainframe service enablement is probably our most important area of
mainframe application development in recent years
• There are many ways to service enable an existing application
• Use your existing skills, tools and methodologies where you can
• Make the service interface completely hide what is behind it
• Remember:
– To be reusable it has to usable in the first place!



Best and Worst Practices
in Service Modelling and
Architecture


Best and Worst
Practices

•Mark Skilton, CSC: Three simple
rules for definition what is a Service
are
•Forrester: North American SOA
Systems Integrators
•Gartner: The 13 least wanted
•Ang, Cherbakov & Ibrahim, IBM:
SOA Antipatterns
•Tarak Modi, Unisys: SOA
Antipatterns
•IBM on SOA Governance

Nice to have research to quote
Rather than admitting your own
mistakes

"The secret to creativity is knowing
how to hide your sources.“
(Albert Einstein)



Mark Skilton, CSC:
Service Oriented
Architecture


Mark Skilton, CSC: Service Oriented Architecture

• Three simple rules for definition
what a Service is
• Five key areas to consider when
looking at the granularity of
business and IT services
• Three key operating principles of
SOA/POA underpin these choices


Mark Skilton, CSC:
Three simple rules for definition what a Service is

• It is strategic
– The capability is critical to your organisation
• Composable
– The service can be run in its own and be combined with other services to build
new services not originally specified
• Rule of Three
– If an interface and/or message is used in more than three systems


Mark Skilton, CSC:
Five key areas to Consider when looking at the
Granularity of Business and IT Services
• Performance and size
– Neither too big nor too small
• Transactionality and state
– This audience should know all about
that!
• Business suitability
– One operation for one business step
• Safe operations
– Read only or reentrant
• Idempotency of operations
– Can be called again without
changing the result


Mark Skilton, CSC:
Three key operating principles of SOA/POA
underpin these choices
• Process Integrity
– Active
– Safe
– Idempotent
• Data Integrity
– Transactionality and states
– Data Synchronisation
– Logic
• Security Integrity
– Security policies, processes and
technologies



Forrester:
North American SOA
Systems Integrators


Forrester: North American SOA Systems Integrators

• In a typical project that uses SOA strategically, there are typically five
steps that organizations need to follow to successfully complete the
project
1. Develop a future state for the business to evolve toward
2. Map existing business services to current business processes
3. Map business services to IT solutions
4. Map IT assets to IT solutions
5. Design SOA governance and infrastructure



Gartner:
The 13 Least Wanted


Gartner: The Thirteen Least Wanted

1. Starting too big 8. Excessive centralization
2. Starting in the wrong place 9. Irrational SOA exuberance
3. Leaving SOA to the "techies“ 10. Forgetting to consider the data
4. Underestimating the technical 11. "Not invented here" syndrome
(and infrastructure) issues 12. Allowing nonshareable services
5. Assuming that everyone thinks to proliferate
like you 13. "I already have 200
6. Selling SOA before you're ready services, now what?”
7. Choosing anarchy or
dictatorship as leadership styles



Ang, Cherbakov &
Ibrahim, IBM:
SOA Antipatterns


Patterns and Anti-Patterns

• Patterns are a popular way of
illustrating best practices
– SOA Patterns are used very much in
discussions and literature
• Anti-patterns are being used more
and more to slow down the hype


Ang, Cherbakov & Ibrahim, IBM:
SOA Antipatterns (1)

• Adoption
– Technology Bandwagon
– So, What’s New?
– The Big Bang
• Design
– Blob
– Poltergeists
• Structure
– Spaghetti code
– Stovepipe systems



• Technology
– Wolf ticket
– Continuous obsolescence
• Reuse
– Cut-and-paste
– Golden hammer



• Identification & Design
– Web service = SOA
– The Silo Approach
– Misbehaving Registries
• Realization
– Chatty Services
– Point-to-point Services
– Component-less Services



Tarak Modi, Unisys:
SOA Antipatterns


Tarak Modi, Unisys: SOA Antipatterns (1)

• The "Same Old, Same Old"
Phenomenon
• The "Big Bang" Approach
• Service Fiefdoms


Tarak Modi, Unisys: SOA Antipatterns (2)

• Technophilia
• Bloated Services
• Anorexic Services
• Hyper Brokerage



IBM on SOA Governance



• "Wild West" or “Rogue” Services
– Extremely difficult to gain control over
• "Duplicated” Services
– Superficially effective but limited real
savings
• "Shelfware” Services
– A waste of resource, won’t deliver
benefits



• Unsecure Services
– Limits service use and business
opportunities
• Rigid Services
– Roadblock to agile, flexible business
processes
• Ineffective Service Management
– Services must be managed as
resources



A few more Issues


Carsten Svensson, EEI: The Cost of SOA

• Cost of SOA =
(Cost of Data Complexity +
Cost of Service Complexity +
Cost of Process Complexity +
Enabling Technology Solution)


Performance

The daily CPU consumption pattern
will change 2500

If you only run an online workload
If you run online and a lot of batch 2000
If you run in a service enabled
environment, where services are
used by a self service web application 1500

If you rely on a batch window it might Online
collide with the self service window 1000 Self-service
after dinner, when the kids are in bed Online & Batch

500

0
1 3 5 7 9 11 13 15 17 19 21 23


The culture clash between Java and COBOL

• COBOL was born to optimize
administrative computing
– Java and XML was born for dynamic
interfaces
– It takes a lot of sweat to reconcile
them
• Data in COBOL working storage
allocated implicitly by the compiler
– Data in Java must be allocated
explicitly by the programmer


To Summarize

• There are many ways to integrate mainframe systems into service
oriented architectures
– A lot of best practices are to be found in the technical solutions
• You need a close cooperation between business
stakeholders, architects, developers and technologists to make it work
– The worst practices are found when application, design and architecture on one
hand does not take the requirements of the technologies and the infrastructure
seriously
• All the mistakes have already been made and are extensively
documented



THANK YOU


S424. Soa Mainframe Practices Best And Worst

Recommended

Recommended

More Related Content

What's hot

What's hot (13)

Similar to S424. Soa Mainframe Practices Best And Worst

Similar to S424. Soa Mainframe Practices Best And Worst (20)

S424. Soa Mainframe Practices Best And Worst

Editor's Notes