7/1/2004 Changes in CSC 4-1-22 - UCF 23277373 reports TIFSYNCH repeatedly tries to scratch a mounted VSM volume and fails. Code is removed from CSC that was a workaround to a problem that existed in CSC 3R4. - The supporting material for UCF 23343975 showed that CSC does not complete initialization if CSC selects one path through an interface and the server returns its responses via another path through the same interface. CSC now ensures that when a path is selected for use, all paths through that interface are initialized and ready for use. - Internal logging code in CSC is enhanced to ease the analysis problems similar to those corrected in this release. 4/7/2004 Changes in CSC 4-1-21 - During internal tests, it was found that CSC would not initialize and use a TSAM interface if CMS or CPCOMM was started after CSC. The interface would also become unusable if CMS or CPCOMM was restarted while CSC is active. These problems are corrected. 3/11/2004 Changes in CSC 4-1-20 - UCF 98906510 reports a CSC hang that occurred after a communication problem that allowed session establishment but prevented data transmission. CSC now times the data transfer portion of communication sessions and aborts connections that time out. - A coding error in CDI is corrected that caused a real time hang. - Timing and internal buffer handling were adjusted to circumvent a CSC abort that occurred after an extended server outage. - The port used for CSC responses will be adjusted at CSC run time. This allows CSC to function even if another program is using port 7000. - The program CSCINFO/O is added to the CSC-2 file to display CSC product registration information that will be needed to obtain a CSC 5R1 license key. - A coding error is corrected that occasionally produced an incorrect "parameter too long" error while processing the CSC configuration data. 12/19/2003 Changes in CSC 4-1-19 - Contact 98308933 reports a CSC failed to switch paths when Library Station was taken down on one server platform and started on another. The path check logic in CSC is updated to try alternate paths even when the server appears to be reachable on the active path. - UCF 9848430 reports that CDI cannot communicate with the high availability server following a fail over. CDI is changed to recognize and processes the network message telling that a new mapping of an IP address to a MAC address has been established. - UCF 98850091 reports an assignment failure when the requested volume resides in an ACS with no drives that are up. CSC now will not direct assignments to an ACS with no drives that are up. OS 2200 will then select a unit in the run default ACS. The assignment will still fail, however, if there are no drives up in the run default ACS. - UCF 99014753 reports a CSC guard mode caused by the server returning an undefined state code in response to a *CSC QUERY ACS keyin. A defect in the CSC code that displays undefined server states is corrected. - UCF 9903839 reports multiple restarts of CSC following a reload of the UCS RTS common banks. A code defect in CSC is corrected that allowed each activity that received the common bank reload contingency to schedule another restart of CSC. 8/21/2003 Changes in CSC 4-1-18 - UCF 19723623 reports periodic CDI aborts on multiple systems. These occur when CDI cannot create a temporary routing entry to respond to a PING or redirect request. CDI is updated to shorten the life of temporary routing entries and to discard responses rather than aborting if a temporary routing entry cannot be created. - UCF 95915060 reports an additional line in the volume report output that did not exist in CSC 3R4. This line is an echo of the server command requesting the volume report. It is now eliminated from the volume report output. - Contact 57414735 reports a truncation error when the ACOBCSCUI interface is mapped above 65K. This was found to be in an unused code fragment from the original CSCUI development. This unused code is removed. - During testing, it was noted that only the first communication interface is brought up during CSC initialization. All others are left in the "Unavail" state until either an "up" request is made for an interface or an "activate" request is made for one of their paths. CSC now brings up all configured interfaces during initialization. - During testing it was noted that the server returned statuses that were not properly handled during CSC initialization if the server was also restarted at the same time. CSC now has code to handle these statuses. 3/20/2003 Changes in CSC 4-1-17 - UCF 94536143 reports an assignment failure when CSC is run with the QUERYSCRATCH parameter set to TRUE and when all drives in the default ACS are down. This update adds a check that each LSM recommended by CSC for a scratch mount contains at least one drive that is up. If all drives in all LSMs of an ACS are down, then CSC will not recommend using that ACS for the scratch mount. 2/25/2003 Changes in CSC 4-1-16 - Contact 10824621 reports a misleading console message if the CSC drive configuration contains drives that are not known to Exec. This update changes the reason given in that message from the uninformative "PROCESS_FAILURE" to "UNKNOWN DRIVE." - Contact 93685833 reports that CSC 4R1 cannot be successfully installed in a C2 security environment. The guaranteed entry point common bank problems that caused this are corrected in this update. - The *CSC CMD keyin for the NCS server is processed using a terminal session between CSC and the server. This session is not properly closed when CSC is terminated. This causes *CSC CMD to be unavailable until the NCS server times out the terminal session. This update changes the CSC termination timing to allow the *CSC CMD session to be properly closed. 12/12/2002 Changes in CSC 4-1-15 - Contact and UCF 93087274 report problems in configuring CSC to use an L180 library. The L180 library has tape units on panel 0. When CSC was originally designed, panel 0 could never contain tape units. This property was incorporated into CSC's internal tests for server availability. This update changes the server availability checks in CSC to eliminate this dependence. - An addendum to Contact 93152214 reports an error in the CSC generation to apply an object module update. The error occurs while producing a merged report of the changes in the current object module along with all previous object module update changes. The net result of the error is that the change report produced by the CSC generation only shows information from the first object module update. The output master tape from this CSC release is updated to correct this problem. Note that any CSC object module update generation based on an output master tape from CSC 4-1-8 through 4-1-14 will still encounter this problem. - During internal testing with a new library type, the server returned a different but equivalent status to the mount request for a volume on a drive that already contains that same volume but in an unloaded position. The CSC handling of the alternate status did not contain the appropriate sequence of actions to recover from this condition so the mount never completed. This update makes the recovery sequences equivalent for these two mount statuses. 11/20/2002 Changes in CSC 4-1-14 - UCF 92750991 reports that programmatic ejects through the CSC User Interface do not work after upgrading to CSC 4-1-13 and CSCUI 2-1-13. This is caused by the cleanup of unused fields in CSCUI 2-1-13. One of the unused fields that was disallowed has been incorrectly documented as valid since the inception of the programmatic eject in 1990. Because of the number of existing programs that may be affected, CSCUI 2-1-14 again allows this unused field to be passed to CSC. The error message displayed by CSCUI when there is a problem with passed fields was also updated. The message now tells if there are extra fields or missing fields and identifies those fields. - When CSC receives a dismount request from OS 2200, it inserts a delay before passing the request to the server. This is designed to allow the rewind and unload operation to complete so the server will not have to return a mount failure because the drive is still busy. For some of the newer drive types, the delay was found to be longer than needed. Those delays have been changed to a more appropriate value. 10/14/2002 Changes in CSC 4-1-13 - UCF 92182729 reports an abort when either a *CSC QUERY LSM ALL or a *CSC QUERY POOL ALL command is issued with ACSLS 6. The size has been corrected for a data area used during CSC initialization. This prevents the memory corruption that occurs when ACSLS 6 returns a longer response than ACSLS 5. - UCF 91398634 for CSC 3R5 reports an abort that occurs if a volume report parameter file contains only blank or empty lines. This abort also occurs in CSC 4R1. CSC code is changed to return an error status in this situation rather than attempting to continue processing the volume report. - While testing the fix for the above problem, it was noted that certain CSCUI exits allowed the transfer of unexpected data fields. CSCUI code is updated to pass only the expected data fields. CSC code is updated to eliminate requests to pass unexpected data fields. 06/18/2002 Changes in CSC 4-1-12 - UCF 90136402 reports problems with CSC builds where the source and destination are other than tape to tape. The CSC product build routine has been updated to correct these problems. - UCF 90052807 against CSC 3R5 reports a communication hang after CSC exhausted its supply of internal connection entries. Code has been added to time opens and closes and to manage CSC connection resources in the absence of TSAM completion notifications. 03/08/2002 Changes in CSC 4-1-11 - During engineering testing of CSC 4-1-10, it was discovered that TSAM interfaces could not be successfully UPed after CSC had completed initialization. A correction is included to initialize the variable that caused this condition. - While analyzing a CSC 3R5 problem, it was noted that during volume report transfer, CSC received continuously until all receive buffers were in use then throttled for a fixed length of time while the buffers were processed. A change is added to deal with receive buffer status before all buffers are exhausted. 02/27/2002 Changes in CSC 4-1-10 - A CSC hang resulted when a deadly embrace occurred between a task trying to resend a timed out request and another task that was beginning to receive part of the response for the same request. The code in CSC is rearranged to eliminate the interaction that caused this problem. - A communication problem caused the server to return a valid ICMP echo response via an alternate path. This caused CSC to believe that the intended path was usable when in reality it was only partially functional. CSC now verifies that path check responses arrive via the expected path. - UCF 76809751 reports a CSC abort during startup. This occurred when CSC was testing a communication path and received an ICMP error report instead of the expected ICMP echo response. CSC now does additional validation of the ICMP responses during path check. - UCF 78218407 reports problems when tapes were not successfully dismounted from DLT 7000 drives. The dismount timeout in CSC was too short for DLT 7000 drives. CSC now has dismount timeouts that are based on drive type. The timeout for the DLT 7000 is increased to a more reasonable value. - It was noted during testing that CSC displayed broadcast messages from the system on which Library Station was running as if they were output from a *CSC CMD keyin. To prevent this, CSC now displays only server responses received within 1 minute of issuing the *CSC CMD. 12/20/2001 Changes in CSC 4-1-9 - UCF 19395103 reports that CSC hung during initialization. This happened because CSC failed to switch paths when CMS returned a "path blocked" status for the first configured path. The handling of this status is updated to cause a path switch. - Corrections are included to prevent CSC hangs under the following conditions: - CSC is terminated with a large number of requests in progress and while the active path is experiencing specific error conditions. - CSC is terminated while the console command session to the NCS server has failed due to a communication error. - A *CSC ACTIVATE pathx command is issued while pathx is experiencing certain communication problems. - The output of the *CSC STATUS PATH keyin is updated to show the status of a path that is up via an interface that is down as "unusable" rather than "available." 12/06/2001 Changes in CSC 4-1-8 - UCF 77195656 reports that CSC does not logoff of the NCS console command session during CSC termination. This causes delays in establishing the session when CSC is restarted. CSC now does console command session logoff during normal CSC termination. - UCF 76809751 against CSC 3R5 reports a CSC abort condition that also existed in CSC 4R1. This occurs when CSC receives an error report from ICMP instead of the expected ICMP echo response. The ICMP response verification in CSC is updated to ignore all but the expected echo responses. - The customer reported that CSC experienced several MAX_PATHS failures during periods of communication problems. This status is generated within CSC to report a lack of resources condition. Two different code paths were identified in CSC that failed to release resources when unexpected communication errors occurred. CSC now releases these RPC program numbers and TCP connections when these code paths are taken. - To aid in future problem analysis, additional tracing and operational state saves have been added to CSC. - The drive initialization code is rearranged to process groups of drives through the phases of initialization rather than sequentially initializing each drive. This greatly decreases the time to initialize all drives.