---<br />title: "network_main"<br />original_file: "network_main"<br />generated: "2026-06-12 10:24:24"<br />---<br /><br />**<br /># <br />Introduction### Network Administration<br />## <br />Who Should Read This Guide<br />This guide is written primarily for use by those persons who will be installing or configuring MAGEC in a networked (cont.)<br />environment. A networked environment means any configuration in which multiple application users will be sharing (cont.)<br />resoruces, especially files. This material is of particular interest to:<br />Technical Support personnel<br />Database Administrators<br />Networked environments can be based upon any of the popular Network Operating Systems (NOS's), such as Novell NetWare, (cont.)<br />Microsoft LanManager or NT, OS/2 LanServer, or others. A networked environment can also be created without a NOS using (cont.)<br />MAGEC's intrinsic networking and communication facilities. In fact, both can happily coexist on the same (cont.)<br />network.<br /># <br />Using a NOS<br />Configuring MAGEC to operate in an environment including a NOS is quite simple. The installation procedure uses two (cont.)<br />sets of installation diskettes, one for a "server" and one for a "workstation"; by following the on-screen instructions (cont.)<br />for each you will properly install MAGEC, ready to run.<br />These installations both presume that the MicroFocus Cobol compiler is installed before MAGEC is installed. The reason (cont.)<br />for this is because the MicroFocus installation generates certain settings into your AUTOEXEC.BAT and/or CONFIG.SYS (cont.)<br />file(s) and the MAGEC installation finds and modifies those settings. The *Installation Guide *booklet gives more (cont.)<br />information about those settings.<br />Essentially, those configurations of MAGEC on a NOS-based network consists of the MAGEC repository files being (cont.)<br />installed on a commonly accessed, shareable server drive (or drives), the MAGEC executable modules (EXE's and DLL's) (cont.)<br />being similarly installed on the same, or another shareable drive, and a "workspace" directory being installed on the (cont.)<br />local disk (if available) for each workstation. This last specification is optional, but for workstations which have (cont.)<br />disk drives can improve overall performance and reduce network traffic to the server.<br />The MAGEC installation automatically generates several environment settings needed by MAGEC on every workstation. They (cont.)<br />include: LANDRV, EXEDRV, and LCLDRV, which tell MAGEC where to look for certain files, directories, or work (cont.)<br />space.<br />## <br />Data Files<br />MAGEC's repository files are ordinary data files, just like your own applications' files. They may reside in one, or (cont.)<br />several, directories on one or several drives. You may wish to refer to the *Installation Guide* for a list of all the (cont.)<br />files and a brief description of each. Most of the files can be placed anywhere you may desire so long as they are (cont.)<br />accessible to all MAGEC users. A few of the files, however, must be located in the \MAGMF directory on the drive (cont.)<br />specified in the LANDRV environmental setting; this is because those files are needed by MAGEC as it is starting up. (cont.)<br />The \MAGMF directory on the drive specified in LANDRV is considered MAGEC's *default* directory in which it will look (cont.)<br />for any file(s) not specifically designated as being elsewhere. The files which must be in the default directory (cont.)<br />are:<br />DCL<br />KYF<br />ELT<br />DVC<br />All other files may be in any directory on any drive. If a file is not in the default directory, its definition must (cont.)<br />include the drive on which it is located, and, if the directory name is not \MAGMF, its path, and, if its name is not (cont.)<br />standard, its complete path and name. Files having standard names in the default directory need none of these (cont.)<br />specified. This is true for both MAGEC's repository files and for your own data files.<br />## <br />Executables<br />Executable files (EXE's and DLL's) must be in the \MAGMF directory on the drive specified in the EXEDRV setting of your (cont.)<br />environment. The installallation procedure will automatically install the MAGEC system programs there, and the MMPCREAT (cont.)<br />and MBPCREAT jobstreams will automatically catalog generated executables there.<br />## <br />Work Space<br />In order to reduce network traffic and achieve lower overhead, MAGEC will utilize the drive specified in the LCLDRV (cont.)<br />environment setting for temporary work space used when generating programs, compiling, sorting, et cetera. One of (cont.)<br />MAGEC's data files is actually a kind of work file as well. The TWA (Transaction Work Area) file can be specifield as (cont.)<br />residing on the local drives of each workstation to further reduce network overhead. To do this you would simply (cont.)<br />specify "C:" in the PC Drive/Path specification for TW3K1 on the KYF definition. In other words, use the online (cont.)<br />command:<br />KYFCHG TW3K1<br />&nbsp;<br />and type "C:" into the PC file/path specification on the screen.<br />Any of your own data files which will be used by only one user can also reside on that user's local disk, if desired.<br />MAGEC assumes that you will have a directory named \MAGMF on the drive specified in LCLDRV and places temporary work (cont.)<br />files there. If you do not have such a directory, you can expect fatal errros whcn you attempt to generate or compile (cont.)<br />programs, or when you execute other batch programs provided with MAGEC. If your workstation does not include a disk (cont.)<br />drive then you must set LCLDRV to a drive on a server. It is permissible for LCLDRV, LANDRV, and/or EXEDRV to all be (cont.)<br />the same drive, if desired.<br />## <br />Virtual Local Drives<br />Files located on a NOS server drive which is accessible using the ordinary mapping provided by the NOS are accessed as (cont.)<br />if they were local (on the local disk drive) and normal record-level locking prevents conflicting updates by multiple (cont.)<br />users. It is not necessary to install MAGEC's intrinsic networking facility, or TCP/IP, to access such (cont.)<br />files.<br /># <br />MAGEC's Intrinsic Facility<br />Whether or not you are using a NOS, you can create a networked environment with MAGEC using the intrinsic networking (cont.)<br />facility which is based upon peer-to-peer TCP/IP communication, assuming that each workstation includes certain (cont.)<br />necessary components. The necessary components are:<br />MAGEC's TCP/IP facility<br />a Network Interface board in each workstation (Token-Ring, Ethernet, etc.)<br />appropriate cabling between workstations<br />a suitable (WinSock compatible) TCP/IP "stack" on each workstation<br />There are many choices among most of these components and almost all of them should work well. If you need help in choosing, call MAGEC Technical Support for suggestions.<br />It is also possible to include your mainframe computer as a node of your network. This enables you to access mainframe (cont.)<br />files transparently from MAGEC applications running in a Windows, GUI (or Text, if preferred) environment. It also will (cont.)<br />enable you to access files on your PC's or PC servers from applications running on the mainframe--or to invoke programs (cont.)<br />or jobstreams on the mainframe from a PC, or vice-versa.<br />## <br />Clients and Hosts<br />The MAGEC intrinsic networking facility enables you to establish Client-Host relationships between any two computers on (cont.)<br />the network, whether they are similar or dissimilar kinds of computers, EBCDIC or ASCII, etc. A Client is a machine (cont.)<br />which is requesting some service of another computer, a Host is a machine which is providing a service. The most common (cont.)<br />type of service is file access, but other types are also possible.<br />## <br />Defining a Host<br />In order to serve as a Host, a computer must be defined properly to MAGEC. You should note that it is perfectly (cont.)<br />legitimate for any computer on the network to be either a Host or a Client, or both at the same time. No particular (cont.)<br />definition is necessary for a computer to be a Client, but MAGEC TCP/IP networking support must be installed--it will (cont.)<br />be invoked automatically, when requested by an application. For example, when an application tries to access a file (cont.)<br />which is specified as being located on another computer.<br />Each Host machine must be defined by an entry in MAGEC Lookup Table #248. This table is called the Gateway table (for (cont.)<br />this discussion, the term *Gateway* is usually interchangeable with *Host*). In this table you must specify a unique (cont.)<br />Gateway Name, up to sixteen characters long, plus the actual Internet Protocol (IP) Address of that machine. The name (cont.)<br />is merely for convenience and is used to identify that machine. Suitable names might be:<br />CONFROOMCOMPUTER<br />**<br />**<br />JOE'S-COMPUTER<br />**<br />and so forth. The names should help a human to know which machine is being described. The IP Address, however, is (cont.)<br />somewhat less meaningful to a human, but necessary for the TCP/IP message handler and router.<br />An IP Address is a code which must be unique among all the computers in your network. If you will be accessing the (cont.)<br />*Internet* using this same TCP/IP, the address may need to be unique among all the computers in the world, but that is (cont.)<br />a different subject. It is entered and stored as a series of four 3-digit numbers (each of which may be in the range 0 (cont.)<br />to 255), separated by dots. For example:<br />**<br />130.060.100.004 -or-<br />**<br />**<br />130.60.100.4<br />**<br />The two above representations are equivalent since leading zeros may be omitted. MAGEC automatically translates these into the form actually recognized by TCP/IP whenever a message is sent.<br />In addition to being defined on Table #248, each Host machine should also have a setting added to its environment. It is:<br />**<br />set MAGHOST=xxx<br />**<br />The MAGHOST setting should specify the Gateway Name (same as was specified in Table #248 for this machine) of this (cont.)<br />machine. This setting is needed only if this machine will be used as both a Client and as as a Host, either (cont.)<br />concurrently or at different times. Its purpose is to advise the MAGEC system (when it is being used as a Client) of (cont.)<br />the fact that this same machine is also used as a Host and is known by this Gateway name, when so used. This tells (cont.)<br />MAGEC not to attempt to issue a remote command or message to that Gateway name, since it is this same machine. Instead, (cont.)<br />MAGEC knows that it can service any such request locally. For example, if the Client application wishes to access a (cont.)<br />file which is specified as being at Gateway "JOE'S-COMPUTER" and the MAGHOST setting tells us that* this is* (cont.)<br />"JOE'S-COMPUTER", we can read the file locally without issuing a remote request to "JOE'S-COMPUTER".<br />## <br />Port #<br />The port number on which a Host will listen for messages is the first port number specified in MAGEC Table #243, the (cont.)<br />Global Parameters table, in the specification for TCPIP-PORT. Refer to the *Installation Guide* for more about the (cont.)<br />Table #243 specifications.<br />## <br />MGHOST<br />To initiate Host processing on any Host PC computer, start the MGHOST program. To start MGHOST from within Windows, (cont.)<br />simply double-click the icon for MGHOST. A small window will appear indicating that MGHOST is up and running and (cont.)<br />listening for messages, or "accepting traffic". MGHOST can be left running while other tasks are being done on that (cont.)<br />same computer, including standard MAGEC execution. MGHOST.EXE can also be started automatically from the Windows (cont.)<br />Startup group, if desired.<br />As MGHOST is initializing itself it will attempt to determine if the recommended environmental settings and stack are (cont.)<br />present. If not, it will issue an error or warning message. If the condition is non-fatal, MGHOST will initialize and (cont.)<br />run once you have responded to the message.<br />To terminate MGHOST, double-click the icon titled ShutHost (see the SHUTHOST topic later in this section). MGHOST can (cont.)<br />be executed without the small window being displayed by using the command "SHUTHOST.EXE Blind". This eliminates (cont.)<br />conflicts which might arise from MGHOST and other MAGEC sessions sharing the MAGEC graphical display (cont.)<br />engine.<br />## <br />MGCLIENT<br />MGCLIENT is a "subroutine" which is dynamically called when appropriate. In the case of an application accessing a (cont.)<br />"foreign" file (one located at a Gateway machine as opposed to one which is accessed locally), MAGEC's I/O module (cont.)<br />automatically calls MGCLIENT with a request to be sent to the specified Gateway machine (the Host) to accomplish the (cont.)<br />desired I/O command. There is no special programming in the application for such access.<br />It is possible, however, for an application program to call MGCLIENT directly to request various operations. One example would be to invoke a jobstream at the Host machine.<br />## <br />ASCII vs. EBCDIC<br />Since some of the computers in your network might be EBCDIC machines (i.e. an MVS mainframe) and others might be ASCII (cont.)<br />machines (i.e. a Windows PC), it may be necessary that data transferred from one machine to another be converted into (cont.)<br />the proper coding scheme. Such data transformations are relatively simple for alphanumeric character data, but become (cont.)<br />very complex for records which contain some alphanumeric fields, some packed decimal fields, some binary fields, and (cont.)<br />some zoned-decimal fields with signs. All of these require different treatment on a byte-by-byte basis in order for a (cont.)<br />program in one environment to properly use data from another. Unfortunately, this complex scenario applies to most of (cont.)<br />the application data files in most installations.<br />Since this has always presented a difficult problem to organizations attempting to distribute both processing and data, (cont.)<br />MAGEC includes an intelligent, automatic data transformation feature which properly converts data as it is transferred. (cont.)<br />The conversion is driven by the actual MAGEC repository data definitions and therefore is aware of the data type of (cont.)<br />every byte of every record. It applies the proper conversions accordingly. This means that your applications can be (cont.)<br />completely unaware of the actual location, or coding-scheme, of any files they access and the proper data will be (cont.)<br />presented in the expected format automatically.<br />It also means that if the data file is moved from one type machine to another, no reprogramming or recompile will be (cont.)<br />needed; and the need for redundant replication of data files in different environments is (cont.)<br />eliminated.<br />**<br />Note:<br />**<br />Since the proper conversion of fields of a record depends upon the data types of those fields, it is possible for you (cont.)<br />to create conflicting definitions through the use of the Cobol REDEFINES clause. For example, you could have a record (cont.)<br />in which bytes 100-104 are a binary field but are redefined as (part of) a zoned-decimal signed number as well. That (cont.)<br />means that in some records on the file these bytes should be treated one way, in other records they should be treated (cont.)<br />another way. MAGEC will have no way to guess which type of record it is handling and will therefore make an arbitrary (cont.)<br />decision that for every record of this file bytes 100-104 will be treated one way. The result is that for some records, (cont.)<br />the conversion of those bytes will be incorrect. *Best solution--<br />don't redefine numeric fields*<br />## <br /><br />next: network02.md.txt