BREXX PARSE errors with literals in the template

[BobBolch]

I opened this issue with the original BREXX implementation. The bug has been carried over into the MVS and CMS versions of BREXX.

 https://github.com/vlachoudis/brexx/issues/8

All versions of BREXX have the parsing error with literals in the template.

Bob

[RossPatterson]

I have a fix in progress for this bug. In order to confirm that I have fixed it, and that I have not made something else worse, I need some test cases for the Rexx PARSE instruction. If any of you have known cases where BREXX'S PARSE does not behave correctly, especially cases that work correctly in either IBM VM Rexx, or in Mark Hessling's Regina implementation, I'd love for you to share them with me. Likewise if you have "creative" uses of PARSE.

What I need is:

1. The PARSE statement.
2. An example input to be parsed.
3. The variable values that you expect it to set.

Please add them to this issue.

[marXtevens]

Here are several that work on VM/SP5 (SDF.org)

PARSE SOURCE . . ?fn? ?ft? ?fm? . /* Find out who we are. */

The following could be for just about any command needing a file and options to process it.

GENPROG MY EXEC A ( CLEANUP NOCOMP

PARSE UPPER ARG fn ft fm . '(' Options /* Find arguments from command.*/

DO WHILE Options ?= ''                 /* Are there any options left? */  
                                       /* Isolate the next one.       */  
   PARSE VALUE Options WITH Option Options                               
   SAY 'Option: ' Option
END                                                                      

... Mark S.

[RossPatterson]

The fix for the upstream, original BREXX is complete and tested, and I havesubmitted a PR. I'm now adapting it to the CMS370 (VM/370) version.

[rvjansen]

Great work, Ross. Thank you!

On 14 Oct 2024, at 16:10, Ross Patterson @.***> wrote:

The fix for the upstream, original BREXX is complete and tested, and I havesubmitted a PR. I'm now adapting it to the CMS370 (VM/370) version.

— Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/61#issuecomment-2411385081, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3WJQMJ3ROAKREDQ463PMLZ3PGGVAVCNFSM6AAAAABPIWGGDKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJRGM4DKMBYGE. You are receiving this because you are subscribed to this thread.

[RossPatterson]

Here is the fix summary from the upstream fix. I have ported the fix to BREXX-CMS370, and it builds and verifies correctly on VM/CE 1.2. I'm having problems with the GitHub CI system that I need to resolve before I can make a beta release for others to test.

---

This PR implements the WORDPARSE operation from section 8.3.1.7 (pp. 86-90) of the ANSI X3J18-199X REXX Standard. This changes bREXX's PARSE instruction to correctly parse blank-separated targets between triggers, including the implied start-of-string and end-of-string triggers.

Because bREXX splits the FINDNEXTBREAK operation from the standard between the compiler and the interpreter, and out of a desire to make the fix as non-invasive as reasonably possible, I chose to leave most of the processing intact, with several significant changes:

1. The compiled code for PARSE no longer proceeds in a straight path from OP_PARSE to OP_TR_END and OP_POP. Instead, I inserted OP_JMPs such that parsing of word-separated targets does not begin until after the trigger to their right has been evaluated. This results in all blank-separated targets are now correctly parsing only the data between the triggers to their immediate left and right.
2. I introduced two more parsing-position variables in the main interpreter loop: word_start and word_end. These are used by the blank-separated-target parsing code to walk through the words in the input substring that was isolated by the triggers.

bRexx has no test suite, but I created a set of tests for PARSE that verify correct operation. To do so, I pulled many examples from my collection of Rexx code, and I typed in all the examples from Mike Cowlishaw's The Rexx Language, 2nd edition. I have attached the file parse_.txt, which demonstrates the failure described in Issue #8 (test 2 in the file), as well as several others I discovered while investigating this bug (tests 3, 8, and 20). It also shows one questionable behavior, that I need to confirm against the original VM/CMS Rexx implementation (test 16), and one separate bug that I'll open up another issue for (test 19). This PR fixes all but the last two, which will be addressed separately (if at all). Run the tests by simply running brexx parse_.txt.

parse_.txt