On Sun, 27 Jun 2021 22:52:26 +, Seymour J Metz wrote:
>...
>They originally wrote Unix for ASCII, which doesn't have a new line character.
>Unix, and C, used a line feed as a logical new line, but I don't know what The
>Open Group or IEEE say about that. OMVS uses an EBCDIC NL character
Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Steve Thompson [ste...@copper.net]
Sent: Sunday, June 27, 2021 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
The diff between Posix compliant and not? Linux is Not Unix. zOS, iirc is by
being Posix
: Coding for the future
The diff between Posix compliant and not? Linux is Not Unix. zOS, iirc is by
being Posix compliant.
Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct
mistaks
> On Jun 27, 2021, at 1:55 PM, Seymour J Metz wrote:
>
> Yes, but the orig
FWIW, I always do it your way, Gil.
We couldn't possibly BOTH be wrong.
(Except, of course, that I never use all-caps for variable names. Sometimes
I'll name something MaxVal, but usually not even that.)
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Computers in the future may
On Sun, 27 Jun 2021 15:05:08 -0400, Steve Thompson wrote:
>The diff between Posix compliant and not? Linux is Not Unix. zOS, iirc is by
>being Posix compliant.
>
Unfortunately, "compliant" with an outdated version of POSIX.
-- gil
On Tue, 22 Jun 2021 20:39:57 +0800, David Crayford wrote:
>
>Lua ports to TSO/MVS just fine with no changes because it uses fopen().
>All I had to do was add "dd:lua(%s)" to package.lua and it just worked.
>Lua runs in CICS no problems. Rocket's Python port uses fopen() but it
>requires enhanced
] on behalf of
> Charles Mills [charl...@mcn.org]
> Sent: Sunday, June 27, 2021 1:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Coding for the future
>
> Right, it makes it into (effectively) on long "continued" (if you will)
> literal. Effectively, not literally.
&
Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, June 27, 2021 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On Sun, 27 Jun 2021 11:01:55 -0700, Charles Mills wrote:
>I t
On Sun, 27 Jun 2021 18:12:26 +, Seymour J Metz wrote:
>Which code looks cleaner?
>
> foo = bar' 'baz,
> foo = bar baz
>
FWIW, I prefer coding:
say 'Result =' RESULT
to:
say 'Result = 'RESULT
I seem to be in a minority.
-- gil
On Sun, 27 Jun 2021 11:01:55 -0700, Charles Mills wrote:
>I tend to think of the insertion of blanks to be unfortunate.
>
Alas, in Regina, with no blanks in the source:
trace R
say 'foo',
'bar'
2 *-* say 'foo' 'bar'
foo bar
607 $
However:
trace R
say 'foo'/* ,
*/'bar'
2 *-* say
[charl...@mcn.org]
Sent: Sunday, June 27, 2021 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
I tend to think of the insertion of blanks to be unfortunate.
It is great if you are wanting to demonstrate the incredible simplicity of
Rexx:
Say Hello World
But I think if you want
ssage-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Sunday, June 27, 2021 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
Yes, but the original code inserted a blank between the two strings; It's
the differenc
cn.org]
Sent: Sunday, June 27, 2021 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
Right, it makes it into (effectively) on long "continued" (if you will)
literal. Effectively, not literally.
I was assuming the IBM mainframe as this is the IBMMAIN mailing list. A
ed on your platform.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Saturday, June 26, 2021 8:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
That '||' changes the semantic; the is
Hi Gil,
No, the LINEND Character does not work in this instance (to retain the
command buffer post-CMS crash.)
The LINEND Character (default "#") LOGICALLY separates the command(s)
being placed into the CMS Buffer.
This buffer is destroyed when CMS crashes (due to the TERM CONMODE 3270
On Sat, 26 Jun 2021 22:49:43 -0400, David Spiegel wrote:
>
>The newline as part of a string is critical in VM-Land for PROFILE EXECs
>which want to IPL a Guest in a Rexx Exec.
>It is necessary because, as soon as the TERM CONMODE 3270 is issued, CMS
>is blown away, yet, the string is still in the
-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 25/06/2021 9:03 pm, Jeremy Nicoll wrote:
>> isredit "(LRECL) = LRECL"
>> local lrecl = ispf.vcopy("LRECL")
> Would that place the current file's lrecl in the ispf variable named
> LRECL then copy that
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Friday, June 25, 2021 7:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
Flogging this terminally ill equine late in the game, but gosh
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
I don't know what he meant; that's what I was asking in the first place.
(He still hasn't answered. Maybe he's busy being entertained watching us.)
And I am further confused by part of your answer: "...by multi-line string
I
...@listserv.ua.edu]
Sent: Friday, June 25, 2021 11:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On Fri, 25 Jun 2021 23:31:49 +, Seymour J Metz wrote:
>I can see him agreeing that an expression involving two distinct strings is
>not what he meant; that tells me n
Hi Gil,
The newline as part of a string is critical in VM-Land for PROFILE EXECs
which want to IPL a Guest in a Rexx Exec.
It is necessary because, as soon as the TERM CONMODE 3270 is issued, CMS
is blown away, yet, the string is still in the CP Command buffer
(waiting to executed).
Regards,
On Fri, 25 Jun 2021 16:57:54 -0700, Charles Mills wrote:
>
>And regarding #2, similarly
>
>Bar = "blah blah" || X2C("0A") || "blah blah"
>
Or, perhaps:
... || '15'x || ...
This may motivate a question on TSO-REXX.
>-Original Message-
>From: Seymour J Metz
>Sent: Friday, June 25, 2021
On 25/06/2021 9:41 pm, Paul Gilmartin wrote:
On Fri, 25 Jun 2021 08:43:31 +0800, David Crayford wrote:
I value languages that support the MVS file system. All I had to do to
enable Lua to run from from PDS data sets was to patch the package
loader with an extra string "//DD:LUA(%s)" and it
On 25/06/2021 9:03 pm, Jeremy Nicoll wrote:
isredit "(LRECL) = LRECL"
local lrecl = ispf.vcopy("LRECL")
Would that place the current file's lrecl in the ispf variable named
LRECL then copy that value to the lua program's same-named
variable?
If so, this is a lot more like writing an ispf
On Fri, 25 Jun 2021 23:31:49 +, Seymour J Metz wrote:
>I can see him agreeing that an expression involving two distinct strings is
>not what he meant; that tells me nothing about what he did mean. Specifically,
>it does not tell me whether he meant:
>
> 1. A string literal running over two
On Fri, 25 Jun 2021 19:12:14 +, Seymour J Metz wrote:
>LF=Line Feed, which *bsd, Linux and Unix use as a line ending string (DOS and
>OS/2 use CRLF).
>
And z/OS Unix System Services uses neither of those conventions.
>The code you show is really an expression, using $() to swallow a new
I don't know what he meant; that's what I was asking in the first place.
(He still hasn't answered. Maybe he's busy being entertained watching us.)
And I am further confused by part of your answer: "...by multi-line string
I mean a string literal split across multiple lines of the source
2, similarly
Bar = "blah blah" || X2C("0A") || "blah blah"
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Friday, June 25, 2021 4:32 PM
To: IBM-MAIN@LISTSERV.UA.ED
du/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob
Bridges [robhbrid...@gmail.com]
Sent: Friday, June 25, 2021 7:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
Correct -- but you can see him agreeing he does not m
Correct -- but you can see him agreeing he does not mean what I said he
could not mean. He and I agreed that by "multi-line string" he did not mean
longstr='blah blah blah blah blah blah blah blah',
'blah blah blah blah blah blah blah blah blah'
You, though, say that by
Subject: Re: Coding for the future
I must be going crazy. Let's review:
Gil> I wish Rexx supported multi-line strings.
Bri> I know you don't mean this:
longstr='blah blah blah blah blah blah blah blah',
'blah blah blah blah blah blah blah blah blah'
Gil>
Met> ...b
I must be going crazy. Let's review:
Gil> I wish Rexx supported multi-line strings.
Bri> I know you don't mean this:
longstr='blah blah blah blah blah blah blah blah',
'blah blah blah blah blah blah blah blah blah'
Gil>
Met> ...by multi-line string I mean a string
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Friday, June 25, 2021 11:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On Fri, 25 Jun 2021
] on behalf of Bob
Bridges [robhbrid...@gmail.com]
Sent: Friday, June 25, 2021 12:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
Wait, now I'm confused. (Well, more confused.) "A string literal split
across multiple lines of the source code" -- that's what Gil said
Wait, now I'm confused. (Well, more confused.) "A string literal split
across multiple lines of the source code" -- that's what Gil said he
~didn't~ mean:
longstr='blah blah blah blah blah blah blah blah',
'blah blah blah blah blah blah blah blah blah'
---
Bob Bridges,
On Fri, 25 Jun 2021 14:14:41 +, Seymour J Metz wrote:
>Here documents create strings containing embedded new lines, which *ix systems
>encode as LF. They do not allow strings not containing embedded new lines to
>be split across multiple lines of the source code.
>
"LF"? FSVO *ix. How
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org]
Sent: Friday, June 25, 2021 8:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On Fri, 25 Jun 2021, at 05:08, Seymour J Metz wrote
On Fri, 25 Jun 2021, at 15:00, Paul Gilmartin wrote:
> In TSO, the argument of ADDRESS is case-insensitive; in CMS, case-sensitive.
> I understand it's a PSW. Sounds dangerous.
PSW?
--
Jeremy Nicoll - my opinions are my own.
On Thu, 24 Jun 2021 19:40:23 -0400, Bob Bridges wrote:
>... I quote
>most constants in REXX, depending as little as possible on REXX's
>interpretation of uninitialized variables. Like so:
>
> address ISPEXEC 'VGET '
> ...
It's MFC's idiosyncrasy. There's sound justification for not
On Fri, 25 Jun 2021 08:43:31 +0800, David Crayford wrote:
>
>I value languages that support the MVS file system. All I had to do to
>enable Lua to run from from PDS data sets was to patch the package
>loader with an extra string "//DD:LUA(%s)" and it worked.
>
From a C/POSIX perspective:
What is
On Fri, 25 Jun 2021, at 02:37, David Crayford wrote:
> On 24/06/2021 9:44 pm, Jeremy Nicoll wrote:
> > On Thu, 24 Jun 2021, at 01:57, David Crayford wrote:
> >
> >> For example, to create and ISPF in Lua you instantiate and ISPF object
> >> and then communicate with it by calling methods
> >>
On Fri, 25 Jun 2021, at 05:08, Seymour J Metz wrote:
> No, by multi-line string I mean a string literal split across multiple
> lines of the source code, whether or not it contains CR, LF or NEL. In,
> e.g., HLASM you can split a string across multiple lines, although the
> syntax is ugly.
For
://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob
Bridges [robhbrid...@gmail.com]
Sent: Thursday, June 24, 2021 7:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future - REXX quoting
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob
Bridges [robhbrid...@gmail.com]
Sent: Thursday, June 24, 2021 7:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
Ah, I see; by "multi-line string" y
List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Thursday, June 24, 2021 9:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 24/06/2021 9:33 pm, Seymour J Metz wrote:
> That wiki article describes exactly the mechanism I was referr
: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 24/06/2021 8:51 pm, Seymour J Metz wrote:
The only meaning that I'm familiar with is the one that I get on a search for
'callback definition programming'. Or were you thinking of a non-computer
contest?
Callback is is a well kno
On 24/06/2021 9:44 pm, Jeremy Nicoll wrote:
On Thu, 24 Jun 2021, at 01:57, David Crayford wrote:
For example, to create and ISPF in Lua you instantiate and ISPF object
and then communicate with it by calling methods
https://lua4z.github.io/Lua4z/modules/ispf.html.
That shows eg that you can
-requ...@listserv.ua.edu]
Sent: Thursday, June 24, 2021 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On Tue, 22 Jun 2021 11:23:41 +, Seymour J Metz wrote:
Yes, I know that TSO support requires heavy lifting, and not just for fopen().
Would a build of OoRexx without f
Ah, I see; by "multi-line string" you mean, I guess, a string with something
like an ASCII CRLF embedded in it. But isn't that a limitation not of REXX but
of EBCDIC? Or have I still misunderstood you?
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Unable to locate coffee.
That brings up an interesting question (by which I mean "a question about
which any answers y'all might provide will interest me, at least"). I quote
most constants in REXX, depending as little as possible on REXX's
interpretation of uninitialized variables. Like so:
address ISPEXEC 'VGET '
The first time I wrote a 200-line program in REXX (a nightly update for
ACF2), I wondered whether I should feel guilty about it. But that was two
decades ago.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* If God had wanted me to touch my toes, he would have put them on my
knees.
ul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, June 24, 2021 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On Tue, 22 Jun 2021 11:23:41 +, Seymour J Metz wrote:
>Yes, I know that TSO support requires heavy lifting, and not just for fopen().
>
smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, June 24, 2021 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On Tue, 22 Jun 2021 18:39:19
On Tue, 22 Jun 2021 18:39:19 -0400, Bob Bridges wrote:
>Gil, I don't follow what you mean about multi-line strings. I know you can't
>mean this, which REXX handles just fine:
>
> Longstr='blah blah blah blah blah blah blah blah',
> 'blah blah blah blah blah blah blah blah blah'
>
No,
On Tue, 22 Jun 2021 11:23:41 +, Seymour J Metz wrote:
>Yes, I know that TSO support requires heavy lifting, and not just for fopen().
>
What else?
Would a build of OoRexx without fopen() be useful?
(bI've long wished that catalogued data sets could routinely be mounted
via NFS so open()
On Thu, 24 Jun 2021, at 01:57, David Crayford wrote:
> For example, to create and ISPF in Lua you instantiate and ISPF object
> and then communicate with it by calling methods
> https://lua4z.github.io/Lua4z/modules/ispf.html.
That shows eg that you can invoke ispf edit via lua. But can you
: Thursday, June 24, 2021 9:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 24/06/2021 8:51 pm, Seymour J Metz wrote:
> The only meaning that I'm familiar with is the one that I get on a search for
> 'callback definition programming'. Or were you thinking of a non-co
Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Thursday, June 24, 2021 5:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 24/06/2021 9:23 am, Seymour J Metz wrote:
You invoke ISPF. You call a REXX script
ur J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom
Brennan [t...@tombrennansoftware.com]
Sent: Wednesday, June 23, 2021 10:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
Ok (probably just f
: Re: Coding for the future
On 24/06/2021 9:23 am, Seymour J Metz wrote:
> You invoke ISPF. You call a REXX script for ISPF. The script does ADDRESS
> ISPEXEC foo and ISPF gets control back. It's well documented in the TSO/E
> REXX Reference, and other implementations have essentially the
d Crayford [dcrayf...@gmail.com]
Sent: Wednesday, June 23, 2021 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
Maybe I'm missing a subtlety here but can you demonstrate how REXX uses
callbacks on z/OS? I'm familar with command environments, I've written
one for REXX re
PL/I, Python or Ruby.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Wednesday, June 23, 2021 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding fo
@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Wednesday, June 23, 2021 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
Maybe I'm missing a subtlety here but can you demonstrate how REXX uses
callbacks on z/OS? I'm familar with command environments, I've
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Wednesday, June 23, 2021 3:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 23/06/2021 10:38 am, Seymour J Metz wrote:
None of those
] on behalf of
Peter Sylvester [peter.sylves...@gmail.com]
Sent: Wednesday, June 23, 2021 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
Hi,
What about extending/embedding.html of the python doc ?
On 23/06/2021 13:04, Seymour J Metz wrote:
> Allow applications to establ
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Peter Sylvester [peter.sylves...@gmail.com]
Sent: Wednesday, June 23, 2021 12:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 23/06/2021 13:04, Seymour J Metz wrote:
> Al
: Re: Coding for the future
Hi,
What about extending/embedding.html of the python doc ?
On 23/06/2021 13:04, Seymour J Metz wrote:
> Allow applications to establish environments for scripts (ADDRESS) , allow
> call-backs from within scripts and access the variables of the scripts. I
On 23/06/2021 13:04, Seymour J Metz wrote:
Allow applications to establish environments for scripts (ADDRESS) , allow
call-backs from within scripts and access the variables of the scripts. I wish
that I could do that from within Perl, although I'd take the time to learn
Python or Ruby if
Hi,
What about extending/embedding.html of the python doc ?
On 23/06/2021 13:04, Seymour J Metz wrote:
Allow applications to establish environments for scripts (ADDRESS) , allow
call-backs from within scripts and access the variables of the scripts. I wish
that I could do that from within
On Wed, 23 Jun 2021 07:25:40 +0800, David Crayford wrote:
> Rocket and IBM don't see any value in integrating
>ported tools with TSO as it's not strategic. The main focus is on
>containers.
Is it zCX containers that run Linux workloads or something else?
MKK
.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Wednesday, June 23, 2021 3:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 23/06
...@gmail.com]
Sent: Tuesday, June 22, 2021 7:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 22/06/2021 10:19 pm, Seymour J Metz wrote:
It's not a question of what environment it can run in; it's a question of what
facilities it supports in those environments.
Indeed. Lua
.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Tuesday, June 22, 2021 7:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 22/06
M-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 22/06/2021 8:55 pm, Seymour J Metz wrote:
What distinguishes REXX is not syntactic sugar but the plumbing that
enables close coupling of scripts with applications. Lua is missing
that.
Maybe. But I can't think of an environment that REXX runs in th
Crayford
Sent: Tuesday, June 22, 2021 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 22/06/2021 8:55 pm, Seymour J Metz wrote:
What distinguishes REXX is not syntactic sugar but the plumbing that enables
close coupling of scripts with applications. Lua is missing
Gil, I don't follow what you mean about multi-line strings. I know you can't
mean this, which REXX handles just fine:
Longstr='blah blah blah blah blah blah blah blah',
'blah blah blah blah blah blah blah blah blah'
And your second wish is surely not significantly different from:
"LA LA LA LA...!"
Ok, truthfully, I keep meaning to dig out PL/1 and start using it again.
Someday. But I do adore REXX. I wrote in CLIST for years, but one day (back
in the '80s, it was) encountered a warning from IBM threatening someday to stop
supporting CLIST and to make REXX the
I do something similar, although rarely. When I need to load a table and it
seems to make sense that the data be hardcoded in the code -- which after
all is pretty seldom -- sometimes I do this:
/* TBLBGN (usually at the end of the program):
name1 value1
name2 value2
name3
Sent: Tuesday, June 22, 2021 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 22/06/2021 8:55 pm, Seymour J Metz wrote:
> What distinguishes REXX is not syntactic sugar but the plumbing that enables
> close coupling of scripts with applications. Lua is missing that.
On 22/06/2021 8:55 pm, Seymour J Metz wrote:
What distinguishes REXX is not syntactic sugar but the plumbing that enables
close coupling of scripts with applications. Lua is missing that.
Maybe. But I can't think of an environment that REXX runs in that Lua
can't. I could port Python to run
From: IBM Mainframe Discussion List on behalf of
David Crayford
Sent: Tuesday, June 22, 2021 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 22/06/2021 7:23 pm, Seymour J Metz wrote:
> Yes, I know that TSO support requires heavy lift
;
},
}
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Tuesday, June 22, 2021 2:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Sub
du/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Tuesday, June 22, 2021 2:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 22/06/2021 3:21 am, Seymour J Metz wrote:
> When
@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Sunday, June 20, 2021 9:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 21/06/2021 2:08 am, Paul Gilmartin wrote:
Do you want to report every error, or leave after the first one?
I wish Rexx supported
9:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On 21/06/2021 2:08 am, Paul Gilmartin wrote:
> Do you want to report every error, or leave after the first one?
> I wish Rexx supported multi-line strings.
>
> I wish Rexx would let me:
> do List = "
On Sat, 19 Jun 2021 09:03:13 -0500, Paul Gilmartin wrote:
>(where does "EXTERNAL:" in the Subject: come from?
>Can it be suppressed?)
I can't speak for others, of course, but within IBM, our mail gateways now tag
all of our external e-mail with "[EXTERNAL]". This was an intentional change
to
cussion List [IBM-MAIN@LISTSERV.UA.EDU] on
behalf of Bob Bridges [robhbrid...@gmail.com]
Sent: Friday, June 18, 2021 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Coding for the future
Ack! To my mind
if fx then
do
ntim=ntim+1
end
else
do
nr
On 21/06/2021 2:08 am, Paul Gilmartin wrote:
Do you want to report every error, or leave after the first one?
I wish Rexx supported multi-line strings.
I wish Rexx would let me:
do List = "ssn ssx stm wcn wcx wln wlx wld" while List<>""
parse var List L List
/* etc. */
On Sun, 20 Jun 2021, at 20:03, Jeremy Nicoll wrote:
> I have in the past rather than using just numbered elements of stems eg
>
> thing.1 = "The problem here is"
> thing.2 = 21
> thing.3 = 25
>
> typically defined
>
> _errpfx = 1 ; _xcoord = 2 ; _ycoord = 3 ...
I slightly
On Sun, 20 Jun 2021, at 19:08, Paul Gilmartin wrote:
> On Sun, 20 Jun 2021 18:08:39 +0100, Jeremy Nicoll wrote:
> >> >
> >> I see. I'd be inclined to code the repetitive part of that as a loop.
> >
> >There'd be no gain in converting the 8 separate named-for-what-they do
> >variables
> >into
On Sun, 20 Jun 2021 18:08:39 +0100, Jeremy Nicoll wrote:
>> >
>> I see. I'd be inclined to code the repetitive part of that as a loop.
>
>There'd be no gain in converting the 8 separate named-for-what-they do
>variables
>into stem variables if that's what you mean, unless one also defined _bfe,
On Sun, 20 Jun 2021, at 17:25, Paul Gilmartin wrote:
> On Sun, 20 Jun 2021 16:09:54 +0100, Jeremy Nicoll wrote:
> >
> >> So what would you do? Suppose it'd not just [been] three things
> >> that need to be exclu[d]ed first but, say, twenty?
> >
> >select
> > when words(f!ce_bfe) \== 1 then
On Sun, 20 Jun 2021 16:09:54 +0100, Jeremy Nicoll wrote:
>
>> So what would you do? Suppose it'd not just three things
>> that need to be exclued first but, say, twenty?
>
>select
> when words(f!ce_bfe) \== 1 then f!ce_err = "bfe '"f!ce_bfe"' not a single
> word"
> when
On Sun, 20 Jun 2021, at 15:57, Jeremy Nicoll wrote:
> So what would you do? Suppose it'd not just three things
> that need to be exclued first but, say, twenty?
Oops, sent that too soon. I find it useful often, usually when
validating things, eg:
select
when words(f!ce_bfe) \== 1 then
On Sun, 20 Jun 2021, at 13:39, Paul Gilmartin wrote:
> On Sun, 20 Jun 2021 10:48:09 +0100, Jeremy Nicoll wrote:
> >Really? What's wrong with
> >
> >select
> > when name='' then nop
> > when st<>'NC' then nop
> > when GetAmount(userID) > then nop
> > otherwise call ProcessUser
> >end
> >
: Sunday, June 20, 2021 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
On Sun, 20 Jun 2021 10:48:09 +0100, Jeremy Nicoll wrote:
>>
>> For example, something like this:
>>
>> /* is this a user we want to process? */
>> do
>> if name='
On Sat, 19 Jun 2021 23:59:21 -0400, Roger W Suhr wrote:
>
> I didn't look out for the indenting, sorry. I used on one line, but
>not on the other, but recently I started to add comments to the "END"
>statement in more complex code, to help with clarity:
>
>if fx then do
> ntim=ntim+1
On Sun, 20 Jun 2021 10:48:09 +0100, Jeremy Nicoll wrote:
>>
>> For example, something like this:
>>
>> /* is this a user we want to process? */
>> do
>> if name='' then exit do /* no */
>> if st<>'NC' then exit do /* no */
>> amount=GetAmount(userID)
>> if amount> then exit
On Sat, 19 Jun 2021, at 23:47, Bob Bridges wrote:
> Peter Sylvester's post reminded me (for no reason I can identify) of
> something else I do in any language that doesn't have an EXIT DO
> statement.
>
> For example, something like this:
>
> /* is this a user we want to process? */
> do
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coding for the future
Actually its probably added by a rule in Office 365.
Joe
On Sat, Jun 19, 2021 at 8:04 PM Seymour J Metz wrote:
> > (where does "EXTERNAL:" in the Subject: come from?
>
> Brain-dead e-mail software. There'
1 - 100 of 232 matches
Mail list logo
