. Just to be clear, the original implementation of ReXX was for VM
. in about 1980, well before OS/2.
Oh yes, I totally agree. What I was attempting to say was that the
original implementation published by RexxLA was based upon the
implementation I cited in the IBM announcement letter.
I stil
"IBM Mainframe Assembler List" wrote on
02/21/2022 09:48:57 AM:
> I like REXX a lot and I find it to be very adept at parsing
> information, but I don't find it to be that adept at conversions --
> particularly packed-decimal conversions.
I suppose I could have just created D2P()
> I like REXX a lot and I find it to be very adept at parsing information,
I'm a REXX bigot, but when it comes to parsing there are better languages,
e.g., Icon, Perl. It would be nice if TSO/E would pick up PCRE and RexxLA would
upgrade the RegularExpression class to equivalent functionality fo
"IBM Mainframe Assembler List" wrote on
02/22/2022 12:15:21 PM:
> > I like REXX a lot and I find it to be very adept at parsing
information,
>
> I'm a REXX bigot, but when it comes to parsing there are better
> languages, e.g., Icon, Perl. It would be nice if TSO/E would pick up
> PCRE and Rex
On Feb 22, 2022, at 10:15:21, Seymour J Metz wrote:
>
>> I like REXX a lot and I find it to be very adept at parsing information,
>
> I'm a REXX bigot, but when it comes to parsing there are better languages,
> e.g., Icon, Perl. It would be nice if TSO/E would pick up PCRE and RexxLA
> would up
I would absolutely prefer POSIX ERE, with which I have many years of experience
via gawk programming. I am not comfortable with PCRE at all.
+1 for the back-reference assignments.
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Paul Gilmartin
Sent: Tuesday, F
I have migrated , and maintaining PCRE on z/OS on regular basis. I do provide
TSO/REXX interface. All available on CBT file 939.I presented that in RexxLa
symposium, just to encounter animosity from at least one audience member who
had suggested that I should do a standartized version (stadart
We are trying to optimize a search routine for keys in fixed length rows
in an unordered array. As the number of rows in the array grows, a
serial search becomes relatively inefficient, so we looked for another
technique. We tried a SEARCH STRING (SRST) against a one byte hash of
the key to see
Gary,
The first thought that comes to mind is why not sort the table and use a binary
search?
If in fact the table is being updated and that is not practical, then your
options are a serial search (which you have ruled out) or a hash.
As you may have guessed, SRST and SRSTU are almost certain
On 2/22/2022 2:44 PM, Tom Harper wrote:
As you may have guessed, SRST and SRSTU are almost certainly milli-coded
instructions and probably not very fast.
In our benchmark testing, SRST reined supreme as the fastest
single-character linear search BY FAR until we discovered how to use the
vect
I was going to say all of these same things ... plus
Consider two tables, one of "stable keys" and one of "new keys." Sort and
binary search the stable list; do a linear search on the additions.
You can pseudo-delete a key from the stable table by turning on a "deleted"
flag.
You might also cons
Thank you, Dave, for your explanation of your use of Rexx stem
variables, and your definition of terms.
Bob
Thanks to all. From the responses so far and my experience I'm inclined
to believe SRST is hardware and probably SRSTU is millicode (perhaps
based on SRST for the first byte) and we must look for another technique.
My original thought was that we would use a serial search until the
number of key
Gary,
Aside from some minor differences with end-of-second-operand determination,
SRST and STRTU do pretty much the same thing, and it doesn't take the CPU any
longer to compare one byte versus two. So the only possible explanation that I
can think of to account for the differences in performan
I'll give up named captures when they pry them out of my cold dead fingers.
If I were using gawk then I would want ERE for that, but certainly not for any
heavy duty parsing. I'm not comfortable with any Unix-based regex syntax, but
the expressive power is too great to ignore. I'd really rather
Back-references are certainly essential, but for complicated expressions
assertions, named captures, etc., make life easier.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
Let's face realityThe top 20 popular programming languages in the world
(according yo TIOBE index), all except SQL, Assembly and perhaps Matlab have
built in Regex capability which is in most cases similar if not identical to
Perl/PCRE, and as powerfull.AWK is number 42. Rexx is somewhere betwe
On Feb 22, 2022, at 18:59:06, Seymour J Metz wrote:
>
> Back-references are certainly essential, but for complicated expressions
> assertions, named captures, etc., make life easier.
>
For substituting in a string, as in sed or vi, numbered back-references
Work well enough. Otherwise the progr
18 matches
Mail list logo