Upgrading to or applying maintenance to TCPaccess 6.0

Products

• TCPaccess

Issue/Introduction

Description:

This outlines changes to be aware of when upgrading from TCPaccess 5.2 or 5.3 to 6.0, or applying maintenance to TCPaccess 6.0 if you are currently at or below SP1.

Solution:

The following is a list of items to be aware of when you apply complete maintenance above SP1 of TCPaccess. You will be affected by the SAS/C change, and maybe some of the others, depending on how the stack and system are configured.

SAS/C applications
This is the one that is most commonly experienced. This will affect you if you are running

• SOLVE:EPS 5.2.
  
  
• VPS (except 2.0).
  
  
• StorageTek products.
  
  
• Mobius (possibly, depending on configuration).
  
  
• Older releases of CCITCP or specific configuration in new release.
  
  
• Certain BMC or EMC applications.
  
  
• Possibly other 3rd party applications.
  

At the SP2 level of TCPaccess, we replaced the TCPaccess version of LSCNCOM using SAS/C 6.5 with the SAS version of LSCNCOM using SAS/C 7.0 in our SASLINK library. Our version uses our proprietary TLI socket interface, while the SAS version uses either OE sockets or HPNS (or sometimes IUCV), depending on the version of SAS with which the application was compiled, as well as what configuration the vendor allows for that product.
What that means on an application basis is that if you change the content of your SASLINK to the 6.0 SP5 version when you upgrade, your SAS/C applications currently using TLI sockets will suddenly try to use HPNS. Typical symptom of this problem is that the application fails with

LSCX471  **** WARNING **** ERRNO = ENETDOWN 
     Generated in   SOCKET called from line    593  of     MAIN(MAIN)   , 
     offset 000582 
     TCP/IP software is down. Reason: HPNS INITAPI to TCP/IP address 
     space: ACSS failed with IBM errno 10102.

The easiest way to fix this problem is to use our version of LSCNCOM. In order to do so, run UMODLSC found in the SAMP library.
This usermod places the TCPaccess LSCNCOM and related aliases into the TCPacces LOAD library.
After running the USERMOD, place the LOAD in your application STEPLIB in front of the SASLINK.
This will allow you to operate as you did prior to installing the new maintenance .
If you want to look at options to use the new LSCNCOM going forward, you will need to look at each application and determine, with our assistence or help of the vendor, whether it may be possible to use either HPNS or OE sockets. This would require configuring the application JCL (and possibly parameters) differently and ensuring that it has an OMVS security along with possible application of maintenance. We have worked through this situation with many applications and can give detailed instructions if you know the specific applications that are affected.

Issuing PING command from TSO
At the SP3 level of TCPaccess 6.0, you may see the following when issuing the PING command from TSO:

LSCX048 Most recent C runtime  library modules not available 
        Use version 00197C70 ( 7.00C) or later to avoid problems. 

PING was relinked to use SAS/C 7.0 (the new SASLINK introduced in SP02) in fix TP10190. If your TSO proc or LINKLIST contains a version of the module LSCNCOM that is lower, you will receive this message. I does not impair the functionality of the command. To fix the problem, determine which library the LSCNCOM module is being taken from and ensure that our SASLINK is in front of that, either in your TSO proc or in the LINKLIST, depending on what is correct for your working environment.
Another workaround is to run PING as a batch job with the correct LINK and SASLINK in the STEPLIB.

FTPing and processing a GDG in the same JCL batch job
When running an FTP batch job that does FTP and processing of a GDG in the same job you may see

550 GDG base already in use
or
550: The process cannot access the file because it is being used by another process.
Unfortunately, this one is hard to ferret out in advance. This was introduced by TP10272 (TCPaccess 6.0), FT10274 (FTP server 6.0), or FT10273 (FTP Server 6.1). This is not a 'problem' as such, but a correction of improper GDG handling on the part of FTP. Before this fix, FTP would create a new GDG data set even if another task already had the base GDG enqueued. We have closed that loophole. Correcting this causes the same situation that has existed for regular sequential datasets since inception of the product. If you have any batch jobs that fit this description, they either need to be separated into two jobs or use an IDCAMS with ALTER ... NEWNAME to correct the problem. A complete description of what is needed can be found in the Users Guide, Chapter 2 under 'Transferring and Using a File in a Single JCL Job' on page 2-65.

Use of CUTYPE parameter in LCS statement of TCPCFG
If you are using an OSA-E device, PTFs TP10646 and TP10647 (and others) correct problems with timeouts. In order to act correctly, the LCS CUTYPE parameter is checked before issuing certain commands. If you are using an OSA device, this field must be TYPE(OSA) in order for the fix to work correctly. This is not noted in the fix, and the current doc states that the field is only used as a label, which is now incorrect for OSA devices.

FTP2 shows message CEE3611I

When  running FTP2 batchjobs at z/OS 1.7 or above, the file transfers correctly, but  the job shows these messages at the end 
CEE3627I  The following messages pertain to the programmer default run-time options.
CEE3611I The run-time option LIBRARY was an invalid run-time option or is  not supported in this release of Language
   Environment.
CEE3611I The run-time option RTLS was an invalid run-time option or is  not supported in this release of Language
   Environment.
CEE3611I The run-time option VERSION was an invalid run-time option or is  not supported in this release of Language
   Environment.

PTF TP10704 (SP5) was written to relink the Telnet and FTP modules that may display this message.
Please be aware that if you ran any of the FTP usermods (UMFTP*) in the past, you will need to remove and rerun them after applying this maintenance.
Samples for the usermods can be found in the TCPaccess SAMP library.

Please also be aware that we now also support OSA-E devices in QDIO mode. That requires SP5 plus additional PTF's.

For details, please review Knowledge Document:
TEC530748 - How do you configure TCPaccess support for OSA Express QDIO or IQDIO (Hipersockets)?

Environment

Release:
Component: NTCPAC