proceedings of the symposium for developers and users

SLAC-368 CONF-9006245 UC-405 (M)

PROCEEDINGS OF THE REXX SYMPOSIUM FOR DEVELOPERS AND USERS

June 11,1990

STANFORD LINEAR ACCELERATOR CENTER STANFORD UNIVERSITY, STANFORD, CALIFORNIA 94.309

Cathie Dager Symposium Organizer

Nancy Larson Symposium Administrative Assistant

Prepared for the Department of Energy under contract number DE-AC03-76SF00515

Printed in the United States of America. Available from the National Technical Information Service, US. Department of Commerce, 5285 Port Royal Road, Springfield, Virginia 221 61. Price: Printed Copy A1 1, Microfiche AOI.

PROCEEDINGS OF THE REXX SYMPOSIUM FOR DEVELOPERS AND USERS

TABLE OF CONTENTS

A. Summary I I

B. Presentations

Mike Cowlishaw: REXX 4.0 1

Bill Hawes Multitasking with Amiga REXX Marvin Weinstein: (no paper)

Walter Pachl: IBM REXX Compiler 33

Kevin Kearney The Astonishment Factor Charles Daney:

59

Keith Watts: I/O and Environment Challenges 65

Brian Marks: Object Oriented REXX 75

Rick McGuire: IBM SAA REXX for OS/2 101

Neil Milsted: REXX for UNlX 112

Bob O'Hara: Why REXX Died (A Retrospective) 124

Tony Johnson: SLAC Use of REXX on VM and VMS 132

Larry Oppenheim: Developing Fullscreen REXX Applications 152

Bebo White: CMS Pipelines 157

Mason Kelsey: REXX in Three Different Environments: VM/MVS/OS/2 172

C. List of Attendees 23 1

D. Announcement of REXX Symposium for 1991 235

1

SUMMARY

The first REXX Symposium for Developers and Users was held at t,he Stanford Linear Accelerator Center on June 11, 1990. Mike Cowlishaw, author of the REXX Language, was the keynote speaker and the developers of all current implementations of REXX made presentations. The 118 par- ticipants represented five countries and all of the REXX user communities. This broad participation demonstrates the growing interest in REXX as a multi-platform computer language.

The Symposium was planned as a gathering where REXX users and developers could meet each other, exchange ideas and information about the language and discuss future plans. In light of these plans, the morning and early afternoon of the Symposium were devoted to plenary presentations by the developers of various REXX implementations:

0 IBM SAA REXX; Mansfield Software Group Personal REXX for DOS and OS/2;

0 Portable REXX for DOS and TREXX for Tandem by Keith Watts; 0 Amiga AR.EXX by Bill Hawes; and

the Workstation Group UniREXX for Unix. Following the individual talks t'he developers sat on a panel and participated with the audience in a lively question and answer period. Late afternoon speakers talked about how they use REXX. This volume contains copies of the talks and transparencies.

The Symposium was a success and many ideas were exchanged. Discus- sions included multi-platform considerations, requests for language extensions and st'andards and plans for continuing the work at another Sympo- sium next year. (Refer to Announcement of REXX Symposium for 1991.)

.. I 1

ti In this paper for the REXX Symposiunl. for DewEopers and Users the history of the REXX language is reviewed and the new features in RE= level 4.00 are introduced.

REXX level 4.00 is described in detail in the author’s new book, the Second Edition of The R E Z Language (Prentice-Hall, 1990, ISBN 0-13-780651-5j; this is the language irnp’lemented in the IBM OW2 Extended Editiejn operating system: Release 1.2.

The REXX language (originally called “REX”) has developed in two distinct phases: the first being the rapid evolution of the language i n an essentially experimental environment, and the second being a more cautious series of enhancements following the commercial availability of implementations of the language.

The first phase took place as a personal project of about four thousand hours during the years 1979 through 1982, at the IBM UK Laboratories near Winchester (England) and at the IBM T. J. Watson Research Center in New York (USA). With this background RE= has an internat.ionaI flavour, with roots in both the European and North Amer- ican programming cultures. Its first presentation outside IBM was to SHARE 56, in Houston, in 1981.

In 1983, my own Systed370 implementation became part of the Virtual Machine/Syst,em Product, as the System Product Interpreter for the Conversational Monitor System (CMS). This implementation of the language is described in the Ref- erence Manual for that product.’ In 1985 the first edition of The REXX Language (describing language level 3.50) wa.s published, and mon after that the pioneer non-IBM implementation of REXX was announced by t . 1 ~ Nmsfield Software Gr0u.p: this runs

under the MS-DOS and PC-DOS operating systems for Personal Computers. A number of other implementations have followed from a variety of suppliers: one which perhaps best demonstrates the suitability of REXX for chfferent environments is a version for the Commodore Amiga computer.

The next milestone for REXX was its choice by IBM as the Procedures Language for the Systems Application Architecture (SA4).2 This 1987 announcement implies a common REXX language across all the SAA operating systems: VM, MVS, OS/400, and OS/2.3 The language interpreter development for all these environments is coordinated at the IBM Endicott Programming Laboratory, New York.

All the first implementations of REXX were interpreters: notable, then, was the announcement in 1989 of IBM’s CMS REXX Compiler, developed at the IBM Vienna Software Development Laboratory in Austria with help from the IBM Scientific Centre at Haifa in Israel.

Inevitably the commercial exploitation of the language has required a stable language definition - the radical changes in the language that were characteristic of its first years are no longer possible. Fortunately, those early years of heavy use and rapid evolution probably mean that such radical changes are no longer necessary: rather one would expec,t to see incremental changes and adjustments consistent with the philosophy of keeping the language small and approachable. This, indeed, is the philosophy that has been followed during the development of REXX level 4.00 over the past several years.

REXX 4.00 - Philosophy New features have been added to the REXX definition following a process of slow re- finement, essentially based on user feedback. In general the intention has been to “Keep the language small”, so the enhancements that have been made have been cho- sen for their high power-to-complexity ratio.

Some of the enhancements have been made for pragmatic reasons, such as for improved input and output flexibility (recognising the diversity of operating systems), error handling, etc. Others have been made in order to “tidy up” the language; these include improved arithmetic, defined character sets, and so on.

. . - . . . . .~ .

. . . . . . . ..

The Procedures Language for SAA comprises the REXX language, Double Byte Character Set support, and a series of common interfaces to the language.

More formally: CMS in the W S y s t e m Product or VMExtended Architecture, TSO/E in the Enterprise Systems Architecture/370, Operating Systeml400 for the Application Systeml400 (AS/400), and Oper- ating Systeml2 Extended Edition.

2

DATE('%'') Base Date function has been added (this returns the number of days since 1 January 0001, calculated by extendmg today's calendar backwards). 11 June 1990 is day 726628.

DAT%("c") Century Date removed because it is superseded by DATE("b"), and its use is likely to lead to problems in a few years4

Trace Scan Removed because it is very expensive to implement in certain cases.

f $ @ $4 @ Removed from symbols (names) due to difficulties in cross-system transfer and portability.

nhancements * Mathematical functions are consistently defined to normalize inputs before use

(most did before, though MIN and MAX &d not and could therefore produce sur- prising answers).

* The definition of basic operators has been clarified (the previous description did not fully define addition and subtraction, for example).

* The Power operator has been slightly redefined for improved accuracy:

should equal

FRED * FhUED * FRED

The algorithm is now defined as using precision D + L + 1 for its intermehate cal- culations, where D is the NUMERIC DIGITS setting, and L is the length of the exponent part of the number.

a Integer Divide and Remainder are in error if the result or partial result, respec- tively, is not a REXX whole number. For example:

123+30//7

was

(instead of 5 ) and is now a n error. This avoids misleading results.

Removing an item from the language does not imply that it would be removed from existing implementations.

3

Parsing A new, explicit, “Absolute” column notation has been added:

parse arg =5 rest

is the same as

parse arg 5 rest

This adds no new function to the language, but allows the following extension:

* Indwect column number (absolute or relative), where the value of a variable can be used for column specification by enclosing its name in parentheses and preceding it with “+”, K-”, or “=,’. For example:

start=7 length=5 parse arg =(start) a +(length)

is the same as

parse arg =7 a +5

Binary String Support New binary-defined string notation:

‘1100 0001‘b = ’Cl‘x

New hexadecimal to binary conversion function:

x2b ( ’ BE’ ) --> ’ 1011111O‘

New binary to hexadecimal conversion function:

b2x ( ’ 10111110‘ ) --> ‘BE‘

Input/Output Enhancements

.. . . . .

. . . . . . , , . . .

. .. . . , . . ... . . . ,

..

New STREAM built-in function, for:

1. Formal state of a stream (Error, Ready, Not Ready, or Unknown)

2. Descriptive state of a stream (adhtional information)

3. System-dependent stream commands.

4

* New NOTREADY condition for improved error handling. For example:

signal on notready

which might be raised when end-of-file is reached on a stream.

Improved Error * The CALL ON condition instruction lets a subroutine be called for the ERROR,

FAILURE, HALT, or NOTREADY conditions.

The new NAME option for CALL OX or SIGXAL ON allows the specification of a label which will be the target of the CALL or SIGNAL when the condition is raised.

or

signal on error name baddie

* The new CONDITION built-in function can be asked to return:

1. The name of current trapped condition

2. A descriptive string associated with the condition (for example, the derived name of the variable whose attempted reference caused NOVALUE)

3. The instruction used to trap the condition (that is, CALL or SIGNAL)

4. Formal state of the conchtion (ON, OFF, or DELAY). DELAY is used when a condition has been raised but bas not yet been processed.

Enhanced variable handling Indwect lists may be used on PROCEDURE EXPOSE; variables whose names are enclosed in parentheses are themselves exposed and then their value is used as a list of variables to expose. For example:

vars=' fred mark st-. '

call mysub

mysub : procedure expose (vars) 20s.

return

e Indirect lists are similarly permitted on the DROP instruction.

The VALUE function c a n now set variables:

ansther=3 €red= ‘ ANOTBEEl‘ say value (fred, 51

sets ANOTHER to 5, and displays 3 (the the previous value of ANOTHER).

0 The VALUE function can now refer to external collections of variables (system- defined). For example:

say value ( ’ LIB‘ , , ‘ OS2ENVIRONKENT‘ ) in the OS/2 implementation provides access to the OW2 environment variables. This example might display “C:\OS2”. If a second argument is given then the variable will be set, as before.

. . , ...

6

32 a, Q

, cb 3

cr, c

T

0

0

cyj X

X u

CT I 0

0

P

X

X W

U

.... ..

.

..

..

.

..

. ._

. . .

.

..

8

.... X

X u a

r' > w

CT a,

.c.r L

v, ii 0

0

l-

-. k

3 3

k

h

h

+--r C

3 0

0

X

..

.

.,

.

..

.

..

..

.

..

..

..

.

......... ........... ,

.

. ..'

..... ......

..

9

..-

eL4 >

ud a

..

.

..

..

.

,.

..

..

.

..

.

..

..

.

..

..

10

. ... .

4

11

L

cbg Q

Q)

P

. .

.

.. ..

12

.........

0

.- 4-J

gz -

K

m,. "0

+

n

OJ

-W

s-

u

..

.

..

...

.. -..

..

.

..

..

..

..

.

..

.

..

.

13

...

a

w X

-c-r

-0

a-

VB

s-

L

+ +

.......

14

cb

b

c.

.

t

rn cn a

.-

a-

a, rn cd 3 0

C

cb

s

."..... .................. .I1 ~.,, . ..., ............... ~~ II ...... ~... ......

..

.

..

.

..

..

.

.~

.

....... .

.

..

..

.

_

..

..

15

n I

0

0

6

X

X

W

CT

.. .. -

cn .- a

x

La

QG

=

ci

b

a, 0

+--r

a

r. 0

ki h

U

a, > 0

2i. E

.. .. .. Q

3

cn S

.-

16

Y- O

a, 12

I

E 3

S u-

U

U

w" a

n

I-

7

0

0

0

-- . ,. .

. ..

..

17

. .\.

c

a, N

I-

.I

M

JC JC a

n

a

2 G-r sc 13

2 G-r cn a, cn 3

..

18

b

0

a, a

cn a

hc-

9J

03

jc * Q

2 b-4 3

0

Iz v,

..

.,

.. ... .

.

... .

.

.. ...

19

L 0

a, +.-r

E 3 S

P

II c, k rd c, cn

m II

rG c, b

d

a, I-i

..

.

.

. .

..

21

x 4

ri u

4 II II a 4

d

0 0

0

0 0

d d

1.

4

El p7 4

A I I

. .. ..

. ..

22

W

W

E

23

b

-c-r cn

o

a .s

eu'

U c

.

,. ..

23

.F Q

,

Em

24

L

+ 0

U

a,

c, -4

x a, c a,

JZ c,

.. k

k a,

25

k 0

k k a, c 0

c) L 0

a, E rd r= k 0

k k a, G

0

26

cn U

27

- ul k rd 3 v

.

*

..

.

..

..

. .

..

.

.. .

.

.. .

28

0

w

oc.

-.ru u

- 29

E a

-a,

wd

4J

0

-

cn c4tr

Xk

a,

3

....... I .

.

.... - .. ......... ,

.

. - ._

. .

..

.. ,

.

..

.

.

..

.

.

..

.

.

..

30

..

0

PC: H

3

z w cu [/I 0

\ \

Q

cn 73

.- E 0

E

..

.. .

... ..

..

.

.

..

.

..

.

.

.. - .

..

31

Walter Pachl

IBM Vienna Software Development Lab

Austria

.. . , . .. . . .

June 1990

33

werview

REXX Positioning

Supported Environments

REXX Compiler Product Components

REXX Compiler Benefits

erformance Improvements

Compiler Output

Compiler Usage Scenarios

Compiier tnvscation

Differences to the CMS Re1 6 Interpreter

C ~ a ~ ~ e ~ ~ ~ to Compile REXX . .

CWlS REXX Cornpiier Walter Pachl

__.. ... .

IBM .. .

6/90

34

REXX Positioning

r-- COMMAND PROCESSOR

yr System Commands Jrogram Logic I

r-- TEXT EDITOR

Program Logic

R E X X

- hogram Logic

'CASUAL' APPLICATION

System Command: A p p l i c a t i o n Command:

Program Logic

f APPLICATION PROTOTYPING

AND PROGRAMMTNG

aS + REXX has been implemented interpreters

Excellent debugging features

Very short and appealin! editlrun cycle

+ Interpreters - by nature - are slow !

.. .. . . . . . . . . .- .

. . . . . .

. . . . . . . . . . . . . ..

CMS REXX Compiler Walter Pachl

- IBM 6/90

35

~

Interpreter

I

Running REXX Program

Everything needs to be done at run-time

. . . . . . .

, . . .. ... . . . .. . . ..

.. . . ..

..... . . . . . . . " . .

. . . ... . . .


-. IBM 6190

36

How does the REXX Compiler work

Two step approach

+ Compile

Source

Program Compiler

o Program Analysis

o Address Resolution

Code Generation/ Opt imiza t ion

---- i Object

----, Program

Program

---- c Doeumen- t a t i o n

Compiler 's

Run-time

Support

I I

Running REXX Program

. . - . . - . . . .. . . . . ..

.. . . . . . . .


-. . IBM 6/90

37

Supported Environments

d CMS Re1 5

on VM/SP Re1 5 (5664-167) and VM/SP Rei 5 HPO (5664-173) . . .

. . .. .

and follow-on releases

d CMS Re1 5.5 (XA support)

on VM/XA SPI (5664-308)

and follow-on releases

+ "REXX Compiler SPE" to upgrade the operating system for support of compiled REXX

VMlSP Re1 5 APAR VM36990 Re1 6 APAR VM37841

VM/XA SP Re1 I APAR VM36991

. . . . -. . . . _.. .


___.-... .

IBM . . ._

6/90

38

REXX Compiler Product Components

+ Compile-time Part

Set of compiler phases performing ail compilation tasks

Written in C and compiled with SAA C1370 Compiler

Prerequisite when compiling:

IBM (3370 Library (5668-039)

+ Run-time Support

Common routines which are invoked from compiled REXX program

String Arithmetic, Conversions, Comparisons, Built-in Functions, Compound Variable Access, _..

0 Extremely time critical --> written in Assembler

Can be loaded into a DCSS

. . - . - . . - .. . .

CMS REXX Compiler IBM 6/90 Waiter Pachl

39

+ Compiled WEXX significantly faster than interpreted . . .

. . .. . .. . . .. . ..

. .. ,

+ "Pletg-Compatibility" with interpreted REXX programs

+ Language Equivalence with REXX Interpreter (SPI)

+ "Unreadable" REXX programs

+ Comprehensive Program Documentation

____.-.-- CMS REXX Compiler IBM 6/90 Walter Pachl 7

40

REXX Compiler Benefits

Comprehensive REXX program documentation

Source and Cross-Reference Listings Syntax check of whole program More accurate messages

0 Increase developer productivity

Improve program quality

"Unreadable" compiled REXX code

Provides for REXX program integrity

Provides for improved maintainai.d!t)

Protects REXX coded assets

CMS REXX Compiler IBM 6/90 Walter Pachl I7

41

REXX Compiler Benefits ...

+ Language Equivalence with the REXX Interpreter

NO compiler-specific language features !

0 Minimize migration effort

Almost all REXX programs run unchanged - except those with INTERPRET instructions

+ Support of SAA Procedures Language

Flagging of non-SAA items (optional)

Eases reuselmigration into other SA A environments


-- -. IBM

- 6/90

. . - . . . . . . . . . ~. . .. . . . . . . . . .

42

REXX Compiler Benefits ...

+ "Plug-Compatibility" with the REXX Interpreter

Identical external interfaces

Compiled REXX programs "transparently" replace interpreted ones

No restriction on their mutual invocation

+ Compiler, Run-time, compiled programs "exploit" XA

Run and use storage also above the Wry:ltbyte line

Make room for others below the line

.. .

. -

CMS REXX Compiler IBM 6/90 Walter Pachl

43

Significant Run-Time Performance improvements -_

Performance gains depend heavily on the program contents , .. .

, . . ... . .. . . .,- . . - . . , ~. .._ . .

Programs with a lot o f .. .

Arithmetic operations with default precision

Arithmetic operations w i t h other precision

Assignments

Changes to variables' values

Constants and simple variables

Reuse of compound v a r i a b l e s

Host commands

TINES faster than Interpreter

6 - 10+

4 - 25

6 - 10

4 - 6

4 - 6

2 - 4

1 - 2

- .-

Performance Category

VERY HIGH

VERY HIGH

VERY HIGH

H I G H

HIGH

W-CTUM

L o l d

- . . . . . . . .


-- - . IBM 6/90

44

Significant Run-Time Performance Improvements ...

Assumptions

An interpreted REXX program

uses 12 seconds virtual CPU runs 60 times a day for 30 days a month

Performance Category

I n t e r p r e t e d

MEDIUM

HIGH

VERY H I G H

Hours/month RUN

6

3 - 1.5 1.5 - 1.2 1.2 - 0 .6

Hourdmonth SAVED

3 - 4 .5

4.5 - 4 .8

4.8 - F . 6

+ With a performance improvement + CPU usage will reduce from + to just

CMS REXX Compiler IBM Walter Pachl

--

2 - 10 6 h/month 3 - 0.6 h/month

6/90

. . - .. . . . ... -.

- . . ..

. ... . . . . . . . .

45

Compiler Output

4 Program documentation

e Source listing Messages

* Cross-reference listing

4 Compiled REXX Program

Compiled Code

Executable /370 instructions Merspersed with invocations of run-time routines Reentrant and relocatable

Run-time control blocks

Symbol tree of all program items

4 Behaves EXACTLY like interpreted REXX

4 "immediately" executable

4 EXECLOADable

0 Can be loaded into an lnstallation DCSS

. . . . .

1 . . . . . . .

CMS REXX Compiler IBM 6/90 Walter Pachl * "

- _. .. - . _ _

46

Source Listing example

SAMPLE EXEC G 1

CliS REXX COMPILER 1.1.0 TIME: 11:35:02 DATE: 30 Hay 1989

IF DO SEL LINE C -+-1-+-2-+-3-+-4-+-5--

1 /* SAMPLE incorrect REXX program X/ 2 3 Parse Arg Tmp 4 V a l . = TRANSLATECtmp) 5 line.2 = LEFT(val.,2,'40')

I + + + E A G G A 0 0 7 7 1 S Invalid o r missing argumentcs) on built-in function

6 $ = EXTFUNC(line.2) 7 Call INTFUNC 2 8 Exit 9 10 INTFUNK: Procedure Expose x. i 11 Signal on NOVALUE NAME my-value

I +.++EAGGA00072S Label not found

12 1 13

Do x . i If x.i//2 /= 0 then

1 1 14 1 15 End

16 Return 17 18 my-valu: Say "NOVALUE raised at I " sigl 19 Return 20 /W end o f program SAMPLE

say "Odd: " x . i

I + + + E A G G A 0 0 6 5 4 S Unmatched "/%"

--__ . - CMS REXX Compiler IBM 6/90 Walter Pachl

47

Cross Reference List example

ITEM ATTRIBUTE L INE REFERENCES

-- LABELS, BUILT-IN FUNCTIONS, EXTERNAL RTNS - EXTFUNC INTFUNC INTFUNK LEFT MY-VALU MY-VALUE TRANSLATE

- CONSTANTS - 'NOVALUE r a i s e d at: ' 'Odd: ' 0 L 2 '40'

SIMPLE VARIABLES - $ I SIGL TMP

EX1 RTN 6 EX1 RTN 7 LABEL l O ( d )

LABEL 18(d) LABEL+++ ll(u)

BUILT-IN 5

BUILT-IN 4

L I T STR 18 L I T STR 14 NUMBER 13 CONST SYM 5 6 NUMBER 5 7 13 L I T STR 5

SIMP VAR 6 ( s ) SIMP VAR 10 12 13 14 SIMP VAR 18 SIMP VAR 3(s) 4

- STEMS AND COMPOUND VARIABLES - LINE. 2 VAL. x.1

COMP VAR 5 ( ~ ) L STEM COMP VAR 10 12 13 14

4(s) 5

CMS R E X X Compiler Walter Pachl

-- -

IBM 6/90

REXX Compiler Usage Scenarios

+ Scenario I: Existing REXX programs

0 Compile -- > CorrectIMigrate L

Compile and Run

0 Scenario 2: Newly developed REXX programs

0 Code * Syntax Check - with REXX Compiler 0 Debug - with REXX Interpreter

Compile - with REXX Compiler Run - with Run-time Support

Q REXX Compiler and Interpreter COMPLEMENT each other in program development

. - . . .~ .. .

-__. . . .__

CMS REXX Compiler IBM 6/90 Walter Pachl

49

Compiled REXX Programs will ...

+ Significantly save CPU time & reduce system load

Improve program quality & increase developer productivity

6 Provide for protection of REXX coded assets

+ Allow is keep applications in REXX

+ Save expensive rewrites to other HLL’s

+ Attract to write even more applications in REXX

CMS REXX Compiler IBM Walter Pachl

-~ .-

6/90

50

How is a Compiled REXX program invoked

Execute:

(EXEC) SAMPLE

CMS EXEC handler recognizes type of EXEC and --b f o r a REXX program, invokes the REXX I n t e r p r e t e r

Compile:

SAMPLE

EXEC

IA REXX Source

FLIP-FLOP (rename)

l-7 Compiler

SAMPLE

ICEXEC] A

I I

REXX Source Compiled REXX

SAMPLE P I A --+ 1-71 (EXEC) SAMPLE

Compiled REXX

CMS EXEC handler recognizes SAMPLE EXEC as "Compiled REXX" -+ invokes REXX Compiler's Run-time Support

---. . . CMS REXX Compiler IBM Walter Pachl

6/90

51

Compiler Invocation ialog - REXXR

Spec i fy a program. Then select a n a c t i o n .

CMS REXX Compiler L i c e n s e d M a t e r i a l s - Prope r ty o f IBM 5664-390 (Cl Copyr ight XBM Corp. 1989

A l l r i g h t s r e s e r v e d .

Program . . . . SAIIPLE-EXEC

2 Switch ( rename1 source and compiled exec

3 Run a c t i v e t s o u r c e l p r o g r a m

4 Edi t sou rce p rog ram 5 I n s p e c t c o m p i l e r l i s t i n g 6 P r i n t s o u r c e p r o g r a m 7 P r i n t c o m p i l e r l i s t i n g

8 S p e c i f y c o m p i l e r a p t i o n s

0

Argument s t r i n g : ___________

Command ===)

E n t e r F1-Help F t z F i l e l i s t F J = E x i t r l t = C a n c e l

- CMS REXX Compiler Walter Pachl

______.____. IBM 6/90

52

Compiler Invocation Dialog - REXXD ...

CMS REXX Compiler Options Specifications

Specify which output files you want, and their File-IDS

File identifiers Program name SAHPLE EXEC G1

V Compiler listing IY/N/P) = LISTING- =- Y Compiled EXEC 1Y/N I = Cr = N TEXT file

- lY/Nl = TEXT-- =-

Specify compiler messages to be issued I FLAG Minimum severity of messages to be shown II/W/EfS/T/Nl N TERM Display messages at the terminal (Y/NI N SAA SAA-compliance checking (Y/N)

specify contents of compiler listing Y SOURCE Include source listing IY/NI N XREF Include cross-reference listing (Y/NI 55 LC Number of lines per page 110-99 or, for no page headings, 0 or N )

Additional options N SL Support SOURCELINE built-in function rY/Nl N TH Support HI immediate command [Y/NI S NOC Error level to suppress compilation Ir/W/E/S)

Special compiler diagnostics N- DUHP Produce diagnostic output (0-2047. Y. o r N I

Command ===> __

Enter Fl=Help FZ=Filelist FJ=Exit F4=Save FSmRefrnsh Fh-Reset

- -.

-_ . - . . .

- . . . CMS REXX Compiler IBM 6/90 Walter Pachl

53

Differences to the CMS Ref 6 REXX Interpreter

+ INTERPRET Instruction not supported

Rarely used Difficult to implement Diagnostic message issued

0 Compiler does not generate code

So, try to avoid it - Interpret target'= 'expr -- >

Call SETVAR target,expr For a SETVAR sample Assembler program s e e ! User's Guide Reference SH19-8120

Restructure the program - isolate interpretative part, - make it a separate program, aw! - let the interpreter handle it

. ._. CMS REXX Compiler IBM 6/90 Walter Pachl

54

Differences to the CMS Re1 6 REXX Interpreter ...

+ TRACE Instruction and Built-in Function

Not supported in the interest of performance !

Does not change the semantics of a REXX program

No need to change REXX program

TRACE instruction - NOP instruction TRACE built-in function - "0" Interpreter default - "N"

Diagnosed with an informational message

+ PARSE VERSION version

REXXC370 3.46 30 Jun 1989

, ., , .

. . . . . . . . . . . .. . .

--- -. __ . . . . . . CMS REXX Compiler IBM 6/90 Walter Pachl

55

hy is REXX hard to compile

6 PROCEDURE is an executable instruction

Not a syntactic boundary Variables' life-time is dynamic - depends on calling sequence - "exposure" among procedures

e No denotation of the END of a procedure

Logical end is an executed RETURN

. . . . -

e Control can be transferred to e v ~ t - v v ~ ~ w ~ e even into "procedure" and loop bodies

0 Computed GOTO: SIGNAL VALUE


-.

IBM 6/90

56

Why is REXX hard to compile ...

4 No data types

0 All data is "character string"

Sometimes contents must be "numeric", "whole number", or "Boolean"

4 No declarations

Variables come and go (DROP)

. Can be shared with external programs (EXECCOMM)

Names of variables can be computed - tails of compound variables

Value of variables only limited by 4cmge Storage for values must be allocated dynamically

.. .

Arithmetic precision can be set dynamically NUMERIC DIGITS

~- _- CMS REXX Compiler IBM 6/90 Walter Pachl

Storage Requirements

4 MediumILarge REXX program of 4500 lines with 2500 instructions

Compiles - typically in a 4Mb virtual machine

(1Mb for (2370 Lib 4- REXX Compiler)

Storage on disk - about 50% more than source (2 to 4 times as large for small and little commented programs)

Run-time storage - about as much as Merpreted

+ 180 Kb for Run-time Support


--.. IBM

. . _- 6190

The Astonishment Factor

Kevin Kearney Mansfield Software Group, Inc. Charles Daney Quercus Systems June 11, 1990

59

“If a feature, acci entally misused, rently unpredictable results, a high astonishment factor

and is therefore rnndesira

e says that

re§SiQIl]; LINEOUT’ ,[expression];

LINEOUT LINEBUT( ,)

A = LIINEQUT A = LINEOUT(,)

CALL LINEOUT PNEOUT

* A = F(B)

CALL F(B)

A = F(B,C)

CALL F(B,C)

* LINEQUT(FILE,STRING)

* Literals vs. Variables

Strengths of

* good human factors for reading & writing

* character string orientation

* stem variables

* dynamic data typing

* automatic storage management

* few artificial limitations

. . ,. . .:.: . , . .. . .~

. .

Problems with the REXX Language

* scope of variables within program

* access to variables in external routines

* passing stems to subroutines

* returning stems from subroutines

* iterating over values of a stem variable

* array subscripting

* signaYexception handling

Characteristics of the Presentation Manager

* object-oriented architecture

* rich collection of user interface elements

* message-driven design

* multi-window, multi-tasking

* single, serialized user input 'queue

62

Challenges facing REXX

* object-orientation

* multi-tasking

* event-driven programming

* modeless application design

* interprocess communication & messaging

Object orientation may be found in:

* user interface

* operating system architecture

* applications & data files as objects

* programming languages

63

What is QOP?

* data abstraction

* encapsulation

* hierarchical classes & inheritance

* polymorphism

Benefits of QQP

* closer modeling of the real world

* easier code reuse & maintenance

* natural for user-interface programming

* more efficient (eliminate switches) . . . . .. .

64

. .

Keith Watts

. . . . .

65

In parallel with the bloom of language offerings, the specification of REXX has not stood still. IBM's SAA procedures language specification {$6) has been revised, and specifications for other new features have arisen unexpectedly eisewhere. Michael Cowlishaw has revised Version 3.50 capabilities specified in his book called "The REXX Language" ($21, with Version 4.00 capabilities {93}. The MVS implementation {57} includes features which remah to be documented in the SAA standard. Presently there are numerous differences in the SAA and Cowlishaw definitions, and VM and MVS implementations. Furthermore, non- IBM vendor offerings have many additional refinements.

The following summarizes enhancements which remain to be commonly accepted:

Feature Variable pool interface [VPII Double-byte character set [DBCSI Multiple segmented stacks Function packages Callable condition handlers Stream I/O model Permanent symbol pools Dropped special characters Bit string literals

Source SAA s AA MVS MVS SAA, Cowlishaw 4.00 Cowlishaw 3.50, 4.00 Cowlishaw 4.00 Cowlishaw 4.00 Cowlishaw 4.00

Perhaps IBM plans to revise the SAA specification, including all of those features, and to incorporate these consistently within its product offerings. Those of us outside l8M have no idea how many independent language specification sources are authentic.

VM origins IBM's VM system environment was the breeding ground for the REXX language &21. This environment has several unique features which make the VM REXX implementation {§8} significantly different.

The foremost difference is how I /Q is accomplished. Files are organized into fixed size records: there are no special I/O characters such as carriage return and newline. A simple file naming convention is used. I/O is canducted using the stack and the EXECI'J command, rather than ianguage statements. The only language statements which can perform I!Q are the SAY statement, and the stack accessing PULL, PUSH, and QUEUE statements. The Cowlisha:%' stream l / f 3 modei is lacking.

. . .. . .... . . . . .. . . .. . .

. . . . . .. .. . . . . . . .. .

. .. . . . . . ~ .~

REXX language 1/0 and environment challenges

66

There are ether significant differences. REX)( is embedded within the VM command interpreter, which is called CMS. As a consequence, it is already resident when a procedure request arrives. The stack is implicitly the source of input for any commands initiated by REXX. Thus, a REXX procedure can easily supervise the progress of commands it initiates. Furthermore, other command processors in the VM environment are modally accessible by name, making them eligible for connectivity with the AEDRESS statement. Console output can also be spooled to a file.

These features may not be easily mimicked by REXX implementations in other system environments. This, in combination with Cowlishaw I/O model usage, causes VM REXX users to go through a painful transition period when they encounter other REXX implementations. Procedures which perform I/Q may require considerable and confusing revision until these work properly in the new environment.

The Cowlishaw model for stream I/O is highly portable to a diversity of system environments. It can be readily implemented using standard ANSI C library services. The primary benefit of this model, is that all fiie accesses can be performed using RE% procedure statements. It provides a base for productivity in file manipulations from a human perspective, even though it may be taxing of machine resources. Unfortunately, the Cowlishaw f/O model has not been accepted by IBM, and is noticeably absent in the SAA language specification and all IBM implementations. These use the aforementioned SAY and stack access statements for simple I/O. All other I/O is performed in programs developed using other language processors.

Cowlishaw's I/O model is simple, and well defined. Still, several aspects require special attention.

Sequential files are either organized in fixed formats, or as an unorganized character sequence with records delimited by special end of line characters. Fixed formats predominate in IBM mainframe environments, whereas unstructured streams prevail in small and medium scale environments. Different methods are used to indicate the end of unstructured records. In MS-DQS@ environments a carriage- return, line-feed combination is usually used, but some developers consider either of these sufficient. unix8 uniformly treats a single line-feed character as a record divider.

Fixed length records are easily accessed, but are wasteful of space. As blanks consume a significant amount of file space, many methods of reducing these have been devised. Leading blanks are often replaced with tab characters. Whereas, trailing blanks are truncated during storage, and altered to pad characters during retrieval. Further space reduction can be achieved by run-length encoding, and data compression schemes.

All of these reduction techniques can significantly impact the portability of REXX procedures which perform l/O using Cowlishaw's model. For example, one system the author works with decided to replace tab characters with 10 spaces, by default. A low level override was required to disable this unsatisfactory behavior.

I/O involving binary data values Is also troublesome. System designers may have preempted any binary fila access intentions a REXX procedure developer harbors, with automatic actions performed whenever special values arrive, and no circumventions at hand. As a general rule, the character-at-a-time functions might be capable of binary I/O, but the line-at-a-time functions will rarely tolerate binary values and are highly unportable when used for this purpose.

. .

. . . - . . . . .

. . ..

REXX language i/B and environment challenges

67

Cowlishaw's I/O model must be restricted when relative I/O is performed with console devices. Though this can be used to effectively access a specific screen character position, users wilt not appreciate procedures which reference position 99,999.

Input from consoles is also a nuisance. The methods for acquiring console input in VM, MVS, PC, and unixB environments are highly unportable.

PC. unix@,, and other environinents enable files to be redirected as stzndard program input and output. Thess rsdiracted files can be bsneficiaiiy linked with the default input and output streams of Cowlishaw's I!O model. This leads to significant productivity gains, as a singie procedure can be reused for multiple purposes simply Sy varying external input and outplrt destinations.

New probfems are introduced when default streams are eligible for redirection. Binary character values often have special rneanings which cannot be altered. For example, in MS-DOS@ " 1 A " x [Ctrl-21 is an immediate end of file character, which causes all input and output on redirected streams to cease. Also, when defauit streams are redirected, the SAY and PULL statements may be unable to communicate directly with the terminal user; communicating with file destinations instead. This requires the introduction of console immediate stream destinations, so procedures can explicitly communicate with the user.

ary inter-pa Communicating between processes using a simple stream model would be beneficial, but there are aifficulties when binary data is interchanged with other processes. How is the end of a byte sequence indicated? IC an empty string is sent using LINEOUT, should any line ending characters be sent? When characters arrive, shocrld special character values be translated? Other problems arise when these inter- ~KXXSS cornnrunicatians proceed asynchronously, with optional exchanges of acknowledgements. Even worse, a HEY& procedure can sake when a synchronous response is expected from a partner which erroneousiy fails to respond, or if bath sides simultaneously enter receive waits.

The main problem for performing non-stream 1/O in REXX is specifications; there are none. It's 1990 and the REXX language is as capable at I/O as rnost 3rd generation languages achieved in the 1960's, and that presumes Cowlishaw's 1/0 model is defined. Whereas the SAA language specification and the VM and MVS implementations consider I/O barely necessary. Apparently these groups consider I/O the privileged domain of assembler and PU1, or perhaps that 1/8 accessing will be superceded entirely by single level storage.

The structuring of files for direct retrieval by keyed values is hardly a novelty. There are more intricacies than those involved in sequential I/O to be sure, particularly if alternate keys are permitted. Yet it is not much to ask for the definition of k e y i n ( 1 and keyout ( ) built-in functions in Cowlishaw's next I/O model. It would be 8 real win if keys could have variable offset and extent within records, and if non-unique keys were permitted as well.

Cowlishaw's introduction of permanent symbol pools in Version 4.00 is an initial foray into keyed file access. This provides an elegant disguise for keyed accessing of structured information, without entering the woods of access specifics. However, these permanent symbol pools can not be easily mapped to existing keyed files.

. . . . . .... . " - I .

REXX lat-igilage i/O and environment challenges

68

RMational databases SBL access of relational data is also well established. The conjunction of REXX with SQL is a small leap of the imagination. Compiled REXX and static SQL can appeal to those with high volume OLTP problems to solve. For those with more ad hoc difficulties, the amplification of SQL semantics with REXX symbolic transformation capabilities is clearly a breakthrough. Query clauses could be dynamically composed. Parameterized database procedures could be considered external REXX procedures. Perhaps REXX procedures and built-in functions could even be used within selection clauses as well. Consider,

create view eurusers as se l ec t firstname, lastname, phoneno, country( phoneno ) from users where assess( phoneno = "European"

This uses hypothetical REXX procedures called country and assess in situ. The country procedure transforms a phone number to a returned country name. The assess procedure analyzes values in the phoneno column to determine if these are European. It may take awhile for the Ansi and IS0 SQL committees to sanction this level of capability.

I1 screen interactions The majority of present application interfaces are full-screen, fill-in-the-blank menus in conjunction with function key actions. Current generation terminals are optimized for "field" modifications, which interact with host systems using block-at-a-time transfers, instead of byte streams. REXX, as defined by SAA and

permit conversational, line-at-a-time user interactions only. The Cowlishaw I/O functions permit relative screen operations, but these are conversational requests. Neither REXX definition provides for display field accesses and block mode transfers.

p-... -.v.rl,sha;iJ, :* is unsuitable for preparing competitive full-screen interactions. The SAY and PULL statements

Within SAA, full-screen interactions are the domain of the dialog manager, based on IBM's proprietary ISPF/PDF product offerings. Application portability was probably of lesser concern when this decision was reached.

The REXX language can be easily enhanced to enable the development of full screen applications using REXX procedures exclusively. Readers interested in studying this concept further can obtain separate literature from the author.

Of course, individuals in the northwestern US contend that full-screen interactions are a historical artifact, for the graphical user interface [GUI] age has arrived. SAA has an independent presentation manager component which addresses this issue. It is the author's conjecture that window-oriented applications could be developed in REXX exclusively, with the full range of capabilities, such as: windows, popups, pulldowns, scroll bars.

ixels The manipulation of graphical objects raises special challenges for REXX. A state-of-the-art graphical display can have 1024 x 1024 pixels, with each pixel having 232 possible colorations. This is a large hexadecimal literal string [4M bytes]. The alteration of bits can not be effectively accomplished with b i tand, b i tor , and bi t x o r . The modifying bit vector also has 4M bytes, and the bit-wise operation produces a 4M byte result. Instead, an array language object should be introduced. It should also be

..

. . . . . ..

REXX language I/O and environment challenges

69

possible to indirectly establish the array's origin * , so that pixel vaiues can be revised as direct memory accesses [DMA]. The need for array accesses are required by other problem domains as well.

Asynchronous I/O High performance applications require I/O operations to be overlapped with procedure execution. Cowlishaw's i/O functions are synchronous by design2. In Version 4.00 the open-ended stream() built-in function was introduced. This rnight accomodate asynchronous I/O. For example,

signal on notready

call lineout journal, "remember this, please" :* < - - an asynchronous write request * /

do whatever end

if strean( journal, c, complete ) <> "READY

say 'Whoa, journal record was not written" then

exit

/ * < - - assert write has completed * /

notready: say Whoa, an I/O error occurred, description:" description( 'D )

A language implemente; could enable the above lineout operation to proceed asynchronously, and assert that the operation completed successfully in the stream function call. If an error occurred during the i/O operation the notready condition can be signalled.

However, this is a significant departure from Cowlishaw's definitions. Procedures based on this capability would be highly unportable. For the "stread journal, c, complete 1" expression is an implementation- dependent extension, even though permitted by Cowlishaw's Version 4.00 specification.

ENVIRONMENT CHALLENGES The REXX language is specified with no environmental dependencies. Automagically procedure source statements are located, run-time arguments become accessible, and execution proceeds on machines with unexhaustible memory resources. Language implementers portably translate commands and I/O requests to native system services. R E M procedures can be developed in one system, and executed on another without source changes, or re-compilation. R E M procedure developers can be blithely unaware of underlying system ideosyncracies.

Operating system proliferation Every year computer corporations announce new hardware families, new operating systems, and major advancements of existing operating environments. Presently versions of REXX are available, or announced, for VM, MVS, OS/400, MS-DOS@, OS2, mix@), Tandem, and the Amiga. Pick any two, they are as similar as condors and kangaroos.

IThis should be done symbolically, without introducing address manipulation capabilities.. *Some implementations may be able to implicitly perform these synchronous requests asynchronously. For example, sequential file I/O in MVS is buffered externally by system I/O services.


70

Naming conventions The easiest way for system architects to establish a new niche is to invent a new naming convention. The following are a few illustrative examples:

filename filetype fiiemode highqual.midqualf.midqual2.lowqcral.ext C:\root\dirl\dirZ!\filename.ext $A$DUA1::~usrgroup.usrdept,userlfilename.ext;3 \node.$disk.subvol.fiiename

These names are used to locate external REYX procedures, and to identify paths for I/O operations. Not only must RE>O( users overcome the shock of learning a new convention when they begin to use a new environment, but they must also locate documents describing how partially qualified filenames are resolved. Often within several days they quickly retreat to their prior environment.

Environment symbol access Most system environments have a proprietary technique of externally parameterizing run-time logical symbols. There are three ways that these affect REXX procedures. First, if these symbols are to influence procedure behavior, there must be a way to acquire the external symbol’s value [getenv]. Second, REXX procedures are often expected to alter the value of these symbols for reference by subsequent system commands Iputenv]. Third, REXX procedures can also be expected to permanently revise or deactivate these symbols for upper level contexts [export , unexportl . None of these operations are identified in existing language specifications.

Other language interfacing Present language specifications enable REXX procedures to interact with programs written in other languages as follows:

1. Commands defined to the underlying system command interpreter 2. External procedure calls 3. Environments accessible with the ADDRESS statement 4. Symbol values and queued lines (SAA variable pool interface fvPlI) 5. External symbol pools (Cowlishaw Version 4.00p 6. Inter-process communications performed via Cowlishaw I/O capabilities [ l i n e o u t / l i n e i n ] 7. Function packages (MVS)

Other capabilities should be defined. Programs initiated from REXX should be able to invoke internal and external REXX procedures, as well as built-in functions, as though these were subroutines within the external module. Formal inter-process communication IIPCI and remote procedure call [RPCI mechafiisms should be specified.

Furthermore, the variable pool interface and function package definitions need to be improved so that these mechanisms can be used with languages other than Assembler.

BreakJinterrupt h a n d i n g [HALT]

A HALT signal causes an abnormal change in the flow of control, at best. The implementation of HALT handling is exposed to host mechanisms. When REXX relinquishes control to a system command, it may be necessary to disable the REXX break handler until the command completes. There are smali time

. .

. . . ..

. . . . . . . - .

, ,

~~

%ariables in external pools can be shared with parallel external procedures.

REXX language l/O and environment challenges

71

windows before and after the command executes where the us8r can hit the BREAK key, and no handler is active. This causes abrupt termination of the REXX environment, without the procedure’s HALT handler receiving control; and REXX cleanup routines may be side-stepped. If the REXX abnormal termination cleanup routine is performed, a new condition should be introduced called EXIT. Unlike the HALT condition handler, which can resume procedure execution, the EXIT handler should perform cleanup operations only. It should not be possible to reactivate the EXIT condition after it has been raised. The EXIT handler could also be used for normal procedure exits.

ory exhaustion REXX procedures can sometimes exhaust available memory capacity. It should be possible for execution to proceed after this event occurs. Phis could be piggy-backed onto the HALT signal handler, or a new MEMORY signal could be introduced. The MEMORY condition handler should drop or carefully restore the values of exposed symbols, and invoke various other cleanup services. Afterwards, the MEMORY condition handier should E X I T the external procedure level which encountered the event. It should not be possible to reactivate the MEMORY condition after it has been raised; for the external procedure level which encountered the condition.

.. . .

As was mentioned earlier, the VM environment has a console spooling feature. This feature is generally lacking, and sorely missed, in other environments. Implementers can accomodate this deficiency by providing special journalling of REXX console activity, during procedure execution. However, there are numerous additional upper level environment features which require emulation. These require consistent resolution by an overall REXX system architecture.


72

EP4TFPBI LEVEL SYSTEM ARCHITECTURE lBM’s SAA architecture was a historic milestone in the history of computing. It provides multiple interrelated specifications for all components of customer application systems. REXX was granted preferred status as the procedures language within this architecture. This has turned out to be a dadble-edged sword for the REXX language overall. Within environments which have the full complement of SAA components, REXX benefits from its interplay with these other components. However, in environments lacking these components REXX language capabilities are noticeably deficient, as has been described earlier in this paper.

What we as a REXX user community require is a minimal, entry-level REXX systems architecture. This architecture should specify components exterior to REXX facilities proper, and explicitly identify the inter- component exchange interfaces. The following diagram is a preliminary sketch of the components within this architecture. The formalization of this architecture would enable REXX system implementers to significantly advance the portability of REXX procedures. Procedure developers and users would be able to use an integrated set of components, rather than spending hours and weeks learning how to use proprietary environment components.

Command I n t e r p r e t e r

Suppor t Tools U t i l i t i e s

In te rac t i ve He lp

REXX 1 Funct iona 1 Packages

I I . .. 1 . . .

Procedure Ca 1 1s [async h] Commands


73

TRY LEVEL SYSTEM ARCHITECTURE LBM’s SA4 architecture was a historic milestone in the history of computing. It provides multiple interrelated specifications for all components of customer application systems. REXX was granted preferred status as the procedures language within this architecture. This has turned out to be a double-edged sword for the REXX language overall. Within environments which have the full complement of SAA components, REXX benefits from its interplay with these other components. However, in environments lacking these components REXX language capabilities are noticeably deficient, as has been described earlier in this paper.

What we as a REXX user community require is a minimal, entry-level REXX systems architecture. This architecture should specify components exterior to REXX facilities proper, and explicitly identify the inter- component exchange interfaces. The following diagram is a preliminary sketch of the components within this architecture. The formalization of this architecture would enable REXX system implementers to significantly advance the portability of REXX procedures. Procedure developers and users would be able to use an integrated set of components, rather than spending hours and weeks learning how to use proprietary environment components.

r 1 t I

Support Tools U t i l i t i e s

Interactive Help

Command Interpreter

L J L I

k-I REXX

I I

I Functional -l -1 Packages 1

Spawned Commands

Remote Procedure

Ca 11 s Casynchl

I Stream I/O I


73

CONCLUSION The advancement of the REXX language faces numerous I/O and environment challenges. It will be best for the REXX community at large if a single standard comes forth with robust specifications for the range of issues addressed within this paper. If this standard does not materialize, then language implementers are forced to develop independent solutions. This causes REXX users to lose countless hours revising procedures as they port them from one environment to another. Let us be optimistic and hope that a single, robust language standard emerges.

BIBLIOGRAPHY

[ l ] Announcement of SANPL, Announcement Letter 287-088, IBM Corporation.

[2] Cowlishaw, M.F., "The design of the REXX Language", IBM Svstems Journal, 23, N0.4, p.326. IBM Corporation (1984).

[31 Cowlishaw, Michael F., The REXX Lanauaae: A Practical Amroach to Proaramminq, Prentice-Hall, Englewood Cliffs, NJ (1985).

[41 Cowlishaw, Michael F., The REXX Lanauaae: A Practical Approach to Proarammina. SECOND EDITION, Prentice-Hall, Englewood Cliffs, NJ (1990).

[51 Hoernes, G.E., "REXX on TSO/E", IBM Svstems Journal, 28, No.2, p.274, IBM Corporation (1989).

[61 Svstems Ar>plication Architecture: Common Proarammins Interface Procedures Lanauaae Reference, IBM Corporation, Publication SC26-4358.

171 TSO Extensions Version 2, REXX Reference, IBM Corporation, Publication SC28-1883.

[81 VM/SP System Product Intermeter Reference, IBM Corporation, Publication SC24-5329.


74

Presenter, not Originator

Dr. Brian Marks

Chairman, SAA Procedures Language ARB IBM UK Laboratories Ltd

Systems Technology Sheridan House

Winchester

11th June 1990

75

Object-Ori nted REXX

Simon C. Nash

IBM UK Laboratories Ltd Systems Technology

Sheridan House Winchester

8th March I990

76

This section consists of foils originally presented at SHARE 74 in Anaheim. They describe an experimental language integrating object oriented principles with REXX. There is currently no plan for an IBM product in this area. Permission is hereby granted to SLAC to reproduce these foils in the Rexx Symposium Proceedings.

77

Background

* Research project

Systems Technology (Hursley Laboratory)

Language description

* Running prototype

SCN 78

Motivation

Bring the power of OOP to REXX

Bring the usability of REXX to OOP

Extend REXX usage

- windowing, multi-media, etc.

Build on existing REXX base

- fully upward compatible

REXX Summary

* Designed for usability

st Natural typing (everything a string)

-cr Comprehensive string handling and numerics

* Procedural logic: IF, DO, SELECT, variables, assignment

~r Program structure: functions, subroutines

* External interfaces: functions, subroutines, commands

* Dynamic semantics (e.g., scope, type)

_____ ~ ___- __ - -

SCN 8 Mar 90 80

OOP Summary

-k de and data as unit

* ta encapsulation, message passing

-34 lymorphism

sses, inheritance

-A- C0d.e reuse

na bles concurrency

OOP Languages

Simula

rt Smalltalk

* c++

Objective C

~r Object Pascal

Eiffel

* CLOS

* etc.

_____

SCN 8 Mar 90

82

Design Goals

* REXX compatibility

Everything an object

* Integrate concurrency

* Maintain usability

Primitive (e.g., string, number) or programmed

A Contain encapsulated data

+- Respond to messages by executing methods

Automatically reclaimed

SCN 8 Mar 90 84

Messages

All REXX operators

A New syntax: receiver-message(arguments)

Receiver defaults to environment if omitted

* Can appear as term or clause

* Sender waits for reply

SCN 8 Mar 90 85

Methods

A Define an object’s behaviour

-k Contain the code of an object

~t Established at creation or defined dyna mica I ly

* Activated when a message received

* May produce a result object

______ ___ -

SCN 8 Mar 90

86

I

Variables

* Object variables persist for object’s lifetime

* Method variables exist during a method activation

Object variables exposed on METHOD instruction

Example: method expose a b. c

SCN 8 Mar 90 87

ing Exam

new - r e c t = myrectangl e-rotate(ang1 e) /* send " r o t a t e " message ( w i t h "angle" argument)

t o 'lmyrectangI e" */ J /* "new - rec t" i s ass igned the resu l t ob jec t */

myfi 1 e-open ( I read ' ) /* 9'resu1t1t i s assigned the resul t object

or dropped i f no r e s u l t */ my f i 1 e-cl ose /* t h i s message has no arguments * /

l e f t - s ide = myrectangle-origin-x /* send a s e r i e s of messages * /

rect-do-set lef t (0)-setr ight(90)-setbot tom(Z5)-set top(75) /* send a s e r i e s o f messages t o " r e c t " */

SCN

88

8 Mar 90

A REXX Example

jack = 3 /* c rea t e a number object with the value 3 */ /* ' ' jack" i s ass igned this 113" object */

j i l l = jack + 4 /* c rea t e a number object w i t h the value 4 */ /* send I t+ ' ' message ( w i t h "4" argument) t o l l jack" */ /* the "3" objec t re turns the sum " 7 " * / /'* I 1 j i 1 1 I 1 is ass igned the 117" object */

say j i l l /* send "1 ineout" message ( w i t h " j i 1 1 If argument)

argument t o defaul t o u t p u t stream object */ /* " s t r i n g " message i s sent t o I l j i l 1 If */ /* " 7 " returns i t s s t r i n g r e p r e s e n t a t i o n */ /* the character 7 i s displayed */

SCN 89

~~ ~

8 Mar 90

Classes

Many objects with the same behaviour (methods)

Define shared behaviour in a class object

The class object creates new instances

SCN 8 Mar 90 90

Inheritance

Bank account

Current Savings

l-----l Repayment Endowment Immediate 90 days

access not ice

Class hierarchy

Subclass acquires behaviour of superclass and modifies it

* Avoids duplication of code

* Programming by differences

.A Subclass sends an “inherit” message to more than one uperclass

ethod conflicts resolved by search order

-~h Methods of the subclass can address any method of any immediate superclass

A No conflict of same-named object variables because of scope rules

SCN 8 Mar 90 92

Object-Based Concurrency

+ Objects are the units of concurrency

* All objects can execute concurrently

* Most objects awaiting message or reply

REPLY instruction

* START message

93

Concurrency Usage (1) __ ._ __ _ _ - -.

* Sequential:

Sender Rece iver

* Early reply (implicit concurrency):

Sender Rece iver

(wai t i ng) 0

(some work) REPLY

( c o n t i n u e ) (more work) RETURN

SCN 8 Mar 90 94

Concurrency Usage (2)

* Start (explicit concurrency):

Sender Proxy Receiver

<-- - - reply - - - - -

SCN 8 Mar 90 95

k Simple: objects execute concurrent each object is sequential

: concurrency within an object, with guarded methods

A Mixture of simple and advanced objects

Simple objects are easier to write

Advanced objects enable more function, better efficiency

SCN 8 Mar 90 96

Example w Stack

/* i n i t : i n i t i a l i z e s t a c k t o empty */ method expose s . s i z e s i z e = 0 L O b- - n i l /* i n case an empty stack popped */

i push: add an item t o the t o p o f the stack */ method expose s . si ze parse a rg item

s , s i z e = item s1.7e =: -. s i z e + 1

J'" pop: re turn the t o p stack item and remove i t */ method expose s . s i z e rep'2 y s . s i ze i f s i z e > 0 then do /* i f s t ack non-empty */

d r o p s . s i z e s i z e = s i z e - 1

Ci-jd

8 Mar 90 97

Example - Stack Usage

/* Define the stack class. The objects init - code, push - code, pop - code and s i z e - code contain t h e methods shown on the previous foil. */

stack = -class-new( 'Stack') stack-define('INIT',init code) stack-define( ' P U S H ' ,push code) stack-define( 'FOP' ,pop code) stack"define( 'SIZE',size code)

- -

- -

/* Create a stack object and use it. When an object i s created, its "init" method (if it has one) i s run automatical 'ly. */

mystack = stack-new mystack-'push( 'John Smith') mystack"push('Bil1 Brown') say mystack-pop /* displays "Bill Brown" */

SCN 8 Mar 90 98

a t

i n i t: method expose balance overdraft - 1 imi t balance = 0 overdraf t - 1 imi t = 0

overdraf t : method expose overdraft - l i m i t parse arg overdraft - l i m i t

deb i t : method expose balance overdraft - 1 i m i t parse arg payee, amount i f balance-amount >= -overdraf t - l i m i t then d o

payee-credi t (amount) balance = bal ance-amount end

e l s e payee-inform('1nsufficient funds ' )

return balance

c r e d i t : method expose balance parse a r g amount balance = bal ance+amount re turn bal ance

SCN 8 Mar 90 99

/* Define the account c l a s s , * /

account = -cl ass-new( 'Bank account I ) account-define('init',init - code) account-def i ne ( ' overdraft ' ,overdraft code) account-define( 'debit ' ,deb; t code) account-define('credit',credit - code)

- -

/* Create some account objects and use them. * /

a = account-new /* create new account * / I

b = account-new /* create new account *I c = account-new /* create new account */ a-credit(1000.00) /* a has 1000.00 *I a-debit(by400.00) /* a has 600.00, b has 400.00 * / b-overdraft(500.00) /* b can overdraw up to 500.00 */ b-debit(~~700.00) /* b has -300.00, c has 700.00 */

SCN 8 Mar 90 100

IBM SAA REXX FOR OS/2

Rick McGuire

101

THE REXX PROCEDURES LANGUAGE WORKSHOP AGENDA

e INVOKING REXX CREATING SUBCOMMAND HANDLERS USING REXX EXITS CREATING REXX FUNCTIONS CREATING A MACROSPACE MANIPULATING REXX VARIABLES

6 return, 8 relstr) :

program MACRO. CMD * arg input

REXX PROGRAM return a

NOTES:

NOTES:

NOTES:

102

\ RXSTRiNGS

RXSTRINGS ARE USED IN REXX APk TO PASS ARBITRARY LENGTH, CONTENT INSENSITIVE CHARACTER STRINGS

I typedel struct {

ULONG slrlength: I * iength Of string * / PCH strptr; / e far pointer !Q strlno /

} RXSTRING: I

I

I

I

RXSTRING MACROS SOME HANDY MACROS FOR WORKING WITH RXSTRlNGs

RXNULLSTRING Tesl II an RXSTRIWG e11slc -7 RXZEROLENSTRING Tell I1 an RXSTRING IC 01 zcto lcnglh

RXVALlDSTRlNC Test II an RXSTRING hac I nan- zero lenplh

RXSTRLEN Refurn or set the lenglh 01 an AXSTRING

RXSTRPTR Retufn or set I h t polntrr of an RXSTRING

MIKERXSTRING Set (he Dointer ane lenulh 01 an RXSTRING

USING IN- STORAGE PROGRAMS REXX PROGRAMS MAY ALSO BE EXECUTED DIRECTLY FROM STORAGE

I rc = R E X X S A A ( argc,argv. c PROGRAM

" M A C R O . C M O " , Instore. NULL. I .!

NOTES:

NOTES:

103

c

L

7-. ! THE REXX PROCEDURES LANGUAGE WORKSHOP AGENDA

INVOKING REXX CREATING SUBCOMMAND HANDLERS USING REXX EXlTS CREATING REXX FUNCTIONS CREATING A MAGROSPACE MANIPULATING REXX VARIABLES

I I

CREATING SUBCOMMAND HANDLERS rc = R E X X S A A ( argc. argv, 1

" SPLIT. ED" , NULL, NULL, RXCOltiMAND, NULL, & return, & retstr) ;

APPLICATION

',I

' LOCATt \sltinq\'

REXX hlACAO return a

Operatng Sysfernb' --_______

CREATING A SUBCOMMAND HANDLER SUBCOMMANO HANDLERS ARE DECLARED WITH

THE RxSUECOMREGlSTER FUNCTION

v handler. scbname = I' MyEdilor" ; handler. scbdll-name = ') ; handler. scbdll-proc = '' '' . handler. scbaddr = ( PFN) 'MyEditorhandler;

rc = RxSubcomRegister( & handler) ;

NOTES:

NOTES:

NOTES: -

., . . . ..

CREATING SUBCOMMAND HANDLERS

THE CALL TO REXXSAA SPECIFIES THE NAME OF THE ENVIRONMENT TO BE USE0 FOR COMMANDS

SPLIT. ED' , NULL, " MyEditor' , RXCOMMAND, NULL, 6 relurn, 6 retstr) ;

CREATING SUBCOMMAND HANDLERS COMMANDS ISSUE0 FROM THE REXX MACRO

ARE PASSED AS RXSTRlNGs TO THE SUBCOMMAND HANDLER

' LOCATE \string\'

I return a

CREATING SUBCOMMAND HANDLERS THE SUBCOMMAND HANDLER PROCESSES THE

SUBCOMMAND

SHORT APIENTRY MyEditorhandler ( PRXSTRING cmd, PUSHORT errorflag.

PRXSTRING ReturnCode) ;

/ handle editor rubcommands /

II ( command= = LOCATE) {

t

.__ - Operattng Systernn-

NOTES:

NOTES:

10.5

r 1 CREATING SUBCOMMAND HANDLERS THEN PASSES BACK A RETURN COOE AND

ERROR INDICATOR

/ Set the return code and error flag / rnemcpy ( RXSTRPTR ( ReturnCode) ,

RXSTRLEN ( ReturnCode) = strlen ( " 1' ) ; errorflag = RXSUBCOM-ERROR;

return 0;

" 1" , s!rlen ( " 1" ) ) ;


INVOKING REXX CREATING SUBCOMMAND HANDLERS USING REXX EXITS CREATING REXX FUNCTIONS CREATING A MACROSPACE MANIPULATING REXX VARIABLES

NOTES:

NOTES:

NOTES:

106

i

f L

U S I N G REXX EXITS REXX PROVIDES A NUMBER OF EXITS TO ALLOW AN

APPLICATION TO SERVE AS A * HOST’

RXFHC Process external functions

~ ~~

RXTCTRC InlaiiraUon pmcesrlnp RXiHl Test external trace

RXTER I Terminalion processinn 1

r 1 U S I N G REXX EXITS

EXIT HANDLERS ARE SPECIFIED WHEN REXXSAA IS INVOKED

exits[Oj. exiIa[O]. exils[l].

sysexil-name = SIOHANDLER’ ;

mysexit-code = RXENDLST; rysexit-code = RXSIO;

re = REXXSAA [ argc, argv, * MACRO. CMD” , NULL, NULL, RXCOMMAND, exits. 6 return, & retstr) ;

I

U S I N G REXX EXITS ..

EXiT HANDLERS MUST ALSO BE REGISTERED BEFORE USE

handier. tcbname = ’ SIOHANDLER’ ; handler. rcbdll-name = ; handier. rcbdll-proc = - handler. rcbaddr = ( PFN)’SIDHandler;

rc = RxExltReplsIer ( 6 handler) ;

NOTES:

NOTES: --

NOTES:

USING REXX EXITS AN EXIT IS INVOKED WHENEVER THE PROGRAM REOUIRES

THAT SPECIFIC SERVICE

EXIT HANDLER nhln 0;

NOperatmg SystemQ' . .

r


INVOKING REXX CREATING SUBCOMMAND HANDLERS USING REXX EXITS

CREATING A MACROSPACE MANIPULATING REXX VARIABLES

1 CREATING REXX FUNCTIONS

CREATING REXX FUNCTIONS REXX EXTERNAL FUNCTIONS MUST BE REGISTERED

BEFORE USE

From C ( ' CHANGE , * CHNGOLL" ,

From REXX IC = RxFuncAdd ( * CHANGE", , " CHNGOLL" , " CHANGE' ) ;

NOTES: ._____

___~

NOTES:

NOTES:

108

CREATING REXX FUNCTIONS WHEN A FUNCTION IS INVOKED, THE ARGUMENTS ARE

PASSED AS AN ARRAY OF RXSTRINGS

I I

Opratrng SystemR-

CREATING REXX FUNCTIONS THE FUNCTION RESULT IS RETURNED AS AN RXSTRING


INVOKING REXX CREATING SUBCOMMAND HANDLERS USING REXX EXITS CREATING REXX FUNCTIONS CREATING A MACROSPACE MAN~PULATING REXX VARIABLES

J

NOTES:

NOTES:

NOTES:

109

CREATING MACRO SPACES FREQUENTLY USE0 REXX FUNCTIONS MAY BE LOADED

INTO A MACRO SPACE FOR QUICKER EXECUTION

I 1 RxMacroChange ( I' CHANGE" , " CHANGE. MAC" ,

RXMACRO-SEARCH-BEFORE) ; RxMacroChange ( " SPLIT" , " SPLIT. MAC" ,

RXMACRO-SEARCH-BEFORE) ; -

RxMacroSave ( 2, FunctionLisl, " EOITMACS. S A V ) ;

CREATING MACRO SPACES MACRO SPACE PROGRAMS CAN BE INVOKE0 AS

SUBROUTINES AND FUNCTIONS

REXX PROGRAM

MACRO SPACE


INVOKING REXX CREATING SUBCOMMAND HANDLERS USING REXX EXITS CREATING REXX FUNCTIONS CREATING A MACROSPACE r MANIPULATING REXX VARIABLES

NOTES:

NOTES:

110

. ..

MANIPULATING REXX VARIABLES PROGRAMS INVOKE0 FROM REXX MAY MANIPULATE

THE VARIABLES OF THE CALLING PROGRAM

C PROGRAM 1

MANIPULATING REXX VARIABLES FUNCTIONS AVAILABLE VIA RXVAR

Felch . privale' variables

Scan Ihe entire variable pool

Operatrng System/Z'

NOTES:

NOTES:

111

REXX FOR UNlX

Neil Milstead

112

U N I -REXX OVERVIEW

AN SAA COMPLIANT IMPLEMENTATION OF THE REXX LANGUAGE FOR ALL U N I X PLATFORMS.

WRITTEN I N C, ONE SOURCE VERSION PRODUCES MANY SEPARATE BINARY EXECUTABLES.

INPUT/OUTPUT CHARACTER STREAMS AND THE EXTERNAL DATA Q U E U E A R E IMPLEMENTED ACCORDING TO THE MODEL DEFINED BY COWLISHAW I N "THE REXX LANGUAGE".

ADDITIONAL FUNCTIONS IMPLEMENT SOME CRITICAL U N I X C L I B R A R Y CALLS, TO ALLOW FULLER EXPLOITATION OF THE UNIX ENVIRONMENT-

PROGRAMMING INTERFACES ALLOW IMBEDDING UNI-REXX INTO C LANGAUGE APPLICATION SYSTEMS AS A MACRO FACILITY-

UNI-REXX HAS ALREADY GENERATED INTEREST I N U N I X NEWS FORUMS.

113

U N I -REXX PLATFORMS

PLATFORM DOS SUN-3 SUN-4 SUN 3861 SCO X E N I X 2 . 3 SCO U N I X 3 . 2 I S C 3861x HP/UX(9000) RS/6000

UN I COS ENCORE SILICON G R . NEXT RT APOLLO x500 A I XI370 APOLLO 10000 ULTRIX(3100 9 CONVEX I NTERGRAF STARDENT UTS

RELEASE NUMBER COMPLETE

COMPLETE

COMPLETE

COMPLETE

COMPLETE

COMPLETE

COMPLETE

COMPLETE

COMPLETE

COMPLETE

COMPLETE

COMPLETE

COMPLETE

COMPLETE

COMPLETE

I N PROGRESS

I N PROGRESS

I N PROGRESS

I N PROGRESS

I N PROGRESS

I N PROGRESS

I N PROGRESS

114

UNI-REXX P R O G R A M EXECUTION

LACKING THE HOOKS F O R EXECUTION THAT A R E BUILT-IN TO VM/CMSJ UNI-REXX RELIES O N U N I X FACILITIES TO R U N A UNI-REXX PROGRAM. THE INTERPRETER MAY BE R U N EXPLICITLY OR IMPLICITLY DEPENDING ON ENVIRONMENT-

EXPLICIT:

RXX PROGRAM- REX I N T E R P R E T A UNI-REXX PROGRAM. RXC PROGRAM. REX COMPILE A UNI-REXX PROGRAM- RXI PROGRAM R U N A COMPILED UNI-REXX PROGRAM.

IMPLICIT: F O R BSD-BASED UNIX SYSTEMSJ IMPLICIT EXECUTION IS SUPPORTEDJ BY STARTING A UNI-REXX PROGRAM WITH A SPECIAL DIRECTIVE.

#!/USR/LOCAL/BIN/RXX

THE PROGRAM MUST BE MARKED EXECUTABLE WITH THE CHMOD COMMAND: CHMOD +X PROGRAM. REX

115

UNI-REXX AND UNIX COMMANDS

THERE ARE THREE SEPARATE MECHANISMS F O R ISSUING UNIX COMMANDS FROM WITHIN A UNI-REXX PROGRAM-

IMBEDDING A COMMAND CLAUSE DIRECTLY IN THE UNI-REXX PROGRAM. CLAUSES WHICH ARE NOT UNI-REXX INSTRUCTIONS A R E PASSED TO THE DEFAULT COMMAND ENVIRONMENT. THE OUTPUT FROM THE COMMAND WILL BE DIRECTED TO STDOUT-

SPECIFYING A U N I X COMMAND AS THE OPERAND OF THE A~~~~~~ UNIX INSTRUCTION. COMMAND OUTPUT ALSO G O E S TO STBOUT.

USE THE P O P E N O FUNCTION, WITH A UNIX COMMAND OPERAND. THE COMMAND OUTPUT WHICH WOULD HAVE GONE TO STDOUT IS PLACED ON THE EXTERNAL DATA QUEUE-

UNI-REXX ADDITIONAL FUNCTIONS

ADDITIONAL BUILT-IN FUNCTIONS ARE PATTERNED AFTER STANDARD U N I X C LIBRARY FUNCTIONS-

C H D I R ~ T R I N G )

C U S E R I D O

GETCWD()

G E T E N V ~ T R I N G )

POPEN (COMMAND)

CHANGE THE CURRENT WORKING DIRECTORY .

RETURN LOGGED ON USERID.

RETURN C U R R E N T WORKING DIRECTORY.

RETURN ENVIRONMENT VARIABLE VALUE. (E. G. PATH, TERM)

EXECUTE A U N I X COMMAND, PLACE I T S STANDARD OUTPUT I N THE EXTERNAL DATA QUEUE-

CHANGE THE VALUE OF AN ENVIRONMENT VARIABLE-

117 -

UNI-REXX INPUT AND OUTPUT

THE UNI-REXX I/O MODEL IS BASED ON "THE REXX LANGUAGE" BY COWLISHAW. THIS MODEL CORRESPONDS CLOSELY TO THE UNIX FILE SYSTEM, UNLIKE THE RECORD ORIENTED I / o OF VM/CMS.

r /o CHARACTER STREAMS

CHARACTER I/O FUNCTIONS SUPPORT THE UNIX STDIN, STDOUT OR ARBITRARY UNIX F ILES.

CHARIN FUNCTION CHAROUT FUNCTION CHARS FUNCTION

EXTERNAL DATA QUEUE LACKING THE "PROGRAM STACK" OF VM/CMS, THE EXTERNAL DATA QUEUE 1s SIMULATED BY UNI-REXX.

PARSE PULL INSTRUCTION PULL INSTRUCTION PUSH INSTRUCTION QUEUE INSTRUCTION

UNI-REXX vs SHELL PROGRAM EXAMPLE

COMPARE THE STRUCTURE, SEMANTICS AND READABILITY OF A SHELL-AWK PROGRAM TO THAT OF A UNI-REXX PROGRAM

A. Here's a shell wrapper-awk p m g m the1 m a r s end dlspleys enfries trWn the Us1 ol names and telephone numbers:

2 1

3 4 5 6 7 8 9

10 11 12 13 14 15 16 17 18 ~~

20 19

22 21

23 24 25

27 26

O ( # ) pdir. sh A simple phone directory searcher # Author: W d t Novinger, January 1989

USAGE="Usage: $0 pattern" # set -x # Unooment for deb-ng

PHOK6ZIST=SHOKE/.phonedir # Phone list database # case $# in ,

0) echo $USAGE >&2 # if no arguments, display usege exit I ;; # and exit

*) ;; - eaac # ENTRY='grep n$*n SPROKELIST' ' # search for pattern(6) if [ -z "$ENTRYm 1; then

echo "Sorry, don't know S * ' s number(s)" exit 2

I1

echo "$ENTRYn I # send content of ENTRY to ark

if (length($2) != 0) I # if there Is a home number awk -P" " ' I # tab character in double quote8

if (length(S3) != 0) # and a work number

else # no work number printf n%-20a %(B) %e(W)\nm, S1, SI 53

. printf m%-20p %s(A)\n", $1, $2 I

28 else . # no home number , 29 30 I

printf m%-20s %s(W)\nm, $1, $3

UNIXWORLD JUNE ID00

/* * A simple phone directory searcher * Author: Ed Spire, June 1990 * */ parse arg pat traceopt If traceopt c- *It1 then trace value traceopt /* turn on trace if req. */ phonelist = "phonedir1I

then say "usage: p pattern traceopt" /* if no arguement, exit */ else do /* if arguement, proceed */ if pat = 11 $1

call popen llgrepll pat phonelist /* que matching lines */ if queued()=O then say ##sorry, no match on" pat /* no matching lines, exit */ else do while queued()>O /* process each match */

parse pull name ll09llx work t80911x hfme If home <> )*Is then home = home*t ( H ) /* add phone */ if work <> MII then work = workI1( W ) /* number identifiers */ say left(name,20)1 /work1 ]home /* and display line */ end

end

119

UNI-REXX PROGRAMMING INTERFACES

THE PROGRAMMING INTERFACES ARE DESIGNED TO ALLOW IMBEDDING UNI-REXX INTO A C LANGUAGE APPLICATION SYSTEM AS A MACRO PROCESSOR.

IRXJCL RUN A UNI-REXX PROGRAM FROM A C PROGRAM.

IRXSUBCM ESTABLISH A NEW HOST COMMAND ENVIRONMENT TO ACCEPT COMMANDS FROM A UNI-REXX PROGRAM-

IRXSTK ACCESS THE EXTERNAL DATA QUEUE FROM A C PROGRAM.

IRXEXCOM ACCESS UNI-REXX VARIABLES FROM A C PROGRAM.

THESE INTERFACES ARE MODELLED AFTER THOSE IN MVS-TSO/E REXX.

120

UNI -REXX TREE PROGRAM EXAMPLE

THIS PROGRAM DISPLAYS A UNIX DIRECTORY T R E E S T R U C T U R E .

/* TREE displays the directory structure that exists below the

* current directory. * * Get the directory argument */

parse arg Directory . if Directory = 'In then Directory = " . " /* command line */ call RecursiveDirectoryDisplay Directory, 0 exit

* Display the directory tree for the directory passed on the

/* * Routine to display the subdirectories for the directory specified

RecursiveDirectoryDisp1ay:procedure */

/* * Get the directory to scan and the amount to indent arguments */

parse arg Directory, Indent /* */ * List the directory on the external data queue.

call popen '1s -1' Directory /* * If there are any entries, skip the first non-file entry

*/ if queued() = 0 then return pull *

/* begir. with Id'. * Scan the external data queue for directory entries. They

If a directory is found, save in the directory table. */

DirectoryCount = 0 do while queued() <> 0 parse pull Permissions +1 . . . . . . . Filename . if Permissions = Id' then do DirectoryCount = DirectoryCount + 1 DirectoryTable.DirectoryCount = Filename

end end /* * Display each directory indented to this level with a

* Then list the directory's contents by calling preceeding ' I+---->'I.

RecursiveDirectoryDisplay.

do DirectoryIndex = 1 to DirectoryCount */ say copies(' I , Indent)'+---->'DirectoryTable.DirectoryIndex call RecursiveDirectoryDisplay

Directory'/'DirectoryTable.DirectoryIndex, Inde nt + 6 end DirectoryIndex return

121

UNI-REXX TREE PROGRAM EXAMPLE OUTPUT

TREE PRODUCED T H I S O U T P U T F R O M A L I V E S Y S T E M :

+---- >customer.mail +--...- >di s

+---- >apollo +---- >uniREM +---->uniXEDIT

+---- >uniREXX +--..- >uniXEDIT

+-- - - >uniREXX +---- >uniXEDIT

+---- >uniREXX +---- >uniXEDIT

+---->uniREXX +---- >uniXEDIT



+---->uniREXX +---- >uniXEDIT

+---->msdos

+---- >rs6000

+---->rt

+---- >sco

+---->sun3

+-e- - >sun386

+---... > sun4

+-- - - >samestuff

UNI-REXX POSSIBLE EXTENSIONS

A NUMBER OF ENHANCEMENTS AND EXTENSIONS ARE PLANNED O R PROPOSED FOR UNI -REXX.

NUMERIC DIGITS 99

REXX VERSION 4 FEATURES: STREAM, NOTREADYJ CALL O N J BINARY CONSTANTS.

REXX SHELL

PROGRAMMING I N T E R F A C E S : FUNCTION PACKAGES VARIABLE POOL I N T E R F A C E EXTERNAL FUNCTIONS

OPTION MIXEDCASE OPTION DBCS OPTION ANSI

, . .. .

(a retros i ’!, > i

Robert P. Q’Hxx

Lotus Development corpora tic^^

55 Cambridge Parkwc?..(

Cambridge MA 021 42

61 7-693-527-5

[email protected]

REXX Symposium

124

FC begins work on REXX

VMlSP 3 released

Modern Programming Using REXX published

The REXX Language published

5 Personal REXX for MS-DOS from Mansfield

Software released

87 REXX designated IBM SAA Procedures Language

89 REXX removed from OS/2 Standard Edition

IBM OS2 1.2 Extended Edition released

June 9,1990 REXX Symposium

125

Robert P. O’Hara

1991 BASIC desianated Microsoft universal macro U

language

1992 Bill Gates rep

ticket

llaces Dan Quay 'le on Republican

1994 BASIC designated IBM SAA supported language

1995 Instruction in BASIC required in all US schools

June 7,1990 REXX Symposium Robert P. O'Hara

126

Stage set for explosive

BUT.. .

June 7,1990 Robert P. O’Hara

IBM doesn’t understand programming languages

Gave up after PUI?

Pigeonhole mentality

(applications/systems/procedures)

No HLL access to OS services

REXX not an application language

Benign neglect would have been OK

BUT...


126

Robert P. O’Hara

Microsoft understands programming languages

* Pushed BASIC with religious fervor

e Saw REXX as a direct competitor

Realized there is war among languages

e Developed a strategic plan to win the war

e Lobbied application vendors to use BASIC

AND.. .


129

Robert P. O’Hara

IBM acquiesced

REXX pulled from OS/2 SE

REXX thoroughly hidden in OS/2 EE

No REXX interfaces to most OS/2 services (DDE,

HLLAP I, APC.. .)

Bid not lobby application developers to use REXX

Did not port REXX to non-SAA platforms (DOS,

Windows, AIX)

The problem was not lack of technology

The problem was lack of vision

June 7,1990 REXX Symposium Robert P. O'Hara

130

Realize you are not alon

Realize you can’t ignore the problem

Lobby ~ Q W for what you’ll need in the future

Expand established IBM forums (SHARE, GUIDE)

June 7,1990 REXX Symposium Robert P. O’Hara

131

SLAC USE OF REXX ON VM AND VMS

TonyJohnson

132

SLAC's use of REXX on VM and VMS.

Tony Johnson 1 lth June 1990

o What is SLAC? Why is REXX useful to SLAC. Interactive Data Analysis with

REXX 0 REXX for VAX/VMS

3 Some other REXX applications.

133

Mission:

Site sod Lacstion:

The Accelerator:

Major Facilities:

Milestans:

Management:

St&: Operatin8 Budget:

munications:

SLAC is dedicated to experimental and theoretical research in elemen- tary particle physics and to the development of new techniques in particle acceleration and detection. Located on 426 ILcrw of Stanford University property, the iabora- tory is three miles west of the main University campus. The main entrance is on Sand Hill W, just east of Interstate 280. Length - Two miles Beam Energy (electrons) - 5Q GeV Beam Energy (positrons) - 50 GeV Three magnetic spectrometers SPEAR, an &GeV calliding-beam storage ring, 80 meters in diameter PEP, a 32-GeV colliding-beam storage ring, 800 meters in diameter SLC, the 100-GeV electron-positron linear coKder

1962 1966 1968 1972 1974 1976 1976 I980 1983 1987 1989

Contract execution a d start of accelerator construction Construction completed and research begins First evidence discovered for quarks SPEAR operations begin Discovery of psi particles Discovery of charm quark and tau lepton Nobel Prize shared by SLAC's Burton Rjchter for SPEAR research PEP operations begin Construction of SLC begins Construction completed and SLC commissioning begins SLC operations begin

Director - Burton Richter Deputy Director - Sidney Drell Associate Director - John Rees Associate Director, Technid Division - Kaye Lathrop Associate Director, Research Division - Charles Prescott Associate Director, Business &wices Division - Eugene Rickansrud

1350 $113,000,000 (FY1990) Mailing address: P.0. Box 4349, Stanford, CA 94309 Shipping address: 2575 Sand Hill b a d , Menlo Park, CA 94025 Telephone: 415/926-3300 - FTS 462-3300 Telefacsixnile: 4151323-3626, verification OR 415/926-3344

SLAC is a National Facility Operated by Stanford University

for the US Department of Energy

I

.. ...

SEI

.i

I

i 3b75 X -

VM imdementation of IDA

User .-

REXX -+ CMS/CP

Command Interpreter

Data Manager (JAZELLE)

Control Program

Physics Analysis

Histogram

Package Display Package

Detector

Programming Language (IDAL)

Graphics System

136

I 'soJ3euI

How is REXX interfaced?

SUBGOM(environment,routine.rc) -

en-vironment e

VMREXX(op t io~ ,~ymbol ,va l~e ) Allows called program to examine and mo REXX variables.

K A G ~ M ( f i l e § p e ~ ~ ~ n v i ~ ~ m e ~ t , r c ~ . Start interpretati of specified file with default environment.

A

138

I

6E I

/ * An IDA exec t o make generating tables easy. Just type

MAKETAB <bank> <elementl> <element2> ... E x a m p l e :

MAKETAB MCHITS TRACKTYP POINTS.VOLNAME POINTS.DOMNAME or MAKETAB MCHITS TRACKTYP POINTSIVOLNAME DOMNAME} - -- T o get t h e f u l l power of JAZELLEs t abu la t e f a c i l i t y you must use the IDA commands TABLE and TABULATE.

. .

A u t h o r : T o n y Johnson Sect ion: Ida 12/12/88

V e r s i o n 2 . 0 0 T o n y A d d e d { } syntax

* / Arg B a n k C o l u m n s

Crea te= ' /C=ATE ' Prefix=' ' Do w h i l e C o l u m n s / = "

Parse V a r C o l u m n s Column C o l u m n s

Open = Index (Co lumn, ' { ' ) C l o s e - Index (Co lumn, ' 1' )

If Open>O T h e n D o Parse V a r Column Pre' { 'Column P r e f i x = Pre f ix ' { ' P r e E n d

If C l o s e > O T h e n Parse V a r C o l u m n C o l u m n ' I ' P r e

' TRBLE' C r e a t e B a n k B a n k I I T r a n s l a t e (Pref ix , ' .' , ' { ' ) ' ' C o l u m n If R c / = O T h e n E x i t Rc

If C l o s e > O T h e n Do I = L e n g t h ( P r e f i x ) t o 1 by -1 If Subs t r (Pref ix , I, 1) /=' { ' T h e n Iterate Pref ixPSubstr ( P r e f i x , 1'1-1) Leave E n d

C r e a t e = ' ' E n d

'TABULATE' B a n k 'DEFAULT' B a n k If R c / = O T h e n E x i t R c ' TABULATE' Bank 'USING' Bank Exit Rc

140

Can REXX be interfaced to VMS more completely?

. -

0 Need to be able to Address VMS

Need to be able to tell if VMS command was successfully executed.

to write output to stack. a VMS commands need to be able

o Rexx needs to get information about VMS environment.

142

I

!

I I XX3

Completion codes from Address VMS

After any command is addressed to VMS-_three variables will be assigned return codes:

RC = -3 (DCL-W-IVVERB) = 0 (Success) = 16 (Failure)

$STATUS = complete VMS completion code $SEVERITY = VMS Severity code

0 = error 1 = success 2 = warning 3 = information 4 = fatal

Also when terminating REXX exec,

EXIT <status>

144

!

m 3 L

P

.. e n

146

..

I xw;L<-+ I

II €Id=<-+ I

II ??Id3W<-+

I 3AIH3W<-+ I

II aowm<-+

I ?IW<-+

I LISP&<-+ i

II

II =3113zvr<-+

I P?3<-+ 1

II QaI<-+

I (INIJXZ<-+ I

II S&W<-+ I

II 3KJdLSyJ<-+

1 sMm-mnac-+

I vaI<-+ I

II M33U<-+

I X3Q~X3VI8<-+

I €;L3Naa<-+

I NIXIdW<-+

I wxazzvr z II~SY<-+

t 3AIH3MI<-+

NOI&'tl&NM30a<-+ I

--

I [XNOLI : o.crsn$xsra

/* Rexx * / Curlevel=l Offsets" 1 n Call Makedir

Do Forever

If Q.curlevel>O Then Do

Q.curlevel=Q.Curlevel-1 Pull . ' 3 ' Actdir' . DIR' Say Offset Say Offset'->'Actdir

'SET DEFAULT [ . 'Actdir' 1 ' Curlevel = Curlevel + 1 Off set=Of f set" I " Call Makedir End

Else If Curlevel>l Then Do ' SET DEFAULT [ -1 ' Curlevel=Curlevel-1 Offset = Substr(Offset,l,Length(offset)-4) End

Else Exit End

Makedir: procedure Expose 9. Curlevel OldQ-Queued ( ) 'DEFINE SYSSOUTPUT NL:' 'DEFINE SYSSERROR NL:' 'DIR/OUT-LIFO/NOHEAD/NOTRAIL *.DIR' 'DEASSXGN SYSSOUTPUT' 'DEASSIGN SYSSERROR' Q. Curlevel=Queued ( ) -0ldQ

Return

148

i

6F1

..

T h i s is t h e main HELP f i l e f o r IDA. HELP may be obtained on any I D A command listed b e l o w . Some of t h e commands l isted h o w e v e r are on ly a c t u a l l y available if t h e relevant module has been loaded w i t h I D A . For example t h e DSP commands listed b e l o w are only available i f t h e DISPLAY package has been loaded.

For an i n t r o d u c t i o n t o IDA and a general d i scuss ion of K E f r i s s u e s select INTRODUCTION from the i t e m s b e l o w .

A d d i t i o n a l I n f o r m a t i o n A v a i l a b l e :

$RETURN ADD CALL DEF ELSEIF

BXNXT HSLICE IDALREXX J L I S T NEXTif PLOT PROJECT mxx SPAWN TIMELIM WRITE

Belp

$SIGNAL ALPHA CLEAR DEL END I F HCAT HIST H SPACE I F JMOD OPEN POINTER READ RUN STATUS TOPDRAW

- - func t ion @-command ATTACH B a n k f u n c t i o n s BANKLOOP BETX CLOSE CMDPEOC CMS CONTINUE DEBUG D I R DO/ENDdo DOPT DSP ELSE ENDWHILE E X I T i f EXTERNAL F I T GET GO

b i t f u n c t i o n s

HCLR HCOMB HDEL HDIV HGE T HMULT HOP TN HOUT HREAD HSET HSTAT HSUB HWRITE I n t r o d u c t i o n IMMEDIATE INDEX INPROC I N T E R P r e t RON LABEL MAKETAB MESSAGE NAN0 OPENTAPE P l o t d e f i n i t i o n PAUSE PEEK

REBIN RECTYPE REMOVE RETURN REWIND SCAT SEGLIST SET SETPTR SIGNAL SYNONYM TABLE TABLELOOP TYPE UNFIT VAR WHILE WIPE

POKE PROC- PROC PROCESSOR

TABULATE TD

PF l rSe lec t I t e m P F 3 - P r e v i o u s Menu P F 4 = Q u i t P F 7 = B a c k w a r d P F 8 = F o r w a r d

PSU5t>

Macro-read 2 Files

150

I

This HELP describes the SLD shell program, IDA, as well as the commands for several of the facilities built into it by default.

The major sections are :

Overview Discussion of the logical organization sf IDA XDAL commands

Jazelle-commands Summary of Jazelle commands. 10 commands Input-output commands Wandypak-commands Hiatogram manipulation commands User I interface Description of the user interface and assoicated

Fit-commands Summary of the c o m n d s t o fit plo t s

- Summary of IDAT, commands and the Jazelle interface to IDAL

commmands

Additional Information Available:

Overview ICDAT, - commands Jazelle-commands Handypak-commands IO - commands User-Interface Fit - commands

PFlmSelect Item PF3mPrevious Menu PFJxQuit PF7-Backward PFB=Forward

=arm=>

Macro-read 2 Files

151

I i’

DEVELOPING FULLSCREEN REXX APPLICATIONS

Larry Oppenheim

152

W h a t i s XMENU?

I A set o f tools making it easy t o wrap f u l l screen menus around REXX appl icat ions.

I The XHENU product has three main pieces:

XMEDIT

A menu pa in ter and menu e d i t o r .

MENUEXEC

The i n t e r f a c e between menus and REXX.

Subroutines

A se t o f subroutines which allow non-REXX languages to handle your existing menus.

154

XMEDIT

8 Bas ic Def in i t ions :

Menus created by XMEDIT c o n s i s t o f p r o t e c t e d and u n p r o t e c t e d f i e l d s t h a t have var ious h i g h l i g h t i n g o p t i o n s .

Fields are assigned names t o a l l o w an a p p l i c a t i o n t o read o r wr i te the screen.

I Advantages:

The programmer doesn’ t need t o know t h e l o c a t i o n s o f t he da ta on the screen.

. You can easi l y make changes t o menus w i thou t touching the support ing REXX code.

It should be obvious that XMENU i s g r e a t f o r r a p i d p ro to typ ing .

I How t o Create a Menu:

Enter the XMEDIT command (it i s to menus what XEDIT i s t o o r d i n a r y f l l e s ) .

Q u i c k l y t y p e t h e t e x t p o r t i o n ( f i e l d c a p t i o n s , e t c . ) on the screen.

. T r a n s f e r t o e d i t mode to re f i ne t he rough ske tch .

Re tu rn t o i npu t mode t o d e f i n e y o u r f i e l d s and assign them a t t r i b u t e s .

Set i n i t i a l c u r s o r p o s i t i o n .

Name t h e f i e l d s w h i c h will rece ive o r d isp lay da ta .

T rans fe r t o d i sp lay mode t o g e t an immediate WYSIWYG view o f your new menu.

155

MENUEXEC

I Allows REXX t o move data back and f o r t h between the EXEC and the screen.

I Control of the menu i s p rov ided i n two ways by MENUEXEC:

MENUEXEC command opt ions

MENUEXEC subcommands

I MENUEXEC i s bes t i nvoked by us ing the CMS SUBCOM i n t e r f a c e . Here i s an example:

/* REXX a p p l i c a t i o n */ MENUEXEC menuname (SUBCMDS ADDRESS MENUCMDS "ERRMSG MESSAGE" "FIELDMSG NAME 'Th is i s the NAME help msg'" "FIELDPFK PFOl" "REQUIRE NAME ALPHA" n e x t subcommand MENUEND /* Terminates SUBCOM i n t e r f a c e */ ADDRESS COMMAND

Notes on the above example:

The SUBCMDS o p t i o n i n i t i a t e s t h e SUBCOM i n t e r f a c e .

The MENUCMDS environment expects val id MENUEXEC subcommands.

MENUEND terminates the SUBCOM i n t e r f a c e .

ERRMSG, FIELDMSG, FIELDPFK and REQUIRE a l l work together :

- ERRMSG d e s c r i b e s t h e f i e l d i n which er ror messages are placed

- FIELDMSG associates a help o r error message w i t h t h e named f i e l d . The message i s t r i g g e r e d by one o f t he f o l l ow ing even ts :

A REQUIRE c o n d i t i o n f a i l s ( i n v a l i d d a t a was entered i n t h e f i e l d ) , o r ... The FIELDPFK (PF 1 ) was pressed wi th the cursor on t h a t f ie7d.

156

Y

i= Q) U

L

> Q) U

cn I

0

0

- yl

Od

L

u) m c 3 L

rn

0

0

0

0

159

L

Q)

> .I

+ Q)

0

> ..I m Q)

Q)

Q)

0

0

160

*I I

L

a

Q

ii e

L

w

+

a

0 c

v a 0 c

a a

v) 3

.- cn L: a

I-

.. E is rc a

L

.I

I

L

a Q e

.- W e

E

a

a

0

CI

c

a 0

w

rc

c

0

.I

+.r

c

;i=

a

a

is E“ rn c a 5 .I

v)

161

a t

U

W

4

'CI

C

Q

cn I 0

~ a

>

0

0

0

0

0

162

. '.

W

0 0

A z

W

t n

L

e

0

0

0

I- K 0

cn 0

w 3

CI 2 3.

163

0

W

x W

W

J

6 K

e V

164

h

0

0

0

0

c\1 e 0

0

e 0

165

L

0

166

.I

8 a v) a

167

.Y

0

.I

c,

8 P

Q)

m

A

Q

LI e 2E

c

Q)

.. f

0

m

.. 0

m

3

0 c

.- v) .I

CI

0

LI Q

) m

..

0

0

. . . .

. , , . . , .

...

170

REXX IN THREE

DIFFERENT ENVIRONMENTS

April 261h, 1990

Mason Kelsey

172

Table of Contents MOVING TOWARDS SAA ................................................ 1

STORAGE ............................................................ 3

CLEARlXG SCREENS ................................................... 5

ADDRESSIXG Ehl'1RON"S .......................................... 7

FUNCTIOXS NOT AVAILABLE ON ALL SYSTERlS ........................... 9

QUEUES (STACKS) .................................................... 1 1

REXXIIO ............................................................ 32

HOW CAS WE JSCREASE REXX PORTABILITY? ........................... 55

Table of Contents

173

THANKS SpeciaI thanks are due to Charlie Fowler, AVP of Systems Training, Fireman’s Fund Insurance Company, for access to the resources necessary to write this paper.

Table of Contents 174

MOVING TOWARDS SAA

MOVING TOWARDS SAA 175

ARE WE ACHIEVING SAA? 1. REXX has been SAA Product since 1987 2. Supplants CMDs (BATS) on OS12 3. Can co-exist with OS/2 Command Files in OS/2 4. IBM OS/2 REXX uses CMD.EXE, just like Command Files 5. Supplants CLIST and JCL (Subset?) on MVS 6 . Runs in TSO Space or Non-TSO Space (Batch) on MVS 7. Can co-exist with CLIST in MVS 8. Supplants EXEC and EXEC2 on VM 9. Can co-exist with EXEC and EXEC2 in VM 10. Learning curve much lower than C 11. Compilers or Run-Time Modules Available

1.

2.

3.

4.

5.

HOWEVER Incompatibility of file state determination, clearing screen, and other general utility type commands in 3 systems.

Not REXX's problem, but REXX portability suffers because of it

Over 38 commonly used REXX functions do not work in all 3 environments

Stacks are handled differently in all 3 environments

MVS and OS/2 have multiple stack capabilities; VM does not MVS and VM have multiple buffer capabilities; OS12 does not OS/2 stacks can be shared with other tasks; MVS and VM can not

FILE I/O is handled differently in all 3 environments

MVS EXECIO (except for DISKRU) is a subset of VM EXEC10 No FINIS command in MVS Environment (operand of EXECIO) Issues over Record I/O vs. Stream I/O clouds portability to OS/2 No EXEC10 command in OS/2 versions; instead has 7 functions

Display capture is different in all three environments

MVS uses OUTTRAP() VM uses (STACK, (FIFO, or (LIFO operands on CPKMS commands OS/2 uses redirection to QUEUE: device

176 MOVISG TOWARDS SAA

STORAGE

STORAGE 177

STORAGE

VM 0 VM REXX Execs are stored with a file type of EXEC.

0 EXEC2 EXECs also have a file type of EXEC. This is the reason why a comment is required in the first line; to tell the two languages apart.

MVS 0 Store in EXEC PDS allocated under SYSEXEC.

0 MVS REXX Execs may also be stored in a CLIST PDS allocated under SYSPROC. They may also be stored in an EXEC PDS allocated under SYSPROC or SYSEXEC.

0 If allocated under SYSPROC, EXEC must have “REXX” in first line comment; otherwise the CLIST interpreter is used during implicit execution.

0 The dataset name can be anything, but UserlD.EXEC or UserlD.REXX.EXEC are highly recommended.

During implicit execution, EXEC libraries are not currently found if allocated under SYSEXEC ddname unless the following command is executed:

EXECUTJL SEARCHDD(YES)

which causes the SYSEXEC files to be inserted in the search path ahead of SYSPROC files. When REXX Execs outnumber CLIST, sometime in the future, this search order can be made automatic.

os12 * Store 16”s O S 2 REXX Execs with an extension of CMD.

Command Language files also have an extension of CMD; but EXECs begin with a comment.

0 Both CTC’s OS/2 REXX2 Source Code Execs and Mansfield’s 0 9 2 REXX Execs can be stored with any extension, if explicitly executed with that extension. If explicitly executed without an extension, the Execs must have a REX extension. This is the design recommended by C ishaw. %

STORAGE 178

CLEARING SCREENS

CLEARING SCREENS 179

CLEARING SCREENS

1. MVS:

UTYTCLER TSO Command

Aliases: K and CLEAR

Syntax: CLEAR [BEEPINOBEEP] [SAVEINOSAVE] [IMMEDIATE]

9 Defaults: NOBEEP NOSAVE

SAVE causes a paging condition under VTAM so the current screen can be seen; NOSAVE inhibits the paging condition

IMMEDIATE clears the screen immediately under VTAM. If not coded the screen is not cleared until the next TPUT (from 110 commands). Should be coded with any Dialog Application.

Not an IBM TSO command

2. OSl2:

CLS Internal 0 9 2 Command

No Operands

3. VM:

VMFCLEAR or CLRSCRN CMS Commands

Both clear the screen immediately when screen in RUNNING status.

VMFCLEAR has no operands and no help.

Although VMFCLEAR has always been on the CMS/SP S-disk, it is not an IBM command. And there is no HELP file, and no documentation.

CLRSCRN MORE causes a MORE ... message to appear. When the user presses CLEAR or PA2, then the screen is cleared.

CLRSCRN ? displays the help for CLRSCRN.

CLEARING SCREENS 180

ADDRESSING ENVIRONMENTS

181 ADDRESSING ENMROKMENTS

1.

2.

3.

ADDRESSING ENVIRONMENTS

MVS Environments:

Non-TSO/E address space MVS (default), LINK, and ATTACH TSOlE address space (TSOlE) TSO (default), MVS, LINK, and ATTACH TSOlE address space (ISPF) TSO (default), MVS, LINK, ATTACH,

ISPEXEC, and ISREDIT

OS/2 Environments:

CMD (default) Default OS/2 Command Environment SPF2 (CTC Only) PDF Look alike by CTC ISPCIR DM/DTL Environment

VM Environments:

CMS

XEDIT COMMAND

no operand ISPEXEC ISREDIT MVS Environs

normal command processing; Exec, load module, CMS, or CP command will go through normal search. Default Environment. commands received by XEDIT commands issued are handled via SVC 202; put 'EXEC' in front of execs and 'CP' in front of CP commands (null); same as COMMAND; this is not the same as no operand switch back to previous environment ISPF Environment ISPF Edit Macro Environment if MVS is running under CP, any MVS environment is available

Use the ADDRESS command to direct a host command to other than the default host environment.

ADDRESSING ENVIROKMENTS 182

FUNCTIONS NOT AVAILABLE ON ALL SYSTEMS

183 FUNCTIONS NOT AVAILABLE ON ALL SYSTEMS

*

* * *

* *

* * *

*

* *

*

* * * * *

1. 2.

3.

BEEP(frequency,duration) IBM OS12 B2X(binarystring) IBM and CTC OS12 CHARIN([name][,start][,length]) IBM and CTC OS12 CHAROUT([name][,start][,length]) IBM and CTC OS12 CHARS([name]) IBM and CTC OS12 CMSFLAG(f1ag) CMS CtATE([option(julian)]) MVS and VM D~TE([opt ion( l ) ] ) IBM and CTC OS12 DlAG[rc]( .....) CMS DIRECTORY([newdir]) IBM OS12 ENDLOCAL() IBM and CTC OS12 EXTERNALS() MVS, VM, and CTC OS/2 FILESPEC(option,filespec) IBM OS12 FIND(phrase,word) MVS, VM, and CTC OS12 JUSTIFY(string,length,[pad]) MVS, VM, and CTC OS/2 LINEIN() IBM and CTC OS12 LINEOUT() IBM and CTC OS12 LINES() IBM and CTC OS12 LINESIZE() MVS, VM, and CTC OS12 LISTDSI() MVS

MSG(”0N”I”OFF”) MVS OUTTRAP(”var.”,rnax-lines,”CONCAT”j“NONCONCAT”) MVS PROMPT() MVS RXFUNCADD(name,module,procedure) IBM OS12 RXFUNCDROP(narne) IBM 0 9 2 RXFUNCQUERY(narne) IBM OS12 RXQUEUE(control,[queuenarne]) IBM and CTC OS/2 SETLOCAL() IBM and CTC OS/2 SHARE() CTC OS12 STORAGE([addr,length,data]) MVS and VM STREAM() IBM and CTC OS12 SYSDSNO MVS SYSVARO MVS USERID() MVS, VM, and CTC OS12 VALUE(ext-var,new-vaI,’OS2ENVIRONMENT’) IBM OS/2 VALUE(ext-var,new-vaI,’CMD’) CTC OS/2 X2BO CTC OS12

LOADFUNCLIBO CTC OS1.2

FIND() and JUSTIFY() are available on all systems, except IBM OS/2. EXTERNAL() is available on all systems, except IBM OS/2, but it is only useful on CMS, which has a terminal buffer. USERID() is available on all systems, except IBM OS/2, but it is only useful on MVS and VM.

FUNCTlOSS NOT AVAILABLE ON ALL SYSTEMS 184

QUEUES (STACKS)

QUEUES (STACKS)

. , .

185

DATA QUEUE OR PROGRAM STACK

Program Stack in some systems is called an "External Data Queue", "Data Queue" or, simply, "Queue". MVS manuals also refer to it as the "Data Stack". In REXX, Queue and Stack are synonyms.

Used to receive data from a command or to pass data to one

In MVS and OS/2, additional stacks can be created although only one is active. In MVS, use the NEWSTACK, DELSTACK, and QSTACK commands, and the QUEUED() function. In OS/2, use the RXQUEUEO function.

LIFO (PUSH) Next record to be read

from the stack

FIFO (QUEUE) . I record n 1 Program Stack

QUEUES (STACKS) 186

UFFERS A buffer is a subdivision of a stack. This capability is available on MVS and VM only. It is controlled with the MAKEBUF, DROPBUF, QBUF, and QELEM commands, and the QUEUED() function. The command, DESBUF, is available on VM only.

(PULL)

1 I

LIFO (PUSH) Next record Buffer 2; Record1 Buffer 2; Record 2 to be read

from the stack

FIFO (QUEUE) Buffer 2; Record n Buffer 1; Record 1 Buffer 1; Record 2 Buffer 1; Record 3

Buffer 0; No Records Program Stack

-

187 QUEUES (STACKS)

MAKEBUF For MVS and VM only.

The current data queue starts with buffer 0. Executing MAKEBUF divides the current data queue into a two buffers, only one active.

The return code is equal to the stack number. MAKEBUF returns a non- zero RC if the command works properly.

Do not use SIGNAL ON ERROR while executing MAKEBUF.

How many buffers with contents can be created depends upon your Re- gion. When you exceed storage, you may get a REXX error message: ”Failure in System Service”.

If a buffer is created in a higher or lower EXEC, a function, or subroutine, it is still active upon return to the other level. Data left in the stack is executed at exit from highest level EXEC, unless you do a DESBUF or DROPBUF. The message ”UNKNOWN COMMAND’’ will appear if a line in the buffer is not a valid command.

QBUF returns the number of the currently active buffer.

QELEM returns the number of records of the currently active buffer.

QUEUED() returns the number of records of all buffers in the currently active data stack.

If a PULL command exhausts the contents of an active buffer in a stack, the next time the PULL command is executed, it does.an automatic DROPBUF and gets the top record of the next buffer, i f the next buffer is not empty. If it is not empty, no DROPBUF occurs.

’ STACK 1

MAKEBUF RC = 1

STACK 1

188 QUEUE§ (STACKS)

DROPBUF AND DESBUF SYNTAX: DROPBUF [N] (MVS and VM Only)

ACTION: Will release one or more buffers DROPBUF will eliminate a buffer and the contents of it if any remain.

N, when specified, will eliminate the buffer number specified. If a buffer exists that has a higher number, it will also be eliminated.

SYNTAX: DESBUF (VM Only)

ACTION: Deletes the contents of the console and program stacks

189 QUEUES (STACKS)

, -,. .

MAKEBUF AN ROPBUF. VM EXAMPLE

Example from VM/CMS EXEC: LINKTO address command ’MAKEBUF’ address command ’SET CMSTYPE HT’ address command ’EXEC10 * DISKR‘ mdisk-name ’$DISKID$’ fm ’0 ( FINIS’ saverc = rc address command ’SET CMSNPE RT’ IF saverc \ = 0

then do . .

IF \quiet then say ’Error’ saverc ’reading’ mdisk-name,

address command ‘DROPBUF’ exit end

’$DISKID$ file’

PARSE PULL mdisk description PARSE PULL lib ders PARSE VAR LIB-DEFS global . ’START=’ pgm-name . address command ’DROPBUF’ etc.

The excessive ”ADDRESS COMMAND” prefix was done for performance. How does this improve performance?

QUEUES (STACKS) 190

SENTRIES UEUEDO

SYNTAX: QUEUED() (MVS and VM Only)

ACTION: Returns the number of lines in all the buffers of the active stack

The return code will. be 0 if there is no data in the current stack

SYNTAX: SENTRIES (VM Only)

ACTION: Returns the number of lines in all the buffers of the active stack to RC

The return code will be 0 if there is no data in the current stack

Example / * SENTRIES VM EXEC “I MAKEBUF SAVERC = RC ’LIST ONE EXEC C (STACK’ SENTRIES LIMIT = RC ‘DO I = 1 TO LIMIT PULL LINES.1 END I

DROPBUF SAVERC EXIT

QUEUES (STACKS)

/* QUEUED MVS EXEC */ MAKEBUF SAVERC = RC X = OUTTRAP(”H0LD.”) ’LISTDS EXEC’ LIMIT = QUEUED()

DO I = 1 TO LIMIT PULL HOLD.1 END I

DROPBUF SAVERC EXIT

191

UFFERS EXAMPLE

/* REXX EXEC TO DEMO MAKEBUF, QELEM, QBUF, DROPBUF, and QUEUEDO */ /*trace a*/

/*"QBUF"*/ /* What would happen i f t h e s e */ /*queue 'Line @ of Buffer' RC*/ /* 2 l i n e s were not commented?*/

"MAKEBUF" say 'Number of buffers created is ' RC queue Line 1 of Buffer ' RC queue ' Line 2 of Buffer' RC c a l l s u b r u t l say

do unt i l queued() = 0 say 'Number of l i n e s i n most cur ren t s tack

say 'Number of l i n e s i n most r ecen t ly made

say 'Number of cur ren t buf fer is ' RC pu l l va r say var s aq!

"QELEM"

"QBUF"

end

is ' queued( )

buffer is' RC

say 'Number of l i n e s i n most cur ren t stack i s ' queued() "QELEM" say 'Number of l i n e s i n most r ecen t ly made buf fer i s ' RC "QBUF" say 'Number of current buffer is' RC "DROPBUF" say 'Now a buffer was dropped' "QBUF" say 'Number of current buffer is ' RC say e x i t

subrut 1 : "MAKEBUF" say 'Number of buffers created is' RC push ' Line A of Buffer ' RC push 'Line B of Buffer ' RC push 'Line C of Buffer ' RC r e tu rn

QUEUES (STACKS) 192

BUFFERS EXAMPLE OUTPUT

Number of buffers created is 1 Number of buffers created is 2

/* Note that the lines in Buffer 2 are PULLed LIFO because they were */ /* PUSHed Number of Number of Number of LINE C OF

Number of Number of Number of LINE B OF

Number of Number of Number of LINE A OF

into the buffer lines in most current stack is 5 lines in most recently made buffer is 3 current buffer is 2 BUFFER 2

lines in most current stack is 4 lines in most recently made buffer is 2 current buffer is 2 BUFFER 2

lines in most current stack is 3 lines in most recently made buffer is 1 current buffer is 2 BUFFER 2

*/

/* Note that the lines in Buffer 1 are PULLed FIFO because they were */ /* QUEUEd into the buffer */ Number of lines in most current stack is 2 Number of lines in most recently made buffer is 0 Number of current buffer is 2 /* As the current buffer has no more lines; the next PULL essentially */ /* performs a DROPBUF and starts popping records of the next buffer */ LINE 1 OF BUFFER 1

Number of lines in most current stack is 1 Number of lines in most recently made buffer is 1 Number of current buffer is 1 LINE 2 OF BUFFER 1

/* Note that because there were no records in the stack, the DO ”/ /* loop ended without another PULL to do an automatic DROPBUF */ Number of lines in most current stack is 0 Number of lines in most recently made buffer is 0 Number of current buffer is 1 Now a buffer was dropped Number of current buffer is 0

193 QUEUES (STACKS)

THE CONSOLE STACK Not available on MVS, where keyboard is typically locked until command just entered is finished executing. On VM or OS/2, data is placed in the console stack by ”typing ahead”.

On OS/2, the console stack may be called the terminal input buffer, default input stream, or the external event queue.

VM PARSE PULL searches the program stack, first, then console stack, second, then a VM READ on the terminal, if the stacks are empty

IBM’s and CTC’s OS/2 PARSE PULL searches the data queue, first, then, if empty, searches the default input stream, then prompts at the console.

CTC’s OS/2 PARSE EXTERNAL searches the console stack, then, if empty, prompts at the console. It behaves like the VM PARSE EXTERNAL.

I Pulis from 1

Program stack

I

PULL var l

next Console

stack

2

QUEUES (STACKS) 194

YNTAX: EXTERNALSO (Only useful in VM)

ACTION: returns the number of fines in the console stack, also called the terminal input buffer or system external event queue

If there are no lines in the stack, zero is returned

In MVS, the EXTERNALS() function always returns a zero

Example lines = EXTERNALS()

303.55

I T 1 100.999

H $1,304.23

o What is lines equal to in this example?

QUEUES (STACKS) 195

MAKING NEW MVS STACKS

* MVS data queues start with Stack 1. Each time you execute NEWSTACK a new stack with the next higher number is created. Only 1 stack is active.

0 Reasons for using NEWSTACK:

1. Protect elements placed on data stack on one level from another level 2. Prevent elements already on stack from being used as prompts to a

TSO Command; i.e., isolate TSO Command with NEWSTACK DELSTACK

3. Pass data stack elements to a module executed from an MVS batch EXEC executed with PGM = IRXJCL

0 HOW many stacks with contents can be created depends upon your Region. When you exceed storage, you may get a REXX error message: ”Failure in System Service”.

0 If a stack is created in a another EXEC, function, or subroutine, it is still active upon moving to other levels. Data left in the stack is executed at exit from highest level EXEC, unless you do a DESBUF or DELSTACK. The message ”UNKNOWN COMMAND” appears if a line in the buffer is not a valid command.

QUEUES (STACKS) 196

MVS STACK COMMANDS

0 QBUF returns the active buffer number of the active stack to RC. If no MAKEBUF has been executed after a NEWSTACK, QBUF returns a zero.

e QELEM returns the number of records of the currently active buffer in the active stack to RC.

Use the QSTACK command to return to RC the current stack number.

@ QUEUED() returns the number of records of all buffers in the currently active data stack only,

0 DELSTACK deletes the most recently created stack, created with the NEWSTACK command; otherwise, deletes contents of original stack.

0 If a PULL command exhausts the contents of an active stack the next PULL command prompts the terminal. If there is another non-empty stack, its contents can not be accessed before a DELSTACK.

-1 QSTACK Stack 1 NEWSTACK

RC = 1

QUEUES (STACKS)

, , . . . .

197

NEWSTACK EXAMPLE

/* REXX EXEC TO DEMO NEWSTACK, QSTACK, DELSTACK, and Q U E U E D O */ push "SENX 'PUSHed b e f o r e f i r s t NEWSTACK' USER(STR1AAA)" push "SEND ' PUSHed b e f o r e f i r s t NEWSTACK' USER(STR1AAA)" "NEWSTACK" "QSTACK" say ' A NEWSTACK has created Stack* RC say queue 'Line 1 of Stack' RC queue 'Line 2 of Stack' RC c a l l s u b r u t l c a l l s u b r u t 2

Y&ACK'* do forever

do unt i l queued() = 0 say 'Number of l i n e s i n S t a c k ' RC ' is ' queued() say 'Pu l l ing from Stack' RC i f queued() \= 0 then do

p u l l v a r say var

end else say 'Nothing in Current Stack '

end "DELSTACK" "QSTACK" say say ' A DELSTACK has been done; returned to S t ack ' RC say i f RC = 1 then ex i t

end ex i t

subru t 1 : "NEWSTACK" "QSTACK" say ' A NEWSTACK has created Stack ' RC say push 'Line X of Stack' RC push 'Line Y of Stack' RC push 'Line Z of Stack' RC r e t u r n

subrut2 : "NEWSTACK" "QSTACK" say ' A NEWSTACK has created Stack ' RC say 'Nothing w i l l be p u t i n i t ' r e t u r n

QUEUES (STACKS) 198

NEWS MPLE

A NEWSTACK has created Stack 2

A NEWSTACK has created Stack 3

A NEWSTACK has created Stack 4 Nothing w i l l be put in it

Number of l i nes i n S t ack 4 i s 0 Pu l l ing from Stack 4 Nothing in Current Stack

/* Note t h a t PULL does */ /*, drop down t o S t a c k 3 */

A DELSTACK has been done; returned t o Stack 3

Number o f l i nes i n S t ack 3 is 3 Pul l ing from Stack 3 LINE 2 OF STACK 3 Pul l ing from Stack 3 LINE Y OF STACK 3 Pul l ing from Stack 3 LINE X OF STACK 3

/* Note reverse o rder */ /* Due t o PUSH command */

A DELSTACK has been done; returned t o S t a c k 2

Number of l i n e s i n S t a c k 2 is 2 Pul l ing from Stack 2 LINE 1 OF STACK 2 Pu l l ing from Stack 2 LINE 2 OF STACK 2

A DELSTACK has been done; returned t o S t a c k 1

PUSHED BEFORE FIRST NEWSTACK STRlAAA /* Execution as Commands */ COMMAND SENX NOT FOUND /* of Text l e f t in S tack */

QUEUES (STACKS) 199

REDIRECTING TSO COMMAND OUTPUT

TO DATA QUEUE BACKGROUND: Just as the &SYSOUTTRAP and &SYSOUTLINEn system variables in CLIST al- lowed the capture of any terminal output created with a WTO macro, you can also do the same in an EXEC with the OUTTRAP() function.

SYNTAX: OUTTRAP(”cv.”,max-lines,”CONCATI”NONCONCAT”)

ACTION: ,Captures output sent to terminal’ with WTO macro

OPERANDS:

cv. is the name of the compound variable, including period, that will receive lines of output

max-lines maximum number lines that are captured; default is 999,999,999

CONCAT subsequent commands or modules append display output; CONCAT is the default

NONCONCAT subsequent commands or modules overlay previous output

After the funtion has executed, three special variables can be used:

cv.max e cv.trapped e cv.con

Maximum lines that can be captured Number of lines captured CONCAT or NONCONCAT. whichever set

QUEUES (STACKS) 200

UTTRAPO EXAMPLE /* REXX EXEC THAT DISPLAYS ALL FILES ALLOCATED UNDER DDNAME PASSED */ arg filedd debug if debug = 'debug' then trace i x = OU?TRAP("catch.",55) /* Capture <= 55 lines in compound variable */ "listdd" /* Command that output will be captured */ DO line = 1 until line = catch.trapped

END queue catch.line /* Put captured lines in data queue */

DO until QUEUEDO = 0 /* Scan to bottom or until filename found */ parse pull ddname DD dsn volser disp . if ddname = filedd then leave

END

if QUEUED() = 0 & ddname \= filedd, then do

say 'No files allocated under' filedd exit

end say "DATASETS ALLOCATED UNDER "filedd" VOLSER DISP"

DO until ddname \= f iledd & ddname \= ""

say ' '---------------------------------------------- ------ ? I - - - - spacel = space2 = do until length(dsn) + length(space1) > 45

1 1

1 1

spacel = spacel I I end

space2 = space21 1 ' end

do until length(vo1ser) + length(space2) > 10

say dsn spacel volser space2 disp parse pull ddname DD dsn volser disp .

end "DELSTACK"

If I enter "EXECNAME ispplib", it displays, for example: \

DATASETS ALLOCATED UNDER ISPPLIB VOLSER DISP

SYS8.ISR.ISRPLIB IGLE91 SHR SYS9.SDSF.ISPPLIB SDD032 SHR SYSE.COB2PLIB ZTSOCO SHR

--------------------_____^______________------ ------ ----

QUEUES (STACKS)

. .

201

XQUEUEO YNTAX: RXQUEUE(”action” ,queuename])

ACTIONS: Control Private Queues in OS12

ACTION OPERANDS: Create Creates a queue with name, queuename. If no name is

coded, REXX provides a name. Returns queuename.

Delete Deletes named queue. Returns 0 if successful. RC = 9 means queue does not exist.

Get

Set

Exits

The RXQ

Returns name of queue currently in use.

Sets name of current queue to operand queuename. Returns name of previous queuename.

Checks for existance of named queue. Returns 1 if queue exists, 0 if it does not exist. Only available with CTC’s OS/2 REXX.

lUEUE() function is used to control OS/2 Private Queues by n ame. The PUSH, QUEUE, and PULL commands are used to perform Queue I/O.

RXQUEUE can also be called.

Private Queue names must be unique across the entire OS/2 system.

Any lower level external process inherits as its default queue the queue in use by the parent process. Private Queues continue to exist until explicitly de- leted.

In OS/2, if no RXQUEUEO function has been executed, the OS/2 Session Queue is automatically provided and controlled by OS/2. Its name is SESSION. All processes in a session can access the session queue.

Private Queues are not owned by any specific process and the synchronization of requests that update any Queue is the responsibility of the programmer.

No queue element can be less than 64 bytes or more than 64K.

QUEUES (STACKS) 202

RXQUEUEO EXAMPLE

/" REXX EXEC TO DEMO RXQVEVE() */ /* "/ /" PUSH/PULL WITHOUT multiprogramming support */ /" */ push da t a ( ) t ime0 /* push date and t ime */ do 1000 /* l e t s p a s s some time "/

*/ end /* end of loop "/ p u l l a b /* p u l l them "/ say 'Pushed at a b I , P u l l e d a t ' da te ( ) t ime( ) /* say now and then */ /* PUSH/PULL WITH multiprogramming support */ /* No error recovery, or unsupported Env t e s t s */ newq = RXQUEUE('Create') /* Create a p r i v a t e queue */ oldq = RXQUEUE('Set',newq) /* Es tab l i sh new queue */ push date() t ime() /* Push da te and time */ do 1000

end p u l l a b say 'Pushed at a b ', Pulled a t ' date( ) t ime() /* t e l l u s e r */ call RXQUEUE 'Delete ' ,newq /* Destroy unique queue created */ c a l l RXQUEUE ' Set ,.oldq /* Reset to defaul t queue (opt ional) */

noP /* doing nothing

/* "/

/* "/

nop

QUEUES (STACKS)

. . . ,

203

OS/2 REDIRECTION WI[TH 'QUEUE:

4S/2 provides a default input and output stream of STDIN: and STDOUT:, which are from and to the console. Redirection allows you to override the default streams with file names. The input/output streams can also be redirected to reserve device names by using:

STDERR:

CON:

KB D:

LPTl: and LPT2:

PRN:

COMl: and COM2:

AUX:

NULL:

QUEUE:

Standard error output

Display screen input and output. If input, an F6 - Enter Key sequence will generate an EOF, terninating CON as input.

Keyboard Input

Parallel Printer Devices

Current default printer output (Same as LPTl:)

Asynchronous Communication Ports

Current Async Comm Port (Same as COMl:)

Dummy Device. If input, immediate EOF.

REXX external data queue

It is the last item that is of interest to us here.

QUEUE: gives us the capability of direct input/ouput to/from the REXX External Data Queue and an OS/2 Command or load module.

For example:

'DIR > QUEUE:'

puts the output of the DIR command in the queue, line by line.

QUEUES (STACKS) 204

CMS CQMMANDS WITH STACK

OPERAND QUERY, IDENTIFY, and LIST are a few of the CMS commands that can put

Data can be put into the stack in either FIFO or LIFO order

The option STACK may be used and denotes FIFO order

data into the data stack.

Examples 'QUERY DISK (STACK'

'QUERY CMSTYPE (FIFO'

'IDENTIFY (LIFO'

'LISTfile fn ft fm (STACK'

QUEUES (STACKS)

. .

205

REXX 110

REXX ! / O 206

EXECIO ACCESS (MVS and VM)

SYNTAX: EXEC10 nl* function [operands] [(options]

n is t he number of lines or records; * means all

Functions:

RDR PUN PRT

CARD PUNCH PRINT

DISKRU /ApPLEEXECl DISKR

DISK "EXECIO ..." CON

CP

CP

FUNCTIONS AVAILABLE ONLY ON VM: CARD, PRINT, PUNCH, CP, EMSG

REXX I/O

MVS EXECIO DISK 1 / 0

Read from disk, DISKR:

EXECIQ nl* DISKR ddname [LN] [(options E)] ]

0 n is number of lines read; * means all 0 LN is the starting line number * Options on next page

e RC = 2 means End-of-File @ Data read into the stack or REXX variable(s) (based on options)

If no "LN", .sequential from record 1

Write to disk, DISKW:

EXEC10 nl* DISKW ddname [(options [)] ]

6 n is number of lines written; * means all 6 File allocated by ddname and must be allocated before EXECIO. * Data written from the stack or REXX variable(s). 0 Writing from stack continues until null line found or null entry made

from console, if stack exhausted. Writing from a compound variable continues until null value or uninitialized variable found.

Update disk, DISKRU:

EXECIQ nl* DISKRU ddname [LN] [(options f)] ]

* m is number of lines read; means all 0 LN should not be set to a value less than current position without

closing and reopening the file; can cause errors

REXX I/O 208

VM EXEC10 DISK 1 / 0

* Read from disk, DISKR:

EXEC10 nl* DISKR fn ft [fm [LN]] [(options]

n - Number of lines (* means all) fn - Filename ft - Filetype fm - Filemode (default: *) LN - Starting Line Number

If no "LN", sequential from record 1 Data read into the stack or REXX variable(s) (based on options)

Write to disk, DISKW:

EXEC10 nl* DISKW fn ft fm [LN [FIV [Irecl]]] [(options]

FIV - Record format, Fixed or Variable fm - Required but may be *

lrecl - Logical record length; default for F= 80

If "LN", over-writes from that record onward If no "LN", appends to End-of-File Data written from the stack or REXX variable(s) (based on options)

209 REXX 1 / 0

) . . .

EXEC10 OPTIONS 0 STEM name. Lines readlwritten to/from stem variables

"narne.1" to "name.n" ("narne.O"= lines read)

* STRING data Data for output, instream on VM EXEC10 crnd

0 FINIS Close fiie after DISKR, DISKRU, or DISKW (aliso available as VM command)

VAR name VM line read/written to/drorn variable

* SKIP Skips over coded number of lines; * skips to EOF

* LIFOIFIFO Order of lines read into the Data Queue

0 NOTYPE Suppress VM I/O error message

0 BUFFER Increases VM CP ops area from 8 K to 32K

VM editing options: FIND, LOCATE, AVOID, MARGINS, STRIP, CASE

IF VAR and STEM are not coded, records are read from or written to the Data Queue.

In MVS, only STEM, FINIS, SKIP, LIFO, and FIFO can be coded. If STEM and FINIS are coded, FINIS is coded after. Atso, you code SKIP, LIFO, or FIFO only if you are accessing the Data Queue.

RESX 110 210

MVS STEM AND FINIS EXAMPLES

EXEC(R0YROGER) ”ALLOC DA(’ROY.ROGERS.BOOTS’) F(OUT1) SHR” LINE1 = ’Pardon me, Roy, is this the cat that ate your new shoes?’ ”EXEC10 1 DISKW OUT1 (STEM LINE1”

EXEC(JESTER) Which lines of the file ”ALLOC DA(JEX.DATA) F(PUNNY) SHR” will be in LINE.1 and .2? ”EXEC10 1 DISKR PUNNY 8 (STEM LINE.” ”EXEC10 1 DISKR PUNNY (STEM LINE.”

EXEC(DICKENS) ”ALLOC DA(ATALEOF.TWO.CITIES) F(DICKENS) SHR” QUEUE ’It was the best of times,’ How many records will QUEUE ’it was the worst of times,‘ will be written? QUEUE ’it was the age of wisdom,’ QUEUE” ”EXEC10 * DISKW DICKENS (FINIS’’

EXEC(PUNS) QUEUE ’ I left my harp in Sam Clam‘s disco’ Can you tell how many QUEUE ’Repaint and thin no more!’ lines will be written? QUEUE ’Hangover: The wrath of grapes.’ ”ALLOC DA(DARK.STORMY(NlGHT)) F(ST0RY) SHR” ”EXECIO * DISKW STORY (FINIS’’

EXEC(HUXLEY) ”ALLOC DA(’6RAVE.NEW.W’) F(FID) S H R ” Explain what is ”EXECIO * DlSKR FID, happening here

(STEM” LINE. ”FINIS”

211

VAR dk ,STEM- OPTIONS Fi:CCULLER EXEC

FIB = 'HEARTISA LONELY H' o If this is a new file, LINE = 'There were two deaf-mutes,' what will the RECFM be? "EXECIO 1 DISKW" FID "(VAR LINE"

HELLER EXEC o Which lines of the file FID = 'CATCH 22' will be in L-A and L-B? "EXECIO 1 DISKR" FID "8(VAR L-A" "EXECIO 1 DISKR" FID "(VAR L-B" o How long is value in L-A?

DICKENS EXEC FIB = 'ATALEOF 2CITIES A' LN.1 = 'It was the best of times,' o How many records will LN.2 = 'it was the worst of times,' will be written? LN.3 = 'it was the age of wisdom,'

o What will the LRECL be?

LN.99 = '/ "EXECIO * DISKW" FID "F 120", "(STEM" LN.

HUXLEY EXEC FID = 'BRAVE NEW W' "EXECIO * DISKR" FID,

"(STEM" LINE. "FINIS"

o Explain what is happening here

R E X S 1/0 212

!

VM UNIT RECORD 1 / 0 * Read from virtual reader, CARD:

- E.g. EXEC10 CARD (STEM DECK.

* Punch to virtual punch, PUNCH:

E.g. EXEC10 1 PUNCH (VAR CARD

* Print on virtual printer, PRINT:

E.g. EXEC10 * PRINT

Special option: CC DATAIcode CC DATA means Carriage control is 1st byte in line Actual CC character (e.g., 0, -, 1) Without CC, it defaults to single spacing

R E X 4 1 / 0 213

VM EXAMPLES Print all lines in the array PRINTME.n, the first byte in each line is the carriage control character.

0 Write the data in variable LETTUCE to the file SALAD DAYS 15 as record 27. Close the file after this write.

* Test if there is a device at vaddr 183. insure no CP response appears on the screen.

4 Read from the file MASON WHYME on some disk. The starting record number is in variable X. Read until EOF into array E3ECAUSE.n. Close the file when done.

* Create a new variable length file with a maximum length of 133. File ID is OHSAY CANYOU C. Data is in the program stack. Number of rows in stack is in variable STACK-NUM.

KEXX 110 214

VM FINIS SYNTAX:

FINIS fn ft [fm] fn - Filename (can be *) ft - Filetype (can be *) fm - Default is A1 (can be *)

ACTION: Closes one or more open fifes If not executed, all files closed automatically by CMS command handler at R; message.

RESX 1/0

. .

215

RECORD vs. STREAM 1 / 0

M V S and VM Files usually use RECORD 110.

RECORD I/O ATTRIBUTES

1. Fixed Length Fields 2. Stored with No Delimiter between Fields 3. Fixed or Variable Length Records 4. Stored with No Delimiter between Records

But in the micro world, it is just as common to see an alternate (and older) method of storing data, STREAM I/O.

STREAM I/O ATTRIBUTES

1. Variable Length Fields 2. Fields Separated by a Delimiter (comma is common) 3 VEriable Length Records 4. Records Separated by a Delimiter (CRLF is common) 5. Or File may be One Long String of Fields or Characters

With STREAM 1/0 so common, there is no EXEC10 command for 0 9 2 RE%. Instead you work with files, whether they were created with RECORD or STREAM I/O techniques, as a "Stream" of Data using functions.

REXX I/O 216

WHAT ARE OS/2 I/O STREAMS?

A Stream may be:

Streams may be accessed a character at a time using:

CHARIN(), CHAROUT(), CHARS()

or a line at a time using:

LINEIN(), LINEOUT(), LINES()

o r explicitly determine and control the state of the stream with:

STREAM()

Which way you code it depends on the way the data was created or how i t will be received.

REXX 1/0 217

LINEOUT() SYNTAX: LINEOUT( [stream] [,[linedata] ,line#])

ACTCON: If not open? implicitly opens stream first time executed, for read or write. Appends a CRLF to the end of the ’’linedata” and writes it to the st ream.

* The only valid value for lineiff in 16”s REXX is 1.

* The stream can be written to a file, data queue, or output device. Returns a 0 if write successful, 1 if unsuccessful. If called as a subroutine, returned value is in RESULT.

REXX l/O 218

LINEOUT() EXAMPLES

X = LINEOUT() /* Opens STDOUT: and wr i t e s a n u l l s t r i n g , CRLF */ X = LINEOUT(, 'Look, Ma, no stream! ' ) /* Writes string-CRLF to conso le (STDOUT:) */ X = LINEOUT( 'QUEUE: ' , ' F i r s t T ime ' ) /* Opens Data Queue and w r i t e s string-CRLF */ X = LINEOUT( 'C: \PATH\OLD.TXT' , 'Overlay I t ' ,I) /* Opens 0LD.TXT f i l e and over lays l ine 1, p o s i t i o n s t o l i n e 2 */ X = LINEOUT( ' OLD. TXT' , Change Rates ' ) /* Writes s t r ing-CRLF over second l ine, posi t ions to l ine 3 */

X = LINEOUT( ' OLD. TXT' , , 1) /" No Write occurs , reposi t ions t o l i n e 1 for next LINEOUT() write */ x = LINEOUT('OLD.TXT') /* I f open , pos i t i ons a t end of f i l e and closes 0LD.TXT */ Cal l LINEOUT ' D O N G . X I ' , ' L i B a i ' , l /* W r i t e s s t r i n g o v e r f i r s t l i n e of D O N G . X I , r e tu rns 0 t o RETURN */ Call LINEOUT 'LPT1: ','Du Fu' /* Wri te s s t r i ng t o p r i n t e r 1 (LPTl:) , returns 0 t o RETURN */

219 REXX 1/0

LINEIN() YNTAX: LINEIN( [stream] [,[line#] ,count])

CTION: If not open, implicitly opens stream first time executed, for read or w-ite. Returns the next line from the stream and strips any CRLF from the end of the line.

The only valid value for line#, if coded in 16”s OS/2, is 1. However, CTC’s REXX allows repositioning to any valid line number in the stream.

A count of 0 returns a null string and no characters are read. Not coding count or coding a 1 means read one string. After read occurs, updates ”count” with 0 if no lines read, 1 if one line read.

The stream can be read from a file, data queue, or input device.

Available as operand in ”PARSE VALUE LINEIN() WITH template” command to perform parsing with stream VO input.

NEXX I/O 220

LINEIN() EXAMPLES

X = LINEIN() /* Opens STDIN: and reads a l i n e */ x = LINEIN( 'QUEUE: ' ) /* Opens Data Queue and r eads s t r i ng ; i f Queue is empty, func t ion */ /* g o e s i n t o w a i t s t a t e u n t i l a l i n e i s p u t i n t o t h e Data Queue. */ /* Remember that Data Queues can be updated by other p rocesses . */

x = LINEIN('C:\PATH\OLD.TXT') /* I f open , r e tu rns nex t l i ne o f f i l e */ X = LINEIN('C:\PATH\OLD.TXT',5,0) /* CTC's O S / 2 REXX ONLY */ /* Returns Nul l Value , pos i t ions to l ine 5 f o r n e x t LINEIN() read */ x = LINEIN('c:\PATH\oLD.TXT',I,~) /* Reposi t ions t o l i n e 1 and r e t u r n s i t , p o s i t i o n s t o l i n e 2 */ X = LINEIN( 'Am: ' ) /* r e a d s s t r i n g from de fau l t communication p o r t , i f l i n e n o t c o m p l e t e */ /* and no e r ro r , t hen func t ion goes i n to wa i t s t a t e un t i l f i n i shed */

REXX I/O

I .

22 1

SYNTAX: LINES( [stream] )

AcYloN: Returns 1 if any data remains between the current read position and the end of the stream; returns if no data remains. The function is used to determine if an EOF condition exists.

e If you explicitly specify a Device as the stream, the function will always return a 1 e

Examples x = LINES() /* Return a 1 i f de fau l t i npu t s t r eam, STDIN:, con ta ins da t a beyond */ /* curren t read pos i t ion ; 0 i f a t EOF */

x = LINES('QUEUE:') /* Returns a 1 regardless of contents of Data Queue. */ x = LINEs('C:\PaTH\oLD.mxr') /* Returns 0 i f a t end of f i l e , o t h e r w i s e , a 1 is re turned */

REXX 110 222

CHAROUT() SYNTAX: CHAROUT( [Stream] [,[String] ,Start])

ACTION: If not open, implicitly opens stream first time executed, for read or write, positioned at the end of the Stream. After each write, the write position is incremented by the number of characters written.

If Stream not coded, the character string is written to STDOUT:, default output stream.

If Start is coded, and the Stream is persistent, it adjust the write position to a positive increment from the beginning of the Stream, and writes the String. A 1 is the first position.

If String is not coded, the write position is set to the value of start, but nothing is written and a 0 is returned. If String and Start are both not coded, the Stream is closed.

The Stream can be written to a file, data queue, or output device. Returns a count of characters remaining after attempting to write String to the Stream. If called as a subroutine, returned value is in RESULT.

RESS 110 223

CHAROUT() EXAMPLES

X = CHAROUT() /* Opens STDOUT: and writes a null string */ X = CHAROUT(, 'Look, Ma, no stream! ' ) /* Writes string to console (STDOUT:) */ X = CHAROUT( 'QUEUE: ' , 'First Time') /* Opens Data Queue and writes string at bottom of Queue */ X = CHAROUT('C:\PATH\OLD.TXT','Overlay It',l) / + c Opens 0LD.TXT file and overlays starting in the first position */ X = CHAROUT('OLD.TXT','Change Rates') /* Writes string over 11th position thru 22nd position */ x = CHAROUT('OLD.TXT',,S) /* No Write occurs, positions to position 5 for next CHAROUT() write */ X = CHAROUT('OLD.TXT') /* If open, closes 0LD.TXT */ Call CHAROUT 'DONG.XI','Wo de Bei Da de pongyou xihuan Zhongguo fan.',l /* Writes string over first CHAR of DONG.XI, returns 0 to RETURN */ Call CHAROUT 'LPTl:','Annata no namae desu ka?' /* Writes string to printer 1 (LPTl:), returns 0 to RETURN */

224 REXX 1 / 0

CHARIN() SYNTAX: CHARIN( [Stream] [,[Start] ,Length])

ACTION: If not open, implicitly opens stream first time executed, for read or write. Returns the next Length Characters from the Stream.

If Stream is not coded, it defaults to STDIN:.

8 Like CHAROUT(), a read-write position is maintained and updated automatically as reads or writes occur. You can override the read position by coding the Start operand, if the positive value is within the range of characters remaining in the persistent Stream.

A Length of 0 returns a null string and no characters are read. Not coding Length or coding a 1 means read one character.

The stream can be read from a file, data queue, or input device.

REXX 1 /0

. .

225

EXAMPLES X = CHARIN() /* Opens STDIN: and reads one character entered at the keyboard */ x = CHARIN('QUEUE:') /* Opens Data Queue and reads a c h a r a c t e r , i f Queue's empty, function "/ /* goes in to wait s t a t e u n t i l a cha rac t e r is pu t i n to t he Da ta Queue. */ /* Remember t h a t Data Queues can be updated by other processes . ;'r /

x = C H A R I N ( ' A U X : ' , , ~ O ) /* Reads 80 bytes from communication p o r t , i f 80 not a v a i l a b l e and */ /* no e r r o r , t h e n f u n c t i o n g o e s i n t o w a i t s t a t e u n t i l 80 received. ;': /

x = CHARIN('C:\PATH\OLD.TXT') /* Opens 0LD.TXT f i l e and r e a d s f i r s t r e c o r d , p o s i t i o n s t o 2nd by te "/

x = CHARIN('C:\PATH\OLD.TXT') /* I f open , re turns next charac te r from Stream, updates read posit ion "1

X = CHARIN('C:\PATH\OLD.TXT',5,0) /* Returns Nul l Value , pos i t ions to 5 th pos i t ion for next CHARIN()

X = CHARIN( ' C : \PATH\OLD. TXT' , 1 , 2) /* Reposi t ions t o p o s i t i o n 1, r e t u r n s 2 by te s , pos i t i ons t o 3 rd by te "/

226

CHARS() SYNTAX: CHARS( [Stream] )

ACTION: Returns 1 if any data remains between the current read position and the end of the stream; returns if no data remains. The function i s used to determine if an EOF condition exists.

e If you explicitly specify a Device as the stream, the function will always return a 1.

Examples X = CHARS( ) /* Return a 1 i f defau l t input s t ream, conta ins da ta ; o therwise , 0 */ x = CHARS( 'QUEUE: ' ) /;: Returns a 1 rega rd le s s of contents of Data Queue. */ X = CHARS( ' C : \PATH\OLD.TXT' 1 /;: Returns 0 i f a t end of f i l e , o t h e r w i s e , /+: charac te rs remain ing in the S t ream. I f /" t h a t is t h e t o t a l number of cha rac t e r s . /;'; s i s t e n t , i t is the remaining bytes from

REXX 1/0 227

a count-of the number of */ t h e Stream i s t r a n s i e n t , */

I f t h e Stream i s pe r - */ t he r ead -wr i t e pos i t i on . */

EAMO

(StrmName [J S 1 D I C, StrrnCrnd I])

CTIQN: Returns a string describing the state of, or result of operation on, the ”StrrnName”

Operands S - State

D - Description

C - Command

Returns a message string indicating the state of the Stream. Default. Messages include:

ERROR An error has occurred NOTREADY Normal I/O not possible READY Normal I/O possible UNKNOWN Stream is closed

Also returns state of Stream followed by a colon and more info about ERROR and NOTREADY states

Executes StrmCmd against Stream. Commands include:

OPEN Explicitly opens Stream for read and write OPEN READ Opens for read only OPEN WRITE Opens for write only CLOSE Closes the Stream and returns ”READY”,

or null string if unsuccessful SEEK offset Moves read-write position relative to cur-

rent position, the start or the end of the Stream. Offset can be prefixed with:

= Offset from beginning of Stream.

0 < Offset from end of Stream. f Offset forward from current position.

* - Offset backward from current posi-

QUERY EXISTS Returns full path of Stream, if it exists; null

QUERY SIZE Returns size in bytes of a persistent

QUERY DATETIME Returns the date/time stamp of a Stream.

Default.

tion.

if not.

Stream.

The 3 QUERY command are not available with CTC’s O W 2 REXX.

HEXX 110 228

HOW CAN WE INCREASE REXX PORTABILITY?

WISH LIST

1. Provide a prepro e:-essor capability; modelled after C. 2. Provide BAT or CMD to REXX.CMD Convert Utility. 3. Provide EXEC2 to R E M EXEC Convert Utility. 4. Provide CLlST and JCL to EXEC(REXX) Convert Utility. 5. Provide simi tar methods of determining file states, etc. (Must put pres-

6. Provide multiple stack capability to VM environment. 7. Provide NEWSTACK et a/ commands for OS/2. 8. Provide OUTTRAP() function on VM and OS/2 for capturing displays. 9. Provide EXEC10 command (as subroutine?) on OS/2 for Record 110. 10. Expand on the EXECIO operands (STRING, VAR, SKIP, LIFOIFIFO, and ed-

11. Provide FINIS command on MVS and OS/2; to ease conversion from VM to

12. Provide DISKRU on VM and 0 9 2 version of EXECIO. 13. Provide a SAYNR command that displays text without a carriage return, to

ease conversion from CLlST (with WRITENRs) to EXEC. 14. Provide the ability in MVS of inserting High/Non-Display/Normal Attributes

in SAY text as can be done in VM with ’1DOx’X. Provide simular capabilities on OS/2.

15. Eliminate synonyms for Data Queue: Program Stack, External Data Queue, Queue, Stack, etc. in documentation.

16. Add Binary String type to MVS and VM, along with a function to convert Binary to Hexadecimal.

17. CTC might create synonym of OS2ENVIRONMENT for their CMD operand of the VALUE function to be compatible with IBM 0 9 2 . On the other hand, it would make more sense if IBM made the synonym of CMD available.

18. Provide a LINESIZE(), EXTERNALS(), FIND(), JUSTIFY(), and USERID() function on IBM’s OS12 REXX.

19. Provide a julian date function on 0 9 2 REXX (IBM and CTC). 20. Provide a language date function on MVS and VM. 21. Provide a beep function on MVS and VM. 22. Establish a REXX User’s Group that will maintain a library of programs,

functions, and subroutines outside of Mansfield, CTC, IBM, SHARE, or GUIDE.

sure on Environment Support People; Not REM’s problem).

iting options) for MVS and OS/2.

MVS or OS/2.

HOW CAN WE ISCREASE REXX PORTABILITl? 230

Ackerman, Alan 675-4358

Agui3.a~- , Ben 405-299-4381

Aitken, David 408-866-8334

Aston, David 920-2457

Bailey, Tom 332-8495

Bakcr, Mark 213-593-8838

Baldwin, Chuck 256-1195

Barnett, Mark 494-8074

Berger , Ramon 926-3446

Boeheim Chuck 926-4640

Bowlby, Gavin 592-0808

Brink, Ed 322-8113

Buder, Pat 408-251-2108

Cava, Phil 408-746-8544

Cholar, Craig 408-655-4000

Cif onelli , John 708-696-4800

Dept. 3477. P . 0 . Box 37QOO San Francisco, CA 91137 BAY on VMSHARE ADSE, Bank of America 1555 Berger Dr. Bldg. 11-3rd Floor, San Jose CA 95112 Sr. Prog. Analyst, Santa Clara County 18311 Baylor Ave., Saratoga, CA 95070 Staff Systems Programmer, Amdahl SLAC, 2575 Sand Hill Road, Menlo Park, CA 94025 DYAEE@SLACVM Physicist-, SLAC 41.1 Tumey St. I Sausalito, CA 94965 Programmer, Log.i.ca1 Condus ion .s 482 Gaviota, Long Beach, CA 90802 Computing Engineer, McDonnell Douglas 1327 Corte De Los Vecinos, Walnut Creek, CA 94598 V. P. Yfktg. , Taliesin, Inc. 451 Alger Drive, P a h Alto, CA 94306 WB(_§LAW Programer, SLAC STLAC, Bin 71, 2575 Sand Hill Road, Menlo Park, CA 94025 RAMON@SLACVM Programer, SLAC Bin 97, SLAC, 2575 Sand Hill Rd, &!enlo Park CA 94-25 B O E H E I M @ S ~ - ~ ~ T J I Programser , S u C 2304 Wooster Ave., Belmont, CA 94002 Staff Design Engineer, Amdahl 1240 Hobart St., Menlo Park, CA 94025-5517 MCI:EBRINK,ConpuServe:76555,422 Brink and Associates PO Box 3408, San Jose CA 95156 Section Mgr., Safeway 1250 E. Arques MS/201, Sunnyvale, CA 94086 Sr. Systems Programmer, Amdahl 99 Pacific St.Suite 155A, Manterey, CA 93940 [email protected] Sys.Prog,Defense Manpwr-Data Ctr. 6300 N. River Rd., Rosemont, IL 60018 uunet.!wrkgrp!jac Software Mgr, Workstation Grp.

Clancey, Patrick PO Box 4349 #50, Stanford, CA 94309 926-2339 CLANCEY@SLA~ Systems Programmer, SLAC

Coffee , Peter 4131 Michelle Dr., Torrance, CA 90503 213-371-8096 MC1:Peter Coffee Compuserve:76344,3161 Analyst,PCWeek

Cole, Creswell 1260 E. Arques, MS/205, Sunnyvale, CA 94086 408-746-4877 Software Engineer, Amdahl Corp.

Coussens, Irene Bin 97, SLAC, 2575 Sand Hill Rd., Menlo Park, CA 94025 926-2842 IRENQSLACVM Programmer, SLAC

Cowlishaw, Mike IBM Hursley Park, Winchester, UK +44-962-844433 [email protected] IBM Fellow, IBM UM Laboratories

Dager , Cathie 415-926-2904

Dager , Terry 415-543-9320

Daney , Charles 408-257-3697

Downey , Teresa 926-2903

Dunkel, Daniel 748-5244

Erickson, Bruce 725-1785

Estes, Will 408-446-0387

Faracchio, Joe 642-,?638

Feller, Bok: 867-1472

SLA? Bin 97, 2575 Sand' Hill Rd, Menlo Park, CA 94025 [email protected] Scientific Programmer, SLAC 150 Spear St, San Francisco, CA 94105 Tesseract 19567 Dorchester D r , Saratoga, CA 95070 Quercus Systems SLAC, Bin 97, 2575 Sand Hill Rd. Menlo Park, CA 94025 [email protected] Programmer Analyst, SLAC 1040 Marina Village Pk~,Alameda, CA 94501 Director, Mktg./Sales, Command Technology Corp. 857 Serra St, Stanford, CA 94305 AS.BAE@stanford Micro Support, Stanford Univ. 12301 DeSanka Ave. Saratoga, CA 95070-3150 sUn!p~rtal!cup.portal.com!will Prog, U.S. Computer CCS , 26 1 Evans, IJC Berkeley, Berkeley, CA 947 20 SPGSAF@ucbcmsa Prog. Arlalyst IV, UCB 10 W. Orange Ave, So. San Francisco, CA 94030 Systems Progranmer: Guy F Atkinson

mailto:[email protected]

Fitch, Joel 1804 Vacca Dr, San Jose, CA 95124

E'raatz, Dave Bldg. 220-3W-01, St. Paul, MN 55144

Franklin, Ray 1214 Paru St, Alameda, CA 94501

Gambelin, Mike 1555 Berger Dr,3rd Floor,Bldg.2, San Jose, CA 95112

Garnett, Forrest 5600 Cottle Rd, San Jose, CA 95193 408-997-4089 GYSLIVES@LSG\"B System Programmer, IBM

Giguere, Suzanne 1260 E. Arques M/S 205, Sunnyvale, CA 94086 408-746-6279 Software Eng., Amdahl Corp.

Ginevich, Rost 4000 N. Mingo Rd. MD 348, Tulsa, OK 74158 918-832-5375 Sr. Prog. Analyst, American Airlines

Goldberg, Gabe 1604 Spring Hill Road, Vienna, VA 22182 703-506-0500 VMG on VMSHARE V.P. VM Systems Group

Gomberg, Dave 7 Gateview Ct. San Francisco, CA 94116 GOMEiERG@UCSFVM UCSF

Graff, Michael 4652 Piper St, Fremont, CA 94538 770-1312 IBM W E T GRAFF@MLPVM2 Programmer, IBM

Green-Suskind,Linda G92lGC14 PC Box 8009, Endicott, NY 13760 601-752-1172 SAA Procedures Lang. Interface Owner, IBM

Gunning, Randy 1755 Grant St,2nd Floor #5863, Concord, CA 94520 675-4148 ADSE, Bank of America

Hall, John 662 Canyon Dr., Pacifica, CA 94944 477-5049 Technical Analyst, Wells Fargo Bank

Hassenplug, Sandra 1117 N. 15, Philadelphia, PA 19102 215-246-6273 Supr. Systems Programming, Towers Perrin

Hawes, Bill 533 Gleasondale Rd, Stow, MA 01775 508-568-8695 BIX:WAWES

Heidenreich, Karen SLAC, 2575 Sand Hill Rd, Menlo Park, CA 94025 926-3962 KAREN@rsICVM Prog. Analyst, SLAC

Helffrick, Boone 1649 S . Main St, Milpitas, CA 94053 408-265-1483 Software Developer, HPL

Holland, Ray IBM ARC, 650 Harry Rd, San Jose, CA 95120 927-2637 HOLLAND@ALMADEN IBM

Jenkins, Jonathan 1250 E. Arques Ave M/S 201, Sunnyvale, CA 94088 408-737-5019 AMDAHL!JUTS!JW50 Systems Prog., Amdahl

Jenkins , Ted SLAC Bin 48, 2575 Sand Hill Rd, Menlo Park, CA 94025 926-4325 TMJRP@LACNM SLAC

Johnson, Bill SLAC Bin 97, 2575 Sand Hill Rd, Menlo Park, CA 94025 326-2660 WBJ@SLACVM SLAC

Johnson, Tony PO Box 4349 Bin 71, Stanford, CA 94309 926-2278 TONYJ@LACVM Physicist, Boston Univ.

Johnson, Vern 1250 E. Arques M/S 249, Sunnyvale, CA 94086 408-746-6993 Staff Design Engineer, Amdahl Corp.

Johnston, Ted SLAC Bin 97, 2575 Sand Hill Rd, Menlo Park, CA 94025 926-2689 TYJ@SLACVM Mgr, SLAC

Kaminski, Peter 159 Los Trancos Circle, Portoh Valley, CA 94028 851-0927 B1X:kaminski Software Designer, self

Kearney, Kevin PO Box 532, Storrs, CT 06268 203-429-8402 President, Mansfield Software

Keller , Bob 39861 Wyatt Lane, Fremont, CA 94538 Kelse-y, Mason 1121C Porter St, Vallejo, CA 94590

Kiesel, Peter 250 E. Fifth St, 4th Floor, Cincinnati, OH 45202

Munz, P a u l SLAC, 2575 Sand Hill Rd, Menlo Park, CA 94025

408-264-6839 JMFIC@SLACVM Eng. Asst, SLAC

612--736-5650 Specialist, 3M

543-9320 programmer, Tesseract

299-4301 System Programmer, County of Santa Clara

770-1479 System Programmer, Motorola

707-645-7195 C.S.E., Bank of America

513-762-2618 Staff Instructor, IBM

y 1 I a6-2884 PL"KER(aSWOJM L Physicist, SLAC

232

I,nngeveld, t4i l ly S L i C Bin 97 , 2575 Sand Hill Rd, Menlo Park, CA 94025

L t : t y I Hank 10420 Castine Ave, Cupertino, CA 95014

Lichtenthal, Marvir: 4 Captain Dr., Emeryville, CA 94608

327-4610 WGLPO9@SLACVM S U C

408-257-9076 HZlf.!KLFvrS' MzPVM2 Programmer, IBM

653-5211 Lichter, Stephen 212-230-5132

LC~:;;~ Conr,ie 92c '2879

T,u !e-::.:: I m , i?eter 3 5 8 - 3050

Luoh, Harry 408-299-4301

Mantino, Mike 523-2616

Mar, Dennis 408-646-2672

Marks, Brian 44-962-841122

Martin, Charlie 926-2260

Maru , Ken j i 408-746-3299

NcClennan, John 855-3722

McGrath, Sean 653-8387

McGuire, Rick 607-752-1865

Mehl, Jim 408-927-1879

Meyer, Mike 853-6507

Milsted, Neil 708-969-4800

Moraes, Roger 408-299-4301

Morrow, Mike 476-4525

Nee, €hi-Mei 408-299-4301

642-5025 Nguyen , Xuan 408-299-4381

Noakes, Michael 408-655-4000

0 ' Hara, Robert 617-252-5275

Oppenheim, Larry 585-1.009

Orr, Sid 856-5405

Pachl, Walter

Ng, May

65 E 55 St: New York, NY 10022 DEVNYS@DALVMNYl Instr. /Developer, IBM SLAC, 2575 Sand H i l l Rd, Menlo Park, CA 94025 CAI.@SL,ACVM Mathematician, SLAC 447 Claremont Way, Menlo Park, CA 94025 [email protected] ludemann@mlpvm Adv. Analyst,IBM 1555 Berger Dr, 3rd Floor GSA/DPC San Jose CA 95112 System Programmer, County of Santa Clara 1442A Walnut St. Suite 412, Berkeley, CA 94709

WR Church Computing Ctr, Code 0141, Monterey,CA 93943 [email protected] S.tat./Prog. Naval PostGrd. School IEM UK Laboratories, Winchester, England FAX 962-840092 Sr. Programmer, IBM SLAC Bin 97, 2575 Sand Hill R d , Menlo Park, CA 94025 CwM@sLAcV" System Programmer, SLAC 1250 E. Arques, Sunnyvale, CA 94088 Sys . Programmer, Amdahl 1520 Page Mill Rd, MS33G, Palo Alto, CA 34304 Programmer, IBM 638 66th St, Oakland, CA 94609 [email protected]' Consultant, URSA MINOR G19/21A-l-E5 PO Box 9008, Endicott, NY 13760 Advisory Programer, IBM Endicott PO Box 632, Los Gatos, CA 95031 [email protected] Programmer, IBM 3657 Ramona Circle, Palo Alto, CA 94306 [email protected] Syst. Programmer, Digital 6300 N. River Road, Rosemont, IL 60018 met!wrkgrp!NFNM Developer, Workstation Group 1555 Eerger Dr, GSA/DPC San Jose, CA 95112 System programmer, County of Santa Clara 533 Parnassus Rm. U76, San Francisco, CA 94143 Syst. Programmer, UCSF 1555 Berger Dr.3rd Floor,Bldg.#2, San Jose CA 95112 System Programmer, County of Santa Clara CCS, 253 Evans, UCB, Berkeley, CA 94720 CSVMN@UCBCMSA User Services Consult., UC Berkeley 1555 Berger Dr, San JQSe, CA 951.12 Programmer Analyst IV, Santa Clara County 99 Pacific St. Suite 155A, Monterey, CA 93940 3547PFNAVPGS.BITNET Sys.Prog, De€. Manpower DataCtr. 1 Rogers St, Cambridge, MA 02142 [email protected] Sys. Arch., Lotus Dev. Corp. 236 W. Portal, Ste. 347, San Francisco, CA 94127 Consultant, Penguin Computing 405 El Camino REal #411,, Menlo Park, CA 94025 SORR@SLACVM Software Engr, SLRC IBM Austria,00/705 Cobdenq.2, Vienna A 1010

43-1-222-211454420 PACHLVABWl Developer, IBM

408-357-9004 PAYTON@MLPVM2 Programmer, IEM

471.-0215 System Programmr, Tesseract Schlage Lock

- .

Payton, Brian 5104 Westmont Ave. #9, San Jose, CA 95130

P h i l l i p s , Russell. 4558 Osai Loop, Union City, CA 94587




Robin, David 100 H a l f Da.y Rd, Lineolnshire, IL 60069

Rockowitz, Sanford 1373 S . Mayfair Ave, Daly City, CA 94015

Rogers, Sara PO Box 532, Storrs, CT 06268

Fmthacker, Frank SLkC. B i n 8 8 , 2575 Sand Hill Rd, Menlo Park, CA 94025

708-295-5000 C o n s u l t a n t , Hewitt Associates

755-4570 ROCK@SUCV~., m e r , Minaret Software

203-429-8402 Srqqort Staff, Mansfield Software

926--2624 Schmidt, Denise 402-333-4385

Snawder, Paul 408-299-4301

Spadafora, John 517-860-6241

Spencer, Randal 222-7595

Stevens , Kevin 649-0479

Sturak , Tamara 642-9123

Style, Bernie 703-264-8362

r;'RrzrrJI<@LAC\?~I SLAC 3118 S . 15th St, Omaha, NE 68130 MC1:362-2229 Independent Ccnsultant 1555 Berger- Ex, Bidg.2, San Jose, CA 95112 Sr. Syst-ems Prog. County of Santa Clara 29 Hartwell P;iie, Lexington, MA 02173 BIX,JSPADAFO%(A Programter Analyst, BIX 2728 Sheldon Dr., El Sobrante, CA 94803 spence.r@bix 160 Caldecott Lane #124, Oakland, CA 94618 BIX Icevinestevens Network Admin, Heals Health Plan CCS, 271 Evans, UC Berkeley, Berkeley, CA 94720 tamara@ucbcmsa User Svs. Coord, UCB 1800 Alexander Bell Dr, Reston, VA 22091 Sr. Syst. Arch., Systems Center

Thompson, Marshall S G C , 2575 SardHill Rd, Menlo Park, CA 94025

Tsai, Raymond 1250 E. Arques Ave M/S 201, Sunnyvale, CA 94086 408-737-5123 Staff Systems Programmer, Amdahl. Corp.

Tunkel , Jay fEM Corp.3600,lCOCI W' 51st St,Boca Raton FL 33432 407-443-5955 Advisory Proyra.mmer: IBN Corp.

Tyree, Scott 125Q E. Arques M/S 201, Sunnyvale, CA 94088 408-746-4634 AMTI on WSHAKE Systems Programmer, Arndahl

Van Herwijnen, Eric CERN, AS Division, Geneva, Switzerland CM-1211 41-22-7675087 ERIC@CERI*S\%. CERN . CH CERN

Vigil, Peter 1250 E , Arques Ave. M/S 249, Sunnyvale, CA 94086 408-746-3493 Design E n g r . , Amdahl Corp.

Vul, Alex Arndahl Corp, Slunnyvale, CA 94086 408-746-8596 amdahl!agv Software Engr, Amdahl Corp.

Warnett, Martin 1420 Harbor Bay Pkky, #200, Alameda, CA 94501 769-4900 Software Engineer, Software Pursuits, Inc.

Watanabe, Gerry 5600 CottPe Rd A6O-029, San Jose, CA 95193 408-997-4279 Mgr, TRM

Watts, Keith 1945 Washington St, #410, San Francisco CA 94109 775-8360 Proprietor, Kilowatt Software

Weeks, B i l l SLhC Bin 97, 2575 Sand Hill Rd, Menlo Park, CA 94025 926-2909 WCW@SLACln4 Sys Prog . , SLAC

Weinstein, Marvin SUC, 2575 Sand Hill Rd, Menlo Park, CA 94025 926-2214 NITf@STLIACWi SLAC

Weissman, J i m 59 Echo Ave, Oakland, CA 94611-4307 396-6979 MCI-MAIL Wells Fargo Bank

White, Beho SLAC Bin 97, 2575 Sand Hill Rd, Menlo Park, CA 94025 926-2907 BEB(?(SSUWA SLAC

Winson, Alan 6 Admiral D r . #437, Emeryville, CA 94608 653-2695 TDA on VMSHARE Independent Consultant

Winters, Joan SLAC Bin 9 7 , 2575 Sand Hill Rd, Menlo Park, CA 94025 924-2530 [email protected] Scientific Programmer, SLAC

Witthaus, Ken SLAC B i n 6 1 , 2575 Sand Hill Rd, Kenlo Park, CA 94025 926--2468 KEN@LACVM Mathematician, SLaC

926-4231 PJIT@LACW Financial Analyst , SLAC

A conference for velopers and users

All in the relaxed atmosphere of the Calvomia coas;

TO teceive further iqformation send a sev-adclressed stamped envelope to the address below.

To make your reservation, sen

235

proceedings of the symposium for developers and users

Documents