PROCEEDINGS OF THE SYMPOSIUM FOR DEVELOPERS AND USERS
Transcript of 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, au- thor 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 exten- sions 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 environ- ment, 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 (de- scribing 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 com- mon 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 an- nouncement 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 philoso- phy 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 imple- mentations.
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
7
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
20
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
m
32
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
. . . . . . .
, . . .. ... . . . .. . . ..
.. . . ..
..... . . . . . . . " . .
. . . ... . . .
CMS REXX Compiler Walter Pachl
-. 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
. . - . . - . . . .. . . . . ..
.. . . . . . . .
CMS REXX Compiler Walter Pachl
-. . 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
. . . . -. . . . _.. .
CMS REXX Compiler Walter Pachl
___.-... .
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
CMS REXX Compiler Walter Pachl
-- -. 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
- . . . . . . . .
CMS REXX Compiler Walter Pachl
-- - . 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
CMS REXX Compiler Walter Pachl
-.
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
CMS REXX Compiler Walter Pachl
--.. 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.
REXX language I/O and environment challenges
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.
REXX language I/O and environment challenges
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
REXX language I/O and environment challenges
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
REXX language I/O and environment challenges
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.
REXX language I/O and environment challenges
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" ) ) ;
THE REXX PROCEDURES LANGUAGE WORKSHOP AGENDA
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
THE REXX PROCEDURES LANGUAGE WORKSHOP AGENDA
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
THE REXX PROCEDURES LANGUAGE WORKSHOP AGENDA
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
THE REXX PROCEDURES LANGUAGE WORKSHOP AGENDA
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
+---- >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
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...
June 7,1990 REXX Symposium
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.. .
June 7,1990 REXX Symposium
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
157
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
168
.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
171
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 gen- eral 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 allo- cated 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 ex- tension. 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 de- fault 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 exe- cuted 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 ac- tive 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 in- put stream, or the external event queue.
VM PARSE PULL searches the program stack, first, then console stack, sec- ond, 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 sys- tem 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 ac- tive 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 redi- rected 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 car- riage 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” com- mand 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 posi- tion 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 auto- matically 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 char- acters 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 capabili- ties 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
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