Hello all
I know it sounds like back-to-the-future kind of thing but I am porting (or 
trying to port) 'pcre' into z/OS (of EBCDIC fame), with the restriction of 
native z/OS (i.e. NO UNIX services whatever.)  My rational is to introduce 
regular expressions into COBOL, PL/I and Rexx, the most popular native z/OS 
languages.  Below I enumerate the main issues.

I wrote an automatic process that convert the needed modules and compile and 
link them into statically linked (to the point that in times my process needs 
to add explicit INCLUDE statement to the binder) independent modules (no dll is 
available under my restrictions above.)  To those who know z/OS, the source 
library has to be RECFM=VB,LRECL=255 and the executable library must be a PDSE.

When FTPing to the mainframe, the character '^' translates correctly to x'bo' 
but the z/OS C compiler prefers the character x'5f' or the trigraph ??'.  My 
process resolves this issue.
Also, the character 'ÿ' is x'ff' in ASCII and it stops the FTP dead.  I did not 
yet resolve this issue which also affects the question of pushing EBCDIC to its 
limits below.

The provided pcre_test.c actually compiles and runs on this platform but with 
some strange results.
1. It is clear that many of the tests do not work properly.  Some of them push 
the EBCDIC environment to the limit but some of them are legitimate and should 
work, which leads me to believe that there are issues with the EBCDIC 
implementation.
2. There is a problem in the C that is almost definitely due to some 
configuration or conversion mistake vis a vis IO or storing new-line character 
and not due to logic error.

Since the test driver is NOT part of the core logic and since I need to test 
the modules in conjunction with COBOL anyway, I am now in the process of 
converting the test driver to COBOL (a manual process unfortunately) so I can 
concentrate on #1 above.  However, I ask if there is anybody who is familiar 
enough with C on z/OS and would like to take a look at the thing.

When I let it read from stdin (SYSIN) and write to stdout (SYSPRINT) I get the 
results only ([i.e. position or "no match" ] correct or incorrect), most of 
them are in new lines as they should, but the image of the input is not 
printed. When I read an actual phisical file and output to an actual phisical 
file, the image of the input is printed as a one long line (wrapped around) but 
no result is printed. Since the program was converted almost verbatim, I assume 
that it's logic, which was correct in Linux, is still correct and what causes 
the problem is either some configuration option or conversion mistake. 

 
Ze'ev Atlas
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

Reply via email to