Browse Prior Art Database

Extension of the CMS IUCV Interface of VM/SP

IP.com Disclosure Number: IPCOM000039824D
Original Publication Date: 1987-Aug-01
Included in the Prior Art Database: 2005-Feb-01
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Hauser, RF: AUTHOR

Abstract

This article proposes an extension of the CMS IUCV interface available in VM/SP, for solving the following problem: The first eight bytes of the user data field in IUCV CONNECT are reserved for exclusive use by CMS IUCV; other applications which would also need this field cannot use it. When several independent programs need to use IUCV in a virtual machine VM1, a demultiplexing program is required to forward the IUCV interrupts to the appropriate program. CMS IUCV has been introduced in VM/SP for that purpose (cf. VM/SP System Programmer's Guide; IBM ordering No. SC19-6203). Each program in VM1 using IUCV can register to this demultiplexing program under a unique name. CMS IUCV monopolizes the first 8 bytes of the user-data field in IUCV CONNECT.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 58% of the total text.

Page 1 of 2

Extension of the CMS IUCV Interface of VM/SP

This article proposes an extension of the CMS IUCV interface available in VM/SP, for solving the following problem: The first eight bytes of the user data field in IUCV CONNECT are reserved for exclusive use by CMS IUCV; other applications which would also need this field cannot use it. When several independent programs need to use IUCV in a virtual machine VM1, a demultiplexing program is required to forward the IUCV interrupts to the appropriate program.

CMS IUCV has been introduced in VM/SP for that purpose (cf. VM/SP System Programmer's Guide; IBM ordering No. SC19-6203). Each program in VM1 using IUCV can register to this demultiplexing program under a unique name. CMS IUCV monopolizes the first 8 bytes of the user-data field in IUCV CONNECT. When a virtual machine VM2 issues IUCV CONNECT to request a connection with VM1 running CMS IUCV, it has to specify the correct name in the first 8 bytes of user-data. However, several IUCV applications make other and incompatible use of the user-data field. The "internal" use of the name in CMS IUCV is no problem, but the "external" use in IUCV connection requests is one.

This restrictive use of the first eight bytes of the user-data field, however, is not necessary. Incoming IUCV connection requests can be demultiplexed based on conditions about the vmid and the user-data field. This approach is described below in more detail. The HNDIUCV and the CMSIUCV macro as well as the DMSIUC and the DMSITE assembler programs have to be slightly modified. HNDIUCV SETX A new subfunction is added to the HNDIUCV macro under the name SETX. The parameter "NAME" does not only point to an 8-byte name but also to a control block: NAME DS CL8 ID OF THE PROGRAM

COUNT DS F NUMBER OF REF/MASK/PRIO TRIPLES

REFR1 DS CL24 REFERENCE 1

MASK1 DS CL24 MASK 1

PRIO1 DS F PRIORITY 1

REFR2 DS CL24 REFERENCE 2

MASK2 DS CL24 MASK 2

PRIO2 DS F PRIORITY 2 REFR3 DS CL24

REFERENCE 3

MASK3 DS CL24 MASK 3

PRIO3 DS F PRIORITY 3

REFR4 DS CL24 REFERENCE 4

MASK4 DS CL24 MASK 4

PRIO4 DS F PRIORITY 4 The "NAME" is the same as in HNDIUCV SET. The "COUNT" tells how many of the following Reference/Mask/Priority triples are actually used. Only up to four such triples are allowed in the above example and at least one has to be given. For "internal" use through HNDIUCV and CMSIUCV the "NAME" is used as usual. But for pending connection-type inter...