Misplaced Pages

#878121

22-416: TCAM provides similar functionality to QTAM , which it replaced. It was the access method for the initial version of Time Sharing Option ( TSO ). With the advent of IBM's SNA , TCAM was eventually superseded by VTAM . TCAM was said to have the following enhancements over QTAM: TCAM consists of a Message Control Program (MCP) and zero or more application programs . The MCP handles communications with

44-402: A batch processing environment. TCAM initially supported Support for 3270 terminals was soon added. This computer networking article is a stub . You can help Misplaced Pages by expanding it . This mainframe computer -related article is a stub . You can help Misplaced Pages by expanding it . Queued teleprocessing access method Queued Telecommunications Access Method (QTAM)

66-481: A System/360 multiplexor channel through an IBM 2701 Data Adapter or IBM 2702 Transmission Control . By 1968 support for the IBM 2703 Transmission Control Unit had been added. QTAM was succeeded by TCAM which provided roughly similar facilities, but was not supported under DOS. QTAM consists of a Message Control Program (MCP) and zero or more Message Processing Programs (MPP) . The MCP handles communications with

88-539: Is a stub . You can help Misplaced Pages by expanding it . Inetd inetd ( i nter net service d aemon) is a super-server daemon on many Unix systems that provides Internet services. For each configured service, it listens for requests from connecting clients. Requests are served by spawning a process which runs the appropriate executable, but simple services such as echo are served by inetd itself. External executables, which are run on request, can be single- or multi-threaded . First appearing in 4.3BSD , it

110-421: Is a simple inetd service, written in C . It expects a command line argument containing a filename for a log file, and then it logs all strings sent through the socket to the log file. Note that this is a very insecure example program. The example uses stdio functions and it responds to network traffic coming in on stdin. In this case, we want all messages logged to a single file, so we only want one instance of

132-441: Is an IBM System/360 communications access method incorporating built-in queuing . QTAM was an alternative to the lower level Basic Telecommunications Access Method (BTAM). QTAM was announced by IBM in 1965 as part of OS/360 and DOS/360 aimed at inquiry and data collection . As announced it also supported remote job entry (RJE) applications, called job processing , which was dropped by 1968. Originally QTAM supported

154-496: Is generally located at /usr/sbin/inetd . inetd is based on the (service) activator pattern Often called a super-server , inetd listens on designated ports used by Internet services such as FTP , POP3 , and telnet . When a TCP packet or UDP packet arrives with a particular destination port number, inetd launches the appropriate server program to handle the connection. For services that are not expected to run with high loads, this method uses memory more efficiently, since

176-444: Is the official name of the service. It is resolved using the system database to map port numbers and protocols to service names. In this case, /etc/services should contain: The second and third words describe the type of socket and underlying protocol respectively. The /etc/protocols database is consulted. The fourth word is the wait/nowait switch. A single-threaded server expects inetd to wait until it finishes reading all

198-449: The IBM 1030 Data Collection System, IBM 1050 Data Communications System, the IBM 1060 Data Communications System, the IBM 2671 Paper Tape Reader, AT&T 83B2 Selective Calling Stations, Western Union Plan 115A Outstations, and AT&T Teletype Model 33 or 35 Teletypewriters. By 1968 terminal support had expanded to include the IBM 2260 display complex, and the IBM 2740 communications terminal. QTAM devices were attached to

220-455: The command line arguments telnetd -a . inetd automatically hooks the socket to stdin, stdout, and stderr of the server program. Generally TCP sockets are handled by spawning a separate server to handle each connection concurrently. UDP sockets are generally handled by a single server instance that handles all packets on that port. Some simple services, such as echo , are handled directly by inetd, without spawning an external server. This

242-414: The data. Otherwise inetd lets the server run and spawns new, concurrent processes for new requests. The fifth word is the user name, from the /etc/passwd database, that the service program should run as. Finally, the path and the arguments of an external program are given. As usual, the first argument is the program name. In the example, inetd is told to launch the program /usr/sbin/telnetd with

SECTION 10

#1732883905879

264-490: The functionality of inetd into launchd . The services provided by inetd can be omitted entirely. This is becoming more common where machines are dedicated to a single function. For example, an HTTP server could be configured to just run httpd and have no other ports open. A dedicated firewall could have no services started. systemd supports inetd services, and expands socket activation beyond IP messaging ( AF INET +6) to include AF UNIX , AF NETLINK and more. While

286-531: The functionality of the above example is usually implemented by using syslog and a process like syslogd. syslogd would normally be started in parallel with inetd, not as an inetd service. In recent years, because of the security limitations in the original design of inetd, it has been replaced by xinetd , rlinetd, ucspi-tcp , and others in many systems. Distributions of Linux especially have many options and Mac OS X (beginning with Mac OS X v10.2 ) uses xinetd . As of version Mac OS X v10.4 , Apple has merged

308-426: The inetd concept as a service dispatcher is not inherently insecure, the long list of services that inetd traditionally provided gave computer security experts pause. The possibility of a service having an exploitable flaw, or the service just being abused, had to be considered. Unnecessary services being disabled and "off by default" became the mantra. It is not uncommon to find an /etc/inetd.conf with almost all

330-424: The inetd.conf man page for information on the other arguments). The first argument contains the filename to be used for the log file: /tmp/logfile.txt . inetd will run the service when needed, and attach port 9999 to the input and output streams, and all strings sent to that port will be logged to the file. By specifying wait , it tells inetd to only use one instance of the server to handle all requests. Note:

352-600: The lines and terminals comprising the system, the datasets required, and the procedures used to process received and transmitted messages. The application programs, incorporating logic to process the various messages, are supplied by the installation, and use standard OS/360 data management macros OPEN and CLOSE , and either the Basic macros READ , WRITE , and CHECK , or the Queued macros GET and PUT . The use of SAM macros allows application programs to be tested in

374-413: The service running to service all requests. This means UDP is the correct protocol to use. First, an unused port number must be selected. In this sample, 9999 will be used. The /etc/services entry will look like this: And the entry in /etc/inetd.conf will look like this: This tells inetd to run the /usr/local/bin/errlogd program, with the commandline: errlogd /tmp/logfile.txt (refer to

396-403: The specific servers run only when needed. Furthermore, in inetd's "nowait" mode of service management, no network code is required in the service-specific programs, as inetd hooks the network stream directly to stdin and stdout of the spawned process. For protocols that have frequent traffic, such as HTTP and POP3, either inetd's "wait" mode of operation, or a dedicated server that intercepts

418-492: The terminals, identifies input messages and starts MPPs to process them as required. This is similar in concept to the much later internet service daemon (inetd) in unix and other systems. The MCP is assembled by the user installation from a set of macros supplied by IBM. These macros define the lines and terminals comprising the system, the datasets required, and the procedures used to process received and transmitted messages. The MPP s, incorporating logic to process

440-426: The terminals, identifies input messages and starts application programs to process them as required. This is similar in concept to the much later internet service daemon (inetd) in unix and other systems. It is also similar to QTAM, where the application programs are called Message Processing Programs (MPP). The MCP is assembled by the user installation from a set of macros supplied by IBM. These macros define

462-427: The traffic directly may be preferable. The list of services that will be serviced is given in a configuration file, usually /etc/inetd.conf . A GUI for managing the configuration file is an optional accessory. The daemon may need a signal in order to re-read its configuration. For an example, telnet can be configured as follows (line taken from a machine running AIX version 5.1): The first word, telnet ,

SECTION 20

#1732883905879

484-460: The various messages, are supplied by the installation, and use standard OS/360 or DOS/360 data management macros OPEN , CLOSE , GET , and PUT . PL/I includes the TRANSIENT file declaration attribute to allow MPPs to be written in a high-level language. This mainframe computer -related article is a stub . You can help Misplaced Pages by expanding it . This computer networking article

#878121