Protecting applications from one another

The transaction isolation function offers storage protection between application programs, ensuring that one application does not accidentally overwrite the storage of another.

Transaction isolation ensures that user-key programs1 execute in their own subspace, with appropriate access to any shared storage, or to CICS storage. Thus a user transaction is limited to its own view of the address space. In general, transaction isolation ensures that each user-key program is allocated a separate (unique) subspace, with appropriate access to any shared storage or to CICS storage. They do not have any access to the user-key task-lifetime storage of other tasks. Existing applications should run unmodi®ed provided they conform to transaction isolation requirements. However, a minority of applications may need special de®nition if they:

vIssue MVS macros directly

vModify CICS control blocks

vHave a legitimate need for one task to access or share another task's storage

Some existing transactions may share task-lifetime storage in various ways, which may prevent them running isolated from each other. To allow such transactions to continue running without requiring that they run in the base space (where they could corrupt CICS data or programs), a single common subspace is provided in which all such transactions can run. They are then isolated from the other transactions in the system that are running in their own subspaces, but are able to share each other's data within the common subspace.

You may have some transactions whose application programs access each other's storage in a valid way. One such case is when a task waits on one or more event control blocks (ECBs) that are later posted, by another task, either an MVS POST or `hand posting'. For example, a task can pass the address of a piece of its own storage to another task (via a temporary storage queue or some other method) and then WAIT for the other task to post an ECB to say that it has updated the storage. Clearly, if the original task is executing in a unique subspace, the posting task will fail when attempting the update and hence fail to post the ECB, unless the posting task is executing in CICS key. CICS therefore checks when a WAIT is issued that the ECB is in shared storage, and raises an INVREQ condition if it is not.

Storage for the timer-event control area on WAIT EVENT, and storage for event control blocks (ECBs) speci®ed on WAIT EXTERNAL and WAITCICS commands, must reside in shared storage.2

You can use the Transaction Affinities Utility to identify those transactions whose programs issue WAIT EVENT, WAIT EXTERNAL, or WAITCICS commands, or MVS POST macros.

1.User key de®nes both the storage and execution key for user application programs.

2.Shared storage is allocated from one of the user-key shared dynamic storage areas, below or above the 16MB boundary (SDSA or ESDSA).

Chapter 1. Introducing transaction affinities 7

Page 22 Page 24
Page 23
Image 23
IBM OS manual Protecting applications from one another
Page 22 Page 24

OS specifications

IBM OS, or IBM Operating System, refers to a family of operating systems developed by IBM to support its hardware architectures. IBM has produced a range of OS versions tailored for different computing needs, such as mainframes, servers, and personal computers. Among the most notable operating systems in IBM's portfolio are OS/2, z/OS, and AIX, representing a blend of innovation and reliability that has defined IBM's reputation in the computing world.

One of the defining features of IBM OS is its robust multitasking capabilities. Both z/OS, predominantly used in IBM's mainframe environments, and AIX, the Unix-based system for IBM Power Systems, support multiple users and processes simultaneously. This ability allows organizations to run numerous applications in parallel efficiently, maximizing resource utilization and improving productivity.

In terms of security, IBM OS incorporates advanced features aimed at protecting data and maintaining integrity. z/OS offers multifactor authentication, data encryption, and a security model that adheres to the latest regulatory requirements. AIX provides Secure Virtualization, which enhances isolation and security in cloud environments, essential for enterprises handling sensitive information.

Another key characteristic is the adaptability of IBM OS to modern technologies. For instance, z/OS is designed to integrate with cloud computing, open source, and DevOps practices. This adaptability supports organizations in modernizing their infrastructure while retaining the stability associated with IBM solutions. AIX similarly supports containerization and virtualization, which are critical for optimizing resource usage in dynamic computing environments.

IBM's commitment to scalability is evident across its OS offerings. Organizations leveraging z/OS can handle enormous workloads and transactional volumes, making it a preferred choice for industries like finance and telecommunications. AIX also supports scalability, allowing businesses to expand their computing resources as demands grow without significant downtime.

The availability of development tools and environments is another noteworthy aspect of IBM OS. With robust IDEs and programming languages support, developers can create and deploy applications smoothly. This assists businesses in streamlining their development processes and improving time-to-market for innovative solutions.

In summary, IBM OS encompasses a suite of operating systems characterized by multitasking, security, adaptability to modern technologies, scalability, and comprehensive development support. These features have cemented IBM's position as a leader in enterprise solutions, allowing organizations across various industries to thrive in an increasingly digital world.
Top Page Image Contents