Chapter 5: MVS Emulation

This chapter describes how Mainframe Express emulates various facilities provided by MVS on the mainframe.

5.1 Introduction

Mainframe Express emulates the following MVS facilities:

MVS control blocks
MVS external writer

Mainframe Express emulates those MVS control blocks that are accessible to applications running in problem program state. The information stored in these control blocks is limited to that which has value and meaning to applications running in problem program state.

Control blocks are accessed in Mainframe Express in the same way as they are on a mainframe, by referencing the appropriate field in the Communication Vector Table (CVT). The address of the CVT is stored at absolute address 16 in memory, as it is on the mainframe.

MVS control blocks in Mainframe Express have the same structure as the mainframe versions, but only those fields most likely to be accessed by Assembler application programs are supported.

5.2.1 Low-memory Address Emulation in Assembler and COBOL

Many absolute memory addresses are used by the MVS operating system and the mainframe hardware itself. The Assembler and COBOL run-time systems under Mainframe Express intercept all accesses to memory locations 0 through 2047 and redirects them to a block of memory that is allocated from the PC operating system and initialized to emulate the bottom 2,048 bytes of memory on the mainframe. Therefore, no matter where in PC memory an Assembler or COBOL program is loaded, absolute addresses 0 through 2047 are guaranteed to exist and can be accessed and modified as on the mainframe.

This area of memory is known as the prefixed save area. You can map it using the control block IHAPSA.

5.2.2 Sample Project

The following sample project is supplied with Mainframe Express to illustrate how to access the MVS control blocks. A readme.txt file is supplied which describes how to create the project and run it.

Project

Summary

CTLBLKC

The CTLBLKC project contains a COBOL program which calls an Assembler routine to extract information from the MVS control blocks.

The readme file is in folder \mfuser\projects\demo\ctlblkc.

The source files are in folder \mfuser\projects\demo\ctlblkc\source.

5.2.3 Control Blocks Supported

The following table lists the MVS control blocks that are emulated by Mainframe Express and specifies any differences between the PC versions and the mainframe versions.

Mainframe Express supplies macros for Assembler to define the MVS control blocks. They are located in the folder mfe\source. The macros have the same name as the control blocks and have the .mac file extension. They describe the key problem program state fields. Only fields that are supported are named in the macros; the others are defined as "fillers".

Name	Description	Differences from mainframe
IHAACEE	Accessor Control Element	ACEEVRSN is set to 2
IHAASCB	Address Space Control Block
IHAASVT	Address Space Vector Table
IHAASXB	Address Space Extension Block
CVT	Communication Vector Table	CVTTOD is set to X'20', indicating that the Time Of Day clock is operational. CVTMVSE - the X'80' bit in CVTDCB is always on, indicating that you are running under MVS/XA or later. CVT4MPS - the X'04' bit in CVTDCB is on (indicating that you are running on System/360 Model 65 MP) only if the MVS control blocks are above the 16MB line (that is, all three-byte addresses are stored as four-byte addresses in the same location). CVTDATE is set with the century number (that is, it uses "0cyyddds" format, where "c" is century number - 0 for 20th, 1 for 21st, etc.)
CVT	CVT Prefix	The CVT prefix is set to all binary zeros.
IHACDE	Contents Directory Entry	One "null" CDE is allocated. So it appears to be using a program for which the load module has not been loaded.
IDADDSA	Dynamic Storage Area (FSA - First Save Area)	This is an 88-byte save area pointed to by TCBFSA. It is used as the TCB First Save Area.
IEFJFCBN	Job File Control Block
IEZJSCB	Job Step Control Block
IHAPSA	Prefixed Save Area	The X'01' bit in byte 7 (the first byte being byte 0) is on only if the MVS control blocks are above the 16MB line (that is, all three-byte addresses are stored as four-byte addresses in the same location).
IEESMCA	SMF Control Area	SMCASID is set to 'MSTR'.
IDADTCA	Task Communication Area	The PRV address is always zero. The storage overflow routine does not provide overflow segments; it merely abends with the abend code S80A. You must ensure that the ISA setting is adequate for your application.
IDADTCA	TCA Prefix
IKJTCB	Task Control Block	The TCB protect key is set to key 8.
IEFTIOT1	Task I/O Table

5.3 Accessing MVS Control Blocks from COBOL Programs

Mainframe Express enables you to access MVS control blocks from a COBOL program. The following sample program shows how you can access the job, step, and program names for the currently running program.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. JOBINFO.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 JOB-NAME             PIC X(8).
       01 PROGRAM-NAME         PIC X(8).
       01 STEP-NAME            PIC X(8).

       LINKAGE SECTION.
       01 PSA.
          05 FILLER     PIC X(540).
          05 PSATOLD    POINTER.

       01 TCB.
          05 FILLER     PIC X(12).
          05 TCBTIO     POINTER.
          05 FILLER     PIC X(164).
          05 TCBJSCBB   POINTER.

       01 TIOT.
          05 TIOCNJOB   PIC X(8).
          05 TIOCSTPN   PIC X(8).

       01 JSCB.
          05 FILLER     PIC X(360).
          05 JSCBPGMN   PIC X(8).

       PROCEDURE DIVISION.
      *    Address PSA
           SET ADDRESS OF PSA TO NULL

      *    Address TCB
           SET ADDRESS OF TCB TO PSATOLD

      *    Address TIOT
           SET ADDRESS OF TIOT TO TCBTIO

           MOVE TIOCNJOB TO JOB-NAME
           MOVE TIOCSTPN TO STEP-NAME

      *    Address JSCB
           SET ADDRESS OF JSCB TO TCBJSCBB

           MOVE JSCBPGMN TO PROGRAM-NAME

           DISPLAY 'JOB NAME     = ' JOB-NAME
           DISPLAY 'STEP NAME    = ' STEP-NAME
           DISPLAY 'PROGRAM NAME = ' PROGRAM-NAME
           GOBACK
           .

5.4 MVS External Writer

Under MVS you can run a program that dynamically outputs a JCL job stream in the form of a SYSOUT data set, and you can specify that an external writer is to process the job stream. You can use the IBM-supplied external writer, INTRDR, or you can supply your own.

You can request an external writer in any of three ways:

In your JCL for the main program. The name of the external writer is a parameter in the DD statement for the SYSOUT data set
In a TSO ALLOCATE command
By issuing the DYNALLOC (SVC 99) service

Mainframe Express emulates the IBM-supplied external writer, INTRDR. It does not support user-supplied external writers.

The Mainframe Express emulation of INTRDR difers in the following ways from IBM's INTRDR:

IBM's INTRDR allows a progam to submit a job without closing the data set, by writing records that contain control statements such as /*EOF, /*DEL, /*PURGE, and /*SCAN. Each of these statements effectively indicates that all data up to the statement is one or more complete jobs and that the action indicated by the statement should be carried out, for example, /*EOF causes the job to be submitted and is therefore equivalent to closing the data set. However, with the Mainframe Express emulation of INTRDR, the program must write an entire jobstream to the SYSOUT data set and then close the data set; the job is then submitted for execution. The program may then reopen the SYSOUT data set, write another complete jobstream and then close the data set for job submission.
IBM's INTRDR supports multiple jobs in one jobstream, regardless of whether the submission is triggered by a control statement or by the closing of the data set. The Mainframe Express emulation of INTRDR does not support multiple jobs in one submission, since Mainframe Express itself cannot handle such jobs. Each submission must contain only one job.
With IBM's INTRDR, the class of the submitted job defaults to the class of the SYSOUT data set. With the Mainframe Express emulation of INTRDR, the class of the submitted job is the same as it would be if the job were submitted from the IDE without a class being specified.