entry is also required for MMP6H2 or MMP6H4, as appropriate.<br />The PCT entries are:<br />for Interlink: =<br />MGH1 MMP6H1<br />MGH2 MMP6H2<br />for OpenConnect:<br />MGH3 MMP6H3<br />MGHA thru MGHZ MMP6H3 (optional)<br />MGH4 MMP6H4<br />MGH5 MMP6H5<br />Multi tasking and multi-thread operation are supported in either implementation; however, they are handled differently. (cont.)<br />The Interlink version of MAGEC's TCP/IP includes built-in multi-thread capabilities. The OpenConnect solution is (cont.)<br />inherently multi-tasking, but accommodates multi-thread processing through a mechanism which allows you to control and (cont.)<br />monitor performance.<br />## <br />OpenConnect Multi-threading<br />The MGH4 transid is associated with the MMP6H4 program. It is the actual host processor for the mainframe. There may be (cont.)<br />one or more instances of MGH4 executing concurrently. The MGH3 transid is associated with the MMP6H3 program. It acts (cont.)<br />as a supervisor to manage traffic to the mainframe. There may be only one MGH3 executing at a time.<br />It is not necessary to have multiple MGH4's executing in order to support multiple clients; each will support an (cont.)<br />unlimited number of clients. The purpose for having multiple MGH4's executing is to share the workload and to permit (cont.)<br />several clients to be serviced at the same time. On a large network this can result in a significant increase in (cont.)<br />throughput. With only one MGH4 executing, client requests will be serviced serially. Because overhead is kept to a (cont.)<br />minimum, each request will be processed and completed very quickly, so several clients can easily be handled without (cont.)<br />any noticeable delay. This is called a single-thread operation since each request must wait for the preceding request (cont.)<br />to finish.<br />With several MGH4's executing concurrently, each can be processing a request for a different client at the same time. (cont.)<br />In order to have several MGH4's active, each must be "listening" on a different TCP/IP port.<br />On a TCP/IP network, messages are sent to a specific port# at a specific IP address. There will usually be only one IP (cont.)<br />address for a given computer (i.e. your mainframe), but different applications can distinguish which messages are for (cont.)<br />them by the port#. The port# might be imagined as analogous to an apartment number within an apartment building, the (cont.)<br />building address being the IP address.<br />The entry in Table #243 for TCPIP-PORT specifies the port# or range of port#'s to be used by MAGEC. Port#'s are 5-digit (cont.)<br />numbers not greater tha 65535. The specification in Table# 243 may be a single port# (i.e. 05998), or a range of (cont.)<br />port#'s (i.e. 05998-06008). The first (or only) port# specified is the primary port#, the remainder of numbers in the (cont.)<br />range (if given) are secondary port#'s.<br />If only one instance of MGH4 is desired, it can be started directly from a PLT entry, or by entering the transid MGH4 (cont.)<br />from any CICS terminal. In this case it will automatically listen on the primary port# from MAGEC Table #243's (cont.)<br />TCPIP-PORT specification.<br />If multiple instances are desired in order to support higher traffic levels, then you should not directly start MGH4 (cont.)<br />either from a PLT entry or from a terminal. Instead, you should start MMP6H3 (MGH3) (preferrably from a PLT entry). (cont.)<br />MMP6H3 is the MAGEC "Host Scheduler".<br />All client requests initially are addressed to the primary port#. If only one MGH4 is executing, it will receive and (cont.)<br />process those requests. If, instead, MGH3 is running, it will receive each client's initial request and will respond to (cont.)<br />the client with a message telling that client to use another port (a specific port# selected from the range of (cont.)<br />secondary port#'s) for all subsequent communications. If necessary, MGH3 will issue the start command to ensure that an (cont.)<br />MGH4 is actively listening on the assigned port#.<br />Through internal algorithms MGH3 balances the workload among all the active MGH4's and maintains statistics for each one. It dynamically re-tunes the network based upon current activity.<br />To control the maximum number of active MGH4's which MGH3 will initiate, simply increase or decrease the range of port#'s in Table #243's entry for TCPIP-PORT.<br />## <br />Dynamic Tuning<br />The third transid associated with MAGEC's OpenConnect solution is MGH5. It is a dynamic system monitor and tuner which (cont.)<br />executes periodically (perhaps every few minutes) to check on the several MGH4's which are executing and to gather (cont.)<br />statistics from each one. It compiles these statistics and reports them to the supervisor (MGH3). It also compares the (cont.)<br />recent workloads of all the MGH4's to determine whether some clients should be switched from a busy host processor to a (cont.)<br />less-busy one.<br />MGH5 occasionally issues commands to the busier MGH4's telling them to handoff clients to other MGH4's which have (cont.)<br />excess capacity. These handoffs occur without any interruption to the client's processing.<br />MGH5 is invoked by the supervisor, MGH3, periodically. If you are running a single-thread configuration, neither MGH3, (cont.)<br />nor MGH5 is needed, and only one port#(the primary port#) needs to be specified in Table #243's TCPIP-PORT entry. When (cont.)<br />MGH3 is used, there must be at least two ports, one primary and one secondary, provided in the Table #243 TCPIP-PORT (cont.)<br />entry.<br />## <br />Message Compression<br />In order to provide faster response and enable greater throughput over any network topology, MAGEC automatically (cont.)<br />compresses the TCP/IP messages it sends between the client and host. This compression is completely transparent to your (cont.)<br />applications as it is handled internally. The compression results in fewer bytes and fewer packets transmitted over the (cont.)<br />network; hence, lower overhead.<br />## <br />Read-Ahead Buffering<br />Typical application processing usually involves numerous browse operations. The MAGEC standard LOC..., SCN..., and (cont.)<br />FND... functions are examples of browse operations. A browse operation can also be called a pseudo-sequential read (cont.)<br />operation. That means that the program will be reading records in the sequence of a key, which may or may not be the (cont.)<br />physical sequence of records on the disk. These operations involve successive read-next accesses after having (cont.)<br />positioned to some point in the index using LOCKY, REDLE. Refer to the Database Administration* section of your (cont.)<br />Programmer's Reference for more about file accesses.<br />When an MMP is accessing a file which is remote, these read-next accesses would normally each involve a two-way (cont.)<br />communication between the client and the host. SInce the MMP can reasonably anticipate that it will do several (cont.)<br />succesive accesses, it would save much overhead if the MMP could signal the I/O module to try to read several records (cont.)<br />at a time, passing them back to the client in one larger message, into a buffer in anticipation of the MMP's future (cont.)<br />requests. The local I/O module would then hold the records in a buffer and return them to the MMP one at a time as they (cont.)<br />are requested.<br />That is exactly what MAGEC's read-ahead buffering capability does. The combination of the read-ahead buffering and (cont.)<br />message compression can make browses of remote files extremely fast and can reduce the number of bytes, number of (cont.)<br />packets, and number of messages sent across the network.<br />## <br />Synchronizing Data Definitions<br />In order for your network to support cross-system data access, it is necessary that the data definitions on the client (cont.)<br />systems and host systems be kept synchronized. That simply means that the DCL, KYF, ELT, and DIT definitions for any (cont.)<br />files you wish to access remotely should be the same on your system and on the gateway (host machine) on which those (cont.)<br />files reside.<br />The batch APUNLOAD / APLOAD processes could be used to copy the definitions from one system to another, or an online synchronize program called DCLSYNC can be used.<br />DCLSYNC is a program which can be executed from a Windows client machine. It can copy any Data Class' complete (cont.)<br />definition either to the host gateway you specify, of from the host to your local system.<br />You can execute DCLSYNC from an icon. It first asks you to specify the gateway you wish to copy from or to, and whether (cont.)<br />you wish to UPLOAD (copy to the fgateway), or DOWNLOAD (copy from the gateway to you local (cont.)<br />repository.<br />Next it dynamically builds a list box showing the DCL names defined on the source system and asks you to select the one you wish to copy.<br />If the Data Class you have selected is currently defined on the target system, you will be asked if you wish to overlay (cont.)<br />it or cancel the process. If you select OVERLAY, DCLSYNC will first copy all of the DCL, KYF, ELT, and DIT records from (cont.)<br />the target system to an UNDO file, then delete them all from the target system, then copy them from the source system (cont.)<br />and add them to the target system.<br />Also refer to the discussions about alias Data Class names (DC$, KY$, EL$, and DI$) in your MAGEC Installation Guide.<br />## <br />Alternate Ports<br />In some installations it may be desirable to have more than one MAGEC host listening for messages on different CICS (cont.)<br />systems running on the same mainframe. This might be done to enable accessing both a test and production CICS system (cont.)<br />concurrently, or perhaps an MVS and a VSE system.<br />If your installation includes multiple physical connections to the mainframe, then each connection will have a distinct (cont.)<br />IP address and there is no practical limit as to the number of connections you may have. If, however, you have only one (cont.)<br />physical connection to the mainframe, then there will be only one IP address and you must distinguish between multiple (cont.)<br />MAGEC hosts (at the same IP address) by using different Port numbers. Refer to the MAGEC Installation Guide discussion (cont.)<br />of TBL #243 parameters for TCPIP-PORT, etc.<br />MAGEC supports up to 27 MAGEC Host Schedulers (MMP6H3) listening on different ports on the same IP address. This means (cont.)<br />that at one mainframe, using one IP address (single connection), you could have 27 CICS regions (or partitions) (cont.)<br />concurrently being accessed through the network.<br />The basic TBL #243 parameter, TCPIP-PORT, defines a range of port numbers to be used by one instance of MMP6H3, the (cont.)<br />Host Scheduler. Additional ranges of port numbers can be specified using the TCPIP-PORTA thru TCPIP-PORTZ (cont.)<br />specifications in TBL #243. This gives you up to 26 ranges in addition to the basic range specified in (cont.)<br />TCPIP-PORT.<br />To tell each instance of MMP6H3 which range it should use, there are 26 CICS transid's defined which are synonyms for (cont.)<br />the basic MGH3 transid. The synonym transid's are MGHA thru MGHZ. MMP6H3 interrogates the transid used to invoke it and (cont.)<br />uses the corresponding range of port numbers--MGHA causes MMP6H3 to use the TCPIP-PORTA specification, etc. If you wish (cont.)<br />to manually initiate MMP6H3 from a CICS terminal, enter one of these transid's with no parameters following it and (cont.)<br />press ENTER. The program will sense that it has been invoked from a terminal and will automatically restart itself as (cont.)<br />an asynchronous task, freeing your terminal.<br />If you invoke MMP6H3 from the DFHPLT, you cannot associate any transid with it (a limitation of executing from the (cont.)<br />PLT); therefore, it is equivalent to executing using the transid MGH3. If the program is not initiated using ome of the (cont.)<br />MGHA thru MGHZ transid's it will serach for a PortID (A thru Z) to use by interrogating a special control record which (cont.)<br />is stored on the MAGEC MAL file. If the control record is not found, MMP6H3 will default to the setting given in the (cont.)<br />basic TCPIP-PORT (with no suffix) specification. If the control record is on the MAL file, MMP6H3 will use the PortID (cont.)<br />specified there (unless it is invalid, in which case it reverts to the basic PortID).<br />## <br />Gateways and PortID's<br />The range of actual port numbers associated with a PortID is defined on MAGEC Table #243 in the 27 TCPIP-PORT (thru (cont.)<br />TCPIP-PORTZ) settings. The assignment of a PortID to a Gateway name is made in MAGEC Table #248 (Gateway Name Table), (cont.)<br />which contains the IP address and PortID for each Gateway name.<br />Each machine which is to serve as a MAGEC Host should be associated with one Gateway name. From that it can determine (cont.)<br />the PortID, and range of actual port numbers, it is to listen on. The control record on the MAL file tells the Host its (cont.)<br />Gateway name. It uses the Gateway name to access Table #248 to obtain the Port ID setting, then uses the PortID setting (cont.)<br />to access Table #243 to get the actual numeric port numbers to use. If the control record is not on file it will use (cont.)<br />the default port numbers specified in TCPIP-PORT in Table #243.<br />To record the setting inthe MAL file control record you should use the GW#LOC function, which lists all the Gateway (cont.)<br />names defined in Table #248, then select the one which applies to this Host. To select one, point the cursor at it and (cont.)<br />press ENTER. A screen will be displayed showing you the result of having made this selection (the Gateway name, PortID, (cont.)<br />and acutal port numbers to be used)<br />Note that it is possible to have more than one Host on one physical machine (i.e.: a test and production region, (cont.)<br />etc.)with each of them known by a different Gateway name. Indeed, if they are to be running simultaneously, they must (cont.)<br />use different Gateway names so that they can be listening on different ports.<br />There should be no two Gateway names having the same IP address and the same PortID setting; but, there may well be several Gateway names having the same IP address with different PortID settings.<br />The MAL file (MAGEC Activity Logging file) must not be shared between two MAGEC systems. This is not only a requirement (cont.)<br />for the TCP/IP networking, it is a basic requirement of MAGEC. This means that the control record on the MAL file (cont.)<br />applies to only one MAGEC system, as it should.<br />MAGEC cannot determine if you have specified the same Gateway name for two Host systems. There may even be situations (cont.)<br />in which you intentionally do so; but those two systems' Host processors cannot be running at the same time. You should (cont.)<br />be careful to assign Gateway names to Host systems appropriately.<br />## <br />Synchronizing Definitions<br />The Gateway name is used by the Client processor to communicate with the Host, therefore the same definitions should be (cont.)<br />made on the Client systems and on the Host. Since thses definitions are made on the MAGEC Tables (TBL file), you may (cont.)<br />wish to use either the batch APUNLOAD/APLOAD jobs or the interactive Windows TBLSYNC program from a workstation to (cont.)<br />synchronize the definitions.<br />The TBLSYNC program can be executed from Windows and enables you to copy Tables from the local system to a remote Host (cont.)<br />system, or vice-versa. It also enables you to merge any missing entries from one ssytem to the other, leaving entries (cont.)<br />which are already present on the target system intact and undisturbed.<br />Any records whichare deleted or overlaid in any TBLSYNC process can be recovered from the archive where they were saved (cont.)<br />before being deleted/overlaid in the event of an error. To recover data from the archive you use the UNDOSYNC (cont.)<br />program.<br />## <br />Mainframe Sub-Tasks<br />Special considerations must be made when issuing a remote execution command from an application running on a network PC (cont.)<br />(using Windows) to invoke a program to be executed on the mainframe. You should first read the topic Remote Execution (cont.)<br />earlier in this chapter, then read this topic.<br />The 128-byte command within the REMOTE-XQT-REQUEST is redefined for mainframe executions as:<br />05 FILLER REDEFINES RXQT-COMMAND.<br />&nbsp;<br />07 RXQT-TRANSID.<br />&nbsp;<br />09 RXQT-MODE PIC X.<br />&nbsp;<br />09 FILLER PIC XX.<br />&nbsp;<br />09 RXQT-USER-VIEW PIC X.<br />&nbsp;<br />07 RXQT-SFUNCT PIC X(6).<br />&nbsp;<br />07 RXQT-SKEY PIC X(31).<br />&nbsp;<br />07 RXQT-AID PIC X.<br />&nbsp;<br />07 RXQT-DATE PIC X(8).<br />&nbsp;<br />07 RXQT-TIME PIC X(6).<br />&nbsp;<br />07 RXQT-INITIALS PIC X(2).<br />&nbsp;<br />07 RXQT-EMP-NO PIC 9(9).<br />&nbsp;<br />07 FILLER PIC X(67).<br />&nbsp;<br /><br />next: network04.md.txt