SAS-USAGE UNDER ROSCOE/ETSO M.H.H. Lange, Centraal Beheer

Size: px

Start display at page:

Download "SAS-USAGE UNDER ROSCOE/ETSO M.H.H. Lange, Centraal Beheer"

George Morris
5 years ago
Views:

1 SAS-USAGE UNDER ROSCOE/ETSO M.H.H. Lange, Centraal Beheer Centraal Beheer is an insurance / financing concern. It consists of five divisions: Life Insurances, Damage Insurances, Financing, Private Insurances, and Computer Services (CB-Automatisering). The computer services division has been grown (since 1959) out of the automation process of CB. It supports the other divisions and sells a wide range of services outside: it is the biggest computer services oranisation in the Netherlands. The product package of CB Automatisering ranges from mainframe services to PC, from standard package service to taylor made applications and software. Since the introduction of the SAS package in 1981, as a replacement for an older package, its usage had been diverted to other goals as will be shown in this presentation. ROSCOE (slice 1) is the main tool for program development and maintenance. At this moment we use the RTS, ETSO, DMF and RPF features. SAS(slide 2) is used as a tool for cost-accounting, for performance and tuning of our computers and for end user analysis. Both products are run on our mainframes (slide 3). The NAS 8040 computer is mainly used for development and maintenance of programs. The IBM 3081 model K computer is.used for production. On this system we use the time-sharing features of ROSCOE to support end users. Because of changes in our organisation a certain applciation had to be re-developped. The existing application had to be extended with rather complex on-line features and it had to be used (and accepted) by all our programmers. The specifications of the new applciation turned out to be very different from the already existing application: it looked saver to implement the new application from scratch.

2 Under the pressure of time we have chosen to use SAS, for this task had to carried out in a very short period of time. (Almost all the time spent was used by negotiations to complete the design!) Given sufficient time and resources this application should certainly have been developped by other means, like IDMS-DC, and other normal development methods used in our company. We decided to implement the on-line parts of the ampplication with the new product SAS-Full Screen Support. We had no exact specifications nor any experience with this facility: so it contained a certain risk. At the same time our system programmers were experimenting with a new feature of ROSCOE that should replace the existing timesharing feature. This Extended Timesharing Feature could handle things like "dynamic allocation" and had better protection and performance characteristics. It was supposed to be much easier to run certain programs on-line under ROSCOE. For our purposes this extension looked ideal (slide 4): we could avoid to use TSO (every user has his own address space) our users should accept the new application much easier: on-line procedures would look like a natural extension of ROSCOE we could offer our end users a new language, as simple as BASIC but a a lot more powerfull (mostly they use BASIC programs under ROSCOE) The new application has been implemented with SAS under ROSCOE/ETSO. 200 on-line users. After this we completed a number of other applications. It has about At this very moment a ROSCOE-user can build his own on-line systems with SAS. The combination of both products has seemingly almost unlimitted capabilities! Of course, several problems had to be solved and the prese.nt combination contain serious flaws. 272

3 In order to run SAS under ROSCOE/ETSO (slide 5) you must concatenate the SAS load and format libraries to the ROSCOE-job control language. For each ROSCOE-user you must create a separate SAS workspace: this task can easily be performed with the ROSCOE Programming Facility. If you use a file, that is connected to a certain DD, more than once in your SAS-program then SAS cannot find that particular DD in the JCL. Because of this error you have to incorporate a number of dummy DD statements in the JCL of ROSCOE. SAS uses PL-l modules that create their own STAE environment: you must ZAP that module SASLIB to destroy this condition. We were afrain that too many users should try to run SAS under ROSCOE at the same time. (We were afraid that they should monopolize our computer resources.) So we made a small program that loads SAS and counts the number of currently active users. If there are more than fifteen active users, - we conjecture that's a reasonable estimate for about two hundred connected terminals - further access to the system will be denied. Looking at a TSO Command List (slide 6) and a RPF procedure (slide 7) notice: the different ways to allocate files. RPF looks more like Job Control Language Besides you have the possibility to allocate the ROSCOE workspace and ROSCOE library-members. However, you cannot allocate SYSOUT files and without changes to the ETSO Input-/Output routines you cannot read or write ROSCOE library members',by means of FILE/INFILE statements! (so SAS programs must be read through a SYSIN-file). under ETSO you cannot use the Command Processor SAS cannot use dynamic allocation under ETSO; so, use the NODYNALLOC-option! the CLIST option cannot be used. Within the parameterlist, you wish to pass to SAS, you cannot use percent signs. As a consequence of this initial loading of SAS programs of the INITSTMNT from a PDS is not possible. Besides, this parameterlist has a limited length: only one hundred characters can be passed to SAS. The options list for SAS tends to be longer. 273

4 Let's have a look at just a program executed under TSO and the same program under ETSO (slide 8). Under TSO a user can see what he has entered: SAS uses the whole screen. Under ETSO he always looks at a "split screen": new lines are entered on the command-area; the results of a run are printed at the bottom of the screen. He can only see his data before it is processed by SAS language parsers: he has no overview over his program! (A way to review the entered program is by means of a %LIST.) In executing SAS programs that reads cards from the SYSIN-file you encounter a small problem (slide 9). SAS uses PL-l modules that issue PUT's and GET's in LOCATE-mode. ETSO doesn't handle this type of 10 properly: the first card you read is lost! The solution is simple: insert a "dummy"-card at the top. As a matter of fact all problems connected with ETSO have to do with 10 and the PL-l environment of SAS! So the same fenomena occurs on the outputs ide e.g. if %PUT statements are issued, the screen between two SAS programs some lines could be lost! The solution is: execute a dummy %INPUT statement; ETSO than prompts this output to the screen. Finally let's look into the possible ways to use SAS under ETSO. SAS can be used as a tool for an end user (slide 10): only small expert programs will be executed and created interactively. But also one can use SAS for very complex pre-programmed, on-line, procedures. We did both. The question was raised about the on-line features of SAS: why is SAS used and not only the Dialog Management Facility with the Program Facility of ROSCOE? This question can only be answered by looking at the problems on one hand and the functional characteristics (and quality) of SAS under ROSCOE/ETSO on the other hand. Highly customized screen procedures with RPF can be made. One is not limited in the way one wishes to assign functions to keys. For instance, the ENTER key can be assigned. One is not limited in the ways one puts messages on the screen, nor in the ways you want to check your screen data, nor in the way what kind of screens and how many of them are to be used. However, using several files at the same time and manipulating the data from these, is rather poor with ROSCOE. 274

5 SAS knows extensive ways to manipulate data from various types of files: SAS is very good at it! The new Macro language has made the SAS language very powerfull!!! With FSP a new dimension has been added! i, ' : } :' : '- t' }:. ) ;. J,: ;,:, : f ::i,,.' J' Ii " V c' ;,(:.': 1,. ;j', J { 1 : it ', r:.:,: F j \,, I \ \ However, as a I,Ifull screen" product, SAS is yet too limited compared with an other product like RPF. So we have some remarks (we exclude FSCALC from this discussion): the method to generate new screens is excellent, but, a screen cannot be really customized: the Command Line cannot be removed A user always can destroy his "own" screen (not the screen dataset!): screens are not really protected! your own, user defined, functions cannot be assigned to function keys (e.g. the ENTER key cannot be assigned at all!) data checking on the screen is poor: only simple checks are allowed (e.g. it is not possible to check the contents of a data item that depends on the contents of an other data item) simple calculations on a screen are not possible SAS error messages cannot be suppressed nor translated only variables can be highlited on a screen it is not possible to assign initial, minimum, maximum values that are calculated by previous programs. only one type of screen is possible in as SAS-proc: changing screens means starting a new SAS PROC. Starting a new PROC means a lot of time. Once the screen is started the performance of FSP is very good. Unfortunately it takes a long (too long) time to start a new screen or a new procedure. We think that a lot of time is consumed by the language parsers and initial loading of the programs. This is not opt,imal in interactive mode!. Conclusion: SAS under ROSCOE/ETSO has the potential to be a great product: SAS, an easy to learn add easy to use language, can be offered to your programmers, and your expert users: it looks like a natural extension of ROSCOE without much effort you are able to program and test your own, on-line, SAS based systems. At the same time you can use ROSCOE as a very fine tool to develop and maintain them. 275

.THE INFORMATION CENTER INTERFACE (TICI) SA SI INQ FSP FSCALC A A2 G P N M J

.THE INFORMATION CENTER INTERFACE (TICI) Robert C. Haering, Houston Lighting & Power Company Inc. In 1982, Houston Lighting and Power Company Inc. (HL&P) did a feasibility study to evaluate the benefits