I think you should abandon the idea of trying to replicate perl syntax. Perl makes me want to hurl, it's user hostile. I just copied the API functions like match, search, replace and implemented a command for each one. I could and should have added functionality to process an entire stem array or file for efficiency.
On 27/07/2013, at 12:09 AM, John McKown <[email protected]> wrote: > I remember and have kept the notes. But the "problem" is designing the > "command set" to be implemented for the ADDRESS PCRE subcommand > environment. > > E.g. > > ADDRESS PCRE > "(REXXVAR)=~s/[^[:print:]]/ /g" /* translate unprintables to blanks in > place*/ > "(NEWVAR)=(REXXVAR)~/s/[^[:print:]]/ /g" /* translate unprintables to > blanks and put the results in NEWVAR > > But is that a good syntax? I'm not sure. It may be "too Perl-like" for REXX > people. > > On Fri, Jul 26, 2013 at 8:35 AM, David Crayford <[email protected]> wrote: > >> I described how I did this a few weeks ago. I wrote two assembler >> programs, the first to create the command enviroment(IRXSUBCM) and >> initialize a persistent LE environment (CEEPIPI). There >> is a user token in the SUBCM control block where you can store state, like >> the PIPI handle. The second one just grabs the PIPI handle from the user >> control block and calls a C++ program to do the >> fancy stuff. I used the C++ TR1 regex library so it supports lots of >> different flavours of regex - basic, extended, ECMAScript, awk, grep and >> egrep.|| ECMAScript is almost identical to PCRE but >> not quite as good. Have fun. >> >> >> On 26/07/2013 8:01 PM, John McKown wrote: >> >>> Yes, I have a guest account for this project. The plus of using HLASM and >>> CEEPIPI is that I can keep the LE environment "active" even when the HLASM >>> interface program returns to REXX. If I use a C main routine, unless I am >>> mistaken, that when it returns, the LE environment will be destroyed. >>> Being >>> the weirdo that I am, I try to save every millisecond of CPU that I can. >>> So >>> using HLASM / CEEPIPI might result in a fair amount of savings if someone >>> uses the interface heavily in some REXX routine. >>> >>> What I'm trying to figure out how to do is something akin to what ISPF and >>> SDSF do with their "ADDRESS ISPEXEC" and "ADDRESS SDSF". I want to create >>> an "ADDRESS PCRE". But I've ever and only been a sysprog. Not a developer. >>> I can develop code fairly well. But doing _design_, especially on a >>> conceptual level, is not a strong skill of mine. >>> >>> On Fri, Jul 26, 2013 at 3:52 AM, David Crayford <[email protected]> >>> wrote: >>> >>> On 26/07/2013 9:56 AM, John McKown wrote: >>>> >>>> I'm still trying to look at how I might due a REXX interface to PCRE. >>>>> But >>>>> I'm not sleeping well due to a sick dog and so just don't have much >>>>> extra >>>>> energy after work. I do now have access to a remote system with a C >>>>> license. But I might actually find it easier to us HLASM and a CEEPIPI >>>>> environment, rather than C. >>>>> >>>>> John, bite the bullet and hack a bit of C. It's easy, especially if you >>>> already know assembler! Did some kind soul offer the use of their system? >>>> >>>> >>>> >>>> On Jul 25, 2013 8:43 PM, "Ze'ev Atlas" <[email protected]> wrote: >>>> >>>>> Gentlemen >>>>> >>>>>> The example and explanations are exactly what I needed to give me the >>>>>> head >>>>>> start (and now I can go to the manual and have some better >>>>>> understanding >>>>>> of >>>>>> details if I need them :) >>>>>> >>>>>> I caught the SYSUT1/SYSUT2 issue and assumed right away that it was a >>>>>> typo. >>>>>> >>>>>> Thank you so much >>>>>> >>>>>> Now - with your help, adding the functionality of deciding what type of >>>>>> file I am looking at (using fldata) and sending it to the correct piece >>>>>> of >>>>>> code seems much less intimidating. HFS files and flat files will >>>>>> pretty >>>>>> much go to the existing Unix oriented code and dealing with PDS is >>>>>> pretty >>>>>> much coded and tested. I will try to code the additional functions in >>>>>> most >>>>>> generic way and since it is open source, it probably could be used all >>>>>> over. >>>>>> >>>>>> It will be shipped with the next version of PCRE for z/OS project. >>>>>> >>>>>> Ze'ev Atlas >>>>>> PCRE for z/OS Open Source project >>>>>> >>>>>> Volunteers are welcome >>>>>> >>>>>> Still in need for analyzing, designing and implementing Rexx interface! >>>>>> >>>>>> ------------------------------****----------------------------**--** >>>>>> ---------- >>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>>> send email to [email protected] with the message: INFO IBM-MAIN >>>>>> >>>>>> ------------------------------****----------------------------**--** >>>>> ---------- >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email to [email protected] with the message: INFO IBM-MAIN >>>>> >>>>> ------------------------------****----------------------------** >>>> --**---------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to [email protected] with the message: INFO IBM-MAIN >> >> ------------------------------**------------------------------**---------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN > > > > -- > This is a test of the Emergency Broadcast System. If this had been an > actual emergency, do you really think we'd stick around to tell you? > > Maranatha! <>< > John McKown > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
