|
The Legacy Transaction Processing Systems Resource – Directory & Links
From Mainframes.in – Home of Legacy & Mainframes Online
|
|
The Legacy Transaction Processing Systems section of Mainframes.in provides a listing of WWW resources for legacy & mainframe transaction processing systems. Mainframes.in is a comprehensive online resource for legacy and mainframe systems.
..
..
Add Links: If you have a web site that you wish to include in this directory, do let us know the details by sending a note about your URL to narsi@esource.in. We’ll quickly review the web site, and if found relevant, add it to the database. We look forward to web site owners and link exchange partners to submit URL. Thanks!
Content derived from Wikipedia article on Transaction Processing
Transaction processing From Wikipedia, the free encyclopedia
In computer science, transaction processing is information processing that is divided into individual, indivisible operations, called transactions. Each transaction must succeed or fail as a complete unit; it cannot remain in an intermediate state.
Contents
1 Description 2 Methodology 2.1 Rollback 2.2 Rollforward 2.3 Deadlocks 3 ACID criteria 4 Implementations 5 See also 6 Books
Description Transaction processing is designed to maintain a database in a known, consistent state, by ensuring that any operations carried out on the database that are interdependent are either all completed successfully or all cancelled successfully.
For example, consider a typical banking transaction that involves moving £500 from a customer's savings account to a customer's checking account. This transaction is a single operation in the eyes of the bank, but it involves at least two separate operations in computer terms: debiting the savings account by £500, and crediting the checking account by £500. If the debit operation succeeds but the credit does not (or vice versa), the books of the bank will not balance at the end of the day. There must therefore be a way to ensure that either both operations succeed or both fail, so that there is never any inconsistency in the bank's database as a whole. Transaction processing is designed to provide this.
Transaction processing allows multiple individual operations on a database to be linked together automatically as a single, indivisible transaction. The transaction-processing system ensures that either all operations in a transaction are completed without error, or none of them are. If some of the operations are completed but errors occur when the others are attempted, the transaction-processing system “rolls back” all of the operations of the transaction (including the successful ones), thereby erasing all traces of the transaction and restoring the database to the consistent, known state that it was in before processing of the transaction began. If all operations of a transaction are completed successfully, the transaction is “committed” by the system, and all changes to the database are made permanent; the transaction cannot be rolled back once this is done.
Transaction processing guards against hardware and software errors that might leave a transaction partially completed, with a database left in an unknown, inconsistent state. If the computer system crashes in the middle of a transaction, the transaction processing system guarantees that all operations in any uncommitted (i.e., not completely processed) transactions are cancelled.
Transactions are processed in a strict chronological order. If transaction n+1 touches the same portion of the database as transaction n, transaction n+1 does not begin until transaction n is committed. Before any transaction is committed, all other transactions affecting the same part of the database must also be committed; there can be no “holes” in the sequence of preceding transactions.
Methodology The basic principles of all transaction-processing systems are the same. However, the terminology may vary from one transaction-processing system to another, and the terms used below are not necessarily universal.
Rollback Transaction-processing systems ensure database integrity by recording intermediate states of the database as it is modified, then using these records to restore the database to a known state if a transaction cannot be committed. For example, copies of information on the database prior to its modification by a transaction are set aside by the system before the transaction can make any modifications (this is sometimes called a before image). If any part of the transaction fails before it is committed, these copies are used to restore the database to the state it was in before the transaction began (rollback).
Rollforward It is also possible to keep a separate journal of all modifications to a database (sometimes called after images); this is not required for rollback of failed transactions, but it is useful for updating the database in the event of a database failure, so some transaction-processing systems provide it. If the database fails entirely, it must be restored from the most recent back-up. The back-up will not reflect transactions committed since the back-up was made. However, once the database is restored, the journal of after images can be applied to the database (rollforward) to bring the database up to date. Any transactions in progress at the time of the failure can then be rolled back. The result is a database in a consistent, known state that includes the results of all transactions committed up to the moment of failure.
Deadlocks In some cases, two transactions may, in the course of their processing, attempt to access the same portion of a database at the same time, in a way that prevents them from proceeding. For example, transaction A may access portion X of the database, and transaction B may access portion Y of the database. If, at that point, transaction A then tries to access portion Y of the database while transaction B tries to access portion X, a deadlock occurs, and neither transaction can move forward. Transaction-processing systems are designed to detect these deadlocks when they occur. Typically both transactions will be cancelled and rolled back, and then they will be started again in a different order, automatically, so that the deadlock doesn't occur again.
ACID criteria Main article: ACID There are many minor variations on the exact methods used to protect database consistency in a transaction-processing system, but the basic principles remain the same. All transaction-processing systems support these functions, which are referred to as the ACID properties: atomicity, consistency, isolation, and durability.
Implementations Standard transaction-processing software, notably IBM's Information Management System, was first developed in the 1960s, and was often closely coupled to particular database management systems. Client-server computing implemented similar principles in the 1980s with mixed success. However, in more recent years, the distributed client-server model has become considerably more difficult to maintain. As the number of transactions grew in response to various online services (especially the Web), a single distributed database was not a practical solution. In addition, most online systems consist of a whole suite of programs operating together, as opposed to a strict client-server model where the single server could handle the transaction processing. Today a number of transaction processing systems are available that work at the inter-program level and which scale to large systems, including mainframes.
An important open industry standard is the X/Open Distributed Transaction Processing (DTP) (see JTA). However, proprietary transaction-processing environments such as IBM's CICS are still very popular, although CICS has evolved to include open industry standards as well.
See also ACID ACMS Audit trail CICS Database transaction IMS Java EE (e.g. WebSphere Application Server) Java Transaction API (JTA) Two-phase commit Transaction Processing Facility TP-Lite and TP-Heavy
Books Jim Gray, Andreas Reuter, Transaction Processing - Concepts and Techniques, 1993, Morgan Kaufmann, ISBN 1558601902 Philip A. Bernstein, Eric Newcomer, Principles of Transaction Processing, 1997, Morgan Kaufmann, ISBN 1-55860-415-4 Ahmed K. Elmagarmid (Editor), Transaction Models for Advanced Database Applications, Morgan-Kaufmann, 1992, ISBN 1558602143
End of Wikipedia content, http://en.wikipedia.org/wiki/Transaction_processing
Content derived from Wikipedia article on Transaction Processing Systems
Transaction Processing System
A Transaction Processing System (TPS) is a type of information system. TPSs collect, store, modify, and retrieve the transactions of an organization. A transaction is an event that generates or modifies data that is eventually stored in an information system. To be considered a transaction processing system the computer must pass the ACID test.
Contents
1 Types of Transaction Processing Systems 1.1 Batch Processing 2 Features of Transaction Processing Systems 2.1 Rapid Response 2.2 Reliability 2.3 Inflexibility 2.4 Controlled processing 3 ACID Test Properties: First Definition 3.1 Atomicity 3.2 Consistency 3.3 Isolation 3.4 Durability 4 Storing and Retrieving 4.1 Databases and files 4.2 Data Warehousing 4.3 Backup Procedures 4.3.1 Recovery Process 4.3.2 Types of Back-up Procedures 4.3.2.1 Grandfather-Father-Son 4.3.2.2 Partial Backups 4.3.3 Updating in a Batch 4.3.4 Updating in Real-Time 5 References 6 See also
Types of Transaction Processing Systems
Batch Processing Batch processing is ave one bill for a month's worth of purchases.[1]
Features of Transaction Processing Systems
Rapid Response Fast performance with a rapid response time is critical. Businesses cannot afford to have customers waiting for a TPS to respond, the turnaround time from the input of the transaction to the production for the output must be a few seconds or less.
Reliability Many organisations rely heavily on their TPS; a breakdown will disrupt operations or even stop the business. For a TPS to be effective its failure rate must be very low. If a TPS does fail, then quick and accurate recovery must be possible. This makes well–designed backup and recovery procedures essential.
Inflexibility A TPS wants every transaction to be processed in the same way regardless of the user, the customer or the time for day. If a TPS were flexible, there would be too many opportunities for non-standard operations, for example, a commercial airline needs to consistently accept airline reservations from a range of travel agents, accepting different transactions data from different travel agents would be a problem.
Controlled processing The processing in a TPS must support an organisation's operations. For example if an organisation allocates roles and responsibilities to particular employees, then the TPS should enforce and maintain this requirement.
ACID Test Properties: First Definition
Atomicity A transaction’s changes to the state are atomic: either all happen or none happen. These changes include database changes, messages, and actions on transducers.[2]
Consistency A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program.[2]
Isolation Even though transactions execute concurrently, it appears to each transaction T, that others executed either before T or after T, but not both.[2]
Durability Once a transaction completes successfully (commits), its changes to the state survive failures.[2]
Storing and Retrieving Storing and retrieving information from a TPS must be efficient and effective. The data is stored in warehouses or other databases, the system must be well designed for its backup and recovery procedures.
Databases and files The storage and retrieval of data must accurate as it is used many times throughout the day. A database is a collection of data neatly organised, which stores the accounting and operational records in the database. Databases are always protective of its delicate data, so it usually has a restricted view of certain data. Databases are designed using hierarchical, network or relational structures; each structure is effective in its own sense.
Hierarchical structure: organises data in a series of levels, hence why it is called hierarchal. Its top to bottom like structure consists of nodes and branches; each child node has branches and is only linked to one higher level parent node. Network structure: Similar to hierarchical, network structures also organises data using nodes and branches. But, unlike hierarchical, each child node can be linked to multiple, higher parent nodes. Relational structure: Unlike network and hierarchical, a relational database organises its data in a series of related tables. This gives flexibility as relationships between the tables are built.
A Hierachical Structure. A Network Structure. A Relational Structure.
The following features are included in real time transaction processing systems:
Good Data Placement: The database should be designed to access patterns of data from many simultaneous users. Short transactions: Short transactions enables quick processing. This avoids concurrency and paces the systems. Real-time backup: Backup should be scheduled between low times of activity to prevent lag of the server. High normalisation: This lowers redundant information to increase the speed and improve concurrency, this also improves backups. Archiving of historical data: Uncommonly used data is moved into other databases or backed up tables. This keeps tables small and also improves backup times. Good hardware configuration: Hardware must be able to handle many users and provide quick response times. In a TPS, there are 5 different types of files, the TPS uses the files to store and organise its transaction data:
Master file: Contains information about an organisation’s business situation. Most transactions and databases are stored in the master file. Transaction file: It is the collection of transaction records. It helps to update the master file and also serves as audit trails and transaction history. Report file: Contains data that has been formatted for presentation to a user. Work file: temporary files in the system used during the processing. Program file: Contains the instructions for the processing of data.
Data Warehousing A data warehouse is a database that collects information from different sources. When it's gathered in real-time transactions it can be used for analysis efficiently if it's stored in a data warehouse. It provides data that is consolidated, subject-orientated, historical and read-only:
Consolidated: Data is organised with consistent naming conventions, measurements, attributes and semantics. It allows data from a data warehouse from across the organisation to be effectively used in a consistent manner. Subject-orientated: Large amounts of data is stored across an organisation, some data could be irrelevant for reports and makes querying the data difficult. It organises only key business information from operational sources so that it's available for analysis. Historical: Real-time TPS represent the current value at any time, an example could be stock levels. If past data is kept, querying the database could return a different response. It stores series of snapshots for an organisation's operational data generated over a period of time. Read-only: Once data is moved into a data warehouse, it becomes read-only, unless it was incorrect. Since it represents a snapshot of a certain time, it must never be updated. Only operations which occur in a data warehouse are loading and querying data.
Backup Procedures
A Dataflow Diagram of backup and reocvery procedures.Since business organisations have become very dependent on TPSs, a breakdown in their TPS may stop the business' regular routines and thus stopping it's operation for a certain amount of time. In order to prevent data loss and minimise disruptions when a TPS breaks down a well-designed backup and recovery procedure is put into use. The recovery process can rebuild the system when it goes down.
Recovery Process A TPS may fail for many reasons. These reasons could include a system failure, human errors, hardware failure, incorrect or invalid data, computer viruses, software application errors or natural disasters. So it is logical to assume that it's not possible to keep a TPS from never failing, however because it may fail time to time, it must be able to cope with failures. The TPS must be able to detect and correct errors when they occur. A TPS will go through a recovery of the database to cope when the system fails, it involves the backup, journal, checkpoint and recovery manager:
Backup: A backup copy is usually produced at least once a day. It should be stored in a secure location, protected from damage and loss. Journal: A journal maintains an audit trail of transactions and database changes. Transaction logs and Database change logs are used, a transaction log records all the essential data for each transactions, including data values, time of transaction and temrinal number. A database change log contains before and after copies of records that have been modified by transactions. Checkpoint: A checkpoint record contains necessary information to restart the system. These should be taken frequently, such as several times an hour. It is possible to resume processing from the most recent checkpoint when a failure occers with only a few minutes of processing work that needs to be repeated. Recovery Manager: A recovery manager is a program which restores the database to a correct condition which can restart the transaction processing. Depending on how the system failed, there can be two different recovery procedures used. Generally, the procedures involes restoring data that has been collected from a backup device and then running the transaction processing again. Two types of recovery are backward recovery and forward recovery:
Backward recovery: used to undo unwanted changes to the database. It reverses the changes made by transactions which have been aborted. It involves the logic of reprocessing each transaction - which is very time consuming. Forward recovery: it starts with a backup copy of the database. The transaction will then reprocess according to the transaction journal that occurred between the time the backup was made and the present time. It's much faster and more accurate.
Types of Back-up Procedures There are two main types of Back-up Procedures: Grandfather-father-son and Partial backups:
Grandfather-Father-Son This procedure refers to at least three generations of backup master files. Hence, the most recent backup is the son, the oldest backup is the grandfather. It's commonly used for a batch transaction processing system with a magnetic tape. If the system fails during a batch run, the master file is recreated by using the son backup and then restarting the batch. However if the son backup fails, is corrupted or destroyed, then the next generation up backup (father) is required. Likewise, if that fails, then the next generation up backup (grandfather) is required. Of course the older the generation, the more the data may be out of date. Organisations can have up to twenty generations of backup.^^
Partial Backups This only occurs when parts of the master file are backed up. The master file is usually backed up to magnetic tape at regular times, this could be daily, weekly or monthly. Completed transactions since the last backup are stored separately and are called journals, or journal files. The master file can be recreated from the journal files on the backup tape if the system is to fail.
Updating in a Batch This is used when transactions are recorded on paper (such as bills and invoices) or when it's being stored on a magnetic tape. Transactions will be collected and updated as a batch at when it's convenient or economical to process them. Historically, this was more widely used as the information technology did not exist to allow real-time processing.
The two stages in batch processing are:
Collecting and storage of the transaction data into a transaction file - this involves sorting the data into sequential order. Processing the data by updating the master file - which can be difficult, this may involve data additions, updates and deletions that may require to happen in a certain order. If an error occurs, then the entire batch fails. Updating in batch requires sequential access - since it uses a magnetic tape this is the only way to access data. A batch will start at the beginning of the tape, then reading it from the order it was stored; it's very time-consuming to locate specific transactions.
The information technology used inclues a secondary storage medium which can store large quantities of data inexpensively (thus the common choice of a magnetic tape). The software used to collect data does not have to be online - it doesn't even need a user interface.
Updating in Real-Time This is the immediate processing of data. It provides instant confirmation of a transaction. This involves a large amount of users who are simultaneously performing transactions to change data. Because of advances in technology (such as the increase in the speed of data transmission and larger bandwidth), real-time updating is now possible.
Steps in a real-time update involve the sending of a transaction data to an online database in a master file. The person providing information is usually able to help with error correction and receives confirmation of the transaction completion.
Updating in real-time uses direct access of data. This occurs when data is accessed without accessing previous data items. The storage device stores data in a particular location based on a mathematical procedure. This will then be calculated to find an approximate location of the data. If data is not found at this location, it will search through successive locations until it's found.
The information technology used could be a secondary storage medium that can store large amounts of data and provide quick access (thus the common choice of a magnetic disk). It requires a user-friendly interface as it's important for rapid response time.
References ↑ a NSW HSC Online ↑ a b c WICS TP Chapter 1
See also Transaction processing Online transaction processing Retrieved from http://en.wikipedia.org/wiki/Transaction_Processing_System
End of Wikipedia content, http://en.wikipedia.org/wiki/Transaction_Processing_System
Content derived from Wikipedia article on Online Transaction Processing
Online transaction processing
Online Transaction Processing (or OLTP) is a class of programs that facilitate and manage transaction-oriented applications, typically for data entry and retrieval transaction processing.
The term Online Transaction Processing is somewhat ambiguous: some understand "transaction" as a reference to computer or database transactions, while others (such as the Transaction Processing Performance Council) define it in terms of business or commercial transactions.
OLTP also refers to computer processing in which the computer responds immediately to user requests. An automatic teller machine for a bank is an example of transaction processing.
Contents
1 Uses 2 Requirements 3 Benefits 4 Disadvantages 5 See also 6 External links
Uses It is a technique used in a number of industries, including banking, airlines, mailorder, supermarkets, and manufacturers. Some applications of OLTP include electronic banking, order processing, employee time clock systems, e-commerce, and eTrading.
Probably the most widely installed OLTP product is IBM's CICS (Customer Information Control System).[citation needed]
Requirements Today's online transaction processing increasingly requires support for transactions that span a network and may include more than one company. For this reason, new OLTP software uses client/server processing and brokering software that allows transactions to run on different computer platforms in a network.
In large applications, efficient OLTP may depend on sophisticated transaction management software (such as CICS) and/or database optimization tactics to facilitate the processing of large numbers of concurrent updates to an OLTP-oriented database.
For even more demanding decentralized database systems, OLTP brokering programs can distribute transaction processing among multiple computers on a network. OLTP is often integrated into service-oriented architecture and Web services.
Benefits Online Transaction Processing has two key benefits: simplicity and efficiency.
Reduced paper trails and the faster, more accurate forecasts for revenues and expenses are both examples of how OLTP makes things simpler for businesses. It also provides a concrete foundation for a stable organization because of the timely updating. Another simplicity factor is that of allowing consumers the choice of how they want to pay, making it that much more enticing to make transactions.
OLTP is proven efficient because it vastly broadens the consumer base for an organization, the individual processes are faster, and it’s available 24/7.
Disadvantages It is a great tool for any organization, but in using OLTP, there are a few things to be wary of: the security issues and economical costs.
One of the benefits of OLTP is also an attribute to a potential problem. The worldwide availability that this system provides companies with allows databases to be that much more susceptible to intruders and hackers.
For B2B transactions, businesses must go offline to complete certain steps of an individual process, causing buyers and suppliers to miss out on some of the efficiency benefits that the system provides. As simple as OLTP is, the simplest disruption in the system has the potential to cause a great deal of problems, causing a waste of both time and money. Another economic cost is the potential for server errors. This can cause delay or even wipe out an immeasurable amount of data.
See also Data mart Data warehouse OLAP ETL Transaction processing Database transaction Derby in-memory Java Database IBM Customer Information Control System
External links IBM CICS official website Transaction Processing Performance Council Comparison of OLTP and OLAP at gnuLAMP Retrieved from http://en.wikipedia.org/wiki/Online_transaction_processing
End of Wikipedia content, http://en.wikipedia.org/wiki/Online_transaction_processing
Legacy, Mainframe Transaction Processing Directory & Resources @ Mainframes.in
..
..
Main Sections @ Mainframes.in
Legacy Operating Systems > Midrange, Mainframe Legacy Databases > DB2, IMS DB/DC, VSAM, CA/IDMS, Unidata Legacy Programming & Development
Legacy Hardware > Mainframe Hardware, Midrange Hardware
Legacy & Non-legacy > Legacy & Contemporary OS, Legacy & Contemporary Databases, Legacy & Networking, Legacy & Contemporary Programming Languages, Legacy & Mainframe Migration
Other IT Resources
eIT.in – IT & Software Directory & Resources
Software > Operating Systems, Databases, Programming & Development, Mainframe & Legacy, Internet & Web
Hardware, Networking & Communications, IT Strategy & Design, IT in Industries, IT in Functions, IT Infrastructure, Tech Support, IT Industry & Trade Network, IT News & Updates
Mainframes.in provides directory and web links resources for the legacy, mainframes and midrange systems. It is intended to be useful for mainframe programmers & developers, midrange programmer & developer, legacy & mainframe databases software development, administrators & DBAs, application developers, mainframe strategy architect, legacy design specialists and architects, mainframe & legacy migration consultants and analysts, administration, maintenance & support professionals, mainframe & legacy outsourcing consultant, legacy solutions programming developers & coders, project management & functional analyst, and for mainframe, midrange, system administrators, testing & quality control engineers. It will make an effort to provide resources on tutorial/tutorials, guide/guides, tips, faq/faqs on these mainframe and legacy topics.
Reference
GeoDig – Get Local!
Have you checked out the GeoDig directories for over 30 countries? GeoDig provides useful local and regional web resources for over 200 cities around the world. See the list of cities and countries for which GeoDig provides locality-specific web resources.
North America USA - Alabama (AL) > Birmingham; Alaska; Arkansas (AR) > Little Rock; Arizona (AZ) > Phoenix, Las Vegas, Tucson; California (CA) > Los Angeles, San Francisco, Sacramento, Fresno, Bakersfield; Colorado, CO > Denver; Connecticut, CT > Hartford; District of Columbia, DC > Washington DC; Delaware (DE) > Wilmington; Florida > Miami, Orlando, Tampa, Orlando, Sarasota, West Palm Beach, Jacksonville; Georgia > Atlanta; Hawaii > Honolulu; Idaho; Illinois > Chicago; Indiana > Indianapolis; Iowa; Kansas (KS); Kentucky (KY) > Louisville; Louisiana (LA) > New Orleans, Baton Rouge; Maine; Maryland (MD) > Baltimore; Massachusetts > Boston, Springfield; Michigan > Detroit, Grand Rapids; Minnesota > Minneapolis-St. Paul; Mississippi (MS); Missouri (MO) > Kansas City, St. Louis; Montana; Nebraska (NE) > Omaha; Nevada (NV) > Las Vegas; New Hampshire; New Jersey (NJ) > Jersey City, Newark; New Mexico (NM) > Albuquerque; New York > New York, Buffalo, Rochester, Albany, Syracuse; North Carolina (NC) > Raleigh-Durham, Charlotte, Greensboro; North Dakota; Ohio> Columbus, Cincinnati, Cleveland, Toledo, Youngstown, Dayton; Oklahoma (OK) > Oklahoma City, Tulsa; Oregon > Portland; Pennsylvania > Philadelphia, Allentown, Pittsburgh, Harrisburg, Scranton, ; Rhode Island (RI) > Providence; South Carolina (SC) > Greenville; South Dakota; Tennessee (TN) > Knoxville, Memphis, Nashville; Texas > Austin, Dallas, Houston, San Antonio, El Paso, Austin, McAllen; Utah (UT) > Salt Lake City; Vermont; Virginia (VA) > Norfolk, Richmond; Washington > Seattle; West Virginia; Wisconsin (WI) > Milwaukee; Wyoming Canada - Vancouver, Montreal, Toronto, Calgary, Ottawa-Gatineau, Edmonton, Quebec City, Winnipeg, Hamilton, London
Europe - UK - London, Glasgow, Manchester, Birmingham, Liverpool, Sheffield, Leeds, Bristol, Edinburgh, Leicester; France - Paris, Marseille, Lyon, Toulouse, Nice, Nantes, Strasbourg, Montpellier, Bordeaux; Germany - Frankfurt (Frankfurt am Main), Munich (München), Berlin, Düsseldorf, Hamburg, Cologne (Köln), Essen, Dortmund, Stuttgart, Bremen, Duisburg, Hannover, Nürnberg (Nuremberg), Dresden, Leipzig; Italy - Milan (Milano), Rome (Roma), Napoli (Naples), Torino (Turin), Palermo, Bologna, Firenze (Florence), Genova (Genoa); Spain - Madrid, Barcelona, Valencia, Sevilla, Zaragoza, Malaga, Murcia, Las Palmas, Bilbao; Scandinavia - Finland - Helsinki (Helsingin), Espoo, Tampere (Tampereen), Vantaa, Turku, Oulu, Sweden - Stockholm, Goteborg (Göteborg), Malmo (Malmö), Uppsala, Vasteras (Västerås), Denmark - Copenhagen (Københavns), Aarhus (Århus), Odense, Aalborg (Ålborg), Norway - Oslo, Bergen, Stavanger, Trondheim; Benelux - Belgium - Brussels (Brussel), Antwerp (Antwerpen), Ghent (Gent, Gand), Charleroi, Liège (Liege), Netherlands - Amsterdam, Rotterdam, Utrecht, Eindhoven, Tilburg, ‘s-Gravenhage (sGravenhage), Groningen, Luxembourg - Luxembourg City; Portugal – Lisbon; Greece – Athens; Hungary – Budapest; Poland – Warsaw; Switzerland - Zürich (Zurich), Geneva (Geneve, Genève), Basel, Bern (Berne), Lausanne; Austria - Linz, Vienna (Wien), Graz, Linz, Salzburg, Innsbruck; Ireland – Dublin
Asia - India - Mumbai, New Delhi, Bangalore; China & Hong Kong - Hong Kong, Beijing, Shanghai, Tianjin, Wuhan, Shenyang, Guangzhou, Harbin, Xian; Japan - Tokyo, Osaka, Yokohama, Nagoya, Sapporo, Kyoto, Kobe, Fukuoka, Kawasaki, Hiroshima; South Korea - Seoul, Pusa, Taegu, Incheon, Taejeon, Taiwan - Taipei; Malaysia - Kuala Lumpur; Singapore; Russia - Moscow, St Petersburg
Middle East - Turkey - Istanbul, Israel - Tel Aviv
Oceania - Australia - Sydney, Melbourne, Brisbane, Perth, Adelaide
Africa - South Africa - Johannesburg, Cape Town, Durban
|
Web Co-ordinator: Narasimhan Santhanam ( narsi@esource.in )
© 2004 – 05, From Mainframes.in – Home of Legacy & Mainframes Online