I was talking about SCEELKED at run time, no compile time. It's (or SCEELKEX for lower-case entry points) definitely required at compile time for static calls, and that works. But when I tried dynamic calls, even with SCEERUN in the linklist, it said it couldn't find the REG* modules.
>________________________________ > From: "Farley, Peter x23353" <peter.far...@broadridge.com> >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Wednesday, July 3, 2013 10:09 PM >Subject: Re: Announcing PCRE 8.33 for native z/OS > > >Sorry, application programmers here are not allowed ANY operator functions >(including "/D"). > >And I realized after I wrote my prior reply that SCEELKED was required in your >case because you used NODYNAM, thus needing static bind-time merging of the >modules from SCEELKED. I didn't need it because apparently DYNAM generates >the correct call to the SCEERUN* library(ies) at runtime or to the in-core C >runtime modules under the LE covers. Or maybe our automated compile scripts >already included SCEELKED. I have to check on that, just in case I am wrong. > If they do automatically include SCEEKLED I'll report back. > >In any case, thanks once again for the terrific POC (proof of concept) code. > >Peter > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Frank Swarbrick >Sent: Wednesday, July 03, 2013 6:41 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Announcing PCRE 8.33 for native z/OS > >Hmm, perhaps underscores did come with COBOL 4.2. I don't recall. > >Can you do "/D PROG,LNKLST" in SDSF? That will get you the active linklist. >The only CEE libraries we have there are CEE.SCEERUN and CEE.SCEERUN2. I >though that CEE.SCEELKED was a link/bind-time library only, but I could be >wrong! > >(What possible harm could it be for an applications programmer to look at the >system PARMLIBs.......) > >Not sure why my use of CP1140 didn't work. Maybe I'll fool around with it >later. > > >Frank > >>________________________________ >> From: "Farley, Peter x23353" <peter.far...@broadridge.com> >>To: IBM-MAIN@LISTSERV.UA.EDU >>Sent: Wednesday, July 3, 2013 4:20 PM >>Subject: Re: Announcing PCRE 8.33 for native z/OS >> >> >>Yes, it did execute just fine in batch from JCL with DYNAM, and our default >>COBOL code page is 1140 as well, and it still worked fine. However, I did >>not need to add SCEELKED to the STEPLIB so our systems folk probably have it >>in the linklist. No way for me to confirm that though, PARMLIB here is >>security protected against reads by ordinary people. >> >>Thanks for the note about using "value" for the length parameter to >>"regerror", I'll change that in my test program. >> >>We are running Enterprise COBOL 4.1 here, and I cannot seem to get it to >>accept underscores. Maybe that was added via PTF or APAR and we don't have >>it applied? Or maybe that was only introduced in 4.2? I'll have to go look >>that up in the FM's later. >> >>Have a happy and safe Independence Day. >> >>Peter >> >>-----Original Message----- >>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >>Behalf Of Frank Swarbrick >>Sent: Wednesday, July 03, 2013 4:55 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: Announcing PCRE 8.33 for native z/OS >> >>1) Did you actually get it to work (execute) with DYNAM? That is our shop >>standard as well, but when I try it I get a "program not found" error (S806), >>or if I add CEE.SCEELKED to the JOBLIB I get an S0C1(?!?!). Also, do you use >>codepage 1047 by default? I didn't expect it to work with codepage 1140 (our >>default) and it in fact did not work. (No errors given, but no matches >>either. >>2) Underscores are allowed in COBOL data names as of COBOL 4, I believe. >>3) Oops! Forgot to code that. You need to pass the length by value, though. >> I used "...value length of msgbuf", but you can use your "...value lmsgbuf' >>if you want. >>4) I won't ask. :-) >> >>Frank >> >> >> >> >>>________________________________ >>> From: "Farley, Peter x23353" <peter.far...@broadridge.com> >>>To: IBM-MAIN@LISTSERV.UA.EDU >>>Sent: Wednesday, July 3, 2013 1:20 PM >>>Subject: Re: Announcing PCRE 8.33 for native z/OS >>> >>> >>>Frank, >>> >>>First let me say: "Very cool, man!" I was inspired by your 30 minutes to >>>take a few of my own to see if I could duplicate your experiment in our >>>somewhat more staid (i.e., no PDSE's for application COBOL load modules) >>>environment, and sure enough I can. I had to make a couple of small changes >>>to your code to accomplish my test: >>> >>>1. Remove PROCESS cards and default to shop-standard PGMNAME(COMPAT) and >>>DYNAM >>>2. Change underscores to hyphens in the data names >>>3. Add "using" and "returning" parameters to the "regerror" call, which I >>>guess never caused you a problem due to no errors happening at execution time >>>4. Use double-quotes instead of apostrophes around the called program >>>names due to an internal application standard requirement (don't ask, long >>>story) >>> >>>So below is my revised copy of your code, which works when compiled to a >>>load module in a PDS and produces the same output as you got. Thank you for >>>taking the time to show us how to do this! >>> >>>Peter >>> >>>Revised code: >>> >>> identification division. >>> program-id. "TSTREGEX". >>> data division. >>> working-storage section. >>> 01 regex. >>> 05 re-nsub comp-5 pic s9(8). >>> 05 re-comp pointer. >>> 05 re-cflags comp-5 pic s9(8). >>> 05 re-erroff comp-5 pic s9(8). >>> 05 re-len comp-5 pic s9(8). >>> 05 re-ucoll comp-5 pic s9(4) occurs 2. >>> 05 re-lsub pointer occurs 10. >>> 05 re-esub pointer occurs 10. >>> 05 re-map display pic x(256). >>> 05 re-shift comp-5 pic s9(4). >>> 05 re-dbcs comp-5 pic s9(4). >>> 77 reti comp-5 pic s9(8). >>> 77 msgbuf display pic x(100). >>> 77 lmsgbuf comp pic s9(8). >>> >>> procedure division. >>> call "regcomp" using regex >>> content z"^a[[:alnum:]]" >>> value 0 >>> returning reti >>> if reti is not equal to zero >>> display 'Could not compile regex' >>> stop run >>> end-if >>> call "regexec" using regex >>> content z'abc' >>> value 0 0 0 >>> returning reti >>> perform check-reti >>> call "regexec" using regex >>> content z'qxp' >>> value 0 0 0 >>> returning reti >>> perform check-reti >>> call "regfree" using regex >>> goback. >>> check-reti. >>> evaluate reti >>> when zero >>> display 'match' >>> when 1 >>> display 'no match' >>> when other >>> move length of msgbuf to lmsgbuf >>> call "regerror" using regex >>> msgbuf >>> lmsgbuf >>> returning reti >>> display 'Regex match failed: ' msgbuf >>> stop run >>> end-evaluate >>> . >>> end program "TSTREGEX". >>> >>>-----Original Message----- >>>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >>>Behalf Of Frank Swarbrick >>>Sent: Wednesday, July 03, 2013 2:17 PM >>>To: IBM-MAIN@LISTSERV.UA.EDU >>>Subject: Re: Announcing PCRE 8.33 for native z/OS >>> >>>Not to discourage you, as I'm sure porting PCRE to z/OS is a fine idea, but >>>it would not be true to say that regex processing is not available for COBOL >>>(or PL/I) on z/OS. I was looking through the IBM XL C/C++ for z/OS Run-Time >>>Library Reference the other day (god knows why, since I don't even have >>>access to XL C/C++) and noticed that there were some regular expression >>>features. >>> >>>So I just took about 30 minutes and came up with this COBOL program (based >>>on C code found here: >>>http://stackoverflow.com/questions/1085083/regular-expressions-in-c-examples): >>> >>><Prior version of regex COBOL code snipped to shorten email> >>> >>>It compiles and runs fine, with the following results: >>>match >>>no match >>> >>>Pretty cool, I must say! >>>FWIW, I didn't need to have the regex data item be the group data item as >>>above. I could have just made it a DISPLAY PIC X(364), since I'm not >>>referring to any of the fields within the group in my COBOL program. >>> >>>Frank >-- > >This message and any attachments are intended only for the use of the >addressee and may contain information that is privileged and confidential. If >the reader of the message is not the intended recipient or an authorized >representative of the intended recipient, you are hereby notified that any >dissemination of this communication is strictly prohibited. If you have >received this communication in error, please notify us immediately by e-mail >and delete the message and any attachments from your system. > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
