Restrictions for Connect:Direct for Microsoft Windows

Connect:Direct® for Microsoft Windows version 4.8 has the following restrictions:

  • Secure+ ParmFiles encrypted with IDEA is not upgradeable. Impacted versions include, Connect:Direct for Windows 4.2.00
  • Changes to the SPCli will break customer scripts.
  • There is no GUI support for creating ECDSA signed certificates.
  • You can keep an earlier version of Connect:Direct for Microsoft Windows on the computer on which you are installing Connect:Direct for Microsoft Windows version 4.8.
  • Connect:Direct for Microsoft Windows version 4.8 SNMP and NT Broadcast do not send messages on 64-bit operating systems.
  • Built-in variables should only be specified in a SUBMIT statement within a Process if the statement will be executed on a Connect:Direct for Microsoft Windows version 4.6 (or later) node or another IBM® Connect:Direct version that supports built-in variables.
  • Temporary addresses, which are a security feature of the IPv6 protocol, are generated automatically by the operating system and are used only for outbound connections. These addresses have a short life span and are replaced by other temporary outbound addresses. This feature of the IPv6 protocol causes problems with Netmap Checking. If the outgoing address of the PNODE randomly changes and netmap checking is enabled by the SNODE, the SNODE always refuses the connection because the IP address of the PNODE never matches the IP address configured for it.

    You can work around the problem created by temporary addresses in two ways:

    • On the PNODE, configure outgoing.address in the initialization parameters file using the IPv6 address for the PNODE server. This ensures that the IP address that the PNODE uses to create a connection to a remote node is always constant. Consider the following:
      • If a PNODE has several IP addresses configured, for example, two IPv6 addresses and two IPv4 addresses, configure the outgoing.address initialization parameter with one IPv6 address. This address can then be used to connect to an SNODE configured with either IPv6 or IPv4 addresses.
      • If a PNODE wants to use an IPv4 address to connect to an SNODE that has both IPv6 and IPv4 IP addresses, ensure that the tcp.api.port and tcp.host.port initialization parameters of the SNODE are configured with an IPv4 address and port.
    • Disable temporary addresses for the PNODE. This is a configuration option in the Windows networking component. If the temporary addresses are not generated, connections to a remote that use the IPv6 protocol use the configured IPv6 address.
      Note: To disable temporary addresses in the Windows Vista OS, issue the following command from a command prompt: netsh interface ipv6 set privacy state=disabled. For other Windows operating systems, see the Microsoft Windows documentation.

      See RFC 3041 for more information on IPv6 temporary addresses.

  • If you modify user authorizations from the IBM Connect:Direct server and the IBM Connect:Direct Requester is attached, you must detach and reattach to the IBM Connect:Direct server. When you reattach to the IBM Connect:Direct server, IBM Connect:Direct Requester reads the updated user information.
  • Connect:Direct for Microsoft Windows previously supported the DESKTOP(YES) parameter in the SYSOPTS statement of a IBM Connect:Direct Process. This parameter enabled user programs launched by the IBM Connect:Direct service to interact with the Windows desktop. Currently this parameter functions only on versions of Microsoft Windows prior to Windows Vista and Windows Server 2008. For security reasons, Microsoft has removed support for Interactive Services from those two operating systems. Microsoft blocks any attempt by a Windows service to interact with the desktop. IBM Connect:Direct administrators should begin to remove the DESKTOP(YES) parameter from all Connect:Direct for Microsoft Windows Process scripts. Alternatively, you can switch DESKTOP(YES) references to DESKTOP(NO).

    To ease the transition of upgrading to Connect:Direct for Microsoft Windows, IBM Connect:Direct detects when a process using DESKTOP(YES) is submitted on a Windows system that does not support Interactive Services. When DESKTOP(YES) is detected, IBM Connect:Direct dynamically switches to DESKTOP(NO) and records the following warning in the statistics:

    LPRS020I  Invalid DESKTOP value specified.
    DESKTOP=YES is not supported on this version of Windows. 
    The RUN TASK / JOB will continue with DESKTOP reset to NO.

    After this warning is written to IBM Connect:Direct statistics, the Process is allowed to continue as if DESKTOP(NO) had been originally specified.

    This transitional feature works only if the RUN TASK or RUN JOB is capable of running without desktop interaction. That is, if manually switching DESKTOP(YES) to DESKTOP(NO) would cause the IBM Connect:Direct Process to fail, then the dynamic switch to DESKTOP(NO) will not be an effective solution. If the program executed by the RUN TASK/JOB is unable to execute without user interaction then that program must be changed so that it no longer needs user interaction.

  • Under conditions of high CPU usage, a IBM Connect:Direct Process running over UDT may be interrupted by a lost connection. Should this occur, IBM Connect:Direct retries the Process. If connection losses due to high CPU usage are occurring, their frequency can be reduced by restricting the number of concurrent UDT sessions through netmap session limits.
  • For Connect:Direct for Microsoft Windows version 4.8.0.0 or later to work using the UDT protocol with servers running Connect:Direct for z/OS® 4.8.0.0, you must install a fix for the Connect:Direct for z/OS server. Without this fix (T014159), the first time a Process is initiated in Connect:Direct for Microsoft Windows using UDT, the Process will fail with a “Connection Broken” error. The RPLERRCK DD indicates the UDT error code of 2001.