MVS Systems Programming: Chapter 3d - MVS Internals http://www.mvsbook.fsnet.co.uk/chap03d.htm

MVS Systems Programming Home Chapter 3d - MVS Internals Contents

The Web Version of this chapter is split into 4 pages - this is page 4 - page contents are as follows:

Section 3.8 - Catalogs 3.8.1 Logical Catalog Structure 3.8.2 Physical Catalog Structure 3.8.3 The Catalog Address Space 3.9 Inter-Address Space Communication 3.9.1 Common Storage and SRB's 3.9.2 Cross Memory Services 3.9.3 Dataspaces and Hiperspaces Bibliography

Home Contents Prev part of chapter Next Section Top of Page 3.8 Catalogs

Catalogs are used by MVS to locate datasets when a task attempts to allocate them without supplying their volume serial number; they hold records of the volume(s) on which each cataloged dataset exists. All allocations of VSAM datasets and SMS-managed datasets must go through the relevant catalog, and in this case the catalog also holds other information - for VSAM datasets, for example, this includes the physical location of each extent of the dataset on the disk, DCB-type information, and much more (this information is held in the VTOC entry, also known as the DSCB, for non-VSAM DASD datasets). This section looks briefly at the logical and physical structure of catalogs and how the catalog management process works.

Over the course of MVS's history, catalogs have gone through a number of different structures. The current flavour is known as ICF (Integrated Catalog Facility), and I shall concentrate on ICF catalogs here, though I will make a few comments on the earlier flavours in passing (the predecessors to ICF catalogs were known as VSAM catalogs, and the previous generation as CVOLs).

3.8.1 Logical Catalog Structure

Each MVS system must have a master catalog, and there will usually also be a number of lower-level catalogs known as user catalogs. All catalog searches begin by searching the master catalog, and many major system datasets must be cataloged in it.

Prior to MVS Version 4, the master catalog was described in the SYSCATxx member of SYS1.NUCLEUS, where the suffix xx was specified in response to the message "IEA3347A SPECIFY MASTER CATALOG PARAMETER" at IPL time, and defaulted to "LG". This is still a valid option on MVS Version 4 systems, but it is also now possible (and simpler) to specify the master catalog parameters in the LOADxx member of SYS1.PARMLIB. The use of LOADxx is discussed in more detail in chapter 7.

MVS obtains the name of the master catalog and the VOLSER of the disk it is on from the SYSCATxx or LOADxx member, and then opens the master catalog, which it uses to find the other datasets it requires for the early stages of the IPL process. At this stage, the master catalog is the only catalog which is open and usable by the system, which is why any system datasets opened during the IPL process must be cataloged in it. Later in the IPL process, catalog management services are fully initialised, allowing the use of user catalogs.

The physical structure of the master catalog is identical to that of a user catalog - they are defined with the same IDCAMS command, and any catalog can be used as either a master catalog or a user catalog. So it is only the selection of a particular catalog at IPL time that identifies it as the master catalog for the MVS system concerned.

However, once you have established which catalog is your master catalog, it is necessary to define its relationships with its user catalogs, and in practice this will make the entries in a master catalog very different from those in a user catalog. Whenever MVS initiates a catalog search in order to locate a dataset, it starts by looking at the master catalog. The dataset to be located may be cataloged in the master catalog, but more commonly it will be cataloged in a user catalog. If the search process is to find it, that user catalog must be defined as a user catalog in the master catalog, and there must be an "alias" entry in the master catalog which relates the high-level qualifier of the dataset's name to the user catalog. When catalog management finds such an alias entry, it interprets this as an instruction to look in the specified user catalog for the catalog entries of all datasets with this high-level qualifier.

1 of 7 11/2/2001 1:48 PM MVS Systems Programming: Chapter 3d - MVS Internals http://www.mvsbook.fsnet.co.uk/chap03d.htm

Thus there is a two-level hierarchy of catalogs, with most user datasets cataloged in the user catalogs, and the master catalog containing alias entries pointing to the user catalogs, plus catalog entries for system datasets required at IPL time. This is illustrated in Figure 3.8 below. It is generally the systems programmer's responsibility to design and enforce this hierarchy.

**** insert Fig 3.8 ****

Home Contents Previous Section Next Section Top of Page

3.8.2 Physical Catalog Structure

Physically, the ICF catalog structure consists of two types of datasets: the BCS (Basic Catalog Structure) and VVDS (VSAM Volume DataSet). When we define a master catalog or a user catalog (using IDCAMS), we are creating a BCS. The BCS is itself a VSAM KSDS, whose cluster name is 44 bytes of binary zeros (as this is used as the key to the dataset, this ensures that the first entry in the data component of the BCS is always its own self-describing entry). The name of the data component is the name you assign in your IDCAMS DEFINE command, and the name of the index component, assigned by IDCAMS, always begins "CATINDEX" and continues with a timestamp.

The BCS contains entries of various types, such as ALIAS, NONVSAM, USERCATALOG, and CLUSTER, describing the various types of entity which may be searched for by catalog management:

* ALIAS entries were discussed in the previous section, and redirect a catalog search from the master catalog to a user catalog for a given high-level qualifier. Note that DFP Version 3 permits multi-level alias structures, but these are still uncommon.

* USERCATALOG entries define user catalogs

* NONVSAM entries describe non-VSAM datasets, and for non-SMS managed datasets include simply their name and the device type and volume serial number of the volume on which they are cataloged - further information, e.g. on the DCB and physical location of the dataset on the volume, is found in the VTOC (Volume Table of Contents) for DASD datasets or in the dataset labels for tape datasets.

* CLUSTER entries describe VSAM datasets, and point in turn to DATA entries describing the data component of the cluster, and (for KSDS's) to INDEX entries describing the index component. This is where ICF catalogs differ most markedly from their predecessors.

In an ICF catalog, the entry in a BCS for a physical component of a VSAM cluster works in a similar way to a NONVSAM entry. The BCS entry only contains minimal information about the component, such as the name, the device type and volume serial number, and all the physical details, such as location of extents, CISIZE, etc, is held on the same volume as the dataset itself, to simplify recovery and space management. For VSAM components, however, this information is not held in the VTOC entry. Instead it is held in the second component of the ICF catalog structure - the VSAM Volume Data Set (VVDS).

The VVDS is a special type of ESDS. It is created automatically whenever a VSAM component (including a BCS) is allocated on a volume which does not yet have a VVDS. The VVDS is always called SYS1.VVDS.Vvolser, where volser is the volume serial number of the volume, and you can preallocate a cluster with this name on the volume if you wish to override any of the defaults for VVDS allocation (or control its physical location on the volume).

The first record in every VVDS is known as the VSAM Volume Control Record (VVCR), and consists of two parts. The first of these lists the BCS catalogs which own (or have owned) VSAM datasets cataloged on this volume - these entries are known as "back pointers". The second part maps free space within the VVDS itself, and allows reuse of space within the VVDS (this is the main way in which it differs from a normal ESDS). The second record in the VVDS is a self-describing record, and the rest of the records are either VSAM Volume Records (VVRs) or Non-VSAM Volume Records (NVRs - a new record type introduced with DFSMS).

There is at least one VVR for each VSAM component on the volume, describing its physical extents, key and record sizes, CI/CA sizes, etc. The physical extent information duplicates information in the VTOC, but the VTOC is only used when the component is being defined, deleted, and extended, while normal read/write accesses to the component use the extent information in the VVR.

It should be clear that in this structure, there is a many-to-many relationship between BCS and VVDS datasets. That is, each BCS can own VSAM components on multiple volumes (and therefore uses multiple VVDS's), while each VVDS can contain entries for VSAM components owned by multiple BCS's. Just as the BCS entry for each component contains a pointer to the volume it exists on (and therefore to the VVDS), each VVR contains an indicator which connects it to the back pointer in the VVCR which corresponds to its owning BCS.

To complicate the matter just a little more, the introduction of DFSMS has extended the function of the VVDS. Non-VSAM datasets before the days of DFSMS were only represented in the catalog structure by an entry in a BCS, while all other dataset information was

2 of 7 11/2/2001 1:48 PM MVS Systems Programming: Chapter 3d - MVS Internals http://www.mvsbook.fsnet.co.uk/chap03d.htm

held in the dataset's entry in the VTOC. SMS-controlled non-VSAM datasets, however, do also have an entry (an NVR) in the VVDS of the volume on which they are located.

Before we leave catalog structures, let us briefly mention the differences between ICF catalogs and their predecessors, VSAM catalogs, which you may occasionally come across (if you do, I strongly recommend getting rid of them as quickly as possible!). The main differences were:

* VSAM catalogs did not use VVDS's - all information was held in the main catalog structure, which was simply known as a VSAM catalog

* Because this would have made recovery of volumes with VSAM components belonging to different catalogs extremely difficult, there was a concept of "VSAM volume ownership" - each volume was "owned" by a VSAM catalog, and VSAM datasets could only be allocated on the volume if they were cataloged in the VSAM catalog which owned it

* Under ICF catalogs, every VSAM component corresponds to a dataset which has space allocated to it using normal DADSM (DASD Space Management) routines and which appears in the VTOC with the same name as the VSAM component. VSAM catalogs, however, allowed the user to allocate a "dataspace" (no connection to the MVS/ESA dataspace concept discussed below!) which was then available for VSAM to suballocate to VSAM components without telling DADSM or the VTOC.

Home Contents Previous Section Next Section Top of Page

3.8.3 The Catalog Address Space

With the introduction of MVS/XA, a catalog address space known as CAS was created, which is started up at every IPL. This is used by the DFP catalog management function to hold most of its program modules and control blocks, which were previously held in the PLPA and CSA respectively. (DFP, or Data Facility Product, like JES, is a product which for all intents and purposes is part of MVS, though IBM markets it as a seperate product).

Catalog management routines also use CAS to "cache" records from catalogs - in other words, frequently referenced catalog records, including ALIAS entries from the master catalog, will be held in virtual storage in the CAS address space to avoid the need to repeatedly perform real I/O to disk for them. Unfortunately, in pre-ESA versions of DFP, records from catalogs shared with other MVS systems are flushed out when the system attempts to re-use them.

Each request for a catalog management service is handled by a "CAS task", which is assigned a task ID, and the status of these tasks can be monitored using the MODIFY CATALOG operator command. The LIST subcommand lists out CAS tasks, showing their task ID, the catalog they are trying to access, and the job on whose behalf they are trying to access it. The END or ABEND subcommand can then be used to terminate the CAS task if necessary.

MVS/ESA versions of DFP also provide commands which allow you to allocate and deallocate user catalogs, enabling certain maintenance functions to be performed more easily.

Home Contents Previous Section Next Section Top of Page 3.9 Inter-Address Space Communication

The way in which the MVS addressing scheme works is ideal for protection of users from one another. Separate address spaces are unable to address each other's private virtual storage because they cannot access the page and segment tables which tell them where the real page frames are which back the virtual storage of another address space. In other words, the architecture itself protects the private virtual storage of each address space from tasks executing in other address spaces.

However, this "advantage" turns into an enormous obstacle when you have a genuine reason for wishing to communicate between two address spaces - and this is an increasingly common requirement in the era of online/real-time computing. Originally, MVS only had one mechanism for communicating between address spaces - the use of common storage. True, the system could schedule an SRB to run in one address space from another one, but this still had to use common storage for any data to be passed between them.

But there are disadvantages in using common storage for inter-address space communication:

* there is a limited amount of common storage available, particularly below the 16 Mb line, so using it for frequent tasks passing significant amounts of data can be impractical - indeed, if you try to use more CSA than was allocated at IPL time, your MVS system will fall over!

* by definition, any address space can "see" what is in common storage, and update it if it is not page-protected, so sensitive or

3 of 7 11/2/2001 1:48 PM MVS Systems Programming: Chapter 3d - MVS Internals http://www.mvsbook.fsnet.co.uk/chap03d.htm

system-critical data is less secure there than in an area of private virtual storage.

So IBM have developed services which allow us to communicate between address spaces without using common storage - Cross Memory Services, introduced with MVS/XA, and Dataspaces and Hiperspaces, introduced in MVS/ESA.

Each of these mechanisms for inter-address space communication is discussed in a little more detail in the sections that follow. Each of them is complex to use, and it seems unlikely that many users or application programmers will use any of them directly, but they are already in widespread use by writers of packaged software inside and outside IBM.

3.9.1 Common Storage and SRB's

We have already covered common storage in the section on Storage Management above. Some areas, such as the PLPA, are page-protected, and others, such as the nucleus, have specialised system uses. Others, however, are available for tasks running with storage protect key zero to GETMAIN, update, read, and FREEMAIN as required. In particular, the Common Storage Area (CSA/ECSA) and System Queue Area (SQA/ESQA) are available for the use of tasks wishing to pass data between address spaces.

Indeed, there are several common system tasks which frequently use CSA for this purpose. The main user of CSA on many systems is VTAM, which puts its message buffers there. Thus, when VTAM has received a message from a terminal via an interrupt from the I/O subsystem, it places it in the CSA, determines which address space it is intended for, then schedules an SRB into that address space to inform it that a message has been received and where in virtual storage it can be found. If VTAM was to place the message in its own private area, the receiving address space could not access it; and the architecture prevents if from placing it directly into the receiving address space's private area.

SRB's were mentioned above in the section on Task Management. They are high-priority dispatchable units of work created with the SCHEDULE macro by functions running in supervisor state and storage key zero. Their relevance to this section is that they can be scheduled to run in any specified address space, whichever address space the function which schedules them is running in. Thus, a function in one address space can schedule an SRB to prompt a function in another address space to process some data placed in common storage by the first function.

The use of this mechanism led to increasing requirements for CSA in older levels of MVS. However, since the introduction of the new methods of inter-address space communication, there has been a tendency to reduce the usage of CSA in favour of the new methods, and most installations should now see a decline in the use of CSA.

Home Contents Previous Section Next Section Top of Page

3.9.2 Cross Memory Services

The term "Cross Memory Services" refers to a set of machine instructions, and the facilities they invoke, which were introduced in MVS/XA. These instructions provide the ability to address data in two address spaces simultaneously, to move data between these two address spaces, and to invoke programs in one address space from another.

Unlike SRB's, Cross Memory Services allow synchronous use of data and programs in different address spaces - a function which switches itself into cross memory mode may access resources in another address space without suffering any interrupts in the process, and without the requirement to initiate another unit of work to access the second address space on its behalf. This is clearly much more flexible, and potentially faster and more efficient, than asynchronous communication using SRB's.

At the heart of Cross Memory Services is the concept of primary and secondary address spaces. Normally the primary address space will be the "home" address space of the unit of work which initially invoked Cross Memory Services, and the secondary address space will be another address space with which communication is required. There are control registers which are used to hold the real addresses of the segment tables for the primary and secondary address spaces, and this enables a modified version of Dynamic Address Translation to be used to resolve the real storage locations of data in both address spaces for a single cross-memory instruction.

The main facilities supplied by Cross Memory Services are implemented as follows:

* data movement between address spaces - several instructions are provided which can perform this function. MVCP moves data from the secondary address space to the primary; MVCS moves data in the opposite direction; and MVCK performs a similar function between areas with different storage protect keys. Note that these instructions require that the function knows the addresses of the data areas it wishes to use in both address spaces - finding these can be complicated!

* data sharing between address spaces - address spaces can be set up which act as data servers for a number of other address spaces, then one of several methods used to access the data from the "clients", without actually moving it into the client address space. For example, programs running in common storage can switch into secondary mode to access data in the shared address space (in primary

4 of 7 11/2/2001 1:48 PM MVS Systems Programming: Chapter 3d - MVS Internals http://www.mvsbook.fsnet.co.uk/chap03d.htm

mode, ordinary machine instructions are taken to refer to storage in the primary address space, but in secondary mode they are taken to refer to storage in the secondary address space). Alternatively, the program call mechanism (see next bullet point) can be used to invoke a "server" program in the shared address space to access data and return a result to the client.

* program sharing - the PC (program call) instruction can be used to transfer control to a program in another address space, and the PT (program transfer) or PR (program return) instructions used to return. This requires the function running in the original address space to know how to find the program to be called, and Cross Memory Services provides a control block structure containing "linkage tables" and "entry tables" to hold this information.

The linkage and entry tables are held in the PCAUTH address space. There is one linkage table for each address space, containing an entry for each PC service the address space is authorised to access. Whenever an address space wishes to offer a PC service, it creates an entry for the service in the linkage table of each address space it wishes to offer the service to. The linkage table entries point to entry tables, which contain more information about the program(s) which can be called as part of this service, including their entry point address and the address space in which they will execute. Thus, any given address space can only invoke PC services which the supplying address spaces have deliberately given it access to.

There are a number of restrictions on programs running in cross memory mode. Some of the most important are:

* they cannot issue any SVC's except ABEND

* cross memory access to swapped-out address spaces is not supported, and any attempt to do so results in an ABEND

* only one step of any given job can set up a cross-memory environment

There is also a seperate authorisation structure which restricts the address spaces which any one address space can access using cross memory facilities. This, and many other aspects of Cross Memory Services, is well documented in "MVS/ESA SPL: Application Development - Extended Addressability" (or "SPL: System Macros and Facilities Volume 1" for XA systems).

It should be clear that use of Cross Memory Services is highly complex, and will usually only be attempted within sophisticated software products. IBM themselves warn that improper use of Cross Memory Services can cause severe system problems, so most of us would be well advised to leave it to the software suppliers!

A typical use of Cross Memory Services is in the implementation of Multi-Region Operation in CICS. Users log on to a "terminal-owning region" (TOR), but when they enter a transaction identifier to select the application they wish to use, the TOR uses Cross Memory Services to "ship" the processing request to the "application-owning region" (AOR) corresponding to the application selected. The AOR processes the transaction, then when it has a message to return to the user, it uses Cross Memory Services to pass this back to the TOR. The TOR is then responsible for sending the response back to the user. Interestingly, CICS is able to run MRO using either Cross Memory Services or SRB's, and it is at the discretion of the CICS systems programmer which is used.

Home Contents Previous Section Next Section Top of Page

3.9.3 Dataspaces and Hiperspaces

Dataspaces and Hiperspaces, introduced with MVS/ESA, are MVS's latest mechanism for inter-address space communication.

A dataspace is a special type of address space which does not include the common areas in its virtual storage (i.e. it has private areas at those addresses which are used for common areas in a normal address space), and from which machine instructions can not be executed. These restrictions make dataspaces unsuitable for any use other than as a repository for data, hence their name. Although they were ostensibly introduced in order to allow a single address space to address more than the 2 Gigabytes of virtual storage allowed by a 31-bit addressing scheme, it seems unlikely that there are many genuine applications yet available which are restricted by this limit. A more important reason for their use is to make it possible to bring large data files into virtual storage in such a way that they are shareable between multiple address spaces.

Dataspaces are much easier to use than previous methods of inter-address space communication, due to a new way of addressing the data in them, called "Access Register Addressing Mode" (AR mode) or the "Advanced Address Space Facility" (AASF). This uses a new set of 16 access registers which are part of the ESA architecture, and a series of changes to machine instructions to take advantage of them. A function can switch itself into AR mode with a single instruction; once it has done this, familiar instructions such as MVC take on new ways of working.

The MVC instruction, for example, normally uses an offset from a value in a general purpose register as a "from" address, and another similarly constructed value as a "to" address. It moves an area of data from the "from" address in the virtual storage of the current address space to the "to" address in the virtual storage of the current address space. In AR mode, however, each general purpose register has an associated "access register". This can contain a "token" which uniquely describes a dataspace or address space, and if

5 of 7 11/2/2001 1:48 PM MVS Systems Programming: Chapter 3d - MVS Internals http://www.mvsbook.fsnet.co.uk/chap03d.htm

so, the corresponding address will be treated as being in the virtual storage of the dataspace or address space concerned. Thus, for example, a function can move data from the dataspace into its own address space by first switching into AR mode and then executing an MVC instruction with the token of a dataspace in the access register for the "from" address. By using two different tokens in the access registers for the "from" and "to" address spaces, it can move data between two data spaces.

These tokens provide the processor with a route to the segment tables of the address spaces or dataspaces concerned. As long as an address space knows the token values for the other address spaces it wishes to communicate with, AR mode provides a much simpler and more efficient mode for moving data between two address spaces than Cross Memory Services. In addition, the ability to have tokens for up to 15 different address spaces simultaneously available in different access registers means that communication involving more than two address spaces becomes feasible without painfully long path lengths. The "Extended Addressability" manual also covers programming with access registers and dataspaces.

A hiperspace is a special type of dataspace ("high performance dataspace"), which cannot exist in central storage. There are two types, "standard", which is created in expanded storage, and paged out to auxiliary storage as necessary, and "expanded storage only", which can only exist in expanded storage. The latter type is used by a number of MVS/ESA facilities to buffer data in expanded storage which users would otherwise need to perform real I/O to obtain - hence "high performance". In both cases, it is necessary to move the data required from the hiperspace to the user's address space (a page at a time) before it can be used, because of the restriction preventing storage belonging to a hiperspace from moving into central storage. A new set of Assembler macros has been provided with ESA to read pages from hiperspaces or write them out to them.

Hiperspaces seem to be intended more for system usage than application usage, and IBM rapidly introduced a series of new facilities which exploit hiperspaces. These include:

* Virtual Lookaside Facility and Library Lookaside - discussed in the Program Management section above;

* "Batch LSR" for VSAM buffering

* "HIPERSORT" - a hiperspace for sort work areas

* "Hiperbatch" - which keeps a single copy of heavily-used sequentially-read files in a hiperspace to speed up batch job execution

All of these are intended to improve system performance by eliminating I/O for frequently used data. In essence they use expanded storage as a clever caching device, and the use of expanded storage to cache large quantities of data seems certain to be a major feature of future MVS systems, since this eliminates the number one bottleneck on most commercial systems today - DASD I/O.

Home Contents Previous Section End of Page Top of Page Bibliography

MVS/XA Overview GC28-1348 - a very readable overview of some aspects of MVS internals

Storage Management

MVS/ESA Initialisation and Tuning Guide GC28-1634 - detailed discussions of MVS storage management and how SRM controls swapping (this is the Version 4 manual - earlier versions of MVS combined the "Init & Tuning Guide" and "Init & Tuning Reference" which covers SYS1.PARMLIB members in a single manual)

"The Age of a Page" Mark Friedman - Mainframe Journal, September 1989 - discusses virtual storage and the paging process

"MVS Expanded Storage - Big Bang or Bust?" Mark Friedman - Enterprise Systems Journal, May 1991 - discusses how expanded storage works and how to monitor usage of it

"Common Storage Advantages and Problems" Eric Jackson and Paul Klein - Candle Computer Report, October 1989

Task Management

"The Service Request Block" Brett Jason Sinclair - MVS Update, June 1987

I/O Management

370/XA Principles of Operation SA22-7085 - includes several chapters on fundamental I/O processing

6 of 7 11/2/2001 1:48 PM MVS Systems Programming: Chapter 3d - MVS Internals http://www.mvsbook.fsnet.co.uk/chap03d.htm

"MVS/XA I/O Subsystem and DASD Event Traces" William R Fairchild - Mainframe Journal, March 1990 - traces a DASD I/O through all the stages of MVS I/O processing

Job Management

"Understanding MVS Converter/Interpreter Processing" Bruce Bordonaro - Mainframe Journal, July 1990

Serialisation

MVS/ESA SPL: Application Development Guide GC28-1852 - detailed programming considerations for system software, including serialisation, program management, etc

System Macros and Facilities, Volume 1 GC28-1150 - the MVS/XA equivalent of the "ESA SPL: Application Development Guide"

MVS/ESA Diagnosis: System Reference LY28-1011 - includes a chapter on the lock hierarchy and ENQ names used by MVS components, plus coverage of storage subpools and storage protection

"Serialisation in MVS/XA and MVS/ESA" Alan Feinstein - Candle Computer Report, November 1989, December 1989, and January 1990 - an excellent explanation of ENQ's, locks, and intersects

Program Management

MVS/ESA Linkage Editor and Loader User's Guide SC26-4510 - documents program attributes and addressing modes and how to assign them

"MVS Program Management" Robert H Johnson - Mainframe Journal, December 1989

"Utilizing MVS/ESA's Library Lookaside" Timothy A Brunner - UKCMG 1990 Proceedings (also USCMG 1989 Proceedings)

"Getting the most out of Contents Supervision" Steve Goldin - Candle Computer Report, August 1989 - explains reusability and re-entrancy

Catalogs

MVS/ESA Catalog Administration Guide SC26-4502

"VSAM Catalogs Concepts" James W Clark - Mainframe Journal, July 1989 - a very useful discussion of the structure of ICF catalogs, VVDS's, BCS's, and the old VSAM catalogs

Inter Address Space Communication

MVS/ESA SPL: Application Development - Extended Addressability GC28-1854 - includes a chapter on cross-memory programming

System Macros and Facilities Volume 1 GC28-1150 - the XA manual to look at for cross-memory programming techniques

"Writing a Cross Memory Program" Scott Dimond - MVS Update, October 1987

"Inter-Address Space Communications using Cross Memory Services" Rickland D Hollar - Technical Support, March 1991

"Through the Data Window" Michael Haupt - Mainframe Journal, March 1989 - explains dataspaces and hiperspaces

"IBM Conquers Space" Michael Haupt - Mainframe Journal, June 1989 - discusses VLF and other ESA facilities

Home Contents Previous Section About the book Top of Page

This page last changed: 5 July 1998. All text on this site © David Elder-Vass. None of the statements or examples on this site are guaranteed to work on your Please see conditions of use. particular MVS system. It is your responsibility to verify any information found E-mail comments to: [email protected] here before using it on a live system. (Please check the FAQ's page first!)

7 of 7 11/2/2001 1:48 PM