Browse Prior Art Database

Call Directory Service EBCDIC/ASCII Problems Resolution

IP.com Disclosure Number: IPCOM000116166D
Original Publication Date: 1995-Aug-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 103K

Publishing Venue

IBM

Related People

Cho, DY: AUTHOR [+3]

Abstract

The Open Software Foundation (OSF) Distributed Computing Environment (DCE) is implemented for ASCII-based systems. A DCE model is introduced to solve interoperability problems with clients on EBCDIC-based platforms. This model allows EBCDIC-based clients to communicate with the rest of DCE world without compromizing interoperability with DCE version 1.0.x servers.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Call Directory Service EBCDIC/ASCII Problems Resolution

      The Open Software Foundation (OSF) Distributed Computing
Environment (DCE) is implemented for ASCII-based systems.  A DCE
model is introduced to solve interoperability problems with clients
on EBCDIC-based platforms.  This model allows EBCDIC-based clients to
communicate with the rest of DCE world without compromizing
interoperability with DCE version 1.0.x servers.

      Data exchange in the DCE environment involves the use of
Interface Definition Language (IDL) interfaces that define the basic
types of data interchanged between DCE clients and servers.  DCE
Remote Procedure Call (RPC) follows the "receiver makes it right"
model, i.e., RPC converts the character data (received from the wire)
from the network code page to the local code page of the system, if
the code pages are not the same.  DCE RPC supports two network code
pages: ASCII code page 8859-1 and EBCDIC code page 500.

      Some of the IDL interfaces for Cell Directory Service (CDS), a
component of DCE that performs lookup and update of DCE entries,
names are defined as "byte" instead of "char" strings.  Since these
names are of type "byte", RPC cannot convert them from network code
page to local code page.  This leads to interoperability problems
when a non-ASCII client sends a request to an ASCII machine and
vice-versa.

      Also code page dependent manipulation of data and hard coding
of character strings is prevalent throughout DCE CDS code.  CDS
heavily relies on the assumption that it will run on an ASCII
platform.  For example the default values for optional parameters of
client Application Programming Interface (API) are stored in static
variables.  These variables are initialized with character strings
which represent the memory map of opaque structures.  For example:
  static byte_t allNames()   = {"\11\1\*"}
  static byte_t allClasses()  = {"\11\1\*"}

If this code is compiled on  an EBCDIC platform, the third byte...