HDTenEightyP/NetNews huggingface dataset:
From: rcg@world.std.com (Richard C Gorton)
Subject: PL/I on *IX
Organization: The World Public Access UNIX, Brookline, MA
Date: Tue, 17 Nov 1992 01:54:41 GMT

I'm interested in hearing from PL/I users on *IX - what kind of
applications you use it for, what platforms you use, whose PL/I
you use, what kind of features are missing from your current PL/I, etc.
I'm developing a PL/I portability library which is intended to fill
in a number of gaps between IBM PL/I and LPI-PL/I.  I would like some
feedback from real-live PL/I programmers, so I can get a feel for
what problems you have encountered pertaining to portability, performance,
etc.

Please respond via email, as I may miss relevant postings

        Thanks in advance,

                        Richard Gorton
                        

Richard Gorton	(or Antix Software, if you please)
rcg@world.std.com		Say "NO" to bugs.

-- 
Richard Gorton	(or Antix Software, if you please)
rcg@world.std.com		Say "NO" to bugs.
Newsgroups: comp.lang.icon
Date: Tue, 17 Nov 1992 13:25:11 MST
From: "Clint Jeffery" <cjeffery@cs.arizona.edu>
Subject: Field names of a record type

   Paul Abrahams writes:
   given the name of an Icon record type, is there a
   straightforward way to list the names of its fields in the same order
   as they appear in its definition?  So far I haven't found one.

While you are waiting for that built-in function, the following program
demonstrates a technique that does what you ask.  Normally I wouldn't
start from a *name* of a record type, but that's how you stated the problem.
Folks who don't believe in semi-colon insertion, let me know if you have
trouble reading this.

record r (alpha, beta, c)

procedure main()
  every write(fieldnames("r"))
end

procedure fieldnames(r)
  R := r()
  every i := 1 to *R do {
    s := name(R[i])
    suspend s[find(".",s)+1:0]
  }
end

Newsgroups: comp.lang.icon
Date: Fri, 20 Nov 92 12:49:16 EST
From: Paul_Abrahams@MTS.cc.Wayne.edu
Subject: Icon templates for MultiEdit?

I wonder if anyone has created Icon templates for MultiEdit, a popular
program editor for the PC.  (American Cybernetics, which markets
MultiEdit, is located in Tempe, just up the road from the Icon Project.)
 
Paul Abrahams

Newsgroups: comp.lang.icon
Date: 16 Nov 1992 08:26:47 -0600
From: Chris Tenaglia - 257-8765 <TENAGLIA@mis.mcw.edu>
Subject: semicolons revisited?
Organization: Medical College of Wisconsin (Milwaukee, WI)


In case any one really really likes semicolons on a string processing language
DEC now offers TPU (text processing utility) for its VAX and RISC boxes. Asoft
offers nu/TPU for other platforms.

TPU has a lot of icon and snobol string concepts yet it enforces semicolons at
the end of the statements. But like pascal it also uses begin and end instead
of curly braces for blocking. No generators, no fail/succeess handling. But
it has an interesting property. All variables declared have scope local to
their procedures. All variables created by operations (not predeclared) have
global scope. This language is the foundation of an editor called EVE. It
allows one to do string programming in a full screen editor environment. I've
used it to customize my editor to do herculean feats.

I still prefer icon for stream crunching, front ending, and game design.
The lack of semicolons, required declarations, and datatypes are the features
that drew me to icon, and that improve my productivity.

Chris Tenaglia (System Manager) |  "The past explained,     
Medical College of Wisconsin    |   the future fortold, 
8701 W. Watertown Plank Rd.     |   the present largely appologized for."
Milwaukee, WI 53226             |   Organon to The Doctor
(414)257-8765                   |     
tenaglia@mis.mcw.edu


Newsgroups: comp.lang.icon
Date: Thu, 19 Nov 1992 06:00:42 MST
From: "Ralph Griswold" <ralph@cs.arizona.edu>
Subject: Re:  Readability of semicolons

Yes, of course you *can* string things together on one line in Icon.
But the use of lines rather than semicolons to separate expressions
encourages a more readable style.

Rick Fonorow once noted that it's never necessary to have any semicolons
in an Icon program (except in literals).  If you use that as a style guide,
you tend to get more readable programs.

Newsgroups: comp.lang.icon
Date: Wed, 18 Nov 92 14:40:44 EST
From: Paul_Abrahams@MTS.cc.Wayne.edu
Subject: Second argument to softf

Thanks to Clint Jeffery for providing the missing link needed to specify
the second argument of sortf as a field name.  Applying the "name" function
to a record object of record type R, you can determine the field occupying
the i'th position of the record.  Inverting this procedure, you can
determine the position (as an integer) of a field name.  Once you've done
that, you have the second argument to sortf that you need.
 
Clint commented:
 
<< Folks who don't believe in semi-colon insertion, let me know if you have
 trouble reading this. >>
 
Yes, but a program (Icon or otherwise) with semicolons is also easy to
read.  The semicolons don't interfere, at least for me.  I certainly agree
that a program is easier to *write* without semicolons.  However, as I
said in an earlier post, the Icon treatment of newlines precludes certain
convenient conventions for line continuations.
 
Paul Abrahams
 
 

Newsgroups: comp.lang.icon
Date: Tue, 17 Nov 92 10:50:06 EST
From: Paul_Abrahams@MTS.cc.Wayne.edu
Subject: Field names of a record type

I recently proposed a builtin Icon function that would convert field names
to their corresponding positions, as a way of constructing the desired
second argument to sortf.  That led me to the following question: does
such a function need to be built in?  Surprisingly, it seems so.
 
Putting it another way: given the name of an Icon record type, is there a
straightforward way to list the names of its fields in the same order
as they appear in its definition?  So far I haven't found one.
 
Paul Abrahams
 

Newsgroups: comp.lang.icon
Date: Fri, 20 Nov 92 12:48:54 EST
From: Paul_Abrahams@MTS.cc.Wayne.edu
Subject: Scanning a list of items

The Icon Analyst #15 describes several versions of code to scan and
process a list of items.  The list has the form of a string with markers
between items but without a marker after the last item.  An unattractive
solution is
 
text ||:= marker
text ? {
   while process(tab(find(marker))) do
      =marker
   }
A better solution suggested by the Analyst is
 
text ? {
   while process(tab(find(marker)|0)) do
      =marker | break
   }
 
But here's another alternative, which is what I've usually done:
 
(text || marker) ? {
   while process(tab(find(marker))) do
      =marker
   }
 
As to which of the alternatives is better, de gustibus non est
disputandum.
 
Paul Abrahams

Newsgroups: comp.lang.icon
Date: Wed, 18 Nov 1992 14:10:06 MST
From: "Ralph Griswold" <ralph@cs.arizona.edu>
Subject: Re:  Second argument to softf

With semicolons, programmers tend to string a bunch of statements
together on one long line.  This often makes programs harder
to read than if they were written one statement per line with
a more vertical layout.

On more than one occassion, I've reformatted programs for publication
by breaking up long multi-statement lines into single lines.

For me, at least, using lines to separate statements not only makes programs
easier to write; it makes them easier to read.

For Icon, read "expressions" for "statements".  The point is the same.
    
Ralph E. Griswold			ralph@cs.arizona.edu
Department of Computer Science 		 uunet!arizona!ralph
The University of Arizona		602-621-6609 (voice)
Tucson, AZ 85721			602-621-9618   (fax)

Newsgroups: comp.lang.icon
Date: Sun, 15 Nov 92 10:49:26 EST
From: Paul_Abrahams@MTS.cc.Wayne.edu
Subject: Second thoughts on semicolons

For a long time I've liked the Icon convention that the end of a line acts
as a semicolon unless the last token on the line is an operator.  There's
no doubt that it makes programs easier to write.
 
But I am having some second thoughts about this convention, because I
think it hinders making programs easier to read.  I don't think semicolons
at the ends of lines affect readability one way or the other, but that by
itself doesn't argue against the Icon convention.  But the Icon convention
does preclude breaking an expression before rather than after an operator,
and therefore precludes the program style, which corresponds to the
mathematical conventions, where continuation lines start with an operator.
 
The Icon conventions are too heavily embedded in existing code for me to
suggest that they should be changed.  But the downside of the Icon
convention is something that language designers should ponder.
 
Paul Abrahams
 

Newsgroups: comp.lang.icon
Date: Wed, 18 Nov 92 22:16:48 EST
From: Paul_Abrahams@MTS.cc.Wayne.edu
Subject: Readability of semicolons

Ralph Griswold commented:
 
<< With semicolons, programmers tend to string a bunch of statements
together on one long line.  This often makes programs harder to read than
if they were written one statement per line with a more vertical layout.
>>
 
Yes, but you can also string a bunch of statements together on one line in
Icon, or write statements one per line in some other language.  So the
Icon convention seems to me at least to be neutral with respect to this
aspect of readability.
 
Paul Abrahams

Newsgroups: comp.lang.rexx
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: Re: Relaxing of arg string passing...
Organization: Draper Laboratory
Date: Mon, 16 Nov 1992 15:52:00 GMT

In article <9211151359.AA05246@SERVER.uwindsor.ca>,
ophof@SERVER.UWINDSOR.CA (Scott Ophof) writes:

>On Mon, 21 Sep 1992 14:59:52 MEZ Otto Stolz
> <RZOTTO%DKNKURZ1.BITNET@uga.cc.uga.edu> said:
...
>>Let us keep in mind that host commands are processed by the respective
>>host system that will impose its own rules on them. Hence, differences
>>between genuine REXX interfaces and commands addressed to the host system
>>inevitably arise. We can neither blame the REXX implementors for them,
>>nor can we expect the forthcoming standard to mend them.
>
>>Hence, Scott is asking too much.
>
>Maybe I don't know what I'm asking?  :-)
>As I see it, the host system passes the command line data to the
>invoked program, which then does whatever it wants with that data.
>Do I see this wrong?
>And are there any opsyses that (might) interpret commas on the
>command line in some special way?

Well, take Unix (please).  The command line passed to a program by
the Unix shell gets cooked quite a bit before the command ever sees it.
Wildcard expressions are expanded - even if you never intended them
to represent file names - variables are substituted, piping and
redirection operators are analyzed, etc.  Then the remaining argument
string is parsed into tokens and fed to your program as a vector of
character strings.

If you wanted your program to see one huge character string exactly
as the user intended, the user would have to enclose the entire thing
inside quotes.  Even then, there are differences in the ways that the
various Unix shells handle backslashes, question marks and bangs.

Now, assuming that the user wanted REXX and not the shell to see the
commas, said user would encase the argument in quotes.  In which case
I think the user would be behaving in a reasonable manner if (s)he
expected the REXX exec to see the string as a whole, and not as a
specification of multiple arguments.  Otherwise, if the user wanted
to pass a comma to the REXX exec in a way that told it not to treat
the comma as a REXX delimiter but really part of the low-level data,
yet another level of quoting would be needed.

In sum, what you see on the terminal isn't necessarily what you get, and
what you get is determined in a very significant way by the operating
system shell.  Most important, the REXX exec has no idea of what the
user originally typed.  It sees only what the shell feeds it, and can
make no assumptions about what was typed on the raw console.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
Newsgroups: comp.lang.rexx
From: shoe@world.std.com (Jack N Shoemaker)
Subject: REXX and TSO
Organization: The World Public Access UNIX, Brookline, MA
Date: Thu, 19 Nov 1992 20:10:45 GMT

Does REXX now come with TSO all the time?  That is, if you are on a TSO
account, is it a given that REXX exists?  TIA - Jack
-- 
Jack Shoemaker
Real Decisions Corporation    Voice: 203-656-1500
Darien, CT  06820          InterNet: shoe@world.std.com

Newsgroups: comp.lang.rexx
From: gencon06@titan.ucc.umass.edu (WatchDog)
Subject: ARexx question
Organization: University of Massachusetts, Amherst
Date: Fri, 20 Nov 1992 13:41:30 GMT

How do I execute B.rexx from within A.rexx?  is this done by passing the
filename for B.rexx to either the REXX or the AREXX port?  If so, which one?

Also, what does the return look like from either req.library or asl.library
if multiple filenames are selected?  ex/
Files selected: (selected in order given here)
	foo.bar
	foo.bar.1
	foo.bar.5
	foo.bar.3
	foo.bar.4
	foo.bar.2

Any help is much appreciated.
                                                        -Watchdog
From: KNP2%MARIST@VM.MARIST.EDU (Christopher J. Schmitz)
Newsgroups: comp.lang.rexx
Subject: EXECIO and MUSIO
Date: 18 Nov 1992 20:36:53 -0600
Organization: UTexas Mail-to-News Gateway
Distribution: inet
NNTP-Posting-Host: cs.utexas.edu

Dear Whoever,
     I'm having a problem tring to make a chat program on a MUSIC
system that we have here at Marist.  Here's the problem.  I want the
REXX program to read the last 21 lines of a file called chatfill1.
However, since this is being done in a MUSIC environment, I can't use
EXECIO, but I have to use MUSIO.  From what I know, they are almost
exactly the same.  As far as reading, writeing, and appending.  After
the program pulls the last 21 lines out of the file, it will display
them in a panel.  And every line that someone inputs to the screen will
be writtin to the last line of chatfill1.  And so it's just one big
loop untill you '/quit' out of it.  Anyway,.. if anyone knows what I'm
talking about PLEASE tell me.  If you want to see the code, which isn't
documentated yet, I can post it to here.  However the panels you'll have
to make up yourself (sorry).  Well,.. that's about it.  Thanks
-- Christopher J. Schmitz --


P.S.  I don't have usenet access at my school, however I can telnet to
      a certian site and read the news there.  So feel free to either
      E-mail here or to the newsgroup thanks.  If you want the code then
      E-mail me,.. Thanks
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Sun, 15 Nov 1992 08:59:45 EST
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      Re: Relaxing of arg string passing...
Comments: To: REXXLIST@uga.cc.uga.edu
              21, 92 2:59 pm

On Mon, 21 Sep 1992 14:59:52 MEZ Otto Stolz
 <RZOTTO%DKNKURZ1.BITNET@uga.cc.uga.edu> said:
>on Sat, 19 Sep 92 01:11:25 EDT Scott Ophof said:
>> [I am] discussing just *one* thing: that there be no
>> difference between a REXX program as to invokability in the
>> following cases re recognized number of arg-strings:
>>  - To be invoked program is internal to the program invoking it
>>    (as subroutine or function).  [note 1]
>>  - To be invoked program is external and invoked from a REXX program
>>    as function, subroutine, or command.  [note 2]
>>  - To be invoked program is invoked straight from the command line.

>Let us keep in mind that host commands are processed by the respective
>host system that will impose its own rules on them. Hence, differences
>between genuine REXX interfaces and commands addressed to the host system
>inevitably arise. We can neither blame the REXX implementors for them,
>nor can we expect the forthcoming standard to mend them.

>Hence, Scott is asking too much.

Maybe I don't know what I'm asking?  :-)
As I see it, the host system passes the command line data to the
invoked program, which then does whatever it wants with that data.
Do I see this wrong?
And are there any opsyses that (might) interpret commas on the
command line in some special way?

Of course it all hinges on there being a command line; MacREXX
(um..sorry, I mean TEXX  ;-) ) might have trouble on the MacIntosh
since there's no command line there, I've been told...


REXXards.
$$/
Organization: Stanford Linear Accelerator Center
Date: Monday, 23 Nov 1992 10:29:56 PST
From: <CATHIE@SLACVM.SLAC.STANFORD.EDU>
Newsgroups: comp.lang.rexx
Subject: REXX Symposium Speakers Wanted (Repost)

Announcement and Call for Participation

REXX Symposium for Developers and Users
18-20 May 1993
San Diego, California

The REXX Symposium provides a forum for information and ideas and an
opportunity to interact personally with others interested in using and
enjoying programming in REXX.

The Symposium consists of plenary sessions and parallel sessions for papers,
status reports, and review talks.  Presentations focus on using REXX on a wide
variety of computing platforms and operating systems.  Of particular interest
are unique applications, REXX tools and function libraries, REXX interfaces
with other languages, user support, and education.  Author Mike Cowlishaw and
other implementors will be present and participate in the sessions.

Abstracts of proposed contributions should be clear and about one page long.
Talks will 20 to 45 minutes.  A paper may be submitted for a poster
session (that is, pages of paper pinned to a wall to be read individually).

Please send the abstract by 1 December 1992 to

                       Cathie Dager
                       SLAC
                       P.O. Box 4349, MS 97
                       Stanford, CA  94309  USA

     or by e-mail to cathie@slacvm.slac.stanford.edu

Contributors will be informed of acceptance no later than 1 March 1993.
Symposium proceedings will include all invited talks and contributed papers.

Special hotel rates have been negotiated for this Symposium if reservations
are made through Village Travel in Palo Alto, CA by 1st April 1993.

Fee schedule:
     Conference    --  US$300 includes 3 meals, socials, proceedings
     Lodging/Night --  US$85  single or double

Registration is required.  The registration fee is due in advance, payable
in cash or check, net US$300 in US funds.  To register for the Symposium,
reserve a room, and make travel arrangements, please contact:

                       Village Travel
                       REXX Symposium
                       69 Town and Country Village
                       Palo Alto, CA  94301  USA
                       1-800-245-3260
                       1-415-326-0510  fax 1-415-326-0245

Please send questions to any member of the program committee:

     Cathie Dager      cathie@slacvm.slac.stanford.edu
     Forrest Garnett   garnett@vnet.ibm.com
     Jim Weissman      jhw@cup.portal.com
     Bebo White        bebo@slacvm.slac.stanford.edu

Cathie Burke Dager   cathie@slacvm.slac.stanford.edu
---> the opinions expressed are mine alone and not necessarily those
     of SLAC, Stanford University or the DOE
---> the above disclaimer is not mine alone and does not reflect my
     opinion or personality (and you'll love San Diego on the beach!)
Newsgroups: comp.lang.rexx
From: giguere@csg.uwaterloo.ca (Eric Giguere)
Subject: Help me with the OS/2 REXX application list
Organization: Computer Systems Group, University of Waterloo
Date: Fri, 20 Nov 1992 18:44:59 GMT


As you may or may not know, I maintain a Frequently Asked Questions list
for REXX that I post every once in a while to comp.lang.rexx and other
appropriate groups.  (The current FAQ can be FTPd from rexx.uwaterloo.ca
as /pub/rexxfaq.)  I am now also starting to collect information on
OS/2 applications that support REXX.  A similar list is maintained 
regularly for ARexx.  As with the REXX FAQ, I will post the list regularly
to appropriate newsgroups, which may or may not include comp.lang.rexx
but will certainly include comp.os.os2.programmer.

To do this I need your help, but you really don't have to do much:  just
send me some email describing any applications that you know of under OS/2
that use REXX.  You might also mention to me HOW it uses REXX, as in:

  1) Can only spawn REXX macros 
  2) Includes a subcommand interface (i.e., you can send the application
     commands using ADDRESS)
  3) Defines new external functions

If the application is freeware, please tell me where you got it as I
may wish to keep a copy on my FTP site.  

Hopefully this list will help people (users and developers) clue in
to the usefulness of REXX as a standard macro language for OS/2.

-- 
 Eric Giguere                                    giguere@csg.UWaterloo.CA
          So is Windows NT short for "Windows, NOT?"
From: dac@prolix.apana.org.au (Andrew Clayton)
Newsgroups: comp.lang.rexx
Subject: Re: PMREXX under OS/2
Date: Sun, 15 Nov 1992 13:29:51 GMT
Organization: More like Dis~, really.
X-Newsreader: Arn V1.00 beta rel2

In article <BxKFE6.JK2@watserv1.uwaterloo.ca>, Eric Giguere writes:

> In article <hokZr*gl0@prolix.apana.org.au> dac@prolix.apana.org.au (Andrew Clayton) writes:
> >1) Is there a generic way to make OS/2 read and write files from
> >   a REXX command file? [There was no readln, writeln, readch,

> Under OS/2 the functions linein(), charin(), etc. are used for
> input and output.  It's actually a very strange model if you're

Thanks.  Several other netters pointed this out.  I also
downloaded the REXX.INF file from Compu$erve, which eased all of
my remaining problems with this particular variant of REXX.

> >2) Using standard input, and PARSE UPPER PULL xyz, I am able to
> >   input the information I need to process, but everytime I go
> >   through the loop and read another line, I get an annoying

> I'm not sure what you're talking about here.  Realize that PMREXX.EXE
> is an _application_ that invokes the REXX interpreter.  The two are not

Sorry about that.  I meant when I executed the REXX command file,
PARSE PULL would issue a '?', since it expected input from the
console, and even if it was reading redirected input, would write
out the '?' prompt.

Using xyz = LINEIN() worked perfectly. [Note: LINEIN/LINEOUT
CHARIN/CHAROUT are not in the Amiga REXX implementation -
replaced with ReadLN, WriteLN, ReadCH and WriteCH.]

>  Eric Giguere                                    giguere@csg.UWaterloo.CA

Dac
--
dac@prolix.apana.org.au              David Andrew Clayton.           // _| _  _
dac@prolix.sserve.cc.adfa.oz.au      Canberra, Australia           \X/ (_](_](_
Newsgroups: comp.lang.rexx