[pcre-dev] Porting PCRE to z/OS - current status 07/29/2012

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