Will@cup.portal.com (Will E Estes) (08/10/89)
I would be interested in hearing from sites that would like to see IBM's REXX language run under UNICOS. Thanks, Will
jac@muslix.llnl.gov (James Crotinger) (08/12/89)
You can register my vote for a port of REXX to the Crays! I'm an Amiga user and have done quite a bit or REXX program on my machine. Infinitely better than COSMOS, the batch language we have here at NMFECC. (The programmer who maintains COSMOS is also an Amiga user and has also expressed a strong desire to have REXX on the Crays). Jim
arnold@mathcs.emory.edu (Arnold D. Robbins {EUCC}) (08/15/89)
Given that many Crays run Unicos, and that KSH will be part of S5R4, so it should migrate to Unicos eventually, I have to wonder if REXX is all that necessary. I can see that on a system like COSMOS or COS, which isn't Unix-based, REXX might be desirable, but I suspect that the percentage of non-Unicos Cray systems is only going to decrease in the future. I just watch the supercomputer world from the outside, so take my opinion with a grain of salt. In article <30469@lll-winken.LLNL.GOV> jac@muslix.UUCP (James Crotinger) writes: > You can register my vote for a port of REXX to the Crays! I'm an >Amiga user and have done quite a bit or REXX program on my machine. >Infinitely better than COSMOS, the batch language we have here at >NMFECC. (The programmer who maintains COSMOS is also an Amiga user >and has also expressed a strong desire to have REXX on the Crays). -- Arnold Robbins -- Emory University Computing Center | Laundry increases DOMAIN: arnold@unix.cc.emory.edu | exponentially in the UUCP: gatech!emoryu1!arnold PHONE: +1 404 727-7636 | number of children. BITNET: arnold@emoryu1 FAX: +1 404 727-2599 | -- Miriam Hartholz
jerry@violet.berkeley.edu ( Jerry Berkman ) (08/15/89)
In article <30469@lll-winken.LLNL.GOV> jac@muslix.UUCP (James Crotinger) writes: > > You can register my vote for a port of REXX to the Crays! I'm an >Amiga user and have done quite a bit or REXX program on my machine. >Infinitely better than COSMOS, the batch language we have here at >NMFECC. (The programmer who maintains COSMOS is also an Amiga user >and has also expressed a strong desire to have REXX on the Crays). > > Jim REXX may be better than COSMOS on CTSS, but that is irrelevant. The question is is it better than the C shell and Bourne shell which are distributed as part of UNICOS? And is it better than other shells likely to become a part of UNICOS, and how many shells do we really need? I find C shell adequate for most uses, and Bourne shell if I really need efficiency. Jerry Berkman U.C. Berkeley
dph@lanl.gov (David Huelsbeck) (08/16/89)
From article <1989Aug15.010010.16811@agate.berkeley.edu>, by jerry@violet.berkeley.edu ( Jerry Berkman ): [...] > > REXX may be better than COSMOS on CTSS, but that is irrelevant. > The question is is it better than the C shell and Bourne shell > which are distributed as part of UNICOS? COSMOS is mighty primative as CTSS command languages go. At Los Alamos it was largely replaced (for new development anyway) by CCL which has subsequently been replaced by FCL. FCL is the best command languages I've worked with yet. It makes the Unix shells look sort of pitiful; it makes COSMOS look pitiful too. Why don't you folks have more up to date CTSS command languages? I must admit that I'm not familiar with REXX. However if it's anything like its predecessors EXEC and EXEC II all I can say is YUCK. The standard Unix shells, UNICOS, COSMOS and CTSS are all things that I'm well versed in. My guess is that the shells will provide some of the functionality that CTSS command language users are used to and will demand under UNICOS. I don't think they'll go far enough though. The Unix shells have evolved to meet the demands of a particular type of user. I don't think most people switching from CTSS to UNICOS are of that type. (I can't speak for COS users) Speaking as a person that has done quite a bit of work on CTSS, Unix and UNICOS I can tell you that the mind set of most Unix users is completely different than that of most CTSS users. Both will find UNICOS inconvenient (I have) but the trauma will be less for Unix users. The people used to working in a VMS environment and moving codes to either CTSS or COS may actually be the lucky ones in this respect. >And is it better than > other shells likely to become a part of UNICOS, and how many shells > do we really need? I find C shell adequate for most uses, and > Bourne shell if I really need efficiency. > To allow users to write the sorts of controllers they're used to writing on CTSS a new non-Unixish command language will *undoubtedly* be needed. It's not just a matter of retraining the poor, dumb, CTSS users to see things the way all these enlightened Unix users have seen them for so long now. Both ways of operating and looking at problems have thier advantages. The catch is that those advantages carry more or less weight depending on the type of work you want to do. So Unix does turn out to be a nice platform for doing software development on fairly small codes. CTSS turns out to be a great production environment for very large codes. UNICOS will have to provide a good environment for both. At this point I still have serious doubts about whether or not it can do both well. It doesn't seem to do either well right at the moment. Ever wonder why CRI is calling it UNICOS 5.0 instead of UNICOS 0.5? UCB has been at it for a very long time and they're only up to 4.3 and most of their products have worked for quite some time. > Jerry Berkman > U.C. Berkeley Of course these are only the opinions of lowly hacker. For official possitions you'll have to talk to somebody much higher up. -dph
jac@muslix.llnl.gov (James Crotinger) (08/16/89)
In article <14019@lanl.gov> dph@lanl.gov (David Huelsbeck) writes: >COSMOS is mighty primative as CTSS command languages go. At Los Alamos it >was largely replaced (for new development anyway) by CCL which has subsequently >been replaced by FCL. FCL is the best command languages I've worked with yet. >It makes the Unix shells look sort of pitiful; it makes COSMOS look pitiful >too. Why don't you folks have more up to date CTSS command languages? > Interesting. I'll have to find out about this. >I must admit that I'm not familiar with REXX. However if it's anything >like its predecessors EXEC and EXEC II all I can say is YUCK. > REXX is an interpretive language (well, there are some compilers on IBM mainframes) that has an excellent set of string parsing/handling functions coupled with a very easy to use method for interprocess communication. A controllee must open a REXX communication port and register it with the REXX server. Once registered, REXX programs can send messages and receive results from the controllee. For instance, suppose we had a controllee with a REXX port named FOO. To send a string to that controllee you'd just say: address FOO message A REXX program always has an active "host". It can switch hosts with the "address" command. Any statement which is not understood by the REXX interpreter is passed to the controllee. (It can be quoted if the message would otherwise be interpreted as a valid REXX statement). Thus: address FOO message1 message2 ... If you need to get a result from FOO, it is returned in a variable named RESULT (or result..REXX is not case sensitive).. address FOO status foos_status = RESULT would, say, return a status string to the variable foos_status, which could then be parsed, and based on that info, a message might be sent to another controllee: /* parse foos_status, etc. */` address BAR message_to_bar You get the idea. AREXX (Amiga REXX) has a very power feature that I believe is an extension of the language (certainly it is not in Cowlishaw's book) called a direct variable interface. This allows a host program to return results directly to a REXX stem variable (REXX supports associative arrays, called stem variables). Thus you might say address FOO getstatus mystatus Then mystatus.cpuseconds, mystatus.size.height, mystatus.size.width, etc., would contain various fields describing the status of the system. (I have an AREXX compatible database that does this, and I find it to be an extremely powerful combination!) Thus REXX is, IMHO, a very good batch language for writing macros to run controllees, and for integrating multiple controllees. REXX was specifically designed to be easy to learn and used. It it typeless (everything is a string, though there are numerical operators which work on strings which contain numbers), interpreted, and the standard implementation has several modes to allow interactive debugging. > >> Jerry Berkman >> U.C. Berkeley > >Of course these are only the opinions of lowly hacker. For official possitions >you'll have to talk to somebody much higher up. > >-dph Jim Crotinger Lawrence Livermore National Laboratory
abh0@GTE.COM (Andrew Hudson) (08/16/89)
In article <14019@lanl.gov> dph@lanl.gov (David Huelsbeck) writes:
<From article <1989Aug15.010010.16811@agate.berkeley.edu<, by jerry@violet.berkeley.edu ( Jerry Berkman ):
< [...]
<<
<< REXX may be better than COSMOS on CTSS, but that is irrelevant.
<< The question is is it better than the C shell and Bourne shell
<< which are distributed as part of UNICOS?
<
<COSMOS is mighty primative as CTSS command languages go. At Los Alamos it
<was largely replaced (for new development anyway) by CCL which has subsequently
<been replaced by FCL. FCL is the best command languages I've worked with yet.
<It makes the Unix shells look sort of pitiful; it makes COSMOS look pitiful
<too. Why don't you folks have more up to date CTSS command languages?
<
<I must admit that I'm not familiar with REXX. However if it's anything
<like its predecessors EXEC and EXEC II all I can say is YUCK.
<
<The standard Unix shells, UNICOS, COSMOS and CTSS are all things that I'm
<well versed in. My guess is that the shells will provide some of the
<functionality that CTSS command language users are used to and will demand
<under UNICOS. I don't think they'll go far enough though. The Unix shells
<have evolved to meet the demands of a particular type of user. I don't think
<most people switching from CTSS to UNICOS are of that type. (I can't speak
<for COS users) Speaking as a person that has done quite a bit of work on
<CTSS, Unix and UNICOS I can tell you that the mind set of most Unix users is
<completely different than that of most CTSS users. Both will find UNICOS
<inconvenient (I have) but the trauma will be less for Unix users. The people
<used to working in a VMS environment and moving codes to either CTSS or COS
<may actually be the lucky ones in this respect.
<
<<And is it better than
<< other shells likely to become a part of UNICOS, and how many shells
<< do we really need? I find C shell adequate for most uses, and
<< Bourne shell if I really need efficiency.
<<
<
<To allow users to write the sorts of controllers they're used to writing on
<CTSS a new non-Unixish command language will *undoubtedly* be needed. It's
<not just a matter of retraining the poor, dumb, CTSS users to see things the
<way all these enlightened Unix users have seen them for so long now.
<-dph
I have used UNIX and VMS extensively and both UNICOS and CTSS to
a small degree. Although I do not doubt that an expert CTSS user could
write and debug numerical application in the style typical of the 50's,
60's, and 70's, I find it hard to believe that a highly detailed,
batch oriented operating system, designed without the benefit of more
modern philosophies could lend itself to contemporary programming
practices. This is not a flame. It's just that I am dubious that
interactive scientific visualization would not benefit more from
a job running under a UNIX stream fed to a workstation, than say
creating a mondo batch-style data set and shipping that to a VMS
front end and plotting it. For instance. It's quite possible that I am naive
to the subtleties of advanced CTSS or COS practices. Maybe you could
cite a few examples of such.
- Andrew Hudson
GTE Laboratoriesmorreale@bierstadt.ucar.edu (Peter Morreale) (09/12/89)
In article <30469@lll-winken.LLNL.GOV> jac@muslix.UUCP (James Crotinger) writes: > > You can register my vote for a port of REXX to the Crays! I'm an etc... I am also interested in REXX for UNICOS. Can someone please email me the details. (I came in late on this one) Is it freeware?, interpreter only..?, availability?, etc..... Thanx, -PWM ----------------- Peter W. Morreale Nat'l Center for Atmos. Research, Scientific Computing Division morreale@ncar.ucar.edu (303) 497-1293
johnny@edvvie.at (Johann Schweigl) (09/16/89)
From article <4283@ncar.ucar.edu>, by morreale@bierstadt.ucar.edu (Peter Morreale): > In article <30469@lll-winken.LLNL.GOV> jac@muslix.UUCP (James Crotinger) writes: >> You can register my vote for a port of REXX to the Crays! I'm an > etc... > I am also interested in REXX for UNICOS. Can someone please email me > the details. (I came in late on this one) Is it freeware?, interpreter > only..?, availability?, etc..... Don't cry for Cray alone. REXX for UNIX in general would be great. I've got one for IBM AIX, binary only, not official, unsupported and undoc'd. By the way, shouldn't this discussion go to comp.lang.rexx ? I believe the response would be better there. How many of us have a Cray to play (me not)? -- ------------------------------------------------------------------ EDV Ges.m.b.H Vienna Johann Schweigl Hofmuehlgasse 3 - 5 USENET: johnny@edvvie.at A-1060 Vienna, Austria Tel: (0043) (222) 59907 257 (8-19 CET)