VTAM'in incelenmesi ve bir VTAM uygulaması

Abstract

Bu tez IBM SNA mimarisindeki haberleşme şebekelerinde kullanılan uygulama katmanı protokollerini ve bu protokolleri kullanan uygulama programlarının nasıl yazılabileceğini anlatmaktadır. İlk olarak, SNA denilen mimari tanıtılmış ve yıllar içinde nasıl geliştiği anlatılmıştır. Sonra bir VTAM uygulamasının nasıl geliştirilebileceği anlatılmış, basit bir program adım adım geliştirilmiştir. En sonunda hem VTAM hem de VSAM kullanan bir veritabanı uygulaması takdim edilmiştir.

Introduction: This project is concerned with application programs that function as part of an Systems Network Architecture (SNA) network. Below is a discussion of SNA, GCS, structure of VTAM applications and IBM 3270 devices. Finally, the development of VTAM applications is explained step by step and a phone directory application using both VTAM and VSAM access methods is presented. All programs have been coded in S7370 and are commented in English. SNA: Systems Network Architecture! is a design specification for computer networks. It was first proposed in 1974. The objective of SNA is to achieve an efficient, reliable, cost-effective environment with interconnection freedom and uniform means of communication. It provides the following:. Application switching. Dissimalar terminal/device coexistence on a line. Trunking. Standard protocol for data transfer between applications For a data communications environment, SNA specifies the following:. Entities that need to be served.. How entities interact with the environment. Control functions. Function grouping and interconnection procedures. Commands and command sequences. Message formats When first revealed in 1974, SNA was a simple architecture which did fulfill the crucial objective of application switching but did little else. It has evolved over the years to become a very sophisticated architecture. Application programs which use SNA defined facilities for communicating to other applications are called VTAM application programs. VTAM stands for Virtual Telecommunications Access Method. VM Systems and GCS: Virtual Machine systems comprise three different operating systems:. Control Program - CP. Conversational Monitor System - CMS. Group Control System - GCS IX The function of CP is to make resource sharing possible by splitting a computer system into independent virtual systems. That of CMS is to provide a means for the average user to run every day applications such as electronic mail, scientific applications, assembler and compilers. GCS is purpose specific. It is only good for communications applications that must use the access method called VTAM. A brief comparison of the two operating systems will reveal the most important differences between CMS and GCS. Both operating systems support the REXX interpreter, OS macros, IUCV and APPC communication, BSAM, QSAM and VSAM filing systems. Therefore it is possible for a CMS VM to communicate to a GCS VM, and files can easily be transferred from one operating system to the other. Unlike CMS, GCS requires VM's to work in groups and different VMs in the same group can have different levels of authorisation. Also, GCS is multi-tasking and supports VTAM, the access method that is essential for telecommunications applications. Some typical SNA applications that can be run under GCS are as follows:. Virtual SNA Console Support - VSCS. Remote Spooling Communications Sunsystem - RSCS. NetView It is possible for an establishment to write its own applications, the phone directory application developed for this project is one such application. VTAM Applications: The reason SNA applications are called VTAM applications, is that they must all use an access method named Virtual Telecommunications Access Method, or VTAM. VTAM allows logical units to communicate to each other. A VTAM application program is also a logical unit and it can communicate with the following:. Other VTAM application programs. SNA devices (channel attached and SDLC link-attached). Non-SNA 3270 devices (channel attached and BSC link-attached). Non-SNA devices in conjunction with the Network Terminal Option (NTO) licensed program. Logical units controlled by another VTAM or TCAM The VTAM applications programmer is concerned with either communication between two applications programs or an application and a device such as a terminal. Both application programs, and devices are logical units (LU). The term device type logical unit refers to any logical unit other than an application program. This project involves writing an application program that can communicate with IBM 3270 terminals. End-users can logon to this application program from their terminals. The VTAM program running in the host processor is of particularly great importance. The part of an SNA network controlled by a VTAM is called its domain. Logical units in the same domain can only communicate to each other by using the services their VTAM provides. The NCP (Network Control Program) runs in communication controllers. If the two logical units are linked by a telecommunication link, they also need the services of an NCP. An application program generally has two parts: the processing part and the communication part. The processing part is service oriented. The communication part enables the processing part to communicate with devices or other applications. The communication part is written in assembler language and uses VTAM macroinstructions to request VTAM services. Macroinstructions are divided into several categories. The macroinstructions that build and initialise the control blocks required for communications are called declarative macroinstructions. Those which can dynamically build, examine and alter such blocks, are called manipulative macroinstructions. Those which begin and end an application are called ACB-based macroinstructions. Most of the macroinstructions fall under the heading RPL-based. These are the macroinstructions that actually handle most of the communication procedures. Communication between logical units cannot begin until VTAM establishes a session between them. In any session between two logical units, one logical unit, the primary logical unit (PLU), acts as the primary end of the session, and the other logical unit, the secondary logical unit (SLU) acts as the secondary end of the session. The PLU has more control over communications than the SLU. There are VTAM supplied macroinstructions and exit routines to assist in establishing and terminating sessions between logical units. Two control blocks play an essential role in sessions: the Request Parameter List (RPL) and the Node Initialisation Block (NIB). The RPL contains information that describes a request for VTAM services. This request is typically sending or receiving data. The NIB, on the other hand, describes a session that is to be established or terminated. It includes the communication identifier (CID) of the target session. Communication between two logical units consists of requests and responses to requests. A response to a request contains information about the success or failure of transmission and processing of a particular request. It is possible for two LUs two communicate over a session without ever sending responses. The sender of a request may specify no response, negative response or definite response. If negative response is specified, a response will be sent to the sender only if the request is not received or processed correctly. If definite response is specified, a response will be returned for every request. Responses can be type 1 (FME), type 2 (RRN) responses, or both. Some LUs require a specific type of response. For example, IBM 3270 terminals never ask for responses and can only send definite or negative FME responses. XI Serial numbers can be assigned to requests and responses to make it easier for the logical units to detect missing messages. The organisation of a VTAM application program is very important. It affects the program's response time, storage requirements and ease of coding. The programmer must decide how much concurrency is required to provide satisfactory performance without making the program too difficult to code. Operations can be synchronous or asynchronous. The greater the number of asynchronous operations the better the response time of the program. There are two alternatives to asynchronous coding: using ECBs and using RPL exit routines. ECB posting gives the programmer more control over how things are done. However using RPL exit routines is easier to code and generally provides better response times. Another way of improving performance is to use scheduled operations rather than responded operations. In scheduled operations, VTAM returns control back to the program as soon as it has scheduled the request to be sent. In responded operations, VTAM does not return control back to the program until the request has been received and a response has been returned. Concurrent applications deal with more than one session at a time. Therefore when receiving data, it is important to be able to specifiy a particular session. A specific-mode RECEIVE macroinstruction will only receive data from the specified session. An any-mode RECEIVE macroinstruction will receive data from any session. Sometimes a programmer wants to prevent data from a certain session to be received by an any-mode RECEIVE, because he has coded a specific-mode RECEIVE for that purpose. To prevent this, an entire session can be switched to the specific-mode. Data from a specific-mode session can only be received by a specific-mode RECEIVE macroinstruction. IBM 3270 Devices: This family of devices comprises displays, printers and cluster controllers. Typical examples for displays are the 3278 and 3191, for printers 3287 and 4224, for cluster controllers 3174 and 3274. Displays can be LU Type 0 or LU Type 2. Those normally under CP control are Type 0, and those normally under VTAM control are Type 2. The data transferred between the application program and the terminal during communicartion is basically a command language called the 3270 Data Stream. Printing on the terminal screen and reading user input requires familiarity with this command language. Use of brackets is required, the programmer must remember that xii whenever the application program is performing a RECEIVE, the display will automatically open a bracket. Therefore a subsequent SEND instruction should only contain an End-Bracket Indicator, not both Begin and End Bracket Indicators. Program Development: Since GCS does not have a text-editor, assembler or link-editor, all GCs programs are developed using CMS services. All GCS programs follow the same routine procedures at the entry and exit points. This involves saving caller's registers and exiting with a return code. The CP PER command is useful for debugging assembler programs. When starting to develop a VTAM application, it is a good idea to go step by step and solve ail problems in one step before proceeding to the next. First, the VM that will IPL GCS must have its directory definition amended accordingly. Then, the systems programmer must define the application to VTAM. After the preliminary preparations, the programmer can add and test the OPEN and CLOSE instruction to open and close his application. To test whether the application is opened successfully, he can test R15 upon completion of the operation, or alternatively, use an authorised VTAM operator VM to ask VTAM the status of his application. Once the application is opened, the first things to add are a SETLOGON macro and a LOGON exit routine. Whenever a display wants to logon to the application this exit routine will be called asynchronously. It will examine the session protocol and password inside the CINIT request and decide whether to accept or to reject the logon. The easiest way to deal with multiple sessions in a GCS program is multi tasking, that is starting a new task for every terminal that logs on. The alternative and the harder way is to use a single task containing asynchronous instructions. Once the application starts communicating to a terminal, the programmer can trace the data transferred between the two logical units. The VM that is tracing the data must be the secondary user of the GCS recovery machine. The console records in the Turkish section of this book show the development of a simple SNA application. In the final section, is the phone directory application. It uses VSAM to access the phone directory and VTAM to access the displays. A VSAM dataset was preferred to a simple CMS file because it is an industry standard filing system, it is xiii related to VTAM, it is very sophisticated and in particular suitable for database type applications. The dataset is a 2500 record phone directory. It has a single key, family names. The application is open to public, no passwords are required to logon. It can serve 64 terminal simultaneously. Conclusion: This project involved close examination of SNA communication protocols and step by step development of a typical database application that complies to these protocols. Its most important function is to provide working sample programs, an important deficiency of many other books on the same subject. It should save a novice programmer many months of learning.