Using the SAS(R) System in a distributed DOS(R)-to-VMS(TM) Environment using PCSA(TM) Software Thomas Emmerich, SAS Institute

Transcription

1 Using the SAS(R) System in a distributed DOS(R)-to-VMS(TM) Environment using PCSA(TM) Software Thomas Emmerich, SAS Institute Features Author: Tony Fisher, SAS Institute ABSTRACT More and more, companies are faced with the proliferation of personal computer worksta'tions to meet' their computing needs. Even,though these workstations provide a nice environment to the end user, they also can,have p'roblems, specifically, resource limitations -in the amount of CPU power, memory, I/O capacity, and disk space. Also,,much of the data required by end U5ers often resides in centralized databases. These data are impractical for storage on a personal computer due to the amou'nt of" data and the need to share the 'data among many people. What would make this environment more 'appealing to both the end user and the systems administrator? The ability to share data between different systems in the company computer network maximiz'es efficient. use of storage. The ability to develop applications that execute using the most appropriate resources of- the network allows the application developer to make the most intelligent decisions about how to use the available resources. One popular example of this distributed environment consists of MS-DOS(R) personal computer systems operating' in conjunction with VMS(TM) server computer systems. This, paper will discuss tools available for using PCSA(TM) and ' DECnet(TM) software, as a way to develop and maintain, SAS(R) System applications. A. combination of features and tools available from Digital ' Equipment Corporation's DECnet PCSA clie-ntfor DOS software and the SAS System' are discussed. INTRODUCTION The PCSA products provide the capability to develop applications that take advantage of resou ces th'roughout the network. There are several techniques available for developing better applications in the DOS-to-VMS environnient~ These techniques allow you' to access the VMS disk drives, the VMS file system-, and peripherals attached to thevax(tm). You can 'also utilize the VMS server CPU power and memory by allowing parts of a SAS System application to execute on the server system. The techniques this paper addresses are o using PCSA software'- to create 'virtual disks on a VMS host in order to store and share' SAS databases and SAS software o usin9 PCSA software tocr'",ate file services in order to share data between DOS users and between DOS and VMS o using PCSA to,access VMS print devices from the SAS System executing on an MS-DOS personal computer o using SAS/CONNECT(TM) with DECnet - PCSA to SAS applications. software distribute This paper will demonstrate when and how to utilize these different tools to create bet ter SAS applicat ions. The examples use personal computers rumiing MS-DOS as the client system and a VMS system as the server. With the exception of using SAS/CONNECT software with a DECnet protocol, the same funct ionali ty is supported using an OS/2(R) client system. With PCSA ULTRIX(TM), you CAn also use an ULTRix system as the server system. Future versions: of the SAS System will support SAS/CONNECT software using DECnet t'askto-task communications protocol on VMS, ULTRIX, MS-DOS, and OS/2. USING THE SERVER RESOURCES There are four components of PCSA software that allow you to take advantage of the resources of the VMS server from the DOS client system. Virtual disk services, file services, and pr inter services are compdnents that allow you to access server resources as though they were local to 677

2 the PC. SAS/CONNECT soft.ware running in the PC SA environment allows you to distribute SAS applications to execute on the PC and the VMS server. USING A VIRTUAL DISK SERVER The virtual disk server allows you to allocate disk space on a VMS disk where you can store, create, and maintain DOS files. This space is actually a VMS container file that functions like a DOS-formatted disk and has all the attributes of a DOS disk. Since the VMS file is internally formatted as though it were a DOS disk, the individual components (DOS directories, subdirectories, and files) are not available to the VMS file system. Creating a virtual disk service requires that the PCSA administrator on the VMS server create the virtual disk using the PCSA administration utility. Once the virtual disk is mounted, a service (or logical) name is assigned to the disk. For example, to connect to a service named PCDISK on DECnet node VAXNOD, you would execute the following: USE F: \\VAXNOD\PCDISK /VIRTUAL SET SASROOT F:\SAS This equates a local disk designation, F:, to the PCSA service PCDISK and therefore to the virtual disk (or VMS container file) on the VMS server node VAXNOD. Once.established, this can be used as a local disk, as shown in the following example: DIR F: To VMS, the virtual disk looks like a single file. However, to the DOS client, it looks and functions like a DOSformatted disk. Virtual disks can be created in a variety of sizes (up to 32 MB). and for a variety of purposes. When a virtual disk is created by the PCSA administrator, the disk type (USER or APPLICATION) is indicated by the TYPE= qual if ier. An APPLICATION virtual disk is a read,.. only disk service that can be shared by PC users. The SAS System can be installed on an APPLICATION virtual disk, allowing all client machines connected to the service to execute the SAS System from the single copy of the executables on the virtual disk. Since there is only one copy of the SAS System installed for all PC users, disk space usage is reduced. The only change needed to the SAS System startup is to modify the configuration file (config.sas) to indicate the new root directory. In the above example, if PCDISK was defined as an APPLICATION disk service, and the SAS System was installed in directory \SAS on that service, the following line should be inserted in the configuration file: SET SASROOT F:\SAS In the same fashion, the APPLICATION disk can store read-only data to be shared by the PC users. A USER virtual disk can be used as a regular DOS directory to store SAS System data, SAS program files, or to contain the SAS work directory and other SAS libraries. In order to use the,sas System for these purposes, the virtual disk should be created as a personal virtual disk (TYPE=USER). This type of data file will normally be mounted for exclusive read and write access by an individual user. For example, if the PCDISK.service above was created with TYPE=USER, it could easily be referenced by a SAS data library: LIBNAME VDISK 'F:\SASDATA'; DATA VDISK.NEWDATA; PROC PRINT DATA=VDISK.NEWDATA; A virtual disk can be mounted as either read-only or read-write. If the disk is read-write, only one user at a time can access the disk. However, if the disk is mounted as read-only, users from multiple DOS client systems can access it simultaneously. 678

3 A virtual disk service offers the same features as a local attached disk drive on the PC without PC disk drive space or throughput limitations. In addition, a read-only virtual disk can be simultaneously shared for read access by multip'le users on multiple DOS client systems. This saves both disk space and time since only one copy of an application or data is maintained. Limitations of a follow: virtual disk service o The maximum size of a virtual disk is 32 MB. o Multiple read-write access is not allowed. o Data cannot be directly accessed from VMS. USING A FILE SERVER The file server provides the availability to access directories, subdirectories and files of the VMS file system as though they were local to the PC. This allows you to access the same directory tree from both the PC and the VMS server. Through a file service, files are mapped to a DOS directory structure when accessed by DOS utilities. Since the files are standard VMS files, they can also be accessed by VMS utilities. Access by the file server is through RMS(TM), the VMS file management system. All security control is provided by RMS. If the DOS client has access to the VMS files designated by the file service (via VMS username/password designation), and the files abide by the DOS file naming convention, accessible as DOS disk. then the files are if they were on a local File services can be either public or private (user specific.) A private file service will map a PC device specification to the home directory of a VMS user. In the following example, the PC device I: will be mapped to the home directory of USERI on node VAXNOD: USE I: \\VAXNOD\USERI password The PCSA administrator must first set up a public file service. Once the public file service has' been set up on the VMS server system, the DOS syntax to connect to that server is USE G: \\VAXNOD\VAXDIR%uname pass This command will make the file service VAXDIR defined on the VMS node VAXNOD available to the DOS cl ient system through PC device G:. From an application standpoint, the file service offers several additional capabilities beyond that of a disk service: o There is not a 32 MB size limitation. o A file service is visible to both VMS and DOS, which has several benefits: - You can share data between' VMS and DOS users. - You only need one copy of files for all VMS and PC users. ASCII data files can be shared by placing them in a VMS directory and connecting a file service to that directory. These files are then concurrently available to multiple SAS sessions execut ing on any VAXes or PCs in the entire PCSA network. Note that binar'y data formats are different between VMS and DOS and it is, therefore, impossible to share binary data between the systems. Since SAS data sets use system dependent, binary storage formats and floating point representations, native SAS data sets cannot be directly shared between the two systems using a file service. It is possible, however, to create SAS transport data libraries in an RMS directort and assign a file service to that directory. Those libraries can then be accessed by both systems. SAS data can then be accessed in the transport format with the data step and procedures. Since transport data seits can onl~ be accessed sequentially, procedures that access the data sets by observation number (for example, the FSEDIT proce~ure and the FSBROWSE procedure) cannot be used. The COPY procedure can convert the data from 679

4 transport format to a native data set format in order to use these procedures. The VMS transport engine can only read fixed length files. Therefore, transport libraries and transport data sets that will be shared by both systems must be created on a file service with the SEQUENTIAL_FIXED fixed-length files attribute. The PC SA administrator indicates the attributes to be associated with the file service (with the ATTRIBUTES= qualifier) at file service creation. By default, a file serv ice is created with the STREAM attribute. To create a transport library, you must assign a library reference using the LIBNAME statement and indicate that the library access is to be via the SASV5XPT engine. Assuming that the VAXDIR service connected in the USE statement above is a SEQUENTIAL_FIXED file service, the following -LIBNAME statement can be used to make the assignment: on DOS: on VMS: LIBNAME XPORT SASV5XPT 'G:TRANS.DAT' ; LIBNAME XPORT SASV5XPT 'DEV:<DIR>TRANS.DAT'; where DEV is the device and DIR is the root directory referenced by the file service. There are two techniques for creating SAS data sets in the transport library. The first method limits you to one data set per library, but is faster. Use the library reference (XPORT) when you create the data set. The dataset will be written in transport format to the data library indicated: LIBNAME XPORT SASV5XPT 'G:TRANS.DAT'; DATA_ XPORT.NEWDATA; R~; If you create more than one data set with the same library reference, each one you create will overwrite the previous data set. The second technique allows multiple data sets in a single transport library. To use this method, you must use PROC COPY to populate the transport library. For example: LIBNAME XPORT SASV5XPT 'G:TRANS.DAT'; DATA NEWDATAl; DATA NEWDATA2; PROC COPY IN=WORK OUT=XPORT MEMTYPE=DATA; ' Unfortunately, files created on a SEQUENTIAL_FIXED file service are difficult - to edit or print. It is better to have at least two file services to have the greatest flexibility accessing files using file services: o one file service that has the attribute SEQUENTIAL_FIXED for storing and accessing transport data libraries o another file service that has STREAM attribute and would be used for other data, text, and ASCII files. Note that both the SEQUENTIAL_FIXED and STREAM services can access the same VMS directory. Although files in a file service can be concur rently shared between users, data in a transport library cannot be concurrently shared. If any user on a DOS client or on a VMS system has a transport library opened, other attempts to access the data will not be honored. Transport data files are the only SAS files that can be directly shared between the SAS System for PCs and. the SAS System under VMS. All other data sets, catalogs, and utility files are not interchangeable. See SAS Technical Report P-195, Transporting SAS Files between Host Systems, for information on transporting SAS files. 680

5 File services give you additional capabilities beyond those of a disk service. The maximum size of a fileservice file is limited only by the size of the VMS disk drive. Files on a file service are accessible by both VMS and 005 users. However, because the file server uses RMS to access all files, it is slower than disk-server access. USING PRINTER SERVICES A printer service is made available to a OOS client using the file server facilities. Using a printer service, VMS printer or plotter devices can be accessed as though they were attached locally to the PC. A printer service designates a printer queue on a VMS computer to be accessed by the PC. This allows a OOS application to spool output or a OOS file to a VMS print queue. Multiple print services can be configured to support different queues with different. printer characteristics. Printer services are set up by the PCSA administrator in much the same way as file services. To access the printer service from within the SAS System, you must connect the service to the PC device LPTl:. For example, if the PC SA adminstrator created a printer service named LN03, the following would make that pr inter available to the SAS System: USE LPTl: \\VAXNOD\VAXDIR%uname pass Note that LPTl: must always be used. Once this has been done, the queue can be accessed anywhere within a SAS application where the FILE command can be used. For example, from the SAS DisPlay Manager System OUTPUT window, you can enter the following: FILE LPTI : The contents of the OUTPUT window will be spooled directly to the VMS printer. The printer services are essentially specialized file services that provide access to VMS printer devices from the PC. This gives PC applications the ability to use printer resources from the VMS server. USING SAS/CONNECT SOFTWARE AND THE DEC NET ACCESS METHOD A final method that allows SAS applications on a DOS client system to utilize VMS resources is using SAS/CONNECT software. SAS/CONNECT software can also use the PCSA environment. SAS/CONNECT software supports a DECnet access method that allows you to establish a SAS System conversation between a local SAS System for PC session and the sarver VMS system. By utilizing this feature, the DOS client is able to employ the CPU and memory resources of the remote VMS server. This access method works with the SAS System on DOS connect ing to a SAS/CONNECT session running on VMS Release 5.18 or Release This software makes use of the DECnet CTERM protocol to provide SAS/CONNECT conversations. By using the SAS/CONNECT CTERM access method, you can take advantage of the processing power of the VMS server system from a PC. After establishing a SAS/CONNECT conversation, you can designate whether you want particular SAS program statement steps to be run on the DOS client or on the VMS server system. Output from either step can be displayed on the DOS system. Before beginning a SAS/CONNECT conversation, you must indicate which remote VMS nodes you want to talk to. This is done by setting DOS environment variables and a SAS system option. First create a DOS environment variable for each node to which you want to connect. The environment variables should be of the form CTERMX where X is a letter (A-Z) designator. For example: set cterma=nodel set ctermb=node2 Then, before executing the SAS/CONNECT SIGNON command, execute a SAS system opt ion statement indicating the node of choice. For example, 681

6 .~ OPTIONS REMOTE=CTERMA; would be used with the I?revious example in order to establish a connection to the VMS node NODE1. By using SAS/CONNECTsoftware,. once the conversation has been established, processing between the client and server can be distributed to make most efficient us'e of the resources of both sys,tems. Steps that require large amounts of memory and,process ing power should be executed on' the server system. Less resource interisive steps are candidates to be executed on the DOS client system. For example, data entry processing could be done on the PC systems and stored locally as the data is entered. Later, the data can be transferred to the larger VMS serv,er system for integration into master databases. Data from several data entry PCs can be integrated in this manner. The data on the server system are available' to all SAS applications, whether on the PC or on the VAX. By using SAS/CONNECT software, files and data sets can be uploaded and downloaded between the two systems using the UPLOAD procedure and the DOWNLOAD procedure. This allows access to data stored on either system without conversions. Jobs that require access to entire centralized databases should be executed on the server node using the resources of the server. Subsets of data can be downloaded to the host for in-depth analysis. SAS/CONNECT software allows you to distribute the processing of SAS applications in a distributed PCSA environment to make the best use of the resources. Data can be accessed in native format from the system on which the data reside. Data can also be moved between the systems to allow you to distribute your applications and still integrate data among all the systems in the network. CONCLUSION Using the SAS System in conjunct ion with PCSA software gives you the ability to take advantage of resources on both local PCs and remote VMS nodes. Applicat,ions can 'be developed to'make the best use of CPU, memory; disk space, or per ipherals. The combinat ion of SAS/CONNECTsoftware, PCSA file' servers, disk servers, and printer 'servers gives you flexibility to select how to best use the resources of this distributed environment. REFERENCES Additional information about SAS/CONNECT software can be found in the following reference: SAS Institute Inc. (1990), SAS/CONNECT Software: Usage and Reference, Version 6, First Edition, Cary, NC:' SASlnstitute Inc. Additional information on transporting SAS System files between host :operating systems can be found in the following reference: SAS Institute Inc. (1990), SAS Technical Report P-195, Transporting SAS Files between Host Systems, Cary, NC: SAS Institute Inc. Additional information on PCSA can 'be found in the following references: Digital Equipment Corporation (1989), PCSA Network Commands Reference Manual, Version 2.2, Maynard, MA: Digital Equipment Corporation. Digital Equipment Corporation (1989), PCSA VAX/VMS Services for MS-DOS Administration Guide Version 2.2, Maynard, MA: Digital Equipment Corporation. SAS is a registered trademark' and SAS/CONNECT is a trademark SAS Institute Inc., Cary, NC, USA. VMS, VAX, PCSA, DECnet, RMS and ULTRIX are trademarks of Digital Ecjuipment Corporation. MS.,..DOS, is a registered trademark,of Microsoft Corporation; OS/2 is a registered trademark of IBM. t,' 682