[omniORB] Ebcdic codesets.

[Duncan Grisby]

On Monday 10 February, Corrigan Coleman wrote:

> Here are codeset tables for EBCDIC (CP037 & CP500) based on RFC1345.
> They are untested (Since I don't have an IBM mainframe lying around), and
> would appreciate it if someone would give them a whirl.

Thanks for these. Is there any reason for installing transmission code
sets for GIOP 1.0?  1.0 doesn't support code set negotiation, so it
should never be the case that anything other and ISO 8859-1 goes over
GIOP 1.0.

I assume you didn't really want to donate the copyright to the
now-defunct AT&T Laboratories Cambridge. What do you want the
copyright line to say?

> Note:	Compilation on the BS2000 suffers similar troubles as SGI, loosing
> unreferenced global static objects in libraries. The fix for this seems to
> be in using INCLUDE lib instead of RESOLVE lib in the BINDER. As a quick
> hack I just moved it into orbcore.

Can you try the current CVS contents, and define
OMNI_NEED_STATIC_FUNC_TO_FORCE_LINK in CORBA_sysdep.h?  That works for
SGI.

> The CORBA standard seems to assume that the client and servant end have a
> fixed native code set.

Yes.

> Can someone recommend how I should handle switching between codesets
> on the fly, Firstly, if I need to use different native codesets for
> servants in the one executable, Secondly, if the client side needs
> to switch?.

There's no way to do that at the moment. Using different code sets for
servants is problematic since code sets are attached to the cdrStreams
representing the network connections; the same network connection is
used for all servants. I think you can do it with a
serverReceiveRequest interceptor, except that there's no way to change
a stream's native code set at the moment. It would be easy to add that
to the cdrStream class. You would also need a serverSendReply
interceptor to set the code set again for the reply, just in case some
other thread had used the connection in the mean time. On the client
side, you could do the same with the client interceptors.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --