Using XML to Integrate existing Software Systems into ...

Using XML to Integrate existing Software Systems into the Web Harry M. Sneed Institut für Wirtschaftsinformatik, Universität Regensburg CaseConsult GmbH, Wiesbaden, Germany Email: [email protected]

Abstract:The eXtensible Markup Language –

70 % of all mainframe applications.[2] A recent

XML – is not only a language for communication

study in Germany conducted by the University of

between humans and the web, it is also a language

Karlsruhe discovered that more than 60 % of the

for communication between programs. Rather than

productive applications in German industry run on

passing parameters, programs can pass documents

the mainframe. Especially in the financial sector

from one to another, containing not only pure data,

where banks, insurance companies and credit

but control information as well. Even legacy

institutes are active, but also in the trade sector and

programs written in ancient languages such as

in governmental administration, the host computer

COBOL and PL/I can be adapted by means of

remains the workhorse of information technology.

interface reengineering to process and to generate

Of the largest 2000 enterprises in the world, over

XML documents. This paper intends to describe the

90% employ an IBM-390 as a central server. [3]

process and the tools required to accomplish that goal and to present three cases – one for online, one

Therefore, it is ignorant to ignore those application

for batch and one for subprograms – to illustrate

systems which are running on the host. The fact

how XML may be used to integrate existing

that they are still there, despite several attempts in

software systems into the web.

the 1990’s to replace them with client/server

Keywords: XML, Software Reengineering, Data

systems, underlines the necessity to cope with

Conversion, Integration, Framework, Enterprise

them.

Application Integration, e-Commerce The strategy advocated by an IBM white paper in

The Case for layered Reuse of existing Systems

the late 1990’s and adapted here is not to replace the host but to reemploy it as the hub of an enterprise intranet.[4] In so doing, it is also necessary to encapsulate the existing legacy

Most

large

commercial

organizations

have

software and data within the

new intranet

application systems which date back to the 1970’s

architecture. They actually become the core of the

and 1980’s. Recent studies show that 80 % of the

future web based information systems. The data

actual IT-production is carried out by legacy

remains in a hierarchical or relational database on

systems.[1] COBOL is still the most widely used

the host, e. g. IMS or DB2. The access shell is

language in the mainframe world, making up for

separated from the application programs, so that all

requests for data pass through that shell no matter

future, it is easy to imagine that over the years a

where they originate from. The host application

multilayered architecture will emerge in which each

programs whether they be online or batch go

generation of new software is built on top of the

through the access shell to obtain and store their

existing software layers reusing their data and

data. The batch programs can be triggered from a

functionality. (See Figure 1.)

remote client. The online programs can run either in a traditional mode with 3270 terminals under a

This layered reuse strategy is a cost effective

classical teleprocessing monitor such as IMS or

alternative to the much propagated replacement

CICS, or in an internet mode with a web server

strategy whereby the legacy systems are totally

such as Websphere or DotNet. Furthermore, both

replaced by modern newly developed ones. Studies

host and batch programs as well as their common

have demonstrated that layered reuse is less than

subprograms can be accessed from other programs

35 % as expensive as replacement systems [6], not

in the periphery to service their requests. In that

to mention the risk of new development. According

way additional application layers can be added on

to the study of the Standish Group only some 43 %

without having to reimplement the functionality

of new development projects are ever finished.[7]

already existing in the core.[5]

Therefore, from an economic point of view, reuse of existing software systems is definitely a better

Since it is reasonable to assume that the additional

choice. Both, the costs and the risks are less, as is

layers being added to the mainframe core will

documented in several studies.[8]

themselves become legacy systems in the near

Web Browser

Web Browser

Web Browser

Corporate Users

Web Application Server (Websphere, DotNet) Work Flow Control Software (JBEE) Newer Distributed Applications (C++, Java) Older Host Applications (Assembler, COBOL, PLI) Database Access Shell Corporate Databases

Figure 1: Layered Software Architecture

The Role of XML in connecting

parameters. The programs remain functionally

Software Layers

bound.

The eXtensible Markup Language – XML – was specified by the W3C Consortium as a more sophisticated solution than HTML for human communication in the internet. Since it was derived form SGML it also had the propensity to represent any type of document.[9] It is an advantage that with the aide of a style sheet, XML documents can be displayed as web pages or printed as printouts. In this respect they serve the requirements of human communication. However, the real benefit of XML is that it can be used to exchange data between programs, programs written in different languages and running in different environments.

For the client/server environment with it’ s statically predetermined interactions between clients and servers, the CORBA model was sufficient to support program to program communication. This does not hold for the internet where interactions are not predetermined and where any server can be invoked by any client and any server can exchange data with any other server. Here a more flexible means of program to program communication is required. The programs should be strictly data bound, meaning that the sender of a message needs to know nothing about the receiver of a message. All of the information required to respond to a message should be in the message itself, i. e. the

Up until now programs have been connected

messages are self describing.[11]

mainly via call interfaces. An entry point or function in the target program is called with a list of parameters. The parameters have to be data types known both to the source and the target program. Besides they must be in the correct order. Any change to the interface on the side of the called program must be reflected in the calling program.

The same requirements apply to communication between programs in different layers of software. Since programs in different layers are usually written

in

different

languages

for

different

environments, their data types and prototypes will seldom be compatible. For instance COBOL and C++ have totally different run time environments

The CORBA architecture specified by the OMG and implemented in a number of commercial products such as Orbix, Visibroker and Component Broker went as far as one could go in standardizing and refining this type of functional interface. The IDL – Interface Definition Language – is used to specify the interfaces stored in a common interface

and calling conventions. Thus, calling a COBOL program from a C++ class is quite a difficult matter. Even using CORBA-IDL, there are still compatibility problems which apply to JAVA and COBOL as well. PL/I is even worse in this respect, since it is totally dependent on the physical environment in which it is executing.[12]

definition repository available to both the client and the server programs.[10] Thus, both use the same interface description. Still the client must be aware of what functions to invoke and with which

If, however, legacy programs in languages such as COBOL or PL/I receive their requests via a data interface, the compatibility problems vanish. Any COBOL or PL/I program can be adapted to read

ASCII character strings. They can recognize tags

Batch programs are driven by transaction files

and interpret the document type definitions –

produced by some other program. In the simple

DTD’ s. Besides that, a tool can be developed which

case it is one file. In more complicated cases, there

would extract the data from the XML document

are many files. The read or get statements have to

and convert it to the program input structure. The

be replaced by stub calls, i. e. calls to an input

only input the tool needs is the original data

subroutine, to provide the next data record. In the

structure declaration and a cross reference table to

environment described here, it is the XMLIN

associate tags in the XML document with field

function. Besides the data record, the stub also

names in the target program. In this way, any

provides control information such as the end of file

legacy program, even Assembler ones, can be

or invalid key signal. For this additional parameters

adopted to process incoming XML documents and

are required as illustrated in Figure 2.

to generate outgoing XML documents, using the same technique, only inverted. This technique of

Batch programs may also produce output files

XML-enabling and how it applies to legacy

which go back to the client. These write or put

programs will be describe in the following sections.

statements also have to be replaced by stub calls, i. e. calls to an output subroutine, to pass on the

Enabling the Legacy Programs

current output record. In the environment described

Life would be so simple if only all legacy programs

here, this is the XMLOUT function which

were subprograms which receive their input data

generates an XML document for the output queue.

from a parameter list. In some cases this is true, but the vast majority of mainframe legacy programs are

Both, the input and the output file statements are

either

replaced

batch

main

programs

or

transaction

automatically

by

the

SoftWrap

processing programs. Both have to first be altered

preprocessor. To make things more convenient to

before they can be used to service requests from a

the user, SoftWrap even displays the names of all

remote client.[13]

files used by a program in a list box so that the user may select which files are to be wrapped, i. e.

Enabling Batch Programs


replaced by XML message queues.

RECHNUNG [ X-CICS-RETCODE? > X-CICS-RETCODE Type = "int"> RECHNUNGSPOSTEN (AUFTRAGNR, KUNDENNR, ARTIKELNR, ARTIKELNAME, BESTELLMENGE, ARTIKELPREIS)> AUFTRAGNR (#PCDATA) > AUFTRAGNR Type (char|dec|pack|int|float|ptr|str) "dec"> KUNDENNR (#PCDATA) > KUNDENNR Type (char|dec|pack|int|float|ptr|str) "dec"> ARTIKELNR (#PCDATA) > ARTIKELNR Type (char|dec|pack|int|float|ptr|str) "dec">

]> < RECHNUNG > < X-CICS-RETCODE>03 < RECHNUNGSPOSTEN > < AUFTRAGNR >1001 < KUNDENNR >10548501 < ARTIKELNR >4711 < ARTIKELNAME >Straps < BESTELLMENGE >0010 < ARTIKELPREIS >018,50 Figure 2: XML Input Document

Enabling Online Programs In the environment under discussion the input maps Online transaction programs are driven by terminal

are provided by the XMLTPIN function which also

input messages. These may come as a data stream

supplies the attribute bytes, field lengths and return

or as a map. Maps are structured according to some

codes. The output maps are handled by the

proprietary convention such as CICS-BMS or IMS-

XMLTPOUT function which extracts the raw data

MFS. In addition to the variable data itself maps

from the map and passes it on as a data stream.

also contain constant texts and control information such as field attribute bytes and field lengths.

As with the batch programs all teleprocessing

Unfortunately, these controls are often used by the

statements are replaced automatically by the

program to decide what to do next, so they cannot

SoftWrap preprocessor. Here the user has no

be removed from the program without causing

choice in the matter. The call statements replacing

errors. The maps are received by proprietary

them have all the parameters necessary to emulate

teleprocessing input operations such as the CICS

the original TP-operation. Teleprocessing messages

RECEIVE macro or the IMS GET UNIQUE call.

may not be left in the program since they would

Maps are sent by TP-output operations such as the

compete with the message queues coming from and

CICS SEND macro or the IMS INSERT call. To

going to the web. The user may not communicate

enable an online program to act as an XML-server,

with the program both by the traditional terminals

these operations have to be replaced by stub calls as

and the web site, i. e. CICS maps and XML

illustrated by the following COBOL/CICS program

documents. There can only be one mode of human

(see Figure 3).

to program communication at one time.[14]

RECEIVE-RECHNUNG. MOVE LOW-VALUES TO RECHNUNGSPOSTEN MOVE SPACES TO ARTIKELNAME WRAP ***************************************************** WRAP * Replace CICS Receive Map with XML INPUT DOCUMENT WRAP ***************************************************** WRAP * EXEC CICS RECEIVE MAP (’RECHNUNG’) WRAP * MAPSET (’ABRECHNG’) WRAP * INTO (RECHNUNGSPOSTEN) WRAP * END-EXEC. WRAP MOVE ’RC’ TO X-CICS-FUNCTION WRAP MOVE ’RECHNUNG’ TO X-CICS-MAP WRAP CALL ’XMLTOCOB’ USING X-CICS-FUNCTION, WRAP X-CICS-RETCODE, WRAP X-CICS-MAP, WRAP RECHNUNGSPOSTEN WRAP MOVE X-CICS-RETCODE TO EIBRESP WRAP EVALUATE TRUE WRAP WHEN X-MAPFAIL WRAP PERFORM VV-860 WRAP WHEN X-PF1 WRAP PERFORM VV-710 WRAP WHEN X-PF2 WRAP PERFORM VV-720 WRAP WHEN X-PF3 WRAP PERFORM VV-730 WRAP WHEN OTHER WRAP CONTINUE WRAP END-EVALUATE. Figure 3: CICS-Map Emulation via XMLTOCOB Stub

separated from the program source and usually are

Generating the Conversion Tables

in the form of a copy book, an include or an The key to converting XML data to Assembler,

Assembler macro. A static analysis tool in

COBOL or PL/I data is the data conversion table.

XMLWrap processes the data structures to extract

This table contains the names, types, positions,

the names, types, lengths, etc. and place them in a

lengths, occurrences and redefinitions of the data in

table. The positions of the data fields have to be

the host program interfaces whether they be

calculated based on the lengths of the preceding

parameter lists, records, or maps. It is via the data

fields. For each program module a separate data

conversion table that character data is extracted

conversion table is generated in the form of an

from the XML document to feed the host program

XML document with a container tag for each data

interface at runtime. It is also via the data

field and an elementary tag for each field attribute.

conversion

The level number of the fields is stored as an XML

table

that

XML

documents

are

generated from the host programs.

attribute of the field name. It would be possible to declare all field attributes as XML data attributes,

To create these tables it is necessary to parse the

but it is more flexible and easier to process if they

target program data interfaces. These can be

are listed as values.

There is only one document type definition – DTD

to have an additional name association table. This is

– for all tables since it is generic to all data

a relational table containing binary tuples. Each

structures. It lists the table elements and attributes.

binary tuple associates an XML tag with a host

Since the tables are automatically generated, this

program field. There must be a 1 : 1 relation

DTD serves more a documentary purpose. A

between tag names and field names, otherwise the

sample XML conversion table is displayed in

data cannot be converted correctly. If a name such

Figure 4.

as “Date” occurs in several places, then it must be qualified, e. g. Birth.Date or Employment.Date.

Should the XML tags differ from the field names of

The hononym, synonym problem is not unique to

the programs, i. e. XML tag names follow other

XML

conventions than Assembler labels, it is necessary

languages.[15]

X-CICS-RETCODE B 0000 0002 0001 RECHNUNGSPOSTEN 0009 AUFTRAGNR D 0001 0008 0001 KUNDENNR D 0009 0008 0001 ARTIKELNR D 0017 0008 0001 ARTIKELNAME A 0025 0020 0001

documents.

It

is

common

to

all

BESTELLMENGE D 0045 0004 0001 ARTIKELPREIS F 0049 0006 0001 Figure 4: XML to COBOL Conversion Table

place them at the proper position in the program

The XML Stubs

data structure. Thus, the standard methods are: The actual tools for processing the XML documents are the XML stubs which are called instead of the

−

Parse_DTD (Doc:Name),

file system or the teleprocessing monitor. There are

−

Select_next_DataItem (Data_Name),

two such stubs for each language and each TP

−

Convert_DataType (Data_Type),

monitor being wrapped. One is for extracting data

−

Store_DataValue (Data_Value).

from an incoming XML document and converting it to the appropriate internal data structure, i. e. CICS

Of course for the Convert_DataType there are

map or COBOL record. This is the stub

several sub methods, one for each target data type –

XMLTOCIS,

fixed binary, packed decimal, hexadecimal, floating

XMLTOIMS,

XMLTOCOB,

XMLTOPLI, etc. The other is for creating an

point etc.

outgoing XML document from the internal data structure of the wrapped program, i. e. from the

The input stub is called each time a map is to be

CICS map or COBOL record. This is the stub

received or a record is to be read. It’ s purpose is to

CISTOXML,

fill the input buffer with the data from the next

IMSTOXML,

COBTOXML,

PLITOXML, etc. (See Figure 5.)

XML document in the incoming message queue.

The stub for converting incoming XML documents

The stub for generating outgoing XML documents

processes the conversion table for that particular

is also based on the corresponding conversion table.

interface. It is generated from a standard template

Only the direction of the conversion is reversed.

and joined together with the conversion table. In

The output stub is called with the record or map

effect the conversion table is the object and the stub

containing the output data. Via the table the

the methods. The methods are to parse the XML

variable names are associated with the field

document, select the data noted in the conversion

displacements, lengths and types to extract the

table, convert the data to internal data types and to

values and embed them in a corresponding XML

document. The DTD is created based solely on the

of redefinitions the conversion type is determined

conversion table. The result is a correct and well

by the actual value. In the case of multiple

formed XML document which is placed in the

occurrences, i. e. vectors, the actual number of

outbox.

elements in the table must be computed. This becomes complicated when repeated data groups

The greatest conversion difficulties are caused by

are involved, but it is a problem which any

multiple occurrences and redefinitions. In the case

compiler must resolve.

CICS Transaction Monitor

XML Docus

Input Message Queve

Output Message Queve

XML Docus

CICS / COBOL Program

XMLTOCOB

XML to COBOL CONVERSION

CICS BMS MAP

Input Map Buffer

Output CICS Map BMS Buffer MAP

DB Access Shell

COBTOXML

COBOL to XML CONVERSION

Database

Figure 5: XML Stubs for Map Emulation

Executing the XML-wrapped Programs

In the online environment, the program remains under control of the TP monitor which opens and

The wrapped programs are executed in their native

closes the databases, commits or roll backs the

environment. For this reason it is important that the

database transactions, establishes connections to

stubs are in the same language as the program, as

other programs, maintains the communication data

they are statically linked to it. In the batch

areas and handles errors. The only difference is that

environment, the program now reads its input from

there are no connections to the terminals. The map

the XML document stream and writes its output

input/output operations have been diverted to the

data into the XML output queue. Otherwise it

appropriate stubs which provide the map data from

functions exactly as before, retrieving and storing

the XML input queue and write the map data onto

records, segments or relations of the database.

the XML output queue. In effect the map processing is replaced by message processing complemented by the XML conversion.

The problem involved here is the need to have a

Reuters News Agency, one for processing stock

second program version for processing XML

orders and derivatives at J. B. Morgan and another

documents which is slightly different than the

one

original map handling version. If the user intends to

Coopers.[17] Peter Aiken, a prophet of XML for

abandon the 3270 terminals and work only on the

system integration, reports on a project taking place

web, there is no problem. He maintains only the

at the Deutsche Bank in New York.[18] All of these

reengineered version. If, however, the user wants to

projects are still in progress, so it is too early for

run the web-based version parallel to the original

statistical results.

for

stock

trading

at

Pricewaterhouse

terminal-based version, then he must maintain two copies of the same program. That is why it is so

In Germany and Austria, where this author works,

important to be able to generate the wrapped

only two projects have so far been reported. One

version out of the original version automatically.

took place at the German Trade Union Bank – DG

The user makes his changes to the original

Bank – using XML to integrate bank trading

terminal-based version and tests it in the standard

applications. The architecture developed for that

environment. Then he invokes the tool to create the

project is called the Trading Room Integration

XML version. In this manner, only one version

Architecture.

need be maintained..[16]

applications with existing COBOL programs. The

It

connects

C++

and

JAVA

frontend components use XSLT to display and

Experiences with XML-based System

accept the user interfaces and XML to transfer the

Integration

contents via a CORBA type communication network. The first applications are already in

The introduction of XML to traditional data

operation.[19]

processing enterprises in the old economy has actually just started, so there have been little experiences reported as of yet. Even in the U.S.A., the world leader in information technology, only a handfull of companies have actually started using XML as a means of integrating their enterprise applications. This is probably due to the fact that the technical environments to support such an XML-based system integration, environments such as Enterprise JavaBeans, BizTalk and WebSphere, are not yet ripe enough for full scale production.

The other project was at the Deutsche Bauspar AG and was reported on in a previous paper. The goal of this project was to connect JAVA applets running at local savings and loan offices with the central host computer in Frankfurt. The web page contents were converted to XML documents which were sent via IBM’ s MQ-Series to the host where they were converted to COBOL structures by an XMLCOBOL tool. The pilot project delivered the proof of concept. The follow up project is now underway.[20]

Don Estes cites in his report on Business to Business System Integration four pilot projects going on in the U.S.A. – one for general accounting reporting at AICPA, one for news dissemination at

In Vienna, where the author is participating in a project to develop a standard stock trading package implemented in C++ to run on several target computers, XML is used to connect a new web-

based frontend implemented in JAVA with the

processes. With batch and subprograms this is less

existing C++ backend applications. This project has

of a problem than with online transaction

just been completed and will be reported on soon.

processing programs. The logic of these programs is based on synchronous event driven map handling

The tools described in this paper are currently being

and function keys. Now they must revert to

tested in a project to integrate the existing

asynchronous sequential document processing. This

production control system at Porsche with recently

entails restructuring of the program interfaces and

installed standard ERP systems running under

presents a significant challenge to the reengineering

MySap from SAP. The author is responsible there

community. The task is to automatically convert

for finding a suitable EAI solution. At the

host programs from CICS/BMS or IMS/MFS to

University of Regensburg, where the author teaches

CICS/XML

Software Engineering, the tools have been used to

opportunities here for universities and research

integrate a JAVA/XML frontend developed by the

institutes to render useful contributions.

or

IMS/XML.

There

are

many

students with a series of existing C and COBOL programs. The JAVA frontend processed order

Conclusions

entries for articles on stock. The modules for accessing the customer and article databases in MS-

This paper has presented a proposal for enterprise

Access were written in C using ODBC to access the

application integration using XML as a common

databases. The modules for producing invoices,

interface language. The main objectives are to link

dispatch orders and supplier orders are legacy

existing legacy programs with new web-based

COBOL programs. All of the inter program

applications within the framework of a multilayered

communication is done by means of message

architecture. XML is used to exchange data

queuing of XML documents produced by the JAVA

between the software layers independently of their

and C components. This research project has been

implementation

reported on in a previous paper.[21]

environments. For this purpose conversion stubs

languages

and

runtime

have been implemented which use data conversion

Areas for further Research

tables generated

from the

existing program

interface structures. These stub can convert XML The basic problem of converting XML to various

documents to COBOL, PLI and Assembler data

target language data structures has been resolved.

structures and generate XML documents from

What is needed now is to optimize the conversion

COBOL, PLI and Assembler. In this way both,

to reduce run time costs. The task of message

batch input records and online maps can be

queuing for web server to host communication is

replaced by XML interfaces.

being addressed by the suppliers of middleware The prerequisite to using this technology is to

products.

reengineer the interfaces of the existing programs The greatest remaining application problem is how

so that they process messages rather than map and

to reengineer the existing program interfaces so that

records. Either the programs have to be rewritten by

they

hand or they have to pass through a precompiler

are

compatible

with

XML

document

which automatically restructures them. This paper

required in optimizing the interface reengineering

has emphasized the latter solution because of the

process to ensure that the reengineered versions are

costs involved in rewriting. More research is

functionally equivalent to the original ones.

References [1]

[2]

Warren, Jan: “The Renaissance of Legacy

Distributed System”, Proc. of CSMR-2000, IEEE

Systems”, Springer Verlag, London, 1999, p. 5

Computer Society Press, Zürich, March 2000,

Schricker, D.: “COBOL for the Next Millenium”,

p. 183 to 188

IEEE Software, March 2000, p. 48 to 52 [3]

Kebschull,

V./Spruth,

Großrechner

als

W.:

[14]

“Kommerzielle

Ausbildungsaufgabe

of COBOL/CICS Legacy Systems”, Proc. of

an

CSMR-1999, IEEE Computer Society Press,

Universitäten und Fachhochschulen”, Informatik Spektrum, Band 24, Heft 3, June 2001, p. 140 to

[4]

Amsterdam, March 1999, p. 72 to 82 [15]

der Interface-Versionshölle”, Object-Spectrum,

IBM: “A Survey of object-oriented Technology

Nr. 4, July 2000, p. 24 to 29 [16]

2505, Pougikeepsie, N.Y., Feb. 1995 Israel,

B.-S./Gish,

J./Robinson,

W.:

“An

IEEE Software, Sept. 1998, p. 79 to 85 Harmon,

P.:

“XML

–

Solving

[8]

[10]

Business [18]

Forum

Internet”, (ed.

Chikofsky,

of E.),

Aiken, P./Yates, M.: “Novel Approaches to Large

Standish Group: “CHAOS – The Cost of IT

Reengineering

Project Failures”, in PC-Week, Nr. 16, Jan. 1995

Zürich, March 2000, p. 16 to 30

Sneed, H.: “Risks involved in Reengineering

Proc.

Estes, D.: “Legacy.NET”, Cutter IT Journal,

Scale

[19]

Systems

Reengineering”, Forum

(ed.

Proc.

Chikofsky,

of E.),

Weitzel, T./Harder, T./Buxmann, P.: “Electronic

Projects”, Proc. of 6 WCRE, IEEE Computer

Business and EDI with XML”, dpunkt Verlag,

Society Press, Atlanta, Oct. 1999, p. 209 to 211

Heidelberg, 2001,p. 181 to 198

Graham, I./Quin, L.: “XML – Specification

[20]

Haeckel, A./Gößner, J./Wahl, H.: “Integration of

Guide”, John Wiley & Sons, New York, 1999,

Legacy Applications in modern object-oriented

p. 1 to 3

Systems via XML” in Object Spectrum, No. 5,

Mowbray,

T./Zahavi,

R.:

“The

Essential

OMG-Series, John Wiley & Sons,

Sept. 2000, p. 35 to 40 [21]

Hasselbring,

W.:

“Information

Sneed, H.: “Wrapping Legacy COBOL Programs behind an XML Interface”, Proc of WCRE 2001,

System

IEEE Computer Society Press, Stuttgart, Oct.

Integration”, Comm. of ACM, Vol. 43, No. 6, June 2001, p. 33 to 36

2001 [22]

Lewis,T.: “Mainframes are dead, Long live

Seligmann, L./Rosenthal, A.: “XML’ s Impact on

Mainframes”, IEEE Computer, August, 1999, p.

Databases and Datasharing”, IEEE Computer,

102-104l

June 2001, p. 59 to 66 [13]

the

Mainframe

Vol. 14, No. 1, p. 35 to 42

New York, 1995, p. 35 to 45

[12]

via

Legacy

2001, p. 5 to 25

CORBA”

[11]

“Accessing

Reengineering

th

[9]

H.:

Zürich, March 2000, p. 34 to 46 [17]

Problems”, Cutter Consortium, Arlington, Mass.,

[7]

Sneed.

Applications

Integrated Network Component Architecture”,

[6]

Westphal, R.: “Strong Tagging – Der Ausweg aus

143

on MVS/ESA”, IBM Red Book Doc. No. GG24-

[5]

Sellnik, A./Sneed, H./Verhoef, C.: “Restructuring

Sneed, H.: “Generation of Stateless Components from Procedural Programs for Reuse in a