[omniORB] Porting omniorb to an ebcdic machine (OS 390 unix)

[Sai-Lai Lo]

Is it a coincidence that you and Jacques both work on the IBM port? This is
email is also an answer to Jacques earlier query.

Jacques has sent me a snapshot of his port to OS/390 unix subsystem. As far
as he can tell, it works well communicating between EDCDIC machines. I've
put the tar-ball in 

ftp://ftp.uk.research.att.com/pub/omniORB/contrib/omniORB-2.8.0-os390u.tgz

He also have the problem of converting EBCDIC to ASCII and vice versa.

As I've told Jacques, I think the best way to tackle the problem is to
convert between ASCII and EBCDIC in the marshalling code.

The work requires going into the idl compiler to modify the generated code
for string and char plus some changes to the runtime. 

1. For string, the marshalling code is in:
        a) src/lib/omniORB2/orbcore/corbaString.cc
             - the marshalling operators for _CORBA_String_member,
                                             _CORBA_Sequence__String

        b) src/tool/omniidl2/omniORB2_be/o2be_operation.cc
             - the code bit that generate marshalling code for string:
                 produceMarshalCode()
                 produceUnMarshalCode()
                 produceSizeCalculation()
                 produceConstStringMarshalCode()
                 produceConstStringSizeCalculation()

                All the case branch that deals with type tString has to be
                changed.

2. For char, this is more problematic because the CORBA char is the same
   type in C++ mapping with CORBA octet and may be CORBA boolean. There is
   just one set of marshalling operators for the three. Now you have to
   distinguish the Char case from the other 2. I think you should be able
   to isolate all Char marshalling code in the few functions inside
   o2be_operation.cc as listed for string above.

   sequence of char is another problem because we implemented this using the
   sequence template _CORBA_Unbounded_Sequence_w_FixSizeElement and
                     _CORBA_Bounded_Sequence_w_FixSizeElement.
   These templates have fast marshalling operators that you also want to
   change to include your conversion routine if it is a sequence of char.

   I suggest you create 2 new template class _CORBA_Unbounded_Sequence__Char 
   and its bounded equivalent, similar to the existing ones for boolean and
   octet (e.g. _CORBA_Unbounded_Sequence__Boolean).

   You then have to modify the IDL compiler to generate stub to use the new
   classes. The relevant file is src/tool/omniidl2/omniORB2_be/o2be_sequence.cc

   The same applies to sequence<array of char>. I.e. you have to create
   specialisation template for this type.

   (Would be nice if we can just use template specialisation but we can't
   because not all compilers support it.)

3. The marshalling code for object reference has to be changed.
   There are 2 parts that needs changing:
      a) The repository ID string
            Change this in src/lib/omniORB2/orbcore/objectRef.cc:
                 marshalObjRef, UnMarshalObjRef, AlignedObjRef.
            Remember like all marshalling code there is a NetBufferedStream
            version and a MemBufferedStream version.

      b) The host address field in the IIOP profile.
            Change this in src/lib/omniORB2/orbcore/tcpSocket.cc
                   decodeIOPprofile, encodeIOPprofile.

  This should also take care of stringified IORs.


4. The relevant bits in src/lib/omniORB2/orbcore/giopServer.cc and
   giopClient.cc have to be changed to make the necessary conversion when
   the strings in the GIOP request header is marshalled. At least 2 fields
   in the header have to be converted:
       a) the first 4 chars 'G' 'I' 'O' 'P'
       b) the operation name.

5. If you use the tcpwrapper gatekeeper, its code has to be changed to do
   the conversion.
 
6. Typecode.
   The marshalling of repository ID, member name and other string members
   in a typecode. I think the modification above would look after this but
   you want to do some testing to make sure this is the case.


There may well be other places that needs changing. This is just a list of
what I can think of at the moment.

Regards,

Sai-Lai


>>>>> hoovey  writes:

> I am porting omniorb 2.8 to an EBCDIC platform. I have the echo examples
> all running on an EBCDIC machine and I am now going to try and tackle
> getting character conversions to work so that it complies with CORBA and
> can be used with ASCII machines.  I believe there are following pieces need
> to be changed:

> 1) On the get/put of data so that data being passed is passed in ASCII
> 2) Parts of the code do comparisons against character data, I will need to
> find these an ensure they are considered ASCII hex data comparisons
> 3) The nameserver omniNames needs the IOR information in ASCII??
> 4) Remote procedure calls are in ASCII??

> Does anyone have any hints as to the best place to try and add the
> conversions for get/put? I am afraid I can't put it in the
> align_and_xxx_bytes routines because it may be used for more than just the
> places I need conversions to occur.

> Do these seem like the right changes that need to be made? Can you think of
> any others I should be aware of?

> I will admit I am very new to CORBA and omniORB, so any help would be
> great!

> Thanks,

> Paul S. Halverson
> (507) 253-5658   (Tie) 553-5658
> hoovey@us.ibm.com





-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND