home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / som30tk.zip / som30os2.zip / README < prev   
Text File  |  1996-12-24  |  51KB  |  1,098 lines
  1.  
  2.         IBM SOMobjects Developer Toolkit - Version 3.0 - README
  3.         -------------------------------------------------------
  4.                          December 1996 Release
  5.                          ---------------------
  6.  
  7. 25H7912 (C) COPYRIGHT International Business Machines Corp. 1992,1996
  8. All Rights Reserved
  9. Licensed Materials - Property of IBM
  10. US Government Users Restricted Rights - Use, duplication or disclosure
  11. restricted by GSA ADP Schedule Contract with IBM Corp.
  12.  
  13.  
  14. Welcome to SOMobjects Developer Toolkit - Version 3.0 December 1996 Release
  15. ===========================================================================
  16.  
  17. SOMobjects Developer Toolkit is now available for AIX, OS/2, and Windows NT.
  18. The SOMobjects Developer Toolkit code, publications, and the latest version
  19. of this README are available at:
  20.   http://www.software.ibm.com/clubopendoc/som30tk.html
  21.  
  22. This file contains information that you need for installing SOMobjects
  23. Developer Toolkit and additional information not included in the original
  24. product documentation.
  25.  
  26. The following components and function which were provided in the
  27. February 1996 Beta release of SOMobjects 3.0 are no longer supported:
  28.  
  29.       - IDL Editor and IR Browser
  30.       - sommak utility
  31.       - somdoc utility and ipf emitter
  32.       - Direct-To-SOM Programming
  33.       - Collection Classes
  34.       - Event Management Framework
  35.       - Event Service
  36.       - Life Cycle Service
  37.       - Persistent Object Service
  38.       - Concurrency Control Service
  39.       - Transaction Service
  40.       - pregimpl Server Registration GUI
  41.       - online documentation
  42.  
  43. This README file is divided into the following categories:
  44.  
  45.    - Before You Install
  46.       - Hardware Requirements
  47.       - Base Software Requirements
  48.       - Networking Software Requirements
  49.       - Supported Compilers
  50.    - Installing SOMobjects Developer Toolkit
  51.       - Installation on AIX
  52.       - Installation on OS/2
  53.       - Installation on Windows NT
  54.       - ISO Latin-1 Code Page Conversion
  55.    - Updated Component Information
  56.       - General Component Information
  57.       - SOM Kernel
  58.       - SOM Emitters
  59.       - Distributed SOM
  60.       - Object Services
  61.    - Trademarks
  62.    - Your Satisfaction
  63.  
  64. Before You Install
  65. ==================
  66.  
  67. Hardware Requirements
  68. ---------------------
  69.   - An IBM or non-IBM hardware platform supporting the required
  70.     level of the operating system
  71.   - Display, mouse, and keyboard
  72.   - OS/2 and Windows NT
  73.     - At least 16 MB of RAM
  74.     - At least 30 MB of fixed disk space
  75.   - AIX
  76.     - At least 24 MB of RAM
  77.     - At least 30 MB of fixed disk space
  78.  
  79. Base Software Requirements
  80. --------------------------
  81. The following levels of operating system products are supported:
  82.   - OS/2 Warp Version 3
  83.   - AIX Version 4.1.4 or 4.2 with fileset xlC.rte
  84.   - Microsoft Windows NT 3.51
  85.  
  86. Networking Software Requirements
  87. --------------------------------
  88. When using Distributed SOM, networking software is required.  This
  89. is true even when DSOM is used on a single workstation for
  90. inter-process communication.
  91.  
  92. Distributed SOM requires one of the following network products:
  93.   - IBM TCP/IP Version 3.0 for OS/2
  94.   - IBM AnyNet/2 with NetBIOS or TCP/IP, Version 2.02 with
  95.     corrective service for APAR IC12389
  96.   - TCP/IP as provided in the AIX operating system
  97.   - TCP/IP as provided in the Windows NT operating system
  98.  
  99. Security Service on OS/2 requires:
  100.   - LAN Server Version 4.0 with fixpak PTF=IP08182
  101.  
  102. Supported Compilers
  103. -------------------
  104. The following compilers are supported:
  105.   - IBM VisualAge C++ for OS/2, Version 3.0, FixPack CTC306
  106.   - IBM VisualAge C++ for Windows, Version 3.5, FixPack WTC352
  107.   - IBM CSet++ for AIX, Version 3.1.4
  108.  
  109. FixPacks for VisualAge C++ are available on the Web.  You can follow
  110. links from the VisualAge C++ Home Page:
  111.  
  112.   http://www.software.ibm.com/ad/visualage_c++
  113.  
  114. Note: The target date for CSD2 for VisualAge C++ for Windows is 1/15/97.
  115.  
  116.  
  117. Installing and Configuring the SOMobjects Developer Toolkit
  118. ===========================================================
  119.  
  120.   The following is a summary of SOM Installation and Configuration.
  121.   See Chapter 2 of the Programmer's Guide, Volume 1: SOM and DSOM for
  122.   complete configuration information.
  123.  
  124.  
  125. Installation on AIX
  126. -------------------
  127.  
  128.   If you already have a previous version of SOM installed, we strongly
  129.   recommend that you install SOM 3.0 in a new directory rather than
  130.   copying over the contents of the previous SOM directory.
  131.  
  132.   Installation instructions should be executed as root user.
  133.  
  134. 1. Copy the SOMobjects Developer Toolkit for AIX tar file, som30aix.tar.Z,
  135.    to the directory where you wish to install SOM 3.0.  If this is a first
  136.    time install, make a directory called /usr/lpp/som and copy the tar file
  137.    to this directory.  If you already have a previous version of SOM
  138.    installed, make a directory called /usr/lpp/som30, and copy the
  139.    som30aix.tar.Z to this directory. The following instructions will assume
  140.    an install directory of /usr/lpp/som.
  141.  
  142.    Uncompress and then untar the file with the following commands:
  143.  
  144.       uncompress som30aix.tar.Z
  145.       tar -xvf som30aix.tar
  146.  
  147. 2. Execute one of the supplied shell scripts in the /usr/lpp/som/bin
  148.    directory, somenv.sh or somenv.csh, to initialize basic SOM environment
  149.    variables.  By default, these scripts assume SOM has been installed in
  150.    /usr/lpp/som.  If you have installed SOM in another directory, edit the
  151.    appropriate script and modify the value of SOMBASE to the directory where
  152.    you installed SOM 3.0.
  153.  
  154.       cd /usr/lpp/som/bin
  155.       . ./somenv.sh       (for Korn shell)
  156.       source ./somenv.csh (for C Shell)
  157.  
  158.    You may want to incorporate these scripts into your .profile (Korn shell)
  159.    or .login (C shell).
  160.  
  161. 3. The irindex command builds indexes for the Interface Repository
  162.    files.  A one-time synchronization must be performed at install time.
  163.    Issue the following command:
  164.  
  165.      irindex $SOMBASE/etc/som.ir
  166.  
  167.    There is no output from the irindex program if it is successful.
  168.  
  169. 4. Configure DSOM
  170.  
  171.    Prior to configuring DSOM, make sure that if the SOMIR environment variable
  172.    is set, that it is a valid setting.
  173.  
  174.    Configuring Install Hosts
  175.    - Edit the /usr/lpp/som/etc/somenv.ini file.
  176.      Change all occurences of "thehostname" to the machine's TCP/IP hostname.
  177.      If you intend to run DSOM across machines, change "SOMDPROTOCOLS=SOMD_IPC"
  178.        to "SOMDPROTOCOLS=SOMD_TCPIP".
  179.      Save the revised somenv.ini file.
  180.    - Run "som_cfg -i" to configure the Install host.
  181.    - If you are going to continue by configuring some DSOM hosts on other
  182.        machines, leave SOMDD running on the Install host.  Otherwise,
  183.        stop somdd with a system "kill" command on the somdd process ID.
  184.  
  185.    Configuring DSOM Hosts
  186.    - Copy the GLOBAL_OBJREF_FILE from the install host to the DSOM host.
  187.  
  188.        The default file name of the GLOBAL_OBJREF_FILE is somnm.ref.
  189.        and is in the /usr/lpp/som/etc/dsom directory on the Install host.
  190.        We suggest copying it to the /usr/lpp/som/etc directory on the
  191.        DSOM host. Do not copy it to the /usr/lpp/som/etc/dsom directory,
  192.        as the som_cfg program needs an empty /usr/lpp/som/etc/dsom directory.
  193.  
  194.    - Edit the /usr/lpp/som/etc/somenv.ini file.
  195.      Change all occurences of "thehostname" to the machine's TCP/IP hostname.
  196.      If you intend to run DSOM across machines, change "SOMDPROTOCOLS=SOMD_IPC"
  197.        to "SOMDPROTOCOLS=SOMD_TCPIP".
  198.      Change the GLOBAL_OBJREF_FILE value in the DSOM host's somenv.ini
  199.        file to "$SOMBASE/etc/somnm.ref".
  200.    - Make sure somdd is running on the Install Host.
  201.    - Run "som_cfg -d" to configure the DSOM host.
  202.    - Stop the DSOM host somdd with a system "kill" command on the somdd
  203.        process ID.
  204.  
  205.    Configuring Simple DSOM clients (cannot run DSOM servers)
  206.    - Edit the /usr/lpp/som/etc/somenv.ini file
  207.      Change all occurences of "thehostname" to the machine's TCP/IP hostname.
  208.      If you intend to run DSOM across machines, change "SOMDPROTOCOLS=SOMD_IPC"
  209.        to "SOMDPROTOCOLS=SOMD_TCPIP".
  210.      Copy the SOMNMOBJREF value from the install host's somenv.ini to
  211.        the DSOM client's somenv.ini.
  212.    - som_cfg does not need to be run for simple DSOM clients. You are done.
  213.  
  214. 5. Build the SOM binding header files.
  215.    To build the SOM binding files for C and C++, do the following:
  216.    - For C header files such that object type variables do not need an '*',
  217.      run somcorba.
  218.    - For C header files such that object type variables do need an '*',
  219.      run somstars.
  220.    - For C++ header files, run somxh.
  221.  
  222. 6. See Chapter 2 of the Programmer's Guide, Volume 1: SOM and DSOM for
  223.    additional configuration information.
  224.  
  225.  
  226. Installation on OS/2
  227. --------------------
  228.  
  229.   If you already have a previous version of SOM installed, we strongly
  230.   recommend that you install SOM 3.0 in a new directory rather than
  231.   copying over the contents of the previous SOM directory. This is
  232.   especially true if you have installed the SOM 3.0 OS/2 Beta.
  233.  
  234. 1. Copy the zip file, som30os2.zip, or the Internet-sized OS/2 zip files,
  235.    som30ox1.zip, som30ox2.zip and som30ox3.zip, to the directory where you
  236.    wish to install SOM 3.0.  If this is a first-time install, make a new
  237.    root directory called som, and copy the zip file(s) there.  If you have
  238.    a prior version of SOM installed on your machine, create a new directory
  239.    for SOM 3.0 and copy the SOMobjects Developer Toolkit for OS/2 zip file(s),
  240.    to this directory.  The following instructions will assume an install
  241.    directory of c:\som.
  242.  
  243. 2. If you must install over a previous version of SOM, disable the Workplace
  244.    Shell before unzipping the zip file(s).
  245.  
  246.    There are two ways to do this:
  247.  
  248.    A. Modifying config.sys to boot OS/2 in non-Workplace Shell mode.
  249.       - Modify the config.sys LIBPATH statement so that the
  250.         c:\som\lib directory where you are installing SOM 3.0
  251.         appears first in the list of directories in each of these
  252.         statements.  This will allow Workplace Shell to pick up the
  253.         new SOM 3.0 dlls.
  254.       - Make a temporary backup copy of this new config.sys. Call
  255.         it config.som.
  256.       - Again, edit config.sys and modify the PROTSHELL statement and the
  257.         RUNWORKPLACE statements.
  258.  
  259.         Change the PROTSHELL statement to:
  260.           PROTSHELL=c:\os2\cmd.exe
  261.  
  262.         Change the RUNWORKPLACE statement to:
  263.           SET RUNWORKPLACE=c:\os2\cmd.exe
  264.  
  265.       - Reboot the system. OS/2 will boot up in non-WPS mode.
  266.       - Change to the directory where you copied the zip file(s), and
  267.         unzip the zip file(s) using your favorite unzip utility. You
  268.         may use any unzip utility that you like, but make sure you restore
  269.         the directory structure when unzipping.
  270.  
  271.         ex) pkunzip -d som30os2.zip
  272.  
  273.       - Copy the backup config.som back to config.sys.
  274.       - Reboot the system. The OS/2 Workplace Shell will pick up the
  275.         new SOM 3.0 DLLs.
  276.  
  277.    B. Interrupting the OS/2 boot sequence with Ctrl-Alt-F1.
  278.       - Reboot the system.
  279.       - When "OS/2" appears in the upper-left-hand corner of the screen,
  280.         press ctrl-alt-F1 (all three keys at the same time). to bring up
  281.         the "Recovery Choices" menu.  Enter "c" to open an OS/2 full screen
  282.         window.
  283.       - Change to the directory where you copied the zip file(s), and
  284.         unzip the zip file(s) using your favorite unzip utility. You
  285.         may use any unzip utility that you like, but make sure you restore
  286.         the directory structure when unzipping.
  287.  
  288.         ex) pkunzip -d som30os2.zip
  289.  
  290.       - Edit config.sys and add %SOMBASE%\lib to the beginning of
  291.         the LIBPATH variable.  This will allow Workplace Shell to pick
  292.         up the new SOM dlls.
  293.  
  294.       - Press ctrl-alt-del to reboot your system. The OS/2 Workplace
  295.         Shell will pick up the new SOM 3.0 DLLs.
  296.  
  297. 3. Execute the supplied command file, c:\som\bin\somenv.cmd, to initialize
  298.    basic SOM environment variables.  You must first edit this command file
  299.    and set SOMBASE to the directory where SOM is installed.
  300.  
  301.      cd som\bin
  302.      (edit somenv.cmd and set SOMBASE to the directory where you
  303.       installed SOM 3.0)
  304.      somenv.cmd
  305.  
  306.    You may want to incorporate the commands in this command file into your
  307.    config.sys file so that you do not have to execute this command file
  308.    whenever you run SOM 3.0 applications.
  309.  
  310. 4. The irindex command builds indexes for the Interface Repository
  311.    files.  A one-time synchronization must be performed at install time.
  312.    Issue the following command:
  313.  
  314.      irindex %sombase%\etc\som.ir
  315.  
  316.    There is no output from the irindex program if it is successful.
  317.  
  318. 5. Configure DSOM
  319.  
  320.    Prior to configuring DSOM, make sure that if the SOMIR environment variable
  321.    is set, that it is a valid setting.
  322.  
  323.    Configuring Install Hosts
  324.    - Edit the c:\som\etc\somenv.ini file.
  325.      Change all occurences of "thehostname" to the machine's TCP/IP hostname.
  326.      If you intend to run DSOM across machines, change "SOMDPROTOCOLS=SOMD_IPC"
  327.        to "SOMDPROTOCOLS=SOMD_TCPIP".
  328.      Save the revised somenv.ini file.
  329.    - Run "som_cfg -i" to configure the Install host.
  330.    - If you are going to continue by configuring some DSOM hosts on other
  331.        machines, leave SOMDD running on the Install host.  Otherwise, stop
  332.        somdd by going to the SOMDD window and pressing ctrl-break.
  333.  
  334.    Configuring DSOM Hosts
  335.    - Copy the GLOBAL_OBJREF_FILE from the install host to the DSOM host.
  336.  
  337.        The default file name of the GLOBAL_OBJREF_FILE is somnm.ref.
  338.        and is in the c:\som\etc\dsom directory on the Install host.
  339.        We suggest copying it to the c:\som\etc directory on the
  340.        DSOM host. Do not copy it to the c:\som\etc\dsom directory,
  341.        as the som_cfg program needs an empty c:\som\etc\dsom directory.
  342.  
  343.    - Edit the c:\som\etc\somenv.ini file.
  344.      Change all occurences of "thehostname" to the machine's TCP/IP hostname.
  345.      If you intend to run DSOM across machines, change "SOMDPROTOCOLS=SOMD_IPC"
  346.        to "SOMDPROTOCOLS=SOMD_TCPIP".
  347.      Change the GLOBAL_OBJREF_FILE value in the DSOM host's somenv.ini
  348.        file to "c:\som\etc\somnm.ref".
  349.    - Make sure somdd is running on the Install Host.
  350.    - Run "som_cfg -d" to configure the DSOM host.
  351.    - After running som_cfg, stop somdd by going to the SOMDD window
  352.        and pressing ctrl-break.
  353.  
  354.    Configuring Simple DSOM clients (cannot run DSOM servers)
  355.    - Edit the c:\som\etc\somenv.ini file.
  356.      Change all occurences of "thehostname" to the machine's TCP/IP hostname.
  357.      If you intend to run DSOM across machines, change "SOMDPROTOCOLS=SOMD_IPC"
  358.        to "SOMDPROTOCOLS=SOMD_TCPIP".
  359.      Copy the SOMNMOBJREF value from the install host's somenv.ini to
  360.        the DSOM client's somenv.ini.
  361.    - Som_cfg does not need to be run for simple DSOM clients. You are done.
  362.  
  363. 6. Build the SOM binding header files.
  364.    To build the SOM binding files for C and C++, do the following:
  365.    - For C header files such that object type variables do not need an '*',
  366.      run somcorba.
  367.    - For C header files such that object type variables need an '*',
  368.      run somstars.
  369.    - For C++ header files, run somxh.
  370.  
  371. 7. See Chapter 2 of the Programmer's Guide, Volume 1: SOM and DSOM for
  372.    additional configuration information.
  373.  
  374.  
  375. Installation on Windows NT
  376. --------------------------
  377.  
  378.   If you already have a previous version of SOM installed, we strongly
  379.   recommend that you install SOM 3.0 in a new directory rather than
  380.   copying over the contents of the previous SOM directory.
  381.  
  382. 1. Copy the zip file, som30nt.zip, or the Internet-sized NT zip files,
  383.    som30nx1.zip, som30nx2.zip and som30nx3.zip, to the directory where you
  384.    wish to install SOM 3.0.  If this is a first-time install, make a new
  385.    root directory called som, and copy the zip file(s) there.  If you have
  386.    a prior version of SOM installed on your machine, create a new directory
  387.    for SOM 3.0 and copy the SOMobjects Developer Toolkit for NT zip file(s),
  388.    to this directory.  Unzip the zip file(s) using your favorite unzip utility.
  389.    You may use any unzip utility that you like, but make sure you restore the
  390.    directory structure when unzipping.
  391.  
  392.    ex) pkunzip -d som30nt.zip
  393.  
  394.    The following instructions assume an install directory of c:\som.
  395.  
  396.    Note: SOM dynamically links with the C runtime.  The SOMobjects Developer
  397.      Toolkit for NT ships somws35i.dll and somwm35i.dll, the single and
  398.      multi-threaded C runtime libraries, to avoid requiring VisualAge C++.
  399.  
  400. 2. Execute the supplied command file, c:\som\bin\somenv.cmd, to
  401.    initialize basic SOM environment variables.  You must first edit
  402.    the command file and set SOMBASE to the directory where SOM is
  403.    installed.
  404.  
  405.      cd som\bin
  406.      (edit somenv.cmd and set SOMBASE and save the file)
  407.       somenv.cmd
  408.  
  409.    You may want to add these environment variable settings to the System or
  410.    User Environment Variables in the System settings panel.
  411.  
  412. 3. The irindex command builds indexes for the Interface Repository
  413.    files.  A one-time synchronization must be performed at install time.
  414.    Issue the following command:
  415.  
  416.      irindex %sombase%\etc\som.ir
  417.  
  418.    There is no output from the irindex program if it is successful.
  419.  
  420. 4. Configure DSOM
  421.  
  422.    Prior to configuring DSOM, make sure that if the SOMIR environment variable
  423.    is set, that it is a valid setting.
  424.  
  425.    Configuring Install Hosts
  426.    - Edit the c:\som\etc\somenv.ini file.
  427.      Change all occurences of "thehostname" to the machine's TCP/IP hostname.
  428.      If you intend to run DSOM across machines, change "SOMDPROTOCOLS=SOMD_IPC"
  429.        to "SOMDPROTOCOLS=SOMD_TCPIP".
  430.      Save the revised somenv.ini file.
  431.    - Run "som_cfg -i" to configure the Install host.
  432.    - If you are going to continue by configuring some DSOM hosts on other
  433.        machines, leave SOMDD running on the Install host.  Otherwise, stop
  434.        somdd by going to the SOMDD window and pressing ctrl-break.
  435.  
  436.    Configuring DSOM Hosts
  437.    - Copy the GLOBAL_OBJREF_FILE from the install host to the DSOM host.
  438.  
  439.        The default file name of the GLOBAL_OBJREF_FILE is somnm.ref.
  440.        and is in the c:\som\etc\dsom directory on the Install host.
  441.        We suggest copying it to the c:\som\etc directory on the
  442.        DSOM host. Do not copy it to the c:\som\etc\dsom directory,
  443.        as the som_cfg program needs an empty c:\som\etc\dsom directory.
  444.  
  445.    - Edit the c:\som\etc\somenv.ini file.
  446.      Change all occurences of "thehostname" to the machine's TCP/IP hostname.
  447.      If you intend to run DSOM across machines, change "SOMDPROTOCOLS=SOMD_IPC"
  448.        to "SOMDPROTOCOLS=SOMD_TCPIP".
  449.      Change the GLOBAL_OBJREF_FILE value in the DSOM host's somenv.ini
  450.        file to "somnm.ref".
  451.    - Make sure somdd is running on the Install Host.
  452.    - Run "som_cfg -d" to configure the DSOM host.
  453.    - After running som_cfg, stop somdd by going to the SOMDD window
  454.        and pressing ctrl-break.
  455.  
  456.    Configuring Simple DSOM clients (cannot run DSOM servers)
  457.    - Edit the c:\som\etc\somenv.ini file.
  458.      Change all occurences of "thehostname" to the machine's TCP/IP hostname.
  459.      If you intend to run DSOM across machines, change "SOMDPROTOCOLS=SOMD_IPC"
  460.        to "SOMDPROTOCOLS=SOMD_TCPIP".
  461.      Copy the SOMNMOBJREF value from the install host's somenv.ini to
  462.        the DSOM client's somenv.ini.
  463.    - som_cfg does not need to be run for simple DSOM clients. You are done.
  464.  
  465. 5. Build the SOM binding header files.
  466.    To build the SOM binding files for C and C++, do the following:
  467.    - For C header files such that object type variables do not need an '*',
  468.      run somcorba.
  469.    - For C header files such that object type variables need an '*',
  470.      run somstars.
  471.    - For C++ header files, run somxh.
  472.  
  473. 6. See Chapter 2 of the Programmer's Guide, Volume 1: SOM and DSOM for
  474.    additional configuration information.
  475.  
  476.  
  477. ISO Latin-1 Code Page Conversion
  478. --------------------------------
  479.  
  480. DSOM 3.0 supports a configuration file setting, SOMDISOLATIN1, in the [somd]
  481. stanza of somenv.ini, which, if set to 1, instructs DSOM to convert to the
  482. ISO Latin-1 codeset (ISO8859-1 or IBM-819) character data in messages sent
  483. between processes.  This support is provided for two reasons:
  484.    (1) to allow interoperability between ASCII-based systems (AIX, OS/2, NT)
  485.        and EBCDIC-based systems (MVS).
  486.    (2) to comply with the CORBA 2.0 IIOP interoperability specification.
  487.        (Note, however, that most non-IBM ORBs do not yet perform translation
  488.        for character data in messages, therefore setting SOMDISOLATIN1 may
  489.        actually hinder interoperability between DSOM 3.0 and other vendors'
  490.        ORBs.)
  491.  
  492. Applications requiring interoperability with SOMobjects on MVS should set
  493. SOMDISOLATIN1=1 in the [somd] stanza of the SOMobjects configuration file.
  494. Most other users will probably want to leave it unset, to enhance performance
  495. and to allow interoperability between SOMobjects 3.0 and non-IBM ORBs.
  496.  
  497. Note that on OS/2 and Windows NT, ISO Latin-1 code set conversion of
  498. character data, using the SOMDISOLATIN1 setting, is only supported for
  499. systems/applications using the IBM-850 or IBM-437 code sets (which is the
  500. case for most English systems).
  501.  
  502. OS/2 and Windows NT users who wish to enable ISO Latin-1 code set conversion
  503. who don't have the VisualAge C++ compiler installed: it is necessary to
  504. download file localeo2.zip (for OS/2) or localent.zip (for Windows NT) from
  505. the SOMobjects Developer Toolkit Web page.  Unzip the file and update the
  506. LOCPATH environment variable in your operating system environment to
  507. include the directory created by unzipping it.
  508.  
  509. Updated Component Information
  510. =============================
  511.  
  512. General Component Information
  513. -----------------------------
  514.  
  515. The following items affect either the product as a whole or multiple
  516. components.
  517.  
  518. 1. Applications written with SOMobjects 2.x may need to increase the
  519.    application stack size when migrating to SOMobjects 3.0.
  520.  
  521. 2. Applications written for Windows NT should use the Gd+ compile option.
  522.    Gd is a compiler option which specifies whether to dynamically or
  523.    statically link with the VAC++ runtime functions.  Gd+ indicates
  524.    dynamic linking.
  525.  
  526. 3. When using the def emitter on Windows NT, update the output .nid file
  527.    to export "_SOMInitModule@12".  This is required when using module
  528.    names within IDL files. 
  529.  
  530. 4. Scripts or processes checking the return code from an application running
  531.    on Windows NT may not receive an accurate value.  Although main may
  532.    return 0 indicating success, another value may be received by the caller.
  533.  
  534. 5. som_cfg creates error log entries that can be ignored if som_cfg
  535.    completes successfully.  You can expect log entries with the following
  536.    error codes:
  537.  
  538.    Error code is 30109 [SOMDERROR_SOMDDNotRunning].
  539.    som_cfg starts the DSOM daemon if it is not running.  When querying
  540.    for the status of the daemon, this error may be raised.
  541.  
  542.    Error code is 30046 [SOMDERROR_EntryNotFound].
  543.    som_cfg registers the Naming Service and Security Service in the
  544.    Implementation Repository.  When querying whether entries for these
  545.    servers already exist, this error may be raised.
  546.  
  547.    Error code is 30088 [SOMDERROR_NamingNotActive].
  548.    When registering with the Implementation Repository, DSOM will
  549.    attempt to store the information in the Naming Service.  If the
  550.    Naming Server is not running, this error will be raised.
  551.  
  552. 6. DSOM and the Object Services do not provide code page conversion.
  553.    Therefore, if a client and server are operating under different
  554.    code pages, operations performed against character data will have
  555.    unpredictable results.
  556.  
  557. 7. On AIX, an application must call SOMD_Init before invoking a method
  558.    migrated from SOMDObject to SOMObject.  This requirement applies to
  559.    the following methods: create_request, create_request_args, duplicate,
  560.    get_implementation, get_interface, is_nil, is_proxy, and release.
  561.  
  562. 8. SOMobjects 3.0 does not support Direct-To-SOM.  The following notes
  563.    are provided to assist users who created DTS C++ code using support
  564.    provided by earlier releases, and who now want to migrate this DTS C++
  565.    code to C or native mode C++ code that uses the C or native mode C++
  566.    bindings provided by the SOMobjects 3.0 product.
  567.  
  568.    DTS C++ allows definition and use of either native mode or SOM classes,
  569.    but the following discussion focuses on DTS C++ code that implements or
  570.    uses SOM classes.
  571.  
  572.    There are a few different usage scenarios for DTS C++:
  573.  
  574.    1) To implement SOM classes:
  575.       a) start with IDL, use the hh emitter to produce a DTS C++ header,
  576.          include this header into a DTS C++ implementation file that you
  577.          write.
  578.       b) start with DTS C++. Optionally, use the DTS C++ compiler to produce
  579.          IDL for other users.
  580.  
  581.    2) To use SOM classes:
  582.       a) if the SOM classes are described using IDL, use the hh emitter to
  583.          produce a DTS C++ header, include this header into your DTS C++
  584.          source file.
  585.       b) if the SOM classes are described using a DTS C++ header, include
  586.          this header into your DTS C++ source file.
  587.  
  588.    The migration issues related to each of the above scenarios are
  589.    somewhat different:
  590.  
  591.    1a) Generate new usage bindings, implementation bindings, and
  592.        implementation template from the IDL that was originally used as input
  593.        to the hh emitter.  In general, for each member function definition in
  594.        your DTS C++ implementation source, your implementation template file
  595.        will contain a global function stub.  You'll need to move the code
  596.        from your member function definitions to the function stubs in the
  597.        template file.  Expect to make lots of changes in the source code.
  598.        You'll have to rewrite any use of stack-allocated objects to use heap
  599.        allocation.  And, of course, access to instance variables is done
  600.        differently in the native mode bindings (via somThis).
  601.  
  602.    1b) The IDL provided by the DTS C++ compiler will likely require
  603.        modifications.  After you have made any necessary modifications,
  604.        proceed as in case 1a.
  605.  
  606.    2a) DTS C++ code that uses SOM objects (as opposed to implementing them)
  607.        should generally port fairly easily to native mode C++ usage bindings.
  608.        The big exception is stack-allocated objects.
  609.  
  610.    2b) Again, as in case 2a, it will be necessary to produce IDL from which
  611.        usage bindings can be generated.
  612.  
  613. SOM Kernel
  614. ----------
  615.  
  616. 1. The somthrd.h file is no longer available.
  617.  
  618.    Replace each of the following functions:
  619.  
  620.    Old Function            Replacement Function on OS/2
  621.    ----------------------------------------------------
  622.    SOMStartThread()        _beginthread()
  623.    SOMEndThread()          _endthread()
  624.    SOMKillThread()         DOSKillThread()
  625.    SOMYieldThread()        DOSSleep(0)
  626.    SOMGetThreadHandle()    DOSGetInfoBlocks()
  627.  
  628.    Similar functions are also available on AIX and Window NT.  For more
  629.    information, see the programming guide for your operating system.
  630.  
  631.    The following typedefs are no longer supported.
  632.  
  633.    somTD_SOMStartThread
  634.    somTD_SOMEndThread
  635.    somTD_SOMYieldThread
  636.    somTD_SOMKillThread()
  637.    somTD_SOMGetThreadHandle
  638.  
  639. 2. The SOMObject methods somDispatchV, somDispatchL, somDispatchA, and
  640.    somDispatchD have been replaced by the single SOMObject method
  641.    somDispatch.
  642.  
  643. 3. The generated class name for a derived metaclasses is now of the form
  644.    SOMM_<class>_Derived.  In 2.x, the class name was of the form
  645.    M_<class>_Derived.
  646.  
  647. SOM Emitters
  648. ------------
  649.  
  650. 1. Usage bindings now support IDL files that contain only global
  651.    definitions. As before, global definitions must be bracketed within
  652.    somemittypes on/off pragmas to emit the corresponding bindings.
  653.  
  654. 2. When a typedef within one IDL file refers to a type defined in some
  655.    other IDL file, the emitted usage bindings for the first IDL file will
  656.    automatically #include usage bindings corresponding to the other IDL just
  657.    prior to the typedef mapping. This side-effect of typedefs allows you to
  658.    use typedefs to assure that headers upon which usage bindings for your IDL
  659.    depend will be #included into the usage bindings for your IDL, while
  660.    avoiding the use of passthru statements.
  661.  
  662.    There is no similar support for types that simply appear in method
  663.    signatures.  If you define a method that uses a type defined in some
  664.    other IDL file, and usage bindings for that other file will not be included
  665.    for some other reason, you should add a typedef to your interface
  666.    that mentions a type defined in the other IDL file.
  667.  
  668. 3. The fix for mapping interface typedefs into usage bindings that was
  669.    originally provided in CSD212 (via the sc command line modifier -mitdfix)
  670.    is now the default behavior. As a result of this fix, the IDL typedef
  671.  
  672.         typedef I myType; // where I is an interface
  673.  
  674.    results in usage bindings that include the following typedef:
  675.  
  676.         typedef I myType;
  677.  
  678.    Thus, in all cases, the name myType must  be treated (by
  679.    bindings and program code) in the same way that the name "I" would be
  680.    treated. Because of the way that previous bindings mapped interface
  681.    typedefs (by adding an explicit star to the typedef in some cases), two
  682.    kinds of source changes may be required when recompiling code that uses
  683.    non-CORBA C bindings:
  684.  
  685.   a. The prototypes for methods that receive myType arguments must be
  686.      changed. Compile-time errors when compiling class implementations would
  687.      signal this, and the simplest response is to use the incremental
  688.      template emitter to modify the method procedure prototypes.
  689.      It should not be necessary to make these changes in your method
  690.      implementations by hand. The template emitter will make the necessary
  691.      changes in the signatures of your method procedures.
  692.  
  693.   b. Code that uses local variables of type myType may have to be modified
  694.      by hand, by adding a star (when using the non-CORBA somstars C bindings).
  695.  
  696.    In this release, the older mapping for typedefs may be generated
  697.    by using the sc command line modifier -mitdlegacy but their continued
  698.    use is not recommended.
  699.  
  700. 4. The following enhancements to initializers have been made:
  701.  
  702.   a. New control argument types have been declared in somobj.idl. These have
  703.      the same structure as the original types, but are passed as "in"
  704.      parameters to initializer methods instead of "inout" parameters.  This
  705.      change does not affect the C and C++ bindings, but is important to
  706.      Smalltalk bindings.  The names of the new control types differ from those
  707.      used previously because they start with "som3" instead of "som".  Thus,
  708.      for example, there is a new type named som3InitCtrl.
  709.  
  710.      The old names are still supported (they are defined in somapi.h, along
  711.      with the new ones). So, there is no reason to modify existing C or C++
  712.      code to use the new type names, but you may want to modify the IDL for
  713.      your classes if you want Smalltalk code to be able to invoke initializers
  714.      on their instances. To do this, add a "3" to the initial "som" in the
  715.      control argument type for your initializers, and change "inout" to "in"
  716.      for this argument.  All the methods in SOMObject that take control
  717.      arguments, and output from the template emitter use the new type names.
  718.      When you define new classes in IDL, their initializers should use the
  719.      new type names.
  720.  
  721.   b. Initializers can now be overridden. That is, a class can define a local
  722.      initialization method by overriding an inherited initializer. You need
  723.      to specify the init modifier along with the override.  For example, if
  724.      foo is an inherited initializer method, the following could be used in
  725.      the implementation section to override it:
  726.  
  727.         foo: override, init;
  728.  
  729.      This results in an initializer template in your emitted implementation
  730.      template file, and usage bindings for your class will include a
  731.      constructor that invokes foo.
  732.  
  733.   c. When the implementation template for overrides of SOMObject's object
  734.      copy and object assignment methods is emitted, the ancestor calls that
  735.      are provided correspond to the method that is overridden.  For example,
  736.      if you override somDefaultConstVCopyInit, then ancestor calls to
  737.      somDefaultConstVCopyInit will be emitted in the implementation template
  738.      file.
  739.  
  740.      But, when the macros that support ancestor calls to SOM's object copy
  741.      and object assignment methods are emitted in implementation bindings,
  742.      macros are provided only for those methods that are actually available
  743.      in the ancestor.  A comment in the implementation bindings indicates
  744.      when one of these methods is not available in an ancestor.
  745.  
  746.      The concept of copy and assignment method availability is new to
  747.      SOMobjects 3.0.  It works as follows: a copy or assignment method is
  748.      available in a class if:
  749.  
  750.      - It is defined by the class (by overriding the method)
  751.      - The method is "below" a stronger method that is defined
  752.      - The method is somDefaultCopyInit or somDefaultAssign.
  753.  
  754.      Here are the strength orderings for SOMObject's copy methods. A similar
  755.      diagram describes the corresponding assignment methods.
  756.  
  757.                   somDefaultConstVCopyInit
  758.                            / \
  759.                           /   \
  760.                          /     \
  761.                         /       \
  762.       somDefaultConstCopyInit   somDefaultVCopyInit
  763.                         \       /
  764.                          \     /
  765.                           \   /
  766.                            \ /
  767.                      somDefaultCopyInit
  768.  
  769.      For example, if a class X defines somDefaultConstInit, ancestor
  770.      initializer macros in a subclass will be provided (only) for
  771.      somDefaultConstInit and somDefaultInit.  So, if you subclass this class
  772.      to create Y and override somDefaultVCopyInit (for example), you will
  773.      have the following unresolved symbol when you try to link your class
  774.      implementation:
  775.  
  776.              Y_Init_X_somDefaultConstVCopyInit
  777.  
  778.      This tells you that somDefaultConstVCopyInit is not available in X.
  779.      You would then look at X's IDL (or at your implementation bindings) to
  780.      see what object copy methods are available in X, and use those instead.
  781.      As mentioned above, somDefaultCopyInit will always be available.
  782.  
  783. 6. A new chk emitter checks that the IDL input to the SOM compiler
  784.    is semantically meaningful, to guarantee that output from all other
  785.    emitters will be useful. This emitter does not create an output file.
  786.  
  787.    Normally, the chk emitter is run automatically before other emitters (you
  788.    can see this by using the -v switch when using the sc command to invoke an
  789.    emitter explicitly). But, you can also invoke the chk emitter explicitly as
  790.    with any other emitter (by using -schk on the sc command line), or you can
  791.    omit its execution by using -mnochk on the sc command line.
  792.  
  793.    Many of the checks performed by the chk emitter are obvious. One of the
  794.    new checks is that all interfaces other than SOMObject must specify
  795.    a parent which guarantees useful .xh bindings. This is a new requirement.
  796.  
  797.    The chk emitter generates warnings for any unsupported modifiers.
  798.  
  799.    * Modifiers related to attributes can sometimes cause spurious warnings,
  800.      for example:
  801.  
  802.         my_attribute: nodata;
  803.  
  804.      This may raise two warnings: Once for "nodata" and once for
  805.      "my_attribute" under certain conditions.
  806.  
  807.      The warning looks like this:
  808.  
  809.      "<file-name>", line <line-no>: warning: Unknown modifier "my_attribute"
  810.      in interface/method "<interface-name>". It may be misspelled.
  811.  
  812.  
  813. 7. The PDL program now supports more sophisticated processing of IDL files.
  814.    In previous versions of the toolkit, PDL could remove only sections of IDL
  815.    text bracketed via #ifdef and #endif directives.  PDL is now also capable
  816.    of removing sections delimited via #if and #ifndef directives, and
  817.    partially evaluating conditional expressions.  See the Programmer's Guide
  818.    Volume I for details.
  819.  
  820. 8. The following Emitter Framework typedefs/functions have been renamed:
  821.       old                          new
  822.      ---------------------------------------------------
  823.      EmitFn                        EmitFnSL
  824.      somterror                     somterrorSL
  825.      somtfatal                     somtfatalSL
  826.      somtfclose                    somtfcloseSL
  827.      somtinternal                  somtinternalSL
  828.      somtmsg                       somtmsgSL
  829.      somtopenEmitFile              somtopenEmitFileSL
  830.      somtresetEmitSignals          somtresetEmitSignalsSL
  831.      somtunsetEmitSignals          somtunsetEmitSignalsSL
  832.      somtwarn                      somtwarnSL
  833.  
  834.    Under SOM2.1, the above functions/typedefs did not make use of SOMLINK.
  835.    This worked on AIX, but is not particularly portable on OS/2 and NT.
  836.    For backward compatibility, the old functions/typedefs are still available.
  837.    However, use the new functions for portability.
  838.  
  839. 9. When a SOMFOREIGN type is referenced in an IDL method declaration, the
  840.    emitters generate incorrect bindings for the method in the following
  841.    situation:
  842.  
  843.    1. the SOMFOREIGN type is declared in the same interface as the method
  844.       that references it
  845.    2. the SOMFOREIGN type has the "struct" storage class as indicated by
  846.       the "struct" IDL modifier
  847.    3. the "struct" modifier for the SOMFOREIGN type is specified using a
  848.       SOM IDL modifier statement (in the implementation section) rather
  849.       than using the modifier #pragma.
  850.  
  851.    The workaround is to use the modifier #pragma instead of the modifier
  852.    statement, for SOMFOREIGN types that need to be referenced in method
  853.    declarations prior to the implementation statement.
  854.  
  855. Distributed SOM (DSOM)
  856. ----------------------
  857.  
  858. Important differences between DSOM 2.1 and DSOM 3.0
  859. ---------------------------------------------------
  860.  
  861. Configuration (regimpl and the Implementation Repository)
  862. ---------------------------------------------------------
  863. DSOM runtime settings must now come from the [somd] stanza in the
  864. configuration file, and from environment variables.  (The configuration
  865. file name is specified by the SOMENV environment variable.)  SOMIR, HOSTNAME,
  866. and USER are still supported as environment variables.  If these environment
  867. variables are unset, the configuration file is consulted.  Compile-time
  868. environment variables (those used by the SOM Compiler and Emitters) are also
  869. not affected.
  870.  
  871. Registering servers (using regimpl) requires that somdd is running
  872. and that the Naming Service has been configured using the som_cfg tool
  873. because DSOM now uses the Naming Service to store server-class
  874. associations.  There are other significant changes to the Implementation
  875. Repository; see the Programmer's Guide Volume 1 for more information.
  876.  
  877. DSOM doesn't support outstanding object references when a server
  878. machine is upgraded from one version of DSOM to another.  This implies
  879. that "object reference table" files are rendered obsolete during the
  880. upgrade.
  881.  
  882. Error Handling
  883. --------------
  884. DSOM 3.0 almost never terminates the process in which it is run
  885. because of a DSOM exception.  This allows applications to control when
  886. they terminate and how they cleanup.  It also means that applications
  887. are responsible for error checking after every DSOM call.  Applications
  888. should avoid, however, checking for specific DSOM minor codes, because
  889. these are subject to change.
  890.  
  891. User exceptions raised by remote method invocations cannot be marshaled
  892. unless the method declares the exception in a "raises" expression in
  893. IDL.  Otherwise, DSOM returns a system exception to the client
  894. (with minor code SOMDERROR_UndeclaredException).  System exceptions can
  895. be raised by any method and are not declared in an IDL "raises" expression.
  896.  
  897. Sockets Classes
  898. ---------------
  899. User-defined Sockets classes are no longer supported.  Configuration has
  900. been simplified by eliminating the SOMSOCKETS environment variable.  One
  901. exception is that SOMSOCKETS is used by migimpl3, a tool to convert 2.1
  902. Implementation Repositories to 3.0 format.  SOMSOCKETS is used by migimpl3
  903. to determine what value of SOMDPROTOCOLS to assume for the converted entries.
  904.  
  905. Parameter Memory Management
  906. ---------------------------
  907. In DSOM 2.x, the default parameter-memory management policy was not
  908. uniformly "caller owns".  (The "memory_management=corba" IDL modifier had
  909. to be used to request this behavior.)  Applications that are recompiled
  910. using DSOM 3.0 will have a new default policy, which is "caller
  911. owned".  If this new default is not appropriate for the application,
  912. then the application's IDL should be modified to contain explicit
  913. modifiers (for example, object_owns_result, object_owns_parameters,
  914. dual_owned_result, dual_owned_parameters, and suppress_inout_free).
  915. See the Programmer's Guide Volume I for more information.  The new
  916. memory-management policy does not affect an application until its .ih/.xih
  917. files are regenerated using the SOMObjects 3.0 SOM Compiler.
  918.  
  919. For some data types, the storage inside an inout parameter will be
  920. unconditionally freed in the "in" direction, and reallocated in the
  921. "out" direction (in the client's address space), when using the default
  922. parameter-memory management policy.  Specifically, an inout object
  923. reference, the _value and _type fields of an inout any, an inout
  924. TypeCode, and inout SOMFOREIGNS have this property.  Thus, this storage
  925. must be allocated with SOMMalloc, and may not be static or automatic
  926. storage.
  927.  
  928. For inout strings, sequences, and pointers, the "in" storage may be freed
  929. and reallocated by DSOM if it changes in the "out" direction.  Specifically:
  930.     - if an unbounded string comes back longer than the original, or
  931.       set to NULL, the original will be freed by DSOM,
  932.     - if an unbounded sequence's _buffer comes back longer than the
  933.       original's _maximum, the original is freed and reallocated by DSOM,
  934.     - if a pointer comes back NULL, then the original value is freed by DSOM.
  935. Thus, even though it is legal for inouts of these types to point to static
  936. storage, it is risky, because it relies on the out value not invalidating
  937. the original storage.
  938.  
  939. When an application object changes an inout parameter (for example, giving
  940. a string a longer value) in a way that causes storage to be "orphaned", the
  941. object is responsible for freeing the orphaned storage (for example, the
  942. old string), unless the method parameter has the IDL modifier
  943. "suppress_inout_free".
  944.  
  945. The argument to ORBfree in DSOM 3.0 is the topmost argument pointer
  946. used to return a result or out parameter.  (In DSOM 2.x, the argument
  947. to ORBfree was the topmost "freeable" pointers within the parameter.)
  948. This allows an application to free all ORB-allocated memory in a return
  949. result or out parameter with a single call, rather than multiple
  950. calls.   As in DSOM 2.x, ORBfree frees only the memory within the
  951. parameter that the ORB allocated on behalf of the client (and not any
  952. memory within the parameter that the application allocated).  ORBfree
  953. is not applicable to inout parameters or exceptions parameters.
  954.  
  955. In DSOM 3.0, it is an error for an application object (within a server) to
  956. dereference an out parameter of type pointer.  Like all other out
  957. parameters, the initial value must be set by the application object, and
  958. the object should not assume that the initial value of an out parameter is
  959. valid data.
  960.  
  961. Object Reference Table
  962. ----------------------
  963. Support for the Object Reference Table, including the SOMOA methods
  964. create_constant and change_id, is now deprecated.  create_constant is
  965. now equivalent to create except for servers whose ImplementationDef object
  966. specifies an Object Reference Table file name.  If a file name is specified,
  967. the 2.x semantics of create apply.  Object Reference Table data will be
  968. stored in the directory designed by SOMDDIR (as opposed to the Object
  969. Reference Table file name specified in the ImplementationDef).  The same
  970. files can be used by multiple servers.  Servers that need persistent storage
  971. of object-reference data, such as that previously provided by the Object
  972. Reference Table, should implement this functionality in an application-
  973. pecific subclass of SOMDServer or use the SOMOS::Server class.
  974.  
  975. New Method Semantics
  976. --------------------
  977. DSOM applications, once recompiled, will receive the new default
  978. behavior for invoking somFree on a proxy object. The new behavior is
  979. that both the remote object and the proxy are freed.  (The 2.x default
  980. was that only the remote object was freed.)  Applications that want to
  981. continue to use the 2.x default behavior for somFree must set the
  982. somd21somFree attribute of the SOMD_ObjectMgr global object to FALSE
  983. after calling SOMD_Init.  This attribute, however, is deprecated and may
  984. not be supported in future releases.
  985.  
  986. DSOM applications, once recompiled, will receive the new default
  987. behavior for the ORB::string_to_object method. The new behavior is that
  988. if the string object reference refers to an object local to a server,
  989. the local SOMObject will be returned, rather than a SOMDObject.  (The
  990. 2.x behavior was to return a SOMDObject, which is not local/remote
  991. transparent.)  Applications that want to continue to use the 2.x default
  992. behavior for string_to_object must set the stringToObject30 attribute
  993. of the SOMD_ORBObject global object to FALSE after calling SOMD_Init.  This
  994. attribute, however, is deprecated and may not be supported in future
  995. releases.
  996.  
  997. Known restrictions in DSOM
  998. --------------------------
  999.  
  1000. 1. For machines that are used together as a DSOM workgroup (where
  1001.    the DSOM client is run on one machine and the DSOM server is run on
  1002.    another machine), both machines must be running the same version of
  1003.    SOMobjects (either 2.x or 3.0 GA).  A machine running SOMobjects 2.x
  1004.    will not communicate via DSOM with a machine running SOMobjects 3.0.
  1005.  
  1006. 2. SOMObject methods get_implementation and get_interface are not supported
  1007.    when executed between DSOM and another ORB.
  1008.  
  1009. 3. User-defined proxy classes and user-defined proxy base classes
  1010.    developed using SOMobjects 2.x are incompatible with SOMobjects 3.0.
  1011.    Such proxy classes must be reimplemented using a new programming model;
  1012.    see the Programmer's Guide Volume I for more information.
  1013.  
  1014. 4. When classes are registered in the Naming Service (for example via
  1015.    regimpl), to be retrieved by client applications using the DSOM Factory
  1016.    Service, the Naming Server running on the install host must be able to
  1017.    load those classes.  This means that the DLLs for those classes must be
  1018.    loadable by the install host's Naming Server (either the real DLL or a
  1019.    "stub" DLL), and if the class name is not the same as the DLL name, the
  1020.    install host Naming Server's SOMIR setting must reference an Interface
  1021.    Repository file that contains the classes' "dllname" modifiers.
  1022.  
  1023. 5. There are known problems restarting the Workplace Shell DSOM server
  1024.    thread.  After running an application and terminating the server thread,
  1025.    a system reboot is necessary before the server can be restarted.
  1026.  
  1027.    As a result, when running the Sample DSOM Client shown in the Workplace
  1028.    Shell Programming Guide (or any DSOM WPS client program that starts/stops
  1029.    the daemon and server programmatically if they are not already running),
  1030.    it is advisable to start the daemon and server using the "wpdsinit /s"
  1031.    command before running the client.  This prevents the client from
  1032.    terminating the server, allowing the client to be rerun any number of
  1033.    times without rebooting.  It also insures that the daemon will be ready
  1034.    before the client attempts to make the first remote request.
  1035.  
  1036. 6. On AIX, if a DSOM process terminates without calling SOMD_Uninit, the
  1037.    resources often remain allocated.  The cleanipc script can be used to
  1038.    free IPC resources for a particular user.  Due to potential side effects,
  1039.    cleanipc does not free resources when run as root.  Consider using a
  1040.    privileged user id other than root to run the DSOM daemon and application
  1041.    servers.  Another disadvantage to running the DSOM daemon as root is
  1042.    that servers started by the daemon will also execute as root; this adds
  1043.    a potential security exposure to the system.
  1044.  
  1045. 7. If your application runs for an extended period of time, it is
  1046.    recommended that you set SOMDNUMTHREADS in the [somd] stanza of
  1047.    somenv.ini.  SOMDNUMTHREADS specifies the maximum number of request
  1048.    threads created per server.
  1049.  
  1050.  
  1051. Object Services
  1052. ---------------
  1053.  
  1054. 1. When deriving classes from somOS::ServiceBase and overriding the method
  1055.    init_for_object_reactivation, do not perform any actions within the
  1056.    implementation of init_for_object_reactivation that will result in a
  1057.    remote method invocation on another server.  When a server is performing
  1058.    init_for_object_reactivation, it cannot perform any remote communication;
  1059.    if any is attempted, the server will hang.
  1060.  
  1061. 2. The Security Service should be used with servers that use somOS::Server
  1062.    (such as somossvr.exe); when used with other servers (such as somdsvr.exe),
  1063.    errors may occur when the server is terminating.
  1064.  
  1065. 3. When using the Security Service, if the server's entry in the
  1066.    Implementation Repository initially indicates that the server is secure,
  1067.    then is changed to indicate that the server is not secure, the server will
  1068.    continue to behave as a secure server.  The workaround is to unregister
  1069.    the server from the Implementation Repository and re-register the server
  1070.    as a non-secure server (so that the server will have a new UUID).
  1071.  
  1072. 4. The Externalization Service is not thread safe.
  1073.  
  1074. Trademarks
  1075. ==========
  1076.  
  1077. AIX is a trademark of International Business Machines Corporation.
  1078. IBM is a trademark of International Business Machines Corporation.
  1079. OS/2 is a trademark of International Business Machines Corporation.
  1080. SOM is a trademark of International Business Machines Corporation.
  1081. SOMobjects is a trademark of International Business Machines Corporation.
  1082. VisualAge C++ is a trademark of International Business Machines Corporation.
  1083. C Set++ is a trademark of International Business Machines Corporation.
  1084. Windows is a trademark of Microsoft Corporation.
  1085. Windows NT is a trademark of Microsoft Corporation.
  1086.  
  1087. Your Satisfaction
  1088. =================
  1089.  
  1090. Your satisfaction is important to us.  If you encounter a problem you
  1091. believe to be a defect in the SOMobjects Developer Toolkit code or
  1092. documentation, please submit a report to the technical support team.  The
  1093. problem submission form is located at:
  1094.   http://www.austin.ibm.com/somservice/supform.html
  1095.  
  1096.  
  1097. SOMobjects, Making Reuse a Reality
  1098.