Porting Poco to the big iron

[crayford]

Greetings!

I'm in the process of porting Poco to the mainframe. By that I mean z/OS not z/Linux. It's going quite well but the big issues are ASCII related.
I notice that Poco has an ASCII class which is used by tokenizers. This won't do for an EBCDIC platform and nor will hard coded tests for ASCII
characters. Is there any reason why cctype or ctype.h were not utilized? Is there any other areas I should be looking at for ASCII/EBCDIC issues?

Also, I need to put some ASCII->EBCDIC EBCDIC->ASCII translation code into the Net library for HTTP, FTP etc. The stream classes are really
good so I suppose I should use EBCDICEncoder, ASCIIEncoder classes to do that. Any advice would be welcomed.

[guenter]

Sounds like an interesting project.
The big issue with using ctype is that on some platforms, depending on the current locale, the ctype functions will fail if applied to a non-ASCII character (those > 127). That's the main reason we've introduced the ASCII class - to get consistent behavior across all platforms. Of course we did not think of EBCDIC systems when doing that (I worked with these beasts 20 years ago...). I guess a good way to handle that would be to create add an EBCDIC class providing the same features as ASCII, and then providing a new type Poco::Character, that's either typedef'd to ASCII or EBDCID depending on platform. This should handle the tokenizers. The Net classes are another issue, though, as every protocol on the net is based on ASCII.
We'll also need an EBCDICEncoding class, for use with the character encoding classes.

[crayford]

Thanks for the prompt reply! Your suggestions seem like the way to go. When I've finished the port are you interested in taking the changes into your main source tree
or do you want me to keep a seperate patch file?

I understand the ASCII issues with Net, I ported libcurl a few years ago. The motivation for porting Poco was for it's networking features. I've already ported boost but
I prefer the Java-like format of Poco. It also compiles a fair bit quicker than boost because it's not header file only.

FYI, z/OS has a POSIX/SUSV3 UNIX subsystem so the port is reasonably straight forward http://en.wikipedia.org/wiki/UNIX_System_Services. Almost all of the modern
middleware like WAS and of course Java are all UNIX ports so it's top quality, as is the C/C++ compiler. The big issues when porting to z/OS is ASCII. If I can iron that out then all is well.

BTW, thanks for a great library. I'm looking forward to using it in anger.

[crayford]

ok, I've built Poco and I'm currently running through the test suites.

I've changed all the parts that I wouldn't compile or need platform implementations:

• Atomics
• Threads
• Semaphores
• Shared Memory
• Sockets

Now I'm going to attack EBCDIC. I will implement an EBCDICEncoding class and all the other stuff.
Is there a hook point in the code for HTTP/FTP streams where I can translate the code pages close to the device?

[guenter]

There is no easy way to do the ASCII/UTF-8 to EBCDIC transcoding at a lower level. You'll probably have to wrap the calls to buf.sbumpc() (e.g., in Poco::Net::MessageHeader) in a function that does the transcoding. Or add the transcoding to the various stream classes. Nasty stuff.

[crayford]

That's unfortunate! I had a plan to use a custom char_traits with BasicBufferedStream but that won't cut it because I need to convert from EBCDIC->ASCII and ASCII->EBCDIC.
Also some streams are unbuffered. I'm still learning the code so bear with me.

The test suites are proving to be invaluable. That's the hallmark of a top quality library.