UCF Programs

The distribution of applications is possible only for tasks that are associated with terminals. The task must be initiated from the front-end system that owns the terminal. During the execution of distributed applications, control of the terminal is transferred from one program to another. All involved programs can issue terminal I/O requests.
idms19
The distribution of applications is possible only for tasks that are associated with terminals. The task must be initiated from the front-end system that owns the terminal. During the execution of distributed applications, control of the terminal is transferred from one program to another. All involved programs can issue terminal I/O requests.
See the following topics for more information:
2
2
Terminating Task Data Transfer
Terminating task data transfer from program storage to a terminal or device uses UCF to pass data and control
serially
between a UCF front-end and back-end. The front-end initiates a task on the back end system and waits until the task is complete to return the requested information. The information usually includes a request to begin a new task on the front-end. This process can be repeated as many times as necessary to accomplish the needs of the application. Using industry-wide terminology, the UCF back-end is an example of a user-written connection-less server.
The following diagram shows a sample distributed application. In this example, Program A running on a UCF front-end (for example, CICS) passes a part number to program B and terminates. Program B retrieves the requested information and passes it back to a new task, Program C:
Terminating Task Data Transfer
The next sections explain:
  • How data and control transfer between programs on the front-end and programs on the back-end.
  • How the DC back-end transfers control and data to the front-end.
  • How the front-end system transfers control and data to the DC back-end. The following front-end systems are presented:
    • DC
    • CICS
    • BATCH
How UCF Transfers Control and Data
Applications distributed between UCF front- and back-ends use UCF facilities to pass data and control. General information on transferring data and control is presented below.
For
details
about passing data and control in a distributed application, see the information presented later in DC Back-end and in the specific description of your back-end system.
Passing data
When you pass data between systems in a UCF distributed application, the data must be passed as a single contiguous piece of data.
Front-end to back-end transfers
When a program transfers control from the front-end to the back-end, the following occurs:
  1. The transferring program specifies the next task or transaction to be executed on the front-end. This task or transaction must be defined to invoke the appropriate UCF front-end program.
  2. The UCF front-end program does the following:
    • Establishes the UCF connection to the back-end.
    • Passes data to the back-end if any was prepared by the transferring program.
    • Initiates on the back-end system a task that has the same name as the related front-end task or transaction. The back-end task must be defined to invoke the program to which control is being transferred.
The following diagram shows what happens when control transfers from the front-end to the back-end of a distributed application. In this example, front-end program A transfers data and control to back-end program B. To do this, program A executes TSKB, which in turn invokes the UCF front-end program. The UCF front-end program passes data and transfers control to the back-end.
┌─────────────────────────────────────────────────────────┐ │                    ┌──────────┐                         │ │    Operating       │ Data and │  ┌────┐                 │ │      System        │ Control  ├──► SVC├─────┐           │ │    Supervisor      └───▲──────┘  └────┘     │           │ ├────────────────────────┼───────┬────────────┼───────────┤ │   ┌──────────┐         │       │       ┌────▼─────┐     │ │   │ Program A│         │       │       │  TSKB    │     │ │   └────┬─────┘         │       │       │          │     │ │        │               │       │       └────┬─────┘     │ │        │               │       │            │           │ │        │               │       │            │           │ │        │               │       │            │           │ │   ┌────▼─────┐    ┌────┴────┐  │       ┌────▼─────┐     │ │   │  TSKB    ├────►   UCF   │  │       │Program B │     │ │   │          │    │Front-End│  │       │          │     │ │   └──────────┘    │ Program │  │       └──────────┘     │ │                   └─────────┘  │                        │ └────────────────────────────────┴────────────────────────┘  UCF Front-End System              DC Back-End System
Back-end to front-end transfers
When a program transfers control from the back-end to the front end, the followiing occurs:
  1. The transferring program specifies the next task or transaction to be executed on the back-end. This task or transaction must be defined to invoke program RHDCUXFT.
  2. Program RHDCUXFT, the UCF program that handles transfers to the front-end, does the following:
    • Initiates on the front-end system a task or transaction that has the same name as was specified by the back-end program. The front-end task or transaction must be defined to invoke the program to which control is being transferred.
    • Passes data to the front-end, as necessary.
    • Terminates the UCF connection.
    Program RHDCUXFT must be defined at system generation time with the following attributes:
    LANGUAGE ASSEMBLER REENTRANT NOPROTECT
The following diagram shows what happens when control transfers from the back-end to the front-end of a distributed application. In this diagram, back-end program B transfers data and control to front-end program C. To do this, program B executes task TSKC, which in turn invokes program RHDCUXFT. Program RHDCUXFT passes data and transfers control to the front-end.
┌──────────────────────────────────────────────────────────────────────┐ │                                   ┌─────┐      ┌─────────┐           │ │   Operating    ┌──────────────────┤ SVC ◄──────┤ Data and◄───┐       │ │     System     │                  └─────┘      │ Control │   │       │ │   Supervisor   │                               └─────────┘   │       │ ├────────────────┼──────────────┬──────────────────────────────┼───────┤ │                │              │                              │       │ │                │              │                              │       │ │         ┌──────▼─────┐        │                         ┌────┴─────┐ │ │         │  Task C    │        │                         │ Program  │ │ │         └──────┬─────┘        │                         │ RHDCUXFT │ │ │                │              │                         └────▲─────┘ │ │                │              │                              │       │ │         ┌──────▼─────┐        │    ┌───────────┐        ┌────┴─────┐ │ │         │  Program C │        │    │ Program B ├────────►  TSKC    │ │ │         └────────────┘        │    └───────────┘        └──────────┘ │ │                               │                                      │ └───────────────────────────────┴──────────────────────────────────────┘   UCF Front-End System             DC Back-End System
DC Back-end
The following information is presented below for the DC back-end:
  • How back-end DC programs transfer control and data
  • How to define tasks and programs for use on the back-end
For information on front-end programs, see the discussion later in this section about the front-end system in use at your site.
Back-end DC programs
The following considerations apply to programs executing on the DC back end:
  • A DC program transferring control to a program on the front-end system does the following:
    • Passes data in storage that is USER KEEP LONG with a STGID of PDAT. The data being passed must begin with a record descriptor word (RDW). The RDW is the standard four─byte prefix for variable─length records. The first two bytes contain the binary length of the data plus 4; the second two bytes contain binary zeros.
      The following example illustrates the storage used to pass the character string ABCDE:
      DC    H'9',H'0'       RDW DC    C'ABCDE'        DATA
    • Transfers control to the program on the front-end system by returning to DC and specifying the next task to be executed for the terminal. The specified task, which must be defined as NOINPUT, indirectly causes the next program to execute.
      In the following example, the DC program specifies that task TSKC is the next task to be executed:
      #RETURN NXTTASK='TSKC'
  • A DC program receiving control from a program on the front-end system retrieves passed data by obtaining USER KEEP LONG storage with a STGID of PDAT. The first four bytes of the passed data comprise the RDW.
Defining tasks and programs
When defining tasks and programs on the back-end DC system, keep in mind that to transfer control from the back-end to the front-end, the transferring program specifies the next task to be executed. The specified back-end task must be defined to invoke program RHDCUXFT with the NOINPUT option (see the example below).
Before terminating the UCF connection, program RHDCUXFT moves the passed data to the front-end and initiates on the front-end system a task or transaction that has the same name as the specified back-end task. The front-end task or transaction must be defined to invoke the program to which control is being transferred.
For example, if program B executes on a DC back-end system and program C executes on a front-end system, the following back-end definitions are required:
  • DC task definition:
    TASK TSKC INVOKES RHDCUXFT NOINPUT.
  • DC program definition:
    PROGRAM RHDCUXFT LANGUAGE ASSEMBLER REENTRANT NOPROTECT.
Example of a back-end program
The following example of distributed applications shows the relevant sections of the DC back-end program (B). Program B performs the following operations:
  1. Obtains the PDAT storage containing the passed data from Program A on the front-end:
    #GETSTG TYPE=(USER,LONG,KEEP),LEN=14,STGID='PDAT',       ADDR=(R2)
  2. Extracts the part number from the passed data:
    MVC   PARTNUM(10),4(R2)
  3. Frees the 'PDAT' storage:
    #FREESTG ADDR=(R2)
  4. Issues database calls to obtain the part record with the passed part number
  5. Obtains new PDAT storage to pass the part information to program C on the front-end:
    #GETSTG TYPE=(USER,LONG,KEEP),LEN=20,STGID='PDAT',       ADDR=(R2),INIT='00'
  6. Copies the part information into the new PDAT storage:
    MVC   4(8,R2),PARTPRIC    PRICE MVC   12(8,R2),PARTQTY    QUANTITY ON HAND MVC   0(2,R2),=H'20'      SET LENGTH IN RDW
  7. Transfers control to program C on the front-end and returns to DC:
    #RETURN NXTTASK='TSKC'
DC Front-end
In an environment that consists of two DC systems, the communication between those systems is achieved by the SVC (if both systems are on the same CPU) or by DDS (using the CCI, TCP/IP, or VTAM access method). Both systems own terminals, and each system can have both a UCF DC front-end program and the appropriated line for the communication. In this case, each system can be thought of as a front-end or a back-end, depending on the terminal to which the user is assigned.
Distributed applications that are executed in such an environment should always transfer control by means of the UCF DC front-end program. The UCF DC front-end program determines whether the associated terminal is already a UCF or a DDS terminal. If it is, the program branches to RHDCUXFT, and the transfer is handled as a back-end to front-end transfer.
The methods for transferring control and data used by programs on the DC front-end are the same as those used by back-end programs. These methods are discussed in DC Back-end.
CICS Front-end
This section contains the following information for applications distributed between a DC back-end and a CICS front-end:
  • How front-end CICS programs transfer control and data
  • How to define transactions and programs for use on the CICS front end
  • Example of an application distributed between CICS and DC
For information on the DC back-end system, see DC Back-end.
CICS programs
Programs that execute on the CICS front-end system transfer control and data as described below:
  • A CICS command-level program transferring control to a program on the DC/UCF system queues the next transaction to be executed for the terminal and specifies the location and length of the data to be passed. The specified transaction indirectly causes the next program to execute.
    In the following example, the next transaction to be executed is TSKB, and the data to be passed is located at PARTNUM:
    EXEC CICS START TRANSID('TSKB') TERMID(EIBTRMID)       FROM(PARTNUM) LENGTH(10)
    When transferring control to a program on the DC/UCF system, a CICS command-level program returns to CICS:
    EXEC CICS RETURN
  • A CICS command-level program receiving control from a program on the DC/UCF system retrieves passed data:
    EXEC CICS RETRIEVE INTO(
    data-area
    )       LENGTH(
    data-length-area
    )
Defining transactions and programs
When defining transactions and programs for the CICS front-end system, keep in mind that to transfer control from the front-end to the back-end, the transferring program specifies the next task or transaction to be executed. The specified task or transaction must be defined to invoke the UCF front-end program.
When the UCF connection is established, the UCF front-end program moves the passed data to the back-end and initiates on the back-end system a task that has the same name as the specified front-end task or transaction. The back-end task must be defined to invoke the program to which control is being transferred.
For example, if program A executes on a CICS front-end system and program B executes on a DC back-end system, the following front-end definitions are required:
CICS program and transaction definitions:
DEFINE   TRANSACTION(TSKA) PROGRAM(A) ... DEFINE   TRANSACTION(TSKB) PROGRAM(UCFCICS) ... DEFINE   PROGRAM(A) ... DEFINE   PROGRAM(UCFCICS) LANGUAGE ASSEMBLER CEDF(NO)          EXECKEY(CICS)RESIDENT
For information on defining DC back-end tasks and programs, see DC Back-end.
Example of a distributed application
The following example of distributed applications shows the relevant section of programs A and C on a CICS front-end system. The programs pass to and receive data from Program B on the DC back-end system. An example of Program B appears in DC Back-end.
Program A (CICS) performs the following operations:
  • Passes data and transfers control:
    EXEC CICS START TRANSID('TSKB') TERMID(EIBTRMID)       FROM(PARTNUM) LENGTH(10)
  • Returns to CICS:
    EXEC CICS RETURN  
    Program B on the DC back-end passes the part information and control to program C.
Program C (CICS) performs the following operations:
  • Sets the length of the input area for the passed data:
    MVC   DATALEN,=H'16'      SET LENGTH OF INPUT AREA
  • Retrieves the passed price and quantity information:
    EXEC CICS RETRIEVE INTO(PARTPRIC) LENGTH(DATALEN)
Non-terminating Task Data Transfer
Non-terminating task data transfer allows a front-end program in one region to exchange multiple packets of information with a back-end program running in a DC/UCF region. Each packet can contain up to 32000 bytes of data. This provides a very efficient method for an application running in one region (such as a WEB access program running in a batch or CICS region) to access and/or update information in a CA IDMS database.
For example, in the following diagram, control returns to the front-end task (program A) after the back-end passes the requested information:
Non-terminating Task Data Transfer
Using industry-wide terminology, the UCF back-end is an example of a user-written connection-oriented server. This is accomplished as follows:
  1. The front-end application links to the UCF distributed application support (UDAS) synchronous front-end program passing parameters that contain a buffer address and a buffer size. The UDAS front-end program emulates a UCF terminal to exchange buffers with the back-end.
  2. The back-end UCF system "thinks" it is communicating with a terminal with an unusually large screen size (up to 31K). The back-end IDMS application is coded as if it were a conversational task communicating with a terminal.
Front-ends supported
UDAS synchronous supports CICS and BATCH front-ends.
Flow of Control
The "conversation" between the back-end and front-end applications always originates on the front-end application by passing the following parameter list to the UDAS front-end program on all requests:
USERPARM DSECT USERBUF  DS   A          ADDRESS OF SEND/RECEIVE BUFFER USERBUFL DS   F          LENGTH OF SEND/RECEIVE BUFFER USERSES  DS   F          SESSION ID USERETCD DS   F          RETURN CODE
Establishing a session with the back-end system
  1. The front-end application links to the UDAS front-end program, specifying USERSES=0 (all other parameters are ignored)
  2. After the UDAS front-end program establishes a session with the back-end system, it returns control to the front-end application passing a session ID in USERSES and a return code in USERETCD
The session ID must be passed to the UDAS front-end program on all subsequent requests. You should check the return code after all requests. A list of valid Return codes appears later in this section.
Allocating a SEND buffer
Next the front-end application links to the UDAS front-end program with the address and length of a SEND buffer. The first SEND buffer must contain the task code that is to be invoked on the back-end. Optionally, the buffer may also contain data to satisfy the first read done by the back-end application.
The back-end task whose name is specified in the first SEND buffer should be defined as an INPUT task in the back-end CA IDMS system.
Passing information back and forth
After a session is established and a back-end application has been invoked, the front-end and back-end application programs are in a SEND/RECEIVE "conversation". The back-end application has control of the conversation. The front-end application always links to the UDAS front-end program with a buffer address.
If the back-end application does a write (#TREQ PUT), then the UDAS front-end program will move the data that the back-end application has written into the front-end application's buffer. The USERBUFL parameter indicates the maximum buffer length that the front-end application can receive. After the UDAS front-end program has moved data into the buffer, USERBUFL will contain the actual length of the data received.
If the back-end application does a read (#TREQ GET), then the UDAS front-end program will get data from the front-end application's buffer and send it to the back-end.
Ending a conversation
To terminate the conversation, the back-end program must link to the program RHDCBYE. RHDCBYE terminates the session and frees resources so that the session can be used by other front-end programs.
.block start
UDAS SEND/RECEIVE flow diagram
Front-End            UDAS Front-End         Back-End          Back-End
Application          Program                UCF               Application
USERSES=0 ─────────► New session
 (signon)            initialization
                     BIND 59 ─────────────► Establish session
                             <-------------
                     SEND ready ──────────►
                              <------------ Read for task code
                                            and input
Signon complete <--- Return with USERSES
Return code 4
USERBUF=taskcode+input
 (SEND) ───────────► Send data to back end  Start task ─────► #TREQ GET
                                            First <---------- (READ)
                                            input already
                                            received ───────► Read complete
                                                              *************
                                                              Process
                                                              *************
Send complete <----- Return <-------------------------------  #TREQ PUT
Return code 8                                                 (WRITE)
USERBUF=buffer
USERBUFL=max ──────► Move data to buffer
                     Put length in USERBUFL
                     Write complete ───────────────────────►  Write complete
                                                              Repeat write,
                                                              if needed.
                                                              Read for next
                                                              request.
Receive com- <-----  Return <-------------------------------- #TREQ GET
plete.
Return code 4.
No more requests.
Send 'All Done' ──►  Send data to back end ─────────────────► Read complete.
                     Finish session  <---   RHDCBYE  <------- Link to BYE
Send complete.  <--  Return ────────────────────────────────► #RETURN
Return code 0.
End
 
Return codes
When the front-end application gets control back from UDAS, the USERETCD field will be filled in with an appropriate return code as follows:
Return code
Meaning
0
The SEND/RECEIVE communication between the front-end and the back-end is closed and finished normally.
4
A "READ" is expected (SEND). The next call to UDAS will send data in USERBUF to the back-end application.
8
A "WRITE" is expected (RECEIVE). The next call to UDAS will receive data from the back-end and put data in USERBUF.
Greater than 8
Any other value in USERETCD is abnormal and is typically an abend condition. In most cases, any other code will be a 4-character alphabetic abend code, such as A101.
Note:
For more information on these codes, see the
Messages section
.
Return codes are useful in keeping the front-end and back-end applications in sync with each other regarding reads (SENDS) and writes (RECEIVES). For example, if the front-end application gets control back from UDAS with a return code of 8, but the application was expecting to do a read, then the two applications are out of sync and should be debugged. As another example, if the back-end application abends, a "FINISH" request is sent to the front-end (RC = 0) when the application was probably expecting a read or write request.
Considerations for the back-end program
  • If data is sent with the task code on the first SEND from the front end to the back-end, the back-end application will receive blanks the length of the task code before it's data.
  • The back-end application must always link to RHDCBYE to terminate a conversation and clean up the session. The following are some recommendations to guarantee that RHDCBYE is invoked:
    1. Code all read and write macros (#TREQ) with COND=ALL, so that the back-end application will get control if there is an I/O error and then can link to RHDCBYE.
    2. Resource time out should be generated to invoke RHDCBYE. This is the default.
    3. The back-end application should establish a STAE exit that will get control and link to RHDCBYE in case it terminates abnormally.
Examples of a UDAS DC back-end application
Up-to-date sample Assembler and COBOL programs can be found in members UDASCVSA and UDASCVSC in sample JCL. For your convenience, a version of each of the sample programs follows.
Sample UDAS DC back-end Assembler program
UCFTEST1 TITLE 'UDAS TEST SEND RECEIVE' * SAMPLE UDAS IDMS/DC BACK-END APPLICATION * UCFTEST1 EP=UCFEP1          #MOPT CSECT=UCFTEST1,ENV=USER UCFTEST1 CSECT         ENTRY UCFEP1 UCFEP1   DS    0H          LR    R12,R15         USING UCFEP1,R12          SPACE          #GETSTG LEN=WORKLEN,PLIST=*,ADDR=(R4),TYPE=(USER,SHORT),     X                INIT=X'00'          USING WORKD,R4 *  Set up STAE exit          #STAE PGM='RHDCBYE' * GET REQUEST GETREQ   DS    0H          #TREQ GET,INAREA=INAREA,MAXIN=INLEN,COND=ALL,OPTNS=(UPLOW)          LR    R3,R15            SAVE RETURN CODE FROM READ.          #SNAP TITLE='UCFTEST1, INAREA/PARTIAL OUTAREA',              X                AREA=(INAREA,INLEN,OUTAREA,100)          LTR   R3,R3             ANY ERRORS ON READ?          BNZ   ERROR             YES, HANDLE ERROR. * CHECK FOR LAST INDICATION FROM FRONT-END          CLC   INAREA(8),=C'ALL DONE'  FRONT-END FINISHED?          BE    DISCON            YES, DISCONNECT.          CLC   INAREA(8),=C'SUSPEND '  FRONT-END FINISHED FOR NOW?          BE    RETURN            YES, SUSPEND.          SPACE ****************************************** ** TALK TO DATA BASE TO CREATE RESPONDE ** ******************************************          SPACE * SEND RESPONSE IN TWO BUFFERS          #TREQ PUT,OUTLEN=OUTLEN,OUTAREA=OUTAREA,COND=ALL          LTR   R15,R15           ANY ERRORS?          BNZ   DISCON            YES, DISCONNECT          #TREQ PUT,OUTLEN=OUTLE2,OUTAREA=OUTARE2,COND=ALL          LTR   R15,R15           ANY ERRORS?          BNZ   DISCON            YES, DISCONNECT          B     GETREQ            GO GET NEXT REQUEST          SPACE DISCON   DS    0H          #LINK PGM='RHDCBYE'          SPACE RETURN   DS    0H *  WE ARE INVOKED AS AN INTERMITTENT TASK, SO THIS TERMINAL *  WILL BE SUSPENDED IF WE HAVEN'T GONE THROUGH BYE *  PROCESSING.          #RETURN ERROR    DC    H'0'              USER FRIENDLY ERROR HANDLING?          LTORG OUTAREA  DC    C'FIRST WRITE *********##END DATA' OUTLEN   EQU   *-OUTAREA          SPACE OUTARE2  DC    C'2ND WRITE - REPEAT ##########'          DC    30000X'C2'          DC    C'##END HERE' OUTLE2   EQU   *-OUTARE2          #BALI WORKD    DSECT SYSPLIST DS    10A INAREA   DC    80X'00' INLEN    EQU   *-INAREA WORKLEN  EQU   *-WORKD          END   UCFEP1
Sample UDAS DC back-end COBOL program
*RETRIEVAL  ID DIVISION.  PROGRAM-ID.  UCFTESTC. *  THIS SAMPLE COBOL PROGRAM HAS SAME FUNCTIONALITY *  AS ASSEMBLER PROGRAM UCFTEST1.  IT IS AN EXAMPLE OF *  A BACK-END UDAS COBOL APPLICATION PROGRAM.  ENVIRONMENT DIVISION.  IDMS-CONTROL SECTION.  PROTOCOL   MODE IS IDMS-DC.  DATA DIVISION.  WORKING-STORAGE SECTION.  01  WS-START             PIC X(50) VALUE       '*****  UCFTESTC WORKING STORAGE STARTS HERE *****'.  01  OUTAREA PIC X(31) VALUE 'FIRST WRITE *********##END DATA'.  01  OUTAREA2.      05  FILLER PIC X(29) VALUE '2ND WRITE - REPEAT ##########'.      05  OUTAREA2-2 PIC X VALUE 'B' OCCURS 30000.      05  FILLER PIC X(10) VALUE '##END HERE'.      05  OUTAREA2-END PIC X.  01  INAREA.      05  INAREA1 PIC X(8) VALUE SPACES.          88  ALL-DONE VALUE 'ALL DONE'.          88  SUSPEND  VALUE 'SUSPEND '.      05  INAREA2 PIC X(72) VALUE SPACES.  01  INLEN    PIC S9(8) USAGE COMP.  01  PROCESSING-INDICATOR PIC X VALUE 'C'.      88  CONTINUE-REQUESTED  VALUE 'C'.      88  SUSPEND-REQUESTED   VALUE 'S'.      88  BYE-REQUESTED       VALUE 'B'.  01  SNAP-TITLE PIC X(134)          VALUE 'UCFTESTC, INAREA/PARTIAL OUTAREA'.      EJECT  01  COPY IDMS SUBSCHEMA-CTRL.      EJECT  PROCEDURE DIVISION.  100-MAIN-ROUTINE SECTION.   *    SET UP ABEND EXIT.  IF PROGRAM TERMINATES ABNORMALLY, *    RHDCBYE WILL BE CALLED.  THIS WILL NOTIFY FRONT-END *    THAT BACK-END HAS TERMINATED (RETURN CODE OF 0 WILL *    BE RETURNED TO FRONT-END UDAS APPLICATION PROGRAM). *    FRONT-END PROGRAM SHOULD TAKE APPROPRIATE ACTION. *      SET ABEND EXIT ON PROGRAM 'RHDCBYE'.        PERFORM 200-SEND-RECEIVE UNTIL NOT CONTINUE-REQUESTED.        IF BYE-REQUESTED      THEN TRANSFER CONTROL TO 'RHDCBYE' RETURN.        GOBACK.    200-SEND-RECEIVE SECTION.   *    RECEIVE REQUEST FROM FRONT-END.  PROCESS REQUEST. *    IF FRONT-END SENDS AN INDICATOR TO TERMINATE, SET *    APPROPRIATE FLAG. * *    TEST PROGRAM PROCESSING JUST CONSISTS OF SNAPPING *    A PORTION OF THE INPUT/OUTPUT BUFFERS AND SENDING *    TWO FIXED BUFFERS TO FRONT-END FOR EACH FRONT-END *    REQUEST.        READ TERMINAL INTO INAREA MAX LENGTH 80          RETURN LENGTH INTO INLEN.        PERFORM IDMS-STATUS.        SNAP TITLE SNAP-TITLE FROM INAREA LENGTH INLEN                            FROM OUTAREA LENGTH 100.        PERFORM IDMS-STATUS.        IF ALL-DONE      THEN MOVE 'B' TO PROCESSING-INDICATOR           GO TO SEND-RECEIVE-EXIT.        IF SUSPEND      THEN MOVE 'S' TO PROCESSING-INDICATOR           GO TO SEND-RECEIVE-EXIT.   *    AT THIS POINT, A REAL APPLICATION WOULD MAKE *    DATABASE CALLS AND/OR PERFORM OTHER PROCESSING *    BASED ON THE MESSAGE FROM THE FRONT-END. *    FOR TEST PURPOSES, JUST SEND TWO BUFFERS, *    THEN ISSUE READ TO GET NEXT MESSAGE FROM FRONT-END.        WRITE TERMINAL FROM OUTAREA LENGTH 31.      PERFORM IDMS-STATUS.        WRITE TERMINAL FROM OUTAREA2 TO OUTAREA2-END.      PERFORM IDMS-STATUS.    SEND-RECEIVE-EXIT.      EXIT.        COPY IDMS IDMS-STATUS.  IDMS-ABORT SECTION.  IDMS-ABORT-EXIT.      EXIT.
CICS Front-end
You create the CICS UDAS front-end using the same assembly and link procedures as a normal UCF CICS front-end except that you use macro #UDASCIC instead of #UCFCICS and you use different parameters on the #UCFUTD macro as shown below in the Sample UDAS CICS Front End Assembly. You do not need the UCFCICZ module for #UDASCIC.
UDAS CICS front-end programs contain an options table and a small stub module that calls the main processing routines that reside in separate modules. To create a UDAS CICS front-end program, assemble the #UDASCIC macro and link the resulting object as shown in the following section.
UDASCIC Syntax
►►─ label #UDASCIC ───────────────────────────────────────────────────────────►  ►─┬───────────────────┬──────────────────────────────────────────────────────►    └─ OS = ─┬─ OS ◄──┬─┘             └─ DOS ──┘  ►─┬───────────────────────┬──────────────────────────────────────────────────►    └─ ,FREESTG= ─┬─ YES ─┬─┘                  └─ NO ──┘  ►─┬───────────────────────────────┬──────────────────────────────────────────►◄    └─ ,PRINT = ─┬─ print-option ─┬─┘                 └─ OFF ◄─────────┘
UDASCIC Parameters
 
  • FREESTG=YES|NO
    Specifies whether CICS GETMAIN storage should be freed at the end of a conversation. If FREESTG=YES is coded, then all the storage allocated by UDASCIC via CICS GETMAINs will be freed when a conversation terminates (that is, at the time USERSESS is set to zero). If FREESTG=NO is coded, then the allocated storage will be held until task termination. If multiple conversations are started and ended in the same CICS task, then a storage build-up may result.
  • OS=OS|DOS
    Specifies the operating system under which the CICS front-end system executes. OS applies to all supported z/OS versions of CICS. DOS applies to all supported z/VSE versions of CICS. The default is OS.
  • PRINT=print-option
    Specifies what print option the Assembler is to use while processing the COPY commands which copy in the DSECTs used in the UCF front-end module. Valid options are ON/GEN/NOGEN. See the documentation for your Assembler product for details. The default is OFF.
For more information on the #UCFCICS macro, see UCF Operations. For more information on IDMSINTC, IDMSCINT, and IDMSTRUE, see CICS Considerations.
The following are the limitations under CICS:
  • No terminal-less tasks are allowed. However, a UDASCIC program can be invoked from a Bridge Facility.
  • SEND/RECEIVE conversations cannot extend over a pseudo-converse.
  • Only CICS command level programming is allowed for the front-end application.
  • A CICS UDAS application program can be coded in Assembler or COBOL. The UDASCIC program should be called using an EXEC CICS LINK with a COMMAREA as shown in the sample programs later in this section.
  • The field UDAS-BUFFER-ADDRESS must be set to ADDRESS OF UDAS-USER-BUFFER before the first call to UDASCIC as shown in the sample COBOL program later in this section.
Creating a UDAS CICS front-end program
Create a sample z/OS or z/VSE UDAS front-end program by following the example in member UDASCICI in sample JCL.
The front-end assembly specifies the largest possible buffer size in the front-end table. It also specifies only one #UCFUTD macro.These are the recommended values.
Sample assembly JCL can be found in member UDASCICI in sample JCL.
Each UDAS CICS front-end program must be defined in the CICS CSD. If you need a template, see the definition of PROGRAM(UDASCIC) in member CICSCSD of the CAGJSRC library. The program must be defined as RESIDENT.
Creating a UDAS CICS front-end application program
Up-to-date sample Assembler and COBOL programs can be found in members UDASCICA and UDASCICC in sample JCL. For your convenience, a version of each of the sample programs follows.
Sample CICS front-end COBOL application:
          TITLE 'TESTCICS -- UDAS TEST PROGRAM'  DFHEISTG DSECT  EYECATCH DS    CL8           DS    0F  COMREG   DS    0XL14            PARAMETERS TO PASS  USERBUF  DS    A                ADDRESS OF READ/WRITE BUFFER  USERBUFL DS    F                LENGTH OF BUFFER/DATA  USERSES  DS    F                SESSION ID  USERETCD DS    F                RETURN CODE  COMLEN   EQU   *-COMREG         LENGTH OF LINK AREA           SPACE 2  SNAPLEN  DS    H'00'  BUFFER   DS    XL31000'00'      31K BUFFER  BUFLEN   EQU   *-BUFFER  ENDDATA  EQU   *-COMREG  TESTCICS CSECT           LA    R12,4095(R3)           LA    R12,1(R12)           USING TESTCICS,R3,R12        2ND BASE REG           MVC   EYECATCH(8),=CL8'PARMPARM'           LA    R1,COMLEN           STH   R1,SNAPLEN          LENGTH TO SNAP OUR STORAGE           SPACE  * SIGNON TO UDAS (#UDASCIC)           SPACE           XC    USERSES,USERSES     NO SESSION ID = SIGNON           SPACE          EXEC CICS LINK PROGRAM ('UDASCIC')                           X                COMMAREA(COMREG) LENGTH(COMLEN)           SPACE  * SESSION ID SHOULD HAVE BEEN RETURNED TO US.  LETS SNAP IT TO SEE.  *        LA    R1,COMLEN  *        STH   R1,SNAPLEN          LENGTH TO SNAP OUR STORAGE  *        EXEC CICS DUMP FROM(COMREG) LENGTH(SNAPLEN) DUMPCODE(DMP1)           SPACE  * TEST RETURN CODE FROM SIGNON. WE EXPECT SEND FIRST.           CLC   USERETCD,=F'4'      RC=4 (SEND)?           BNE   ERROR               NO, WE HAVE AN ERROR.           SPACE 2  * OUR FIRST SEND WILL CONTAIN DC TASK CODE AND DATA.           MVC   BUFFER(8),=CL8'UCFTEST1'  TASK CODE           MVC   BUFFER+8(20),=CL20'SAMPLE DATA 12345678'           SPACE           LA    R1,BUFFER           ST    R1,USERBUF          GIVE ADDRESS OF BUFFER TO UDAS           LA    R1,28               LENGTH OF TASK CODE + DATA           ST    R1,USERBUFL         GIVE TO UDAS           SPACE          EXEC CICS LINK PROGRAM ('UDASCIC')                           X                COMMAREA(COMREG) LENGTH(COMLEN)          SPACE  *       EXEC CICS DUMP FROM(COMREG) LENGTH(SNAPLEN) DUMPCODE(DMP2)  * TEST RETURN CODE -- WE EXPECT A RECEIVE NEXT .           CLC   USERETCD,=F'8'      RC=8 ? (RECEIVE)           BNE   ERROR               NO, WE HAVE AN ERROR.           SPACE 2  * NOW WE WILL RECEIVE TO GET OUR RESPONSE. FOR THIS EXAMPLE  * WE"LL JUST KEEP READING UNTIL WE GET A RETURN CODE NOT EQUAL TO 8.  *        LH    R1,=AL2(ENDDATA)    WE'LL SNAP ALL OF OUR STORAGE  *        STH   R1,SNAPLEN          LENGTH TO SNAP  T100     LH    R1,=AL2(BUFLEN)           ST    R1,USERBUFL         TELL UDAS MAXIMUM LENGTH TO RECV           SPACE           XC    BUFFER(200),BUFFER           SPACE  * LINK TO UDAS TO RECEIVE          EXEC CICS LINK PROGRAM ('UDASCIC')                           X                COMMAREA(COMREG) LENGTH(COMLEN)           SPACE  * SNAP STORAGE TO SEE WHAT WE RECEIVED, ACTUAL LENGTH IN USERBUFL.  *        EXEC CICS DUMP FROM(COMREG) LENGTH(SNAPLEN) DUMPCODE(DMP3)  * TEST RETURN CODE           CLC   USERETCD,=F'8'      RC=8 ? (RECEIVE)           BE    T100                YES, KEEP RECEIVING.           CLC   USERETCD,=F'4'      RC=4 ? (SEND)           BNE   ERROR               NO, SOMETHING WENT WRONG>           SPACE 2  * WE COULD SEND ANOTHER DATA REQUEST AT THIS POINT, BUT THIS IS  * ENOUGH FOR THIS TEST.  * WE MUST SEND BACKEND DC TASK AN INDICATION THAT WE HAVE NO  * MORE REQUESTS SO IT CAN SIGNOFF OUR SESSION.           SPACE           MVC   BUFFER(8),=CL8'ALL DONE'  TELL BACKEND TASK           LA    R1,8                LENGTH OF MESSAGE           ST    R1,USERBUFL         GIVE TO UDAS  *        LA    R1,BUFFER  *        ST    R1,USERBUF          GIVE ADDRESS OF BUFFER TO UDAS           SPACE  * LINK TO UDAS TO SEND          EXEC CICS LINK PROGRAM ('UDASCIC')                           X                 COMMAREA(COMREG) LENGTH(COMLEN)           SPACE           EXEC CICS DUMP FROM(COMREG) LENGTH(SNAPLEN) DUMPCODE(DMP2)  * TEST RETURN CODE           OC    USERETCD,USERETCD   RC=0? -- WE EXPECT FINISH.           BNZ   ERROR               NO, WE HAVE AN ERROR.           SPACE 2  * WE'RE ALL DONE  ERROR    DS    0H  FINISH   DS    0H           B     RETURN           SPACE 3  DMP0    DC    C'IMUP'  DMP1    DC    C'SIGN'  DMP2    DC    C'SEND'  DMP3    DC    C'RECV'  DMPY    DC    C'YESS'  DMPN    DC    C'NONO'          SPACE  R0       EQU   0  R1       EQU   1  RETURN   DS    0H           EXEC CICS DUMP FROM(COMREG) LENGTH(SNAPLEN) DUMPCODE(DMP0)           EXEC CICS RETURN           END
Sample CICS front-end COBOL application
IDENTIFICATION DIVISION.        PROGRAM-ID.  UDASCOBC.        ENVIRONMENT DIVISION.        DATA DIVISION.        WORKING-STORAGE SECTION.        01   WS-TEXT PIC X(30) VALUE 'WORKING STORAGE STARTS HERE'.        01   ABEND-FIELDS.             05  FORCE-ABEND PIC S9(8) USAGE COMP VALUE +1.             05  FULL-ZERO   PIC S9(8) USAGE COMP VALUE +0.        01  UDAS-PARAMETERS.             05   UDAS-BUFFER-ADDRESS USAGE POINTER.             05   UDAS-BUFFER-LENGTH PIC S9(8) COMP.             05   UDAS-SESSION-CODE  PIC S9(8) COMP.             05   UDAS-RETURN-CODE   PIC S9(8) COMP.             05   UDAS-RETURN1 REDEFINES UDAS-RETURN-CODE.                  10  UDAS-RETURN-ALPHA PIC X(4) .             05   UDAS-RETURN2 REDEFINES UDAS-RETURN-CODE.                  10  UDAS-RETURN-FIRST PIC X(1) .                  10  FILLER PIC X(3).        01  UDAS-USER-BUFFER.             05  BUFFER-1 PIC X(40).             05  BUFFER-2 PIC X(10000).             05  BUFFER-3 PIC X(10000).             05  BUFFER-3 PIC X(10000).             05  BUFFER-4 PIC X(1960).        01  FIRST-BUFFER.             05  TASK-CODE PIC X(9) VALUE 'UCFTEST1 '.             05  SAMPLE-DATA PIC X(20) VALUE 'SAMPLE DATA 12345678'.             05  FILLER PIC X(11) VALUE SPACES.        01  ALL-DONE.             05  FILLER PIC X(8) VALUE 'ALL DONE'.             05  FILLER PIC X(32) VALUE SPACES.        01   COUNTERS .       *       *     LOOP-COUNTER CAN BE ADJUSTED TO SEQUENTIALLY       *     START AND END MULTIPLE BACK-END TASKS.       *             05  LOOP-MAX  PIC 9(4) VALUE 2.             05  LOOP-COUNTER PIC 9(4) VALUE 0.             EJECT        01   MESSAGES .       *       *     LOOP-COUNTER CAN BE ADJUSTED TO SEQUENTIALLY       *     START AND END MULTIPLE BACK-END TASKS.       *             05  OUTPUT-MESSAGE PIC X(70) VALUE SPACES.             05  MSGLEN PIC S9(4) USAGE COMP VALUE +70.             05  SUCCESS-MESSAGE.                 10 LOOP-COUNTER-SUCC PIC 9(4) VALUE 0 .                 10 FILLER PIC X(66) VALUE                    ' SUCCESSFUL UDASCOBC CONVERSATIONS COMPLETED'.             05  BEGIN-MESSAGE.                 10 FILLER PIC X(26) VALUE                    ' BEGINNING CONVERSATION #'.                 10 LOOP-COUNTER-BEGIN PIC 9(4) VALUE 0 .             05  BAD-SIGNON-MESSAGE.                 10 FILLER PIC X(50) VALUE                    ' BAD RETURN CODE FROM SIGNON'.             05  BAD-SEND-MESSAGE.                 10 FILLER PIC X(50) VALUE                    ' BAD RETURN CODE FROM SEND'.             05  BAD-RECEIVE-MESSAGE.                 10 FILLER PIC X(50) VALUE                    ' BAD RETURN CODE FROM RECEIVE'.             05  BAD-SIGNOFF-MESSAGE.                 10 FILLER PIC X(50) VALUE                    ' BAD RETURN CODE FROM SIGNOFF REQUEST'.             05  BUFFER-LENGTH-MESSAGE.                 10  FILLER PIC X(14) VALUE 'BUFFER LENGTH '.                 10  BEFORE-AFTER PIC X(6).                 10  FILLER PIC X(7) VALUE ' CALL: '.                 10  UDAS-BUFFER-LENGTH-DISPLAY PIC 9(4).                 10  FILLER PIC X(39) VALUE SPACES.             05  BUFFER-CONTENTS-MESSAGE.                 10 FILLER PIC X(26) VALUE 'PARTIAL BUFFER CONTENTS : '.                 10 BUFFER-1-DISPLAY PIC X(40).                 10 FILLER PIC X(4) VALUE SPACES.             05  UDAS-RETURN-MESSAGE.                 10 FILLER PIC X(23) VALUE 'RETURN CODE FROM UDAS: '.                 10 UDAS-DISPLAY-NUMERIC PIC 9(8).                 10 UDAS-DISP-COMPOSITE REDEFINES UDAS-DISPLAY-NUMERIC.                    15 UDAS-DISPLAY-ALPHA PIC X(4).                    15 FILLER PIC X(4).                 10 FILLER PIC X(31) VALUE SPACES.             EJECT        PROCEDURE DIVISION.        MAIN SECTION.       *  In this sample program, UDAS-PARAMETERS and       *  UDAS-USER-BUFFER are coded in the WORKING STORAGE       *  SECTION.  Alternatively, either or both O1 level       *  fields could be in the LINKAGE SECTION if       *  a) The storage is allocated and passed to       *     UDASCOBC from a higher level program or       *  b) The storage is allocated via an EXEC CICS       *     GETMAIN with the SET(ADDRESS OF ...) parameter.       *       *  Note that some compilers do not allow the ADDRESS OF       *  special register for WORKING STORAGE fields.       *  One of the techniques above is necessary if your compiler       *  does not allow the following statement:             SET UDAS-BUFFER-ADDRESS TO ADDRESS OF UDAS-USER-BUFFER.             PERFORM DO-CONVERSATIONS UNTIL               LOOP-COUNTER = LOOP-MAX.             MOVE LOOP-COUNTER TO LOOP-COUNTER-SUCC             MOVE SUCCESS-MESSAGE TO OUTPUT-MESSAGE             PERFORM DISPLAY-MESSAGE.             PERFORM SEND-MESSAGE.             GOBACK.        DO-CONVERSATIONS SECTION.             ADD 1 TO LOOP-COUNTER.             MOVE LOOP-COUNTER TO LOOP-COUNTER-BEGIN             MOVE BEGIN-MESSAGE TO OUTPUT-MESSAGE             PERFORM DISPLAY-MESSAGE.       *     ESTABLISH COMMUNICATION WITH UDAS.             MOVE 0 TO UDAS-SESSION-CODE.             PERFORM CALL-UDAS.             IF UDAS-RETURN-CODE NOT = 4               MOVE BAD-SIGNON-MESSAGE TO OUTPUT-MESSAGE               PERFORM DISPLAY-MESSAGE               PERFORM ABORT.       *     SEND FIRST BUFFER WITH TASK CODE AND SOME SAMPLE DATA.             MOVE FIRST-BUFFER TO BUFFER-1.             MOVE 29 TO UDAS-BUFFER-LENGTH.             PERFORM CALL-UDAS.       *     WE EXPECT THE BACK-END TO RETURN DATA SO WE SHOULD HAVE       *     A "RECEIVE" REQUEST FROM UDAS.KEEP RECEIVING DATA       *     AS LONG AS BACK-END SENDS IT.             IF UDAS-RETURN-CODE NOT = 8               MOVE BAD-SEND-MESSAGE TO OUTPUT-MESSAGE               PERFORM DISPLAY-MESSAGE               PERFORM ABORT.             PERFORM RECEIVE-DATA UNTIL UDAS-RETURN-CODE NOT = 8.       *     IF WE DON'T GET A RECEIVE REQUEST, WE SHOULD GET A       *     SEND REQUEST, I.E., THE BACK-END IS TRYING TO "READ"       *     DATA.             IF UDAS-RETURN-CODE NOT = 4               MOVE BAD-RECEIVE-MESSAGE TO OUTPUT-MESSAGE               PERFORM DISPLAY-MESSAGE               PERFORM ABORT.       *     WE COULD SEND MORE DATA AT THIS POINT, BUT THIS IS       *     ENOUGH FOR TEST PURPOSES.  JUST SEND AN INDICATOR       *     TO THE BACK-END THAT IS TIME TO CLEAN UP.             MOVE ALL-DONE TO BUFFER-1.             MOVE 8 TO UDAS-BUFFER-LENGTH.             PERFORM CALL-UDAS.             IF UDAS-RETURN-CODE NOT = 0               MOVE BAD-SIGNOFF-MESSAGE TO OUTPUT-MESSAGE               PERFORM DISPLAY-MESSAGE               PERFORM ABORT.        ABORT SECTION.       *     APPROPRIATE ERROR HANDLING CAN BE PERFORMED HERE.       *     FOR TEST PURPOSES WE WILL ABEND THE TASK WITH       *     A CODE OF 'UDAS'.             EXEC CICS ABEND ABCODE('UDAS') CANCEL END-EXEC .        RECEIVE-DATA SECTION.       *     RECEIVE A BUFFER SENT FROM THE BACK-END.             MOVE SPACES TO BUFFER-1.             MOVE 32000 TO UDAS-BUFFER-LENGTH.             PERFORM CALL-UDAS.        CALL-UDAS SECTION.       *     CALL UDASCIC AFTER PUTTING ADDRESS OF BUFFER IN       *     UDAS PARAMETER BLOCK.             MOVE UDAS-BUFFER-LENGTH TO UDAS-BUFFER-LENGTH-DISPLAY.             MOVE 'BEFORE' TO BEFORE-AFTER.             MOVE BUFFER-LENGTH-MESSAGE TO OUTPUT-MESSAGE.             PERFORM DISPLAY-MESSAGE.             MOVE BUFFER-1 TO BUFFER-1-DISPLAY             MOVE BUFFER-CONTENTS-MESSAGE TO OUTPUT-MESSAGE.             PERFORM DISPLAY-MESSAGE.             EXEC CICS LINK PROGRAM ('UDASCIC')             COMMAREA (UDAS-PARAMETERS)             LENGTH (LENGTH OF UDAS-PARAMETERS) END-EXEC .             MOVE SPACES TO UDAS-DISP-COMPOSITE.             IF UDAS-RETURN-FIRST = LOW-VALUES               MOVE UDAS-RETURN-CODE TO UDAS-DISPLAY-NUMERIC               MOVE UDAS-RETURN-MESSAGE TO OUTPUT-MESSAGE               PERFORM DISPLAY-MESSAGE             ELSE               MOVE UDAS-RETURN-ALPHA TO UDAS-DISPLAY-ALPHA               MOVE UDAS-RETURN-MESSAGE TO OUTPUT-MESSAGE               PERFORM DISPLAY-MESSAGE.             MOVE UDAS-BUFFER-LENGTH TO UDAS-BUFFER-LENGTH-DISPLAY.             MOVE 'AFTER ' TO BEFORE-AFTER.             MOVE BUFFER-LENGTH-MESSAGE TO OUTPUT-MESSAGE.             PERFORM DISPLAY-MESSAGE.             MOVE BUFFER-1 TO BUFFER-1-DISPLAY             MOVE BUFFER-CONTENTS-MESSAGE TO OUTPUT-MESSAGE.             PERFORM DISPLAY-MESSAGE.        DISPLAY-MESSAGE SECTION.       *     FOLLOWING COMMAND WILL DISPLAY INFO TO THE       *     CSMT (MSGUSR) FILE.             EXEC CICS WRITEQ TD QUEUE('CSMT')               FROM(OUTPUT-MESSAGE) LENGTH(MSGLEN) END-EXEC .        SEND-MESSAGE SECTION.       *     FOLLOWING COMMAND WILL DISPLAY INFO TO THE       *     TERMINAL.  IT CAN BE COMMENTED OUT FOR       *     STRESS TESTING PURPOSES.             EXEC CICS SEND FROM(OUTPUT-MESSAGE) LENGTH(MSGLEN)               ERASE WAIT END-EXEC .
Batch Front-ends
The interfaces for BATCH front-end UDAS applications uses the #UDASBCH macro to create UDAS front-end programs.
Calling conventions to UDAS
The following calling conventions are used to link to UDAS from the front-end application program:
R1
User parameter block
R13
18-word save area
R14
Return address
R15
V(UDAS front-end entry point)
Calling the UDAS front-end from an Assembly language program
To call the UDAS front-end for a request, use the Assembly language instructions below:
LA    R1,USERPARM L     R15,=V(
udasb
) BALR  R14,R15
where
udasb
is the entry point created when assembling #UDASBCH.
R1 points directly to USERPARM when calling the standard #UDASBCH entry point. If calling the special entry point UDASBCHY, R1 points to a fullword that contains the address of USERPARM.
For sample JCL and a complete sample program, see member UDASBCHA in sample JCL.
Calling the UDAS front-end from a COBOL program
To call the UDAS front-end for a request, use the COBOL instructions below:
CALL 'UDASBCHY' USING 
udas-parameters
where
udas-parameters
is the 01 level structure that matches the USERPARM DSECT which is shown in Flow of Control.
For sample JCL and a complete sample program, see member UDASBCHC in sample JCL.
How to create a front-end module
To create the UDAS BATCH front-end module, assemble a #UDASBCH macro and link the resulting object as described in the following sections.
UDASBCH Syntax
To create the UDAS BATCH front-end module, assemble a #UDASBCH macro and link the resulting object as described.
►►─ label #UDASBCH ───────────────────────────────────────────────────────────►  ►─┬─────────────────────────────────────────────┬────────────────────────────►    └─── SYSTEM ──── = ─┬─ BATCH ◄──────────────┬─┘                        └─ front-end-system-id ─┘  ►─┬──────────────────┬─┬─────────────────────────────┬───────────────────────►◄    └─ OS= ─┬─ OS ◄──┬─┘ └─ BUFSIZ= ─┬─ 8000 ◄───────┬─┘            └─ DOS ──┘               └─ buffer-size ─┘
UDASBCH Parameters
 
  • label
    The macro label provides the entry point name for the assembled module. The default is UDASBCH
  • SYSTEM
    The rules for the front-end system name are the same as those described in UCF Operations for macro #UCFUFT.
  • OS=OS|DOS
    Defines the operating system environment. Use OS for z/OS operating systems and DOS for z/VSE operating systems.
  • BUFSIZ=buffer-size
    Specifies the size of the buffer that will be allocated to pass data between the front-end and the back-end. Buffer-size must be at least as big as the largest output buffer length specified by either the front-end or back-end programs. The default is 8000.
Creating a UDAS Batch front-end interface program
Use the sample JCL in member UDASBCHI in sample JCL.