Oppolzer - Informatik / Blog

Hello D.,

some comments below.

Kind regards

Bernd



Am 25.02.2014 16:59, schrieb D.J.:
> Hello, Bernd.
>
> Thank you very much for your help with this, it's been of great use.
>
> PCRE stands for "Perl Compatible Regular Expressions" and Z.A.
> has ported the C library over to z/OS, with APIs for both COBOL (which
> works) adn PL/I (which doesn't).
>
> The COMPILE8 routine takes a regular expression and returns a pointer to
> the pcre structure, which, in turn, is used by the 'exec" routine to do
> the actual matching against a text string.
>
> In C code, it is invoked like this:
>   pcre *re;
>           const char *error;
>           int erroffset;
>           re = pcre_compile(
>             "^A.*Z",          /* the pattern */
>             0,                /* default options */
>             &error,           /* for error message */
>             &erroffset,       /* for error offset */
>             NULL);            /* use default character tables */

this looks very good to me and makes perfect sense now ...

> The pattern is a C string terminated by a binary zero, and is passed in
> the  pattern  argument.  A  pointer to a single block of memory that is
> obtained via pcre_malloc is returned. This contains the  compiled  code
> and related data. The pcre type is defined for the returned block; this
> is a typedef for a structure whose contents are not externally defined.
> It is up to the caller to free the memory (via pcre_free) when it is no
> longer required.
>
> The options argument contains various bit settings that affect the
> compilation. It should be zero if no options are required.

if there are several options which can be set simultaneously, you could define
constants for them and "add" or "logical or" them, when issuing the call ...

>
> If errptr is NULL, pcre_compile() returns NULL immediately.  Otherwise,
> if compilation of a pattern fails,  pcre_compile()  returns  NULL,  and
> sets the variable pointed to by errptr to point to a textual error mes-
> sage. This is a static string that is part of the library. Normally, the
> offset from the start of the pattern to the data unit that was being
> processed when the error was discovered is placed  in the variable
> pointed to by erroffset, which must not be NULL (if it is, an immediate
> error is given). This is the confusing part to me....how the offset and
> error message text are handled....

not confusing for me; if an error is detected, you get the pointer to the error
message and the offset (the error position) into the input message (byte
position starting from the begin of the input message, where the error was
detected). Let's discuss this again, if you have further questions ...

> As P.E. has pointed out, the PL/I available on z/OS has
> significantly more capabilities for handling this sort of problem than
> the PL/I we have available on z/VM. I plan on fixing this by writing a
> small bit of PL/I "glue" code that would be callable by the old PL/I for
> MVS and VM and have it do the real call, since PL/I code compiled on
> z/OS is runnable without change (almost) on z/VM.

this is where I believe you will run into troubles.

The old PL/1 you are using will probably not have the BYVALUE attributes for the
parameters and the return value. So you are stuck with BYADDR and with the
RETURN mechanism that I pointed out in my earlier posts (and maybe with PLIRETV
with type BIN FIXED (15)). So you will probably not be able to do a PL/1 glue
routine, that fixes this. You will need to do a C glue routine (what I called a
wrapper function in my earlier posts), or - of course - ASSEMBLER, which would
work, too. Maybe there is a way to do it with PL/1, but this will become very
ugly and strange (for example: get rid of descriptors, when passing CHAR
strings, by passing DEC FIXED(1) instead, which overlay the CHAR strings - old
workaround instead of NODESCIPTOR - when the old PL/1 compilers didn't have
NODESCRIPTOR - but I guess: there is no such easy workaround for BYVALUE ...)

Maybe P.E. can jump in and give some suggestions for this, too.

> Thanks again.
>
> DJ