VA Smalltalk Readme


Contents

Welcome to VA Smalltalk Version 7.0

Welcome to VA Smalltalk Version 7.0



Late-breaking news, technical tips, and product updates

	Please refer to the Instantiations Smalltalk web page for technical information, including 
	tips, and product updates made after this product release. The web page includes information 
	about what's included in the release,  and how to contact us as well as hints and tips for 
	using and deploying VA Smalltalk. 
	You can download the latest product updates from the Instantiations Smalltalk web site.

Version 7.0 files and installation

	Installing VA Smalltalk
	
	For installation information, see
	cd_m\doc\instgd.htm or 	
	cd_c\doc\instgd.htm 
	in the CD drive or the temporary directory where you extracted the manager or client 
	installation files. The Installation Guide is also available at Instantiation's Smalltalk 
	website. To install  VA Smalltalk, follow the instructions for your specific platform. 
	
	Before installing Version 7.0, follow these steps: 
	
	1. If EMSRV is running from the directory to be updated, stop EMSRV. 
	2. Stop any running VA Smalltalk images.

VA Smalltalk Migration Guide

	If you have a version of VisualAge Smalltalk  installed, please 
	refer to the Migration Guide for important information before using VA 
	Smalltalk Version 7.0. The Migration Guide can be installed with the VA 
	Smalltalk Client by selecting the "VA Smalltalk Documentation" feature. 

Components and Features

	The following sections list some important information about some of the components and features. 
	For the latest product information, please refer to Instantiations Smalltalk web page.

APARs
Non-APAR defects fixed in Version 7.0
  ***** - versioning/releasing owned parts in Organizer causes a walkback
  ***** - Add tracing to the SCI DLL on Windows platforms
Product Enhancements in VAST V7.0
  VA Smalltalk lets programmers create and deploy e-business applications that are cross-platform and object-oriented:
  New support for Red Hat Linux, SUSE and Fedora 
Application Builder
On AIX, turn NumLock off when dropping parts
  Be sure that your numlock key is turned off if you are using the composition editor.  The numlock 
  will prevent parts from being dropped on the Composition Editor. 
   
On UNIX, "X Error: BadWindow" message appears for Slider part
  Each time the Slider part is repainted the "X Error: BadWindow (invalid Window parameter)" message 
  is printed in the xterm window which VisualAge Smalltalk was launched.
  
  The Slider part still functions normally.
Setting your monetary symbols in UNIX
  On UNIX, make sure your LC_MONETARY locale setting contains a non-empty mon_decimal_point entry.  
  On some machines, mon_decimal_point may be empty for the "C" locale.  For example, if you wish to 
  change to the en_US locale, set your LANG environment variable to en_US before starting VA 
  Smalltalk with the ksh command:
     export LANG=en_US
  
  You can check the value of mon_decimal_point with the command:
     locale -k LC_MONETARY
  
  The output should look like:
     int_curr_symbol="USD "
     currency_symbol="$"
     mon_decimal_point="."
     mon_grouping="3"
     mon_thousands_sep=","
     positive_sign=""
     negative_sign="-"
     int_frac_digits=2
     frac_digits=2
     p_cs_precedes=1
     p_sep_by_space=0
     n_cs_precedes=1
     n_sep_by_space=0
     p_sign_posn=1
     n_sign_posn=1
     debit_sign="DB"
     credit_sign="CR"
     left_parenthesis="("
     right_parenthesis=")"
Base
Add-on products fail to load because they define Object>>#->
  The Object>>#-> method has been added as a convenience for constructing instances of Associations 
  (for example, evaluating the expression 'upperLeft' -> (0@0) will answer anAssociation with 
  'upperLeft' as the key and 0@0 as the value).  Some add-on products have extended Object with this 
  same method.  One such product is the RefactoringBrowser.  Attempting to load such a product will 
  cause a conflict and result in a load failure with a message similar to the following:
     Error: 330   Cannot complete the load because Object>>#-> is defined by RBParserVAApp and CLDT
  NOTE: The method collisions will be resolved if you reload after executing:
     EmImageBuilder cancelIfMethodsCollide: false
  
  Following the suggested course of action will allow the add-on product to load correctly.
ANSI Smalltalk support
  Support for ANSI Smalltalk (see ANSI/NCITS 319-1998 Smalltalk Programming Language, available in 
  PDF format from http://www.techstreet.com/cgi-bin/detail?product_id=56122) is included in this 
  release of VisualAge Smalltalk Enterprise.  This support greatly enhances the portability of 
  Smalltalk applications between different Smalltalk implementations that provide ANSI Smalltalk 
  support.
  
  All methods supporting the ANSI Smalltalk protocol are categorized as ANSI-API.  Methods associated 
  with ANSI Smalltalk function that is not complete in this release are categorized as 
  ANSI-Unimplemented.
  
  The following restrictions with respect to ANSI Smalltalk are in force for this release:
  The following Exception methods are not functional
  isNested
  outer
  pass
  resignalAs:
  retry
  retryUsing:
  
  The following DateAndTime methods are not functional:
  timeZoneAbbreviation  
  timeZoneName
  
  The MessageNotUnderstood exception class is provided, but is not signaled by the standard 
  #doesNotUnderstand: method.
  
  The ZeroDivide exception class is provided, but is not signaled when a divide by zero occurs.
Modify validation of EsString>>#bindWithArguments:
  As a result of the changes made by the fix to defect 19427 in the EsString>>#bindWithArguments: 
  processing (which also affects all EsString>>#bindWith:..... methods), documentation for the 
  handling of missing or extra arguments is modified, and documentaiton for the pre-existing handling 
  of the %0 sequence in the template string is added.  These changes will be reflected in the IBM 
  Smalltalk Programmers Reference when it is republished.
  
  Update IBM Smalltalk Programmers Reference, Chapter 13: NLS, section "Tools for developing 
  International software", sub-section "Using message templates":
  
  1) In the paragraph beginning "A template string is expanded...", delete the last sentence.
  
  2) Add a new paragraph following this paragraph: 
  
  There are also 2 special escape sequences.  The double percent escape sequence ('%%') is replaced 
  by a single percent chatacter in the composite message.  The percent zero escape sequence ('%0') is 
  replace by a platform line delimiter in the composite message.
  
  3) in the paragraph beginning with "A template string permits ...", replace the last sentence with:
  
  Argument that are not referenced in the template string are ignored.  Template string references to 
  missing arguments are replaced by the escape sequence itself.
  
  4) Repace the last entry in the "Resultant message" column of Table 49 with the following:
  
  'Missing arguments are %2.'
  
On Linux, Ghost dialog windows may appear
  Under certain Linux configurations, some operations that use progress dialogs can cause empty or 
  "phantom" dialog boxes to remain after the operation has completed.  These phantom dialog boxes can 
  show up as a small rectange that is completely blank and cannot be moved.
  
  To work around this problem, make the following modification to 
  EtWindow>>#execLongOperation:message:allowCancel:showProgress:
  ...
    aBlock argumentCount = 1
      ifTrue: [runBlock := [aBlock value: inProgressDialog]]
      ifFalse: [runBlock := [(Delay forMilliseconds: 100) wait. aBlock value]].
  ...
On MVS, INIs are optional for packaged applications. All other platforms, INIs are required for packaged applications
  On MVS, an .ini file is optional. On all other platforms, an .ini file is required. The .ini file 
  may have the same name and be in the same directory as your executable (on Unix, the executable is 
  es or esnx). The .ini file can also have the same name and be in the same directory as your .icx or 
  .ic file. 
  
  In addition, you can specify your .ini file as a command line parameter. For example, you can 
  launch your program by typing the following: 
  
  abt -imyapp.icx -ini:c:\any.ini
On OS/2, Cannot start VisualAge Smalltalk V6.0 if previous version is running
  On OS/2, if you have an older version of VisualAge Smalltalk running, when you attempt to start 
  VisualAge Smalltalk 6.0, you will fail with the following message:
  
  "The program in session encountered a problem. Registry: the system could not demand load the 
  application's segment ABT->ESVM40.  EsReportWarning is in error.  Help Sys127."
  
  To workaround this problem, start VA Smalltalk 6.0 before starting the older version.  Another 
  solution is to replace the bin directory of your older version with a copy of the bin directory 
  that is installed with VisualAge Smalltalk 6.0.
On UNIX, cannot read stack dump files generated on a different platform
  When your development image is running on UNIX, you will not  be able to read stack dump files that 
  were generated on an architecture with different endian-ness.  Doing so will cause a walkback.
  
  To work around this problem, swipe and execute the following doit from your development environment:
  
  PlatformLibrary mapLogicalName: 'EsLoadAndSave' toPhysicalName: 'libeslsi40'
PQ72134 - Multiple exception handling errors
  Problem:
  
  Resumable execption instance variable not set (should answer an empty collection)
  Exception withAllSubclasses
        select:
              [:each |
              each exceptionalEvent resumable isNil]
  
  defaultHandler instance variable not set (should answer an empty collection?)
  Exception withAllSubclasses
        select:
              [:each |
              each exceptionalEvent defaultHandler isNil]
  
  3rd (and after) element, of the contents of ExceptionalEventCollection,  is the Exception subclass 
  and not an instance of ExceptionalEvent (should answer false)
  (MessageNotUnderstood, Error, Warning) ancestorOf: Notification exceptionalEvent
  
  Sample below should answer nil (same as Notification signal) but instead executes the exception 
  block although Notification does not inherit from Error (should answer nil).
  [Notification signal] on: Error do: [:error | error exitWith: 'Not Okay']
  
  Examples:
  
  All the following (non comment) lines should answer true when evaluated.
  
  "Class based exception problems"
  
  ([Notification signal. 'Hello' ] on: Warning, ZeroDivide, Notification do: [:error | error resume: 
  'Goodbye']) = 'Hello'.
  ([Notification signal. 'Hello' ] on: Warning, ZeroDivide, Notification do: [:error | error return: 
  'Goodbye']) = 'Goodbye'.
  ([ZeroDivide signal. 'Hello' ] on: Warning, ZeroDivide, Notification do: [:error | error resume: 
  'Goodbye']) = 'Hello'.
  ([ZeroDivide signal. 'Hello' ] on: Warning, ZeroDivide, Notification do: [:error | error return: 
  'Goodbye']) = 'Goodbye'.
  
  ([Notification signal. 'Hello'] on: Error do: [:error | error resume: 'Goodbye']) = 'Hello'.
  ([Notification signal. 'Hello'] on: Error do: [:error | error return: 'Goodbye']) = 'Hello'.
  
  ([Notification signal. 'Hello'] on: Warning do: [:error | error resume: 'Goodbye']) = 'Hello'.
  ([Notification signal. 'Hello'] on: Warning do: [:error | error return: 'Goodbye']) = 'Hello'.
  
  ([Object new not foo. 'Hello'] on: Error do: [:error | ^true]).
  ([Object new not foo. 'Hello'] on: Error do: [:error | 'Goodbye']) = 'Goodbye'.
  ([Object new not foo. 'Hello'] on: Error do: [:error | error return: 'Goodbye']) = 'Goodbye'.
  ([Object new not foo. 'Hello'] on: Error do: [:error | error resume: 'Goodbye']) = 'Hello'.
  
  ([Notification signal. 'Hello'] on: Notification do: [:error | error pass]) = 'Hello'.
  
  ([Warning signal. 'Hello'] on: Notification do: [:error | error resume: 'Goodbye']) = 'Hello'.
  ([Warning signal. 'Hello'] on: Notification do: [:error | error return: 'Goodbye']) = 'Goodbye'.
  
  Solution:
  
  The ANSI exception handling code has been reworked as a result of this defect.
  
  2 aspects of this code update may cause customers who work outside the scope of the identified API 
  method some concern:
  
  1)  It was discovered that an erroneous Exception class>>#signal: API method was provided.  This 
  protocol is not defined by the ANSI Specification.  Therefore, although the method was left in 
  place, it was commented appropriately and recategorized to 'ANSI-Obsolete' meaning that its use is 
  depricated.
  
  2)  The atttempt to homogonize the old and new forms of exception handling simply won't work.  
  Undoing this failed attempt results in the following changes:
  
   -- The creation and extension of ExceptionEventCollection for class-based exceptions is removed 
   and replaced by the creation and extension of a new ExceptionSet class.  Since there was no 
   explicit API for creating instances of these collections, this should be a generally transparent 
   change.  In addition, all instance-side ANSI-API has been moved from ExceptionalEventCollection to 
   ExceptionSet since ExceptionalEventCollection no longer supports holding ANSI-style exceptions. 
   
   -- The Block>>#on:do: method is changed to handle ONLY ANSI-style class-based exceptions. Handling 
   the old style instance based exceptions was an undocumented extension of function in this method 
   that is now eliminated. 
ScaledDecimal>>#hash corrected
  The fix for APAR PQ62316 changed the algorithm used to hash a ScaledDecimal object.  This change 
  affects existing collections that rely on the hash value.  The affected collections are, at least, 
  KeyedCollection (and its subclasses) and Set (and its subclasses).
  
  If your application uses ScaledDecimal objects as keys for any of these hashed collections, you 
  MUST recompute the hash values after loading the fix and before modifying the collection in any 
  way.  To recompute the hash values, send the rehash message to the collection (for example, 
  myDictionaryKeyedWithScaledDecimals rehash).
Subtle change to compiler (CodeStream>>#literalIndexFor:)
  Due to a subtle change to the compiler, some methods, when recompiled, may behave differently in 
  6.0.1 and 6.0.2 than they did in earlier versions.  
  
  The original problem involved an error in the way the compiler determined whether 2 array literals 
  were identical when the array literals contained one or more numeric values.  See badArrayIdentity 
  below as an example.
  
  This problem was corrected in 6.0.1, but some unforseen side-effects were introduced as shown in 
  the table below.  These side-effects have been eliminated in 6.0.2.
  
  While testing the changes for 6.0.2, we discover and fixed another (pre-existing) problem in this 
  same code as demonstrated by  poolDictionaryModification below.
  
  badArrayIdentity
   | a |
   a := #(3.0).
   ^a == #(3) "Should answer false"
  
  stringLiteralIdentity
   | a |
   a := 'hello'.
   ^a == 'hello' "Should answer true"
  
  mixedArray
   |a|
   a := #('string' #symbol 3).
   ^a == #('string' #symbol 3) "Should answer true"
  
  poolDictionaryModification
   "Upon method compilation, both constants = 'y'"
   "Upon entry to this method, TestPoolB::Value1 = 'y'"
   TestPoolA::Value1 := 'x'.
   ^TestPoolB::Value1 "Should answer 'y'"
  
                              6.0.0  6.0.1  6.0.2
  badArrayIdentity            true   false  false
  stringLiteralIdentity       true   false  true
  mixedArray                  true   false  true
  poolDictionaryModification  'x'    'x'    'y'
Communications
Local Socket Enhancements
  Support for socket options get/set via the setsockopt and getsockopt function calls, previously 
  available only for TCP stream and datagram sockets, has been added for Local Sockets on Linux/Unix 
  platforms in V 6.0.1.  There are two basic types of options: boolean options that enable/disable 
  specific flags and others that set/get configurable features.  Here are the names of the options 
  that are typically supported by the underlying TCP/IP stack: SODEBUG, SOACCEPTCONN, SOTYPE, 
  SOLINGER, SOREUSEADDR, SOKEEPALIVE, SOSNDBUF, SODONTROUTE, SOBROADCAST, SOERROR, SODONTLINGER, 
  SORCVBUF.  The operations use a boolean for the following options:
  SOACCEPTCONN, SODEBUG, SOREUSEADDR, SODONTROUTE, SOKEEPALIVE, SOBROADCAST, SODONTLINGER.
  
  The operations use an integer for the following options. SOERROR, SOSNDBUF, SOTYPE, SORCVBUF.
  
  The operations use a two entry array for the SOLINGER option. The first entry is a boolean and the 
  second is an integer.
  
  In addition, a pair of connected local sockets can now be created via the 
  SciSocketManager>>socketpair: call.  For example, to create a pair of connected local stream 
  sockets, call SciSocketManager default socketpair: SciSocketConstants::SOCKSTREAM.  A collection 
  containing a pair of connected local stream sockets will be returned ready for use.
Local Socket message size limitations.
  By default, the send and receive buffers used for local sockets are set at 32 K (32768 bytes).  In 
  addition, there are platform-dependent limitations the programmer should be aware of.  On Linux, 
  the size of messages sent over a local socket should not exceed 63 KB, (64,512 bytes).  On Solaris, 
  the message size should not exceed 64 KB (65536 bytes).  On HP-UX, the message size should not 
  exceed 32 KB (32768 bytes).  Finally, at the time of this writing, the limits on AIX are 2 KB (2048 
  bytes) for local datagram sockets and 4 KB (4096 bytes) for local stream sockets.
MQ Support Enhancements
  Support for MQCONNX and MQBEGIN function calls, along with their associated options and structures 
  has been updated.  MQCONNX is similar to MQCONN except that it allows options to be specified that 
  controls the way the call works.  The AbtMQBOStruct allows the application to specify options 
  relating to the creation of a unit of work. The structure is an input/output parameter on the 
  MQBEGIN call.  The AbtMQBOStruct is not available for MQ clients.  Refer to MQSeries documentation 
  for further information about these functions and structures. 
MQConnectX function undefined for MVS
  When loading the MQSeries feature on MVS, users will notice the following warning...
  
  Warning: 91   Defined global MQConnectX in unmanaged namespace while loading AbtMQCall 
  class>>connectXTo:with:.
  
  This error is due to the existence of the MQConnectX function in the AbtMQSeriesBaseApp while not 
  being defined as it should in hte AbtMQSeriesMVSSubApp.  Although this problem will not break 
  applications created with versions of VisualAge Smalltalk up to and including V 6.0, this function 
  will not be available to new applications unless defined.  To avoid this error message a definition 
  for the function can be placed in AbtMQSeriesMVSSubApp class>> _PRAGMA_AbtMQSeriesFunctionsMVS by 
  adding the following code to the pragma declaration...
  
   (name: MQConnectX isConstant: true valueExpression:
    '(PlatformFunction callingConvention: #c
     function: 'MQCONNX'
     library: nil
     parameterTypes: #(#pointer #pointer #pointer #pointer #pointer)
     returnType: #void)')
On Linux and HP-UX, MQ now supported
  Support has been added for MQSeries on Linux and HP-UX platforms.  
On Solaris, HP-UX and Linux, APPC and CPIC not supported
  VisualAge Smalltalk Enterprise V6.0 does not support APPC and CPIC on Solaris, HP-UX or Linux. 
SSL API Additions
  There are several additons to SSL support in version 6.0.2 for peer X509 certificate verification 
  on the SciSslsocket and SciSslSocketConfiguration levels.  The information in this README item is 
  meant to complement the Secure Sockets Layer chapter of the Smalltalk Programmer's Reference.  An 
  example SciSslSocketConfiguration using this new verfication API appears at the end of this README.
  
  SciSslSocket protocols - Instance Methods
  
    sslGetPeerCertificate
          Returns a pointer to the X509 certificate the peer presented or an SslError.  If the peer 
          did 
          not present a certificate, nil is returned.
        
          Due to the protocol definition, a TLS/SSL server will always send a certificate, if 
          present. A client will only send a certificate when explicitly requested to do so by the 
          server.  If an anonymous cipher is used, no certificates are sent. 
              
    sslSetVerify: verifyMode
          Set the verification mode for the SSL connection.  Valid modes of operation are...
          SSL_VERIFY_NONE -  
                Server - the server will not send a client certificate request to the client, so the 
                client will not send a certificate. 
                Client - if anonymous ciphers are not in use (by default disabled), the server will 
                send a certificate which will be checked. 
                      The result of the certificate verification process can be checked after the 
                      TLS/SSL handshake using the sslVerifyCertificate method. The handshake will be 
                      continued regardless of the verification result. 
    
          SSL_VERIFY_PEER -
              Server - the server sends a client certificate request to the client. The certificate 
              returned (if any) is checked. If the verification process fails, the TLS/SSL handshake 
              is immediately terminated with an alert message containing the reason for the 
              verification failure. The behaviour can be controlled by or-ing the additional 
              SSL_VERIFY_FAIL_IF_NO_PEER_CERT and SSL_VERIFY_CLIENT_ONCE flags.
              Client - the server certificate is verified. If the verification process fails, the 
              TLS/SSL handshake is immediately terminated with an alert message containing the reason 
              for the verification failure. If no server certificate is sent, because an anonymous 
              cipher is used, SSL_VERIFY_PEER is ignored. 
          
          SSL_VERIFY_FAIL_IF_NO_PEER_CERT -
              Server - if the client did not return a certificate, the TLS/SSL handshake is 
              immediately terminated with a handshake failure alert. This flag must be used together 
              with SSL_VERIFY_PEER. 
              Client - ignored 
          
          SSL_VERIFY_CLIENT_ONCE -
              Server - only request a client certificate on the initial TLS/SSL handshake. Do not ask 
              for a client certificate again in case of a renegotiation. This flag must be used 
              together with SSL_VERIFY_PEER. 
              Client - ignored
          
          Note: Exactly one of the mode flags SSL_VERIFY_NONE and SSL_VERIFY_PEER must be set at any 
          time. Verification failure will lead to a termination of the TLS/SSL handshake with an 
          alert message, if SSL_VERIFY_PEER is set.
  
      
      sslSetVerifyDepth:
          Set the maximum depth to which the certificate chain will be verified.  This depth is only 
          used if SSL_set_verify has previously been set to SSL_VERIFY_PEER.
          
      sslVerifyCertificate 
          Answers the result of peer certificate verification. 
      
          If verification mode is not set to SSL_VERIFY_NONE (see sslSetVerify:), 
          sslVerifyCertificate checks the validity of the peer's X509 certificate to the specified 
          verify depth, or 1 level if unspecified. Although there are many ways the verification of a 
          certificate can fail (expired, revoked, invalid, etc.), the only error code that is 
          returned is the last error that occurred during processing.
  
      
  SciSslContext protocols - Instance Methods
      
      
      certificateChainFile: aCertificateChainFilename
          The certificate must be in PEM format and must be sorted starting with the subject's 
          certificate (actual client or server certificate), followed by intermediate CA certificates 
          if applicable, and ending at the highest level (root) CA.
      
      certificateFile: anX509CertificateFilename
          Sets the context's certificate to be anX509CertificateFilename.  The file must be in PEM 
          format. 
      
      privateKey: anSslPrivateKey 
          Sets the privateKey used by this context to encrypt and decrypt data flowing over the 
          SSL/TLS connection. 
      
      sslMethod 
          Answers the SSL method being used by this context. The SSL method describes the protocol 
          version being used by the peer using this context. 
      
      sslMethod: anSslMethod 
          Sets the SSL method being used for this connection to be the method specified by 
          aPlatformFunction.
              SSLV2 - SSL version 2 
              SSLV3 - SSL version 3 
              SSLV23 - SSL version 2 or 3 
              TLSV1 - TLS version 1 (sometimes called 3.1). 
      
  SciSslSocketConfiguration protocols - Instance methods
      
      caFile: aCertificateAuthorityFile
          Sets the CA file for the configuration.  The Certificate Authority (CA) file is a trusted 
          certifcate used for verification purposes.
      
      caFile
          Answers the CA file for the configuration.
      
      caPath: aCAPath
          Sets the path to the directory containing CA certificate files.
          
      caPath
          Answers the path to the directory containing CA certificate files
          
      certificateChainFilename: aPemCertificateChainFilename
          Sets the certificate chain file to be used by the configuration for verification.
          
      certificateChainFilename
          Answers the certificate chain file beign used by the configuration for verification.
          
          
      verify: verifyMode
          Set the verification mode for the SSL configuration.  Valid modes of operation are...
          SSL_VERIFY_NONE -  
              Server - the server will not send a client certificate request to the client, so the 
              client will not send a certificate. 
              
              Client - if anonymous ciphers are not in use (by default disabled), the server will 
              send a certificate which will be checked. The result of the certificate verification 
              process can be checked after the TLS/SSL handshake using the sslVerifyCertificate 
              method. The handshake will be continued regardless of the verification result. 
                  
          SSL_VERIFY_PEER -
              Server - the server sends a client certificate request to the client. The certificate 
              returned (if any) is checked. If the verification process fails, the TLS/SSL handshake 
              is immediately terminated with an alert message containing the reason for the 
              verification failure. The behaviour can be controlled by or-ing the additional 
              SSL_VERIFY_FAIL_IF_NO_PEER_CERT and SSL_VERIFY_CLIENT_ONCE flags.
              
              Client - the server certificate is verified. If the verification process fails, the 
              TLS/SSL handshake is immediately terminated with an alert message containing the reason 
              for the verification failure. If no server certificate is sent, because an anonymous 
              cipher is used, SSL_VERIFY_PEER is ignored. 
                  
          SSL_VERIFY_FAIL_IF_NO_PEER_CERT -
              Server - if the client did not return a certificate, the TLS/SSL handshake is 
              immediately terminated with a handshake failure alert. This flag must be used together 
              with SSL_VERIFY_PEER. 
              
              Client - ignored 
                  
          SSL_VERIFY_CLIENT_ONCE -
              Server - only request a client certificate on the initial TLS/SSL handshake. Do not ask 
              for a client certificate again in case of a renegotiation. This flag must be used 
              together with SSL_VERIFY_PEER. 
              
              Client - ignored
                  
          Note: Exactly one of the mode flags SSL_VERIFY_NONE and SSL_VERIFY_PEER must be set at any 
          time. Set the verification mode for the SSL connection.  Valid modes of operation are...
      
      verify
          Answer the verification mode for the SSL configuration.
  
      verifyDepth: anInteger
          Set the maximum depth to which the certificate chain will be verified to anInteger.  This 
          depth is only used if #verify: has previously been set to include SSL_VERIFY_PEER.
      
      verifyDepth
          Answer the maximum depth to which the certificate chain will be verified
  
  
  The following is an example SciSslSocketConfiguration using the new API to enable peer certificate 
  verification...
  
  SciSslSocketConfiguration new
      certificateFilename: '<path>/certificateFilename.pem';    
                privateKeyFilename: '<path>/privateKeyFilename.pem';
      caFile: '<path>/caFilename.pem';
                sslVersion: SciSslConstants::SSLv3;
      verify: SciSslConstants::SSL_VERIFY_PEER | SciSslConstants::SSL_VERIFY_FAIL_IF_NO_PEER_CERT;
      verifyDepth: 1;
                yourself.
   
SSL support
  The Secure Socket Layer (SSL) support for VisualAge Smalltalk uses OpenSSL binaries.  OpenSSL is an 
  open source implementation of SSL/TLS based on the SSLeay library developed by Eric A. Young and 
  Tim J. Hudson.  The use of OpenSSL is provided under a dual license, the OpenSSL license and the 
  SSLeay license.  A copy of this license can be found at the end of Chapter 13. SSL in the 
  Programmer's Reference.  The SSL feature is supported on Windows 2000/NT/XP/98/ME, Linux, AIX, 
  HP-UX, and Solaris.  The SSL feature is not supported on MVS and OS/2 platforms.
Database
Get schema function on Stored Procedure Specification Settings
  When using stored procedures with the new Oracle 8 database connection, the Get schema function on 
  the Stored Procedure Specification Settings view only works for procedures that are not contained 
  in packages. Users must manually define host variables for procedures that are contained in 
  packages. 
ODBC Drivers are no longer shipped with VisualAge Smalltalk
  ODBC drivers have not been shipped with VisualAge Smalltalk since Version 4.5. The drivers in 
  previous versions were provided by MERANT (formerly INTERSOLV Inc.). If you need to obtain ODBC 
  drivers, the DataDirect product is still available directly from MERANT. For more information call 
  800-876-3101 or visit http://www.merant.com/datadirect 
  
  You can also check your DBRM for ODBC drivers. Most, if not all, major DBRMs now ship with ODBC 
  drivers. 
On AIX, database features require extracting shared library
  Before you can run the database features on AIX, you must extract a shared object from the 
  appropriate archive file. This is true for IBM DB2, ODBC, and Oracle databases. 
  
  IBM DB2
  For IBM DB2, extract the file from $DB2INSTANCE/sqllib/lib/libdb2.a by performing the following 
  steps: 
     1.Extract the shared object 
       ar -x libdb2.a  
     2.Rename the extracted file libdb2.so 
       mv shr.o libdb2.so
  
  ODBC
  For ODBC, extract from your libodbc.a file by performing the following steps: 
     1.Extract the shared object 
       ar -x libodbc.a
     2.Rename the extracted file libodbc.so 
       mv libodbc.o libodbc.so
  
  Oracle
  For ORACLE, extract from your libclntsh.a file by perform the following steps: 
     1.Extract the shared object 
       ar -x libclntsh.a
     2.Rename the extracted file libclntsh.so 
       mv clntsh.o libclntsh.so
  
  Note:
       For each of these databases, the resulting .so file must be in the library path (LIBPATH) in 
       order to be located by VisualAge.
On HP and Solaris, Library path not set up properly for DB2
  On HP and Solaris, the abt script file attempts to set up the shared library path to include DB2 if 
  DB2 is detected. However, the Korn shell on HP and Solaris does not always evaluate the tilde 
  character (~) so that VisualAge can set up the shared library path to include DB2. This causes the 
  libraries for DB2 to not be added to the path correctly. 
  
  To workaround this problem, you must add the DB2 libraries. You may want to add the one of the 
  following examples to your profile. 
  
  HP:   export SHLIB_PATH=/home/db2inst1/sqllib/lib:$SHLIB_PATH
  Solaris: export LD_LIBRARY_PATH=/home/db2inst1/sqllib/lib:$LD_LIBRARY_PATH
On Unix, running Database Features
  On Unix, if you are using database features and experience a core dump when exiting VisualAge, 
  comment out the PlatformLibrary>>shutDown method. An alternative solution for your packaged 
  application is to execute the following code when exiting: 
  
  System primitiveExit
Oracle initialization mode can be changed without subclassing AbtOracle8DatabaseManager
  Prior to this fix, the only provided method for changing the Oracle initialization mode was to 
  create a subclass of AbtOracle8DatabaseManager in order to override the #userDefinedInitializeMode 
  method.  While this method is still available, it is now possible to change the default 
  initialization mode by setting a class variable. The provided method for doing this is 
  AbtOracle8DatabaseManager  class>>#defaultInitializeMode: . The shipped default value is 
  OCI_DEFAULT, which is unchanged from previous VisualAge Smalltalk version.  See the comment in 
  AbtOracle8DatabaseManager  class>>#defaultInitializeMode: for other possible values.
Prerequisite AbtRecordStructureApp in Database Applications
  Some database applications will need to add a prerequisite for the AbtRecordStructureApp 
  application. Applications that use Database Parts will not need to add this prerequisite because 
  the parts will include the AbtRecordStructureApp application. If an application manipulates 
  instances of any of the subclasses of AbtRow, they will probably need to add this prerequisite. 
  
  If you package your application and get the error The attribute Pub <Attr name> does not exist at 
  runtime, you need to include the AbtRecordStructureApp application. 
Running Oracle samples
  To create the stored procedure used in the Oracle sample, logon to SQL*PLUS and use the file found 
  in your vast\samples\oracle.
  
  1.  Logon to SQL*PLUS
                  sqlplus scott/tiger
  2.  Execute the file
                  SQL> @vast\samples\oracle\sample.sql
DBCS
DBCS Notes on installing VisualAge Smalltalk
  When installing on a DBCS machine please remember the following: 
  
  1.If you are using OS/2 Warp 4.0J, you must apply Warp J4 Fixpack FX00004 before using VisualAge 
  Smalltalk. 
  2.If you are using a DBCS version of OS/2 Warp 4.0, other than OS/2 Warp 4.0J, IBM VisualAge 
  Smalltalk Enterprise requires the equivalent to Warp 4.0J Fixpack FX00004. 
  3.If you are using IBM VisualAge Smalltalk Enterprise on a DBCS system, you must use the 
  ABTRULES.DBC file instead of the default US-English ABTRULES.NLS provided by the system. The 
  ABTRULES.DBC file contains additional codepage conversion tables needed for the DBCS environment.  
  You can find this file in your VisualAge NLS directory. Back up the ABTRULES.NLS file to 
  ABTRULES.BAK, then rename ABTRULES.DBC to ABTRULES.NLS. 
Display Resolution for DBCS machines
  To ensure all information is displayed on your computer, we encourage you to use the highest 
  resolution offered by your display terminal. 
Using an English version of Lotus Notes
  The NLS versions of Lotus Notes must be installed on the native Operating System (OS) platforms, in 
  order for Notes to work. If a US-English version of Lotus Notes is installed on the native OS, then 
  the user will not be able to input either SBCS or DBCS characters correctly. This is a restriction 
  with Lotus Notes. 
Web Connection does not support DBCS char for Cookies
  DBCS cookies are not supported using the Servlet Interface.   This is a limitation of the HTTP 
  Server.
Documentation and Helps
On UNIX, Netscape 4.7 may not start automatically
  On the UNIX platform, if you use Netscape 4.7, VisualAge Smalltalk may not be able to bring up 
  Netscape when you try to access the help system. To workaround this problem on HP-UX and Sun 
  Solaris, bring up Netscape manually before accessing the VisualAge Smalltalk Help. On AIX, bring up 
  Netscape manually and type in the following URL : 
  
  http: //localhost:57002/abtwebx/6.0/va/vast.htm
Domino Connection
Domino Connection supported on Windows XP
  The VisualAge Smalltalk Domino Connection feature is now supported on Windows XP when running with 
  Lotus Notes V6.0.
Error detaching documents using Domino Connection
  When detaching a file attachment using the Domino connection, the detached file is corrupted.  The 
  problem only shows up if the attachment is BASE64 encoded.  Detaching the same attachment using the 
  Notes Client works fine. Detaching via Domino connection also works fine if the file has been 
  attached manually using the Notes Client.
EMSRV
EMSRV 7.1a
  EMSRV 7.1a and EMADMIN 7.0a are made available with this modification level.  The changes from 
  EMSRV 7.1 and EMADMIN 7.0 are as follows:
  
  Platform Support -- the following additional operating system levels are supported by EMSRV 7.1a:
  Windows XP Professional
  Solaris 8.0
  NetWare 6.0
  
  Bug fixes:
  Fixed bug in EMADMIN where a copy of a library would fail with an error if the size of the library 
  in bytes was exactly divisible by 32768.
  Fixed bug in EMSRV where in extremely rare conditions, connections with locks might be incorrectly 
  terminated by the "EMSRV inactivity monitor".  Such terminations would be accompanied by a warning 
  message in the log but since the default behavior of EMSRV is only to report errors, these messages 
  were not often seen.
On OS/2, Starting EMSRV
  In an OS/2 environment, if EMSRV is installed under a directory name that contains spaces (e.g. 
  x:\VAST60 MG\bin), attempting to invoke EMSRV via an OS/2 START command may fail with a SYS1041 
  message. For example, when issued from the varoot\bin directory, the following command: 
  
  START EMSRV -u <userid> <password> 
  
  may get the message SYS1041: The name EMSRV is not recognized as an internal or external command, 
  operable program or batch file. To bypass this problem, issue the command sequence without the 
  START: 
  
  EMSRV -u <userid> <password> 
Using the Manager file
  Be sure to use the following good development practices with EMSRV: 
  
  - Backup the manager file regularly.
   
  - Run library statistics utilities on a regular basis to ensure the integrity of the manager file.
   
  - Protect the manager file. 
Withdrawal of EMSRV support for Windows NT/2000/XP on SMP hardware
  Running any release of EMSRV for Windows NT/2000/XP on a machine with more than one processor may 
  lead to code repositories becoming corrupt.  The increasing number of reports of corrupt code 
  repositories resulting from running EMSRV in these environment has caused the following changes to 
  be made to EMSRV:
  
  EMSRV 7.0a (shipped only with VisualAge Java) and EMSRV 7.1 (shipped with VisualAge Smalltalk 5.5 
  and 6.0)  -- if EMSRV detects more than one installed processor, it will report the following to 
  the console (or to the Application Log if EMSRV is running as a service) and then exit:
  
  WARNING:  Running EMSRV for Windows NT/2000 on multiprocessor hardware is not supported due to the 
  likelihood of a repository becoming corrupted.
  
  EMSRV 7.1a (shipped with VisualAge Smalltalk 6.0.1) --  if EMSRV detects more than one installed 
  processor, and the -mp command line option is not specified,  it will report the following to the 
  console (or to the Application Log if EMSRV is running as a service) and then exit:
  
  WARNING:  Running EMSRV for Windows NT/2000 on multiprocessor hardware is not supported due to 
  suspected operating system bugs that may result in repository corruptions.  Install and run EMSRV 
  on a machine with a single processor or start EMSRV with the -mp option to bypass this check.
  
  The check for SMP hardware can be bypassed by starting EMSRV with the -mp command line option.  By 
  doing this, you will be running EMSRV on an unsupported platform and must assume full 
  responsibility if code repositories become corrupted.  When starting with the -mp command line 
  option, EMSRV will still report a warning to the console (or to the Application Log if EMSRV is 
  running as a service):
  
  WARNING:  Running EMSRV for Windows NT/2000 on multiprocessor hardware is not supported due to 
  suspected operating system bugs that may result in repository corruptions.  You have chosen to 
  start EMSRV with the -mp option to bypass a check that normally restricts EMSRV from running on 
  multiprocessor hardware.  This may cause repositories to become corrupted.
  
  Note that EMSRV continues to support SMP hardware in all other operating system environments.
Installation
Accessing the Smalltalk newsgroup using Netscape
  If you are attempting to access the VisualAge Smalltalk newsgroup 
  news://news.software.ibm.com/ibm.software.vasmalltalk using a Netscape browser, you must choose one 
  of the following items in the Netscape browser's
  Edit->Preferences->Advanced->Proxies menu: 
  
       1. Direct connection to the Internet 
       2. Manual proxy 
  
  If you have selected an autoproxy from this menu, your attempt to access the VisualAge Smalltalk 
  newsgroup will fail. 
On AIX, create a Journaled File System before Installing Smalltalk
  On an AIX machine, before installing Smalltalk for the first time, use Smitty or Smit to create a 
  Journalled File System. 
On AIX, increasing disk space for Smalltalk installation
  On an AIX machine, before installing base Smalltalk for the first time, use Smitty or Smit to 
  increase the disk size to 200 Megabytes.
On Linux, client install may become unresponsive
  We have seen rare cases where the client installation program on Linux will hang and become 
  unresponsive after only partially completing the install.  We have only noticed this on machines 
  whose hard drive is one giant partition located at /.
  
  If this happens, a safe workaround is to terminate the install program and completely delete 
  everything in the /opt/IBMvast/6.0 directory.  Then restart the install.
Select Features Screen in UNIX Installs
  On some Unix platforms, problems have been reported on the Select Features screen. After selecting 
  a new feature to install, sometimes the Next button is not enabled due to an error in 
  synchronization of the features. To correct this problem, select the Back button and then on the 
  License Agreement screen, select the Accept button. The Next button on the Select Features screen 
  should then be enabled. 
OLE
Copying from Windows Explorer into an OLE Client part
  Use copy and paste to share OLE objects between the Windows Explorer and an OLE Client part. 
  Dropping an OLE object that was dragged from the Windows Explorer onto an OLE Client part does not 
  work.
Packaging
Fix to class variable initializer packaging rules for IC packaging
  The fix to APAR PQ62227 introduced a change in packaging behavior for ICs.  Previously, the 
  #initializeClassVariable:to:inObjectNamed: and #initializeClassVariable:toObject:inClassNamed: 
  packaging rules were being ignored.  After the fix is applied, these packaging rules have their 
  desired effect of initializing the identified class variable(s) in the packaged runtime IC.  You 
  should examine the senders of these messages in your code to ensure that they specified the 
  initialization values that you want for the class variables at runtime.
XD packaging of non-MVS leaf ICs which use MPRs at runtime
  When using the Packager UI (Modifiy Instructions :: Applications and ICs), you must manually add 
  AbtNlsCfsSupportApp to the image that you are packaging as follows: 
  
     1.Select AbtNlsCfsSupportApp in the left pane. 
     2.Press the >> button. (It will be highlighted. There are two of these buttons. You want to 
     press the one on the left that is below the left and/or center panes). 
Server
5.0 RMI Wizard considerations
  The RMI Wizard adds the following instance methods to all mapped classes: 
  
  sstRmiClassName 
       Answers the Java class name the receiver is mapped to. 
  
  sstIsRmiSerializable 
       Answers true if the receiver is serializable (passed by value). 
  
  sstIsRmiRemotable 
       Answers true if the receiver is remotable (passed by reference). 
  
  The above methods, along with the class mapping definitions (added to the application class), are 
  used by SST to enable instances of the class for use with RMI. There may be some cases where you 
  want to enable the class itself (versus instances of the class) for use with RMI. For example, you 
  might want to have a Java client send messages to a Smalltalk class. If this is the case, you'll 
  need to add the above methods as class methods. 
HTTP server access log
  An SST HTTP server now writes an "access" log, named "httpd.log". Entries in the log are formatted 
  according to the default format used by the Apache HTTP server, in order to enable tooling for 
  Apache logs to be used for SST logs as well. 
  
  This access log is initialized in SstHttpServer>>startUp. An alternate formatter or message target 
  can be specified by sending #accessLog: prior to #startUp.
HTTPS client tunneling through an HTTP proxy
  The SST HTTP client support for HTTP proxies has been enhanced to provide for tunneling HTTPS 
  through an HTTP proxy. 
  
  The central feature of this enhancement is a new connection class - SstHttpsTunnelConnection - 
  which knows how to do the upgrade from TCP to SSL.
   
  To make use of this enhancement, a client must use a transport configuration that specifies a 
  #socketClass of SciSocket and a #connectionClass of SstHttpTunneledConnection. The following method 
  has been added as a convenience for defining a transport configuration to support this scenario.
   
      SstHttpClient class>>#initializeTransportScheme:forHttpsTunnelThrough:proxyAuth:
   
  Example:
   
      SstHttpClient    
      initializeTransportScheme: 'local_https_tunnel'
      forHttpsTunnelThrough: 'proxy.acme.com:80'
      proxyAuth: nil
   
  The method above accepts 'nil' as a proxyAuth credential to indicate that proxy authentication is 
  not required.
   
  The class SstHttpClient is introduced with this enhancement. A client using the transport 
  configuration defined above would be created using the factory method SstHttpClient 
  class>>#forTransportScheme:, as in the example below.
   
    |client|
    (client := SstHttpClient forTransportScheme: 'local_https_tunnel') startUp.
    [client get: 'https://www.foobar.com/secure/index.html']
      ensure: [client shutDown].
  
  It is also possible to configure SST so that the convenience method SstHttpUrl>>fetch uses this 
  tunneling feature. This is done in the same way as illustrated above for an application-specific 
  transport configuration, specifying instead the identifer for the default https client 
  configuration.
  
      SstHttpClient    
      initializeTransportScheme: 'httpsl'
      forHttpsTunnelThrough: 'proxy.acme.com:80'
      proxyAuth: nil
  
  Having done this, the following code is equivalent to the example above.
  
   'https://www.foobar.com/secure/index.html' sstAsUrl fetch
HTTPS server certificate validation by an HTTPS client
  Typically, security policies indicate that an HTTPS client should validate the X509 certificate 
  presented by an HTTPS server, and should verify that the identity asserted by a validated 
  certificate is in fact the identity of the intended server. 
  
  Version 6.0.2 includes enhancements to the SST HTTPS client which enable applications to specify 
  via the security configuration for an HTTPS client transport that a strict certificate validation 
  policy should be applied. In addition, an SstHttpClient can be configured with a @requiredPeerName 
  that will result in the client auto-verifying the identity asserted by the server credential.
  
  To enable strict certificate validation, the HTTPS client transport security configuration must 
  specify: 
  
   1) @caFile - the file name of a trusted certificate authority (CA) certificate store, and 
   2) @verify - the validation policy, and
   3) @verifyDepth - the maximum depth of the presented certificate chain. 
   
  The @verify parameter must be set to "SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT".
  
  Unless known to be too limiting, a reasonable default value for @verifyDepth is the Integer '2'.
  
  The @caFile is a certificate store in PEM format, as per OpenSSL. 
  
  Example 1. The code below configures the default HTTPS client transport for strict server 
  certificate validation.
  
   (SstTransport configurationRegistry at: 'httpsl') 
    securityConfiguration: (SciSslSocketConfiguration new
             sslVersion: SciSslConstants::SSLv3;
             caFile: 'certs/sst_ca.pem';
             verify: SciSslConstants::SSL_VERIFY_PEER | Sc
             iSslConstants::SSL_VERIFY_FAIL_IF_NO_PEER_CERT;
             verifyDepth: 2;
             yourself).
  
  With this configuration in place, the fetch below will fall into the exception handler if the 
  presented server certificate cannot be validated against the trusted CA certificate store.
  
   ['https://www.acme.com/secure/index.html' sstAsUrl fetch]
    when: SstConstants::ExSstNonFatalError
    do: [:sig| sig exitWith: ('SSL handshake failed:*' match: sig arguments last errorObject)].
  
  To enable server identity verification, in addition to certificate validation, SstHttpsConnection 
  now has a "getter" for @peerCredential, allowing an application to test the Subject attribute of 
  the server's X509 certificate. Auto-verification is enabled in SstHttpClient via a new 
  @requiredPeerName attribute. If this attribute is set, the client will test the certificate Subject 
  immediately after successful SSL connection negotiation (prior to sending the HTTP request) and 
  generate an exception if the Subject does not match the specified @requiredPeerName.
  
  Example 2.
  
   |client response|
   (client := SstHttpClient forTransportScheme: 'httpsl') startUp.
   client requiredPeerName: '/who/do'.
   [['https://www.acme.com/secure/index.html' sstAsUrl fetch] ensure: [client shutDown]]
    when: SstConstants::ExSstNonFatalError
    do: [:sig| sig exitWith: ('Invalid peer:*' match: sig arguments last errorObject)]. 
IIOP PingPong examples fails with an object other than a String.
  When running the IIOP PingPong examples you must pass a type that conforms to the CORBA Any type 
  interface. Typically, Strings are used as the argument representing @anAnyType when sending the 
  method SstPingPongIIOP>>start: @anInteger with: @anAnyTYpe. Passing Smalltalk Integers and Floats 
  as arguments will cause the example to fail because CORBA does not represent these as objects, and 
  therefore, they do not conform to the Any interface. 
On AIX, SST using MQ requires threaded versions of MQ library
  On AIX, some SST applications that use the MQ transport layer will fail when using the unthreaded 
  versions of the AIX MQ libraries. If you are getting the error MqCallInProgress, this may be the 
  cause. 
  
  By default, Smalltalk MQ calls will use the unthreaded libraries. To switch to the threaded 
  libraries, before making your first MQ call, execute the call AbtMQSeriesBaseUnixSubApp threaded. 
Performance improvement in writing walkback log
  In previous releases of VisualAge Smalltalk Server Runtime, only one method of logging a simple 
  walkback was provided.  When an error occurred, the walkback information was written to 
  TranscriptTTY.  This caused the walkback information to be written to the console (Unix) or to a 
  log file identified by the -l commandline option.  Since TranscriptTTY does unbuffered 
  character-at-a-time output, it can be very time consuming to write the walkback information.
  
  For VisualAge Smalltalk V 5.5.2 and later, an alternative output mechanism is provided.  When it is 
  enabled, this mechanism writes the walkback information to a file stream just as would be done for 
  a Reduced Runtime image.  This is a buffered operation which can be more than an order of magnitude 
  faster than writing to TranscriptTTY.
  
  To enable writing the walkback information to a file stream, you must provide the startUp class 
  with the filename of the file to be associated with the file stream.  For example, to see the 
  difference in behavior, create an XD image and load the HelloWorld application.  Then package it 
  specifying AbtHeadlessRuntimeStartUp as the image startup class.  If you specify HelloWorld 
  haltHelloWorld as the application entry point, the walkback will be written to TranscriptTTY (you 
  need to specify the -l commandline switch at runtime to see this output on Windows and OS/2); if 
  you specify System image startUpClass walkbackFileName: 'runtimeWB.log'.  HelloWorld haltHelloWorld 
  as the application entry point, the walkback will be written to the runtimeWB.log file.
SST IIOP Support is Obsolete
  CORBA IIOP facilities provided by SST in previous releases are obsolete as of this release. The 
  implementation provided in previous releases continues to be shipped with this release, but all 
  methods have been recategorized as 'OBSOLETE'. There will be no further developement or enhancement 
  of these facilities, and they may be removed from the product in a future release. 
  
  Customer applications which made use of these facilities in a previous release will continue to be 
  supported as they are migrated to this current release.
  
  Customers are advised to make use of Web Services technologies, such as XML and WSDL, for future 
  interoperability strategies.
Support for JDK 1.3 using RMI
  The RMI in Server Smalltalk will run under JDK 1.3, using the same techniques that were required 
  for JDK 1.2.
UnixSocketDemux>>sstWarn: sends AbtCLDTAdditions message
  SstUnixSocketDemultiplexer>>sstWarn: sends #abtPadWith:upToLength:onRight:, which is implemented in 
  AbtCLDTAdditions - an app not in the prereq chain of the controller for 
  SstUnixSocketDemultiplexer>>sstWarn:.
  
  This method will likely be removed during packaging, causing a runtime DNU.
  
  Workaround: include AbtCDLTAdditions when packaging an SST app.
Using XD Interactive Debugger over TCP/IP with no nameserver
  When trying to use the interactive debugger, if you are getting the error EHOSTNOTFOUND or 
  EADDRNOTAVAIL on the runtime side, the problem may be that your runtime machine cannot resolve the 
  dotted TCP/IP address of your development machine. You can work around this problem by adding an 
  entry to the hosts file on the runtime machine for your development machine. 
Web Connection
#selectionType for table column gives confusing error message in properties
  When a Table part is dropped onto an Html Page, the #selectionType attribute for a table column 
  contains the following selections in the properties table: 
  
  "<Error: No Form - Multiple Select>"
  " Error: No Form - Single Select>"
  
  These messages are a bit confusing. The #selectionType attribute is only valid for tables that are 
  dropped onto an Html Form part. 
Debugging Web Connection applications using interactive debugger
  It is not currently possible to use the interactive debugger facility of an XD image to debug a Web 
  Connection application. In order to debug a Web Connection application (or an XML application that 
  uses the Web Server Interface), perform the following steps: 
  
     1.In the AbtWebServerInterfaceBaseApp>>AbtWsiConnection>>#handleTransaction: method, change the 
     ExAll exception reference to ExError. 
     2.In the AbtWebServerInterfaceBaseApp>>Block>>#abtWsiAtEndOrWhenExceptionDo: method, replace the 
     code with the following: 
  
       abtWsiAtEndOrWhenExceptionDo: completionBlock
         " Code hacked to enable debugging in XD runtime image via the interactive debugger "
         self value.
         completionBlock value
        
       After making the above changes, package the application and execute it as usual. 
       Note: Be sure to load the original code prior to packaging the application for production. 
Including the Web Server Interface Monitor in packaged applications
  The Web Server Interface Monitor is no longer included, by default, in the prerequisites for Web 
  applications. In order to include the monitor in a packaged application, users should modify the 
  prerequisites for web applications to include theAbtRunHtmlPageApp application. Alternatively, 
  users can package their web applications using the Tools->Browse Packaged Images option. You can 
  add the AbtRunHtmlPageApp application to the packaged image from the Package Control Panel without 
  modifying application prerequisites. This approach is necessary for Web applications that must be 
  loaded into an XD image because the AbtRunHtmlPageApp application will not load into an XD image. 
  
  For example, the sample application AbtWebSamplesApp is now headless by default because it does not 
  include the prerequisite AbtRunHtmlPageApp. When the packaged image for this sample is started, no 
  windows will open. The application AbtWebSamplesApp can be loaded into a passive XD image and 
  packaged if desired. 
  
  The application AbtWebSamplesWithMonitorUIApp contains prerequisites to include the Web Server 
  Interface Monitor as well as all the sample parts from AbtWebSamplesApp. This application cannot be 
  loaded into an XD passive image. 
  
  Note:
       Applications constructed before v4.5 already include the prerequisite AbtRunHtmlPageApp, so no 
       special action is necessary. 
On OS/2, starting SST-HTTP server hangs
  On OS/2, attempting to start a WSI Server with transport type sst-http causes Smalltalk to hang if 
  TCP/IP loopback is not enabled. 
  
  Eventually, a Smalltalk debugger appears with the following error message: Could not create socket 
  pair: ETIMEDOUT (10060): Connection timed out. To correct this problem, enable loopback on OS/2 by 
  performing the following steps: 
  
     1.Open TCP/IP Configuration windows. 
     2.Select loopback interface from the Interface to Configure list box. 
     3.Select the Enable interface check box. 
     4.Close the TCP/IP Configuration window. 
  
  To determine if the loopback interface is working properly, type the following from an OS/2 command 
  prompt: 
  
  ping 127.0.0.1
  
  If loopback is properly configured, a series of messages will be written to the OS/2 session 
  indicating that the target address for the ping was successfully contacted. Press ctrl-c to 
  terminate the ping operation. 
  
  After successfully configuring loopback, you should be able to use the sst-http interface from 
  OS/2. 
Packaging an image with Web Connection image components
  To package your Web Connection application so that it utilizes the Web Connection image components, 
  you must implement a packager method to force inclusion of your web parts in the packaged image. 
  
  For example, implement the following method as a class method of the application containing your 
  web connection parts. 
  
  packagerIncludeClassNames
     ^self defined collect: [:i | i name ]
WebServices
Additional runtime files
  Several new runtime files are required by the VAST Web services feature for 6.0.2.  They are:
  sstaxis.xsd  -  An XML schema that contains definitions for common Java types including 'Map', 
  'Hashtable', and 'Vector'
  sstaxis.map - An XML mapping specification that enables seamless mapping of common Java types into 
  Smalltalk objects.
  abtvast.map   --  Contains unique mappings to enable unambiguous serialization of objects that can 
  be mapped to a variety of schema types.
Modifications to Web services examples
  The Web services examples have been augmented to demonstrate new Web services functionality (WS-I 
  Basic Profile. SOAP 1.2, security enhancements).  The directory structure for the samples has been 
  modified.  See the file ./samples/sstws/Readme.txt for additional information about using the Web 
  services samples.
Namespace for sample WSDL changed
  The targetNamespace for the implementation WSDL of the insurance example was changed from 
  "http://www.SstWSInsurancePolicyInterface.com/SstWSInsurancePolicyInterface" to 
  "http://www.SstWSInsurancePolicyInterface.com/SstWSInsurancePolicyInterface-impl" (added '-impl' 
  suffix).  The documenation still references the old namespace in some of the code samples; however, 
  the code samples in the .\samples\sstws directory are correct.
Server Fault message construction
  When a Web services client receives a SOAP fault response from the server, standard Web services 
  handler chains are traversed prior to signalling an exception to report the SOAP fault.  Therefore, 
  fault chains are traversed after standard client processing has already completed.  Custom client 
  chains may need to be aware of the possibility that the message result could be a fault.  Ideally, 
  the Web services support should circumvent standard processing and branch immediately into the 
  fault handlers after discovering a SOAP fault in the output message.
  
  Client handlers can use the message #isSoapFault to verify that message results contain expected 
  content.
            example:   fault :=  anSstWSMessageContext results detect:[:each | each isSoapFault] 
            ifNone: [ ]. 
Web services hints, tips, and FAQs
  -------------------------------
  How can I override the default XML serialization logic?
  
  XML serialization is performed by objects called 'serializers'.  Developers can supply custom 
  serializers that replace the default serialization logic.  
  
  | container config |
  container := SstWSContainer containerNamed: 'MyContainer'.
  config := container serializationManager serializationConfigurationNamed: 
  SstSoapConstants::SstSoapDefaultEnvelopeNamespace.
  config serializer: MyCustomSerializer current.
  
  Alternatively, the serialization configuration itself can be replaced.
  
  | container  |
  container := SstWSContainer containerNamed: 'MyContainer'.
  container serializationManager 
   addSerializationConfiguration: AbtXmlSerializationConfiguration newSoapConfiguration 
   named: SstSoapConstants::SstSoapDefaultEnvelopeNamespace.
  
  
  -------------------------------
  How can I disable/enable SOAP multi-ref serialization?
  
  By default, SOAP encoded messages are constructed using the serialized named 
  SstSoapOutputSerializer. This serializer causes all complex SOAP messages to be encoded as SOAP 
  multi-refs.  Notice that the serialization configuration is referenced using the SOAP encoding 
  namespace.
  
  | container config |
  container := SstWSContainer containerNamed: 'MyContainer'.
  config := container serializationManager serializationConfigurationNamed: 
  SstSoapConstants::SstSoapDefaultEncodingNamespace.
  config serializer: AbtXmlSchemaOutputSerializer current.
  
  
  -------------------------------
  How can I supply custom deserializers to provide custom logic for mapping XML into objects?
  
  Mapping parsed XML into Smalltalk model objects is performed by objects called 'deserializers'. 
  Developers can supply custom deserializers to enhance default mapping behavior.  Custom 
  deserializers can be created and set in deserialization configurations.  
  
  
  | container config |
  container := SstWSContainer containerNamed: 'MyContainer'.
  config := container serializationManager 
   deserializationConfigurationNamed: SstSoapConstants::SstSoapDefaultEnvelopeNamespace.
  config deserializer: AbtXmlSchemaInputDeserializer current.
  
  
  Alternatively, the default SOAP deserialization configuration can be replaced
  as shown below.
  
  | container config |
  container := SstWSContainer containerNamed: 'MyContainer'.
  config := AbtXmlDeserializationConfiguration newSoapConfiguration.
  config deserializer: AbtXmlSchemaInputDeserializer current.
  container serializationManager 
   addDeserializationConfiguration: config
   named: SstSoapConstants::SstSoapDefaultEnvelopeNamespace.
  
  
  
  -------------------------------
  How can I print incoming and outgoing SOAP messages on my Web services server?
  
  The message handler chain can be modified to add code that dumps the contents of the SOAP message 
  and response.
  
  | factory pluggableHandler |
  factory := ( SstWSContainer containerNamed: 'VastSampleServerContainer' ) handlerFactory.
  pluggableHandler :=SstWSPluggableHandler new
   invokeBlock: [ :anSstWSMessageContext |  | message |
    [ 
    message :=  anSstWSMessageContext propertyNamed: ##wsTransportMessageRequest.
    AbtXmlUtility logError: 'Request->'.
    AbtXmlUtility logError: message header debugPrintString.
    AbtXmlUtility logError: message contents asString.
    AbtXmlUtility logError: ''.
    AbtXmlUtility logError: 'Response->'.
  
   " NOTE:  The output message is not stored in the message context. "
    AbtXmlUtility logError: (
     anSstWSMessageContext container serializationManager
     serialize: anSstWSMessageContext currentMessage context: anSstWSMessageContext )] fork ].
  
  factory
   register: pluggableHandler
   named: 'wsHttpServerResponseHandler' inNamespace: factory
   globalNamespace
  
  
  To disable the tracing code, execute the snippet below:
  
   | factory |
   factory := ( SstWSContainer containerNamed: 'VastSampleServerContainer' ) handlerFactory.
   factory
    register: SstWSNoOperationHandler default
    named: 'wsHttpServerResponseHandler'  inNamespace: factory globalNamespace
  
  -------------------------------
  How can I print incoming and outgoing SOAP messages on my Web services client?
  
  The message handler chain can be modified to add code that dumps the contents of the SOAP message 
  and response.
  
  | factory pluggableHandler |
  factory := ( SstWSContainer containerNamed: 'VastSampleClientContainer' ) handlerFactory.
  pluggableHandler :=SstWSPluggableHandler new
   invokeBlock: [ :anSstWSMessageContext |  | message |
    [ 
    message :=  anSstWSMessageContext propertyNamed: ##wsTransportMessageRequest.
    AbtXmlUtility logError: 'Request->'.
    AbtXmlUtility logError: message  asString.
    AbtXmlUtility logError: ''.
    AbtXmlUtility logError: 'Response->'.
  
   " NOTE:  The output message is not stored in the message context. "
    message :=  anSstWSMessageContext propertyNamed: ##wsTransportMessageResponse.
    AbtXmlUtility logError: message header debugPrintString.
    AbtXmlUtility logError: message contents asString  ] fork ].
  
  factory
   register: pluggableHandler
   named: 'wsHttpClientResponseHandler' inNamespace: factory globalNamespace
  
  
  To disable the tracing code, execute the snippet below:
  
   | factory |
   factory := ( SstWSContainer containerNamed: 'VastSampleClientContainer' ) handlerFactory.
   factory
    register: SstWSNoOperationHandler default
    named: 'wsHttpClientResponseHandler'  inNamespace: factory globalNamespace
  
  
  -------------------------------
  How can I clean up the sockets and active HTTP servers in my image?
  
  The script below shuts down all active HTTP servers, and terminates all active sockets.
  
  [true] ensure: 
  ["Stop a running system and clean everything out"
  SstHttpServletEngine allInstances do:[:e | e shutDown. e clear. e become: nil].
  SstHttpServer allInstances do:[:e | e shutDown. e clear. e become: nil].
  
  Processor allProcesses do: [:s | (s == UIProcess currentUI) ifFalse: [s basicTerminate]].
  Processor reschedule.
  
  SstApplicationContext clearAll.
  SciSocketManager default closeAllSockets.]
  
  
  -------------------------------
  How does VAST default serializer determine the XML schema type for an object that is defined as 
  'anyType'? 
  
  The algorithm for processing 'anyType' and for processing 'subtypes' is very similar.
  
  A new mapping spec is introduced (contained in 'abtvast.map') to represent the Smalltalk namespace. 
  The new mapping spec is intended to describe how Smalltalk objects should map to XML schema types.  
  For typical mapping specs, it is possible to have multiple types map to the same object; therefore, 
  determination of a schema type from an object instance is ambiguous.  The Smalltalk namespace 
  mappings remove ambiguity because each object maps to a single schema type.
  
  For many cases, it is not necessary to refer to the Smalltalk mapping spec in order to determine a 
  proper type mapping. The Smalltalk namespace exists strictly to remove ambiguity when the same 
  class can map to multiple types.
  
  When trying to determine the 'actual' type for an object, VAST does the following:
  
  - Check the schema of the base schema type to see if there is a more specialized type that matches 
  the class name of the object being serialized.
  
  - Try to find a mapping for the class name of the serialized object and use the mapping to 
  determine the actual schema type.  The mapping is searched for in:
  1) Smalltalk mapping namespace
  2) Base type namespace
  3) All other visible namespaces (namespaces visible at that point in serialization of the object)
  
  For types other than 'anyType', if no 'specialized' type is found, the 'baseType' is assumed to be 
  the serialization type.
  
  For an 'anyType', if no 'specialized' type is found, a type definition is constructed based on the 
  class shape.  The type is created in the "VisualAge Smalltalk" namespace.
  
  The "Smalltalk" namespace is settable in the serialization configuration.  The default value is 
  'urn:Vast' and is globally settable in the pool variable  AbtXmlConstants::AbtXmlSmalltalkNamespace.
  
  
  -------------------------------
  How can I disable validation during WSDL parsing?
  
  AbtXmlObjectCache current
   addDeserializationConfiguration: (AbtXmlDeserializationConfiguration newWsdlConfiguration 
   validate: false)
   named: 'http://schemas.xmlsoap.org/wsdl/'.
  
  -------------------------------
  How can I enable code page conversion of SOAP messages during serialization?
  
  Add an 'XmlSerializationEncoding' entry to the [Xml] stanza of your application's .ini file as 
  shown below.
  [Xml]
  DefaultResourceQualifier=D:\vast\b49\xml\
  XmlSerializationEncoding=UTF-8
  
  The value for this entry should be the target encoding for the serialized SOAP message.  The VAST 
  Web services support will always attempt to serialize SOAP messages using the specified encoding. 
  
  For less common encodings, it may be necessary to add a code page mapping using API in 
  AbtXmlStreamConverter to map the specified encoding value to a valid code page supported by the 
  platform.
   AbtXmlStreamConverter mapEncoding: 'UTF-8' toCodePage: 65001
  
  -------------------------------
  How can I deploy commonly used schemas to a Web services container?
  
  The deployment descriptor contains a <schemaUrls> block for this purpose.  Schemas that are 
  imported by deployed WSDL documents are automatically deployed to the container and do not need to 
  be included in the <schemaUrls> block of the deployment descriptor.   
  
   <schemaUrls>
     <schemaUrl>http://schemas.xmlsoap.org/ws/2002/07/secext/</schemaUrl>
   </schemaUrls>
  
  Use the <schemaUrls> block to:
   - Specify XML schemas required to provide supplemental functionality (ie.  SOAP 1.2, WS-Security )
   - Override schemas that are already deployed to the global XML object cache (ie. WSDL, SOAP)
  
  -------------------------------
  How can I enable a VAST container to process SOAP 1.2 messages?
  
  VAST Web services containers can be configured to enable processing of SOAP 1.2 messages.  This is 
  accomplished by deploying SOAP 1.2 schemas and mapping specifications to the server container.  See 
  the sample directory /samples/sstws/soap12/Readme.txt for additional information about configuring 
  a Web services container for SOAP 1.2.
  
  The same Web services container can be used to process SOAP 1.1 and SOAP 1.2 messages.
  
  -------------------------------
  How can I enable a VAST client service to send SOAP 1.2 messages?
  
  VAST Web services client containers can be configured to enable processing of SOAP 1.2 messages.  
  This is accomplished by deploying SOAP 1.2 schemas and mapping specifications to the client 
  container.  In addition, SstWSService instances contain accessors to allow the SOAP 1.2 namespace 
  to be specified for outgoing SOAP messages.
  
  ie)
  | service |
  service := (SstWSContainer containerNamed: 'MyContainer') serviceManager serviceNamed: 
  'SstWSInsurancePolicyInterface' 
   inNamespace: 'http://www.SstWSInsurancePolicyInterface.com/SstWSInsurancePolicyInterface-impl'.
  service sstSoapEnvelopeNamespace: SstSoap12Constants::SstSoap12EnvelopeNamespace.
  
  See the sample directory /samples/sstws/soap12/Readme.txt for additional information about 
  configuring a Web services 
  container for SOAP 1.2.
  
  -------------------------------
  How can I configure client services to pass WS-Security information?
  
  The schema (http://schemas.xmlsoap.org/ws/2002/07/secext/) must be managed by the 
  serializationManager of the Web services container.  This is accomplished by modifying the client 
  deployment descriptor to include the required schema.
  ie)
  <schemaUrls>
     <schemaUrl>http://schemas.xmlsoap.org/ws/2002/07/secext/</schemaUrl>
  </schemaUrls>
  
  Authorization credentials can be specified in the SstWSService that is being invoked causing those 
  credentials to be passed automatically as part of the message.  The SstWSService contains accessors 
  for getting and setting HTTP authorization credentials (#sstAuthCredential:) as well as WS-Security 
  username tokens (#sstUsernameToken:). See the sample directory 
  /samples/sstws/ws_security/Readme.txt for additional information and examples.
  
  
  -------------------------------
  How can I specify a custom servlet for processing incoming service requests?
  
  The default servlet for processing incoming Web services messages is SstWSServlet.  Developers may 
  provide their own custom servlet if more sophisticated rocessing is required.  To enable an 
  alternative servlet using the default http transport strategy, execute code like that shown below:
       SstWSHttpNetworkTransportStrategy defaultServletClass: MyWebServicesServlet
  
  -------------------------------
  How can I make use of custom SST transports for invocation of remote service operations?
  
  The container configuration supports transport mappings that are used to map url schemes to the 
  registered SST transport schemes used for invocation.   
  
  The #urlScheme setting can specify a full URL name to enable special processing for a specific 
  resource location, or the value can be a scheme prefix (ie. 'http' or https') for general cases.
  
  The #transportScheme is the identifier for an SstTransport configuration that describes the details 
  of the underlying communications protocol.
  
  <!-- transportMappings is an optional element that appears after the </managers> end tag
   in the container deployment descriptor.   -->
   <transportMappings>
    <transportMapping urlScheme="http" transportScheme="httpl"  />
    <transportMapping urlScheme="http://vasthost:63003"  transportScheme="vasthost" />
    <transportMapping urlScheme="https"  transportScheme="testhttps" />
   </transportMappings>
  
  
  The code below accomplishes the same task: 
  
   | myContainer |
   myContainer :=  SstWSContainer containerNamed:  'VastSampleClientContainer'.
   myContainer configuration 
    mapUrlScheme: 'http' toTransportScheme: 'httpl' ;
    mapUrlScheme: 'http://vasthost:63003' toTransportScheme: 'vasthost' ;
    mapUrlScheme: 'https' toTransportScheme: 'testhttps'
  
  SST transport schemes must be registered in class SstTransport prior to usage.  See the class 
  methods #serverTransportConfiguration and registerPluginConfigurations in SstHttpCommunications for 
  an example of how transport configurations are created and registered.
  
  
  -------------------------------
  How can I map a Smalltalk Dictionary to XML?
  The resource files 'sstaxis.map' and 'sstaxis.xsd' contain the rules required for mapping Smalltalk 
  Dictionary objects to/from XML.  Dictionaries are represented in XML as 'Map' elements in the 
  namespace 'http://xml.apache.org/xml-soap'
  
  
XML
On Unix, testing the XML server sample AbtXmlSampleCustomerRequestHandler
  The XML server sample named AbtXmlSampleCustomerRequestHandler contains code with hard coded 
  directory references that do not resolve properly. If you would like to test this sample, you must 
  first do the following: 
  
     1.Create a subdirectory named xml from your VisualAge base client directory. For example: 
        mkdir xml
  
     2.Copy the xml files from the directory /opt/IBMvast/6.0/xml to the newly created xml directory. 
     For example: 
       cd <vast client directory> /xml
       cp /opt/IBMvast/6.0/xml/*.* .   
Packaged image with XML image components
  If you wish to package your XML application so that it utilizes the XML image components, you must 
  implement a packager method to force inclusion of your XML request handler parts in the packaged 
  image. For example, you can implement the following method as a class method of the application 
  containing your XML request handler parts: 
  
  packagerIncludeClassNames
  | handlers |
    handlers := AbtXmlServerSamplesApp defined select: [:aClass | 
       aClass inheritsFrom: AbtXmlWsiHandler ].
    ^handlers collect: [:aClass | aClass name ]
  
  For reduced runtime images that are packaged without the XML image components, all XML request 
  handlers are automatically included in the packaged image. 
Packaging considerations when using XML input serialization
  If the input serialization functionality of the XML feature is used to map incoming XML requests 
  into Smalltalk business objects, the packager will exclude classes that are not specifically 
  referenced in code. The specific sequence of events that may cause packaging concerns is as 
  follows: 
  
     1.Parse an XML file to construct a DOM (document object model). 
     2.Send the #mapUsing: method to the DOM and pass it a valid instance of the AbtXmlMappingSpec 
     class. 
  
  The #mapUsing: API uses the passed mapping specification to build an object from the contents of 
  the DOM. However, the steps above do not cause any actual references to the class name of the 
  constructed instance. Therefore, packaging rules must be used to instruct the packager that 
  unreferenced classes should be included in the packaged image. 
  
  For example, the #packagerIncludeClassNames packager method (a class method) can be implemented in 
  the application class.  For example, if MyModel1 and MyModel2' are classes in MyApplication, then 
  the method below should be implemented as a class method in MyApplication. 
  
  packagerIncludeClassNames
     " Include class names that might be constructed via XML mapping "
   
     ^#(MyModel1 MyModel2)
Removed unused method #abtXmlPrintOn:namespaces:
  The following public methods are removed:
  
  AbtXmlSchema>>#abtXmlPrintOn:namespaces:
  AbtXmlSchemaComplexType>>#abtXmlPrintOn:namespaces:
  AbtXmlSchemaDeclaration>>abtXmlPrintOn:namespaces:
  
  These methods were not used by supported versions of the VAST XML support and should not affect 
  user applications.
Suppress serialization of nil attribute values when attribute mapping specifies Required="false"
  This change does NOT affect objects that utilize an XML schema for serialization.
  Nil attribute values are now suppressed during serialization of attributes with attribute mappings 
  that specify 'Required="false".
  
  For example:
  <ClassElementMapping ElementTagName="customer" ClassName="AbtXmlSampleCustomer" >
  <AttributeMapping ClassAttribute="lastName" Required="false"><Attribute>lastName</Attribute>
  </AttributeMapping>
  </ClassElementMapping>
  
  If the lastName attribute of a serialization target object is nil, the serializer will not render 
  the 'lastName' attribute.  
Using the XML server examples
  To try out the XML server samples, perform the following steps: 
  
  Testing XML request handlers over HTTP 
          1.From the VisualAge Organizer, select the AbtXmlServerSamplesUIApp application. 
          2.Select the AbtXmlSampleHttpClientTesterView part. 
          3.Enter an XML string or a piece of code that evaluates to an XML string 
                  AbtXmlSampleCustomerRequest xmlTestString1      
                  AbtXmlSampleCustomerRequest xmlTestString2
          4.From the Actions menu, select the Open WSI monitor option to bring up the Web Server 
          Interface monitor. Follow the instructions in the Web Connection User's Guide to start a 
          WSI server with transport type wsi-tcp 
          5.Specifiy the URL that will handle the request: 
                   http://myserver/cgi-bin/abtwsac.exe/AbtXmlSampleCustomerRequestHandler
          6.Enable the Options->Inspect result option so that you can view the returned XML response 
          string 
          7.Select the code string in the text box, and select the Actions->Evaluate and send menu 
          option (or use pop-up menu for text box). 
  
       After the command is processed, an inspector should open to display an XML string that 
       contains the results. 
  
  Testing XML request handlers over sockets (very similar to the steps for testing over HTTP) 
          1.From the VisualAge Organizer, select the AbtXmlServerSamplesUIApp application. 
          2.Select the AbtXmlSampleSocketClientTesterView part. 
          3.Enter an XML string or a piece of code that evaluates to an XML string 
                  AbtXmlSampleCustomerRequest xmlTestString1      
                  AbtXmlSampleCustomerRequest xmlTestString2
          4.From the Actions menu, select the Open WSI monitor option to bring up the Web Server 
          Interface monitor. Start a  WSI server with transport type xml-tcp and select the request 
          handler class that you wish to use for handling incoming requests on the socket. For 
          example: 
                   AbtXmlSampleCustomerSaxRequestWsiHandler
          5.From the XML socket client tester view, specify the server and port number for the 
          request that is to be made (the same server and port from step #4 above). 
          6.Enable the Options->Inspect result option so that you can view the returned XML response 
          string. 
          7.Select the code string in the text box, and select the Actions->Evaluate and send menu 
          option (or use pop-up menu for text box). 
  
       After the command is processed, an inspector should open to display an XML string that 
       contains the results. 
XML code page conversion (unsupported encodings)
  The XML parser automatically performs code page conversion before attempting to parse an XML 
  stream. Many code pages are handled seamlessly using the default code page conversion routine of 
  the runtime operating system. However, there are some character encodings that cannot be converted. 
  Unsupported code page conversions cause walkbacks at execution time. 
  
  The following code pages are not supported: 
  
   * EUC_JP conversion is not properly supported by native Windows code page routines. A Windows 
   implementation of ICONV supports EUC_JP. To download ICONV, see 
   http://www.ibm.com/software/ad/smalltalk/downloads/vacodepage.html Using the ICONV support, 
   additional code pages, including EUC_JP, can be supported.  
  * The code page ISO-2022-JP is not supported by native routines or by ICONV. 
  
  The VisualAge XML support attempts to map XML character set encodings to valid code pages. The 
  default mappings can be overridden using the API shown in the following example: 
  
  AbtXmlStreamConverter mapEncoding: 'UTF-8' toCodePage:  65001.
  
  VisualAge uses the code page conversion support APIs that are built in to each of the supported 
  platforms. Therefore, code page mappings may be different for different operating systems. If you 
  encounter a debugger with the following message it is likely that you have encountered an unmapped 
  or mismapped encoding. 
  
  Abt.Nls.160.e: Conversion from code page <sourceCodePage> to code page <targetCodePage> is not 
  supported.

Disclaimer

	THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. INSTANTIATIONS DISCLAIMS 
	ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, THE 
	IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE AND MERCHANTABILITY 
	WITH RESPECT TO THE INFORMATION IN THIS DOCUMENT. BY FURNISHING THIS DOCUMENT, 
	INSTANTIATIONS GRANTS NO LICENSES TO ANY PATENTS OR COPYRIGHTS. 
	
	(C) Copyright Instantiations Corporation 2005. All rights reserved.

[10/6/2003 - 11:19:02 PM]