fail as they choose. Instead, the sizing and configuration of this environment is
more closely matched to production needs. Fully tested applications are
introduced here and stress tested using the teleprocessing network simulator
(TPNS). The scripts used with TPNS are created from production traces and
matching production data.
1.2.3 Software Levels
As of August 1998, the following key product software levels were installed on
the systems used during the residency:
Software Release Level
MVS OS/390 2.4
IMS Version 6.1
BMC Delta/VT V6.0.7
DB2 V5.0
VTAM V4.4
RACF V1.9
1.2.4 Software Maintenance Environment
IMS Support has responsibility for providing a stable IMS software environment
to the user community. The installation of all software and fixes into the System
Modification Program (SMP) distribution libraries is carried out by a Product
Installation Group at the request of the IMS group. This installation is always
done on the machines used by the systems programmers, the Apex. To ensure
that correct versions, maintenance levels and fixes are installed, close
coordination is required between the Product Installation group and the IMS
group. Thus the Product installation Group and IMS Support both have well
documented and well understood procedures.
IMS system generations are carried out as required, using the distribution
libraries containing the appropriate software levels. The distribution library is
selected by means of an ISPF panel that forms the front-end of an automated
IMSGEN process. Before distribution to application development environments
the new software is installed into systems programming run-time libraries and
tested using the IBM-supplied Installation Verification Program (IVP) application.
Any new software is always installed into new SMP libraries so its introduction
into application environments can be strictly controlled. After a suitable
shakedown period, the new software is rolled out to the next IMSs. This
technique removes the need to make multiple maintenance runs of the same
fixes. A fix needs to be applied and accepted only once. This process is
described further in Appendix E, “System Maintenance Procedures” on
page 147.
1.3 Understanding the IMS Environment in which Flexcab Runs
IMS systems IME1 and IME2, are the two IMS systems that are used by Flexcab
for stress and volume testing. IME1 and IME2 were the targeted environments
for the shared-queue implementation. IME1 and IME2 are IMS systems that are
copies of the two production IMSs, IMFD and IMFK. A successful implementation
of shared queues in the IME1 and IME2 environments will lead to implementing
shared-queues in the IMFD and IMFK environments later. IME1 and IME2 are the
Chapter 1. Introduction to Telstra and IBM Global Services Australia 5
two IMSs used as a stress test environment for the Flexcab application. CPU
constraints make it impossible to replicate the workload that is put through the
IMFD and IMFK environments in IME1 and IME2. IMFD is the front-end
production IMS and it normally has about 5000 users connected to it, processing
up to 320 full-function transactions a second.
IME1 is the front-end IMS in the stress and test environment that the users
connect to, and a subset of the transactions are routed to IME2 via an MSC link
for processing. The routing to IME2 is required because no data sharing is
performed between the two environments, although plans for data sharing are
under way.
IME1 has 2794 transactions defined to it, while IME2 has 159 transactions defined
to it. A few transactions are defined on both systems that require special
attention. A small number of transactions are received from APPC and
MQSeries. The APPC transactions are explicit-mode transactions. Most of the
Flexcab databases are DB2 databases, connected to both IME1 and IME2.
Transaction volume varies depending on when a new release of the application
is being rolled out or fixes are being tested.
Flexcab managements is charged with producing a document detailing how
IME1 and IME2 systems will be put into a shared-queue environment. The move
to shared-queues must not effect reliability and must cause only minor
performance degradation. A plan to fall back to a non-shared-queues
environment needs to be prepared. Such fallback would need to be performed
within 60 minutes.
6 IMS/ESA Shared Queues Planning Guide

Get IMS/ESA Shared Queues: A Planning Guide now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.