3/7/2005 Changes in CSC 4-1-24
- Contact 27578078 reports truncation of the USERID configuration parameter.
  This is corrected in this release.
- A CSC hang occurred during internal testing and another was reported by
  contact 27170061.  The root causes of these were never discovered but they
  were linked to failures in CDI and CSCUI respectively. The code in CSC 4-1-24 
  is rearranged to make it less susceptible to failures in external programs.
- During internal testing with CSC 5R1 and 4R1, a condition was observed where 
  CSC 4R1 could not mount or dismount tapes and produced no error indications.
  This occurs if CSC 5R1 using CARTTAPELIB$ is taken down and replaced with CSC
  4R1.  CSC 4-1-24 now produces a message during initialization for each drive
  that it cannot use because that drive is still under CARTTAPELIB$ control.

11/9/2004 Changes in CSC 4-1-23
- UCF 25357435 reports a problem when the fields of the SIGNON configuration 
  parameter are too long.  The improper truncation of long names is corrected 
  in this release.
- During internal testing a duplicate dismount message occurred and was traced 
  to incorrect handling of duplicate server responses.  This is corrected.
- During internal testing a path unavailable message often occurred immediately 
  before the path is activated.  Status handling is updated to eliminate this 
  false failure message.
- During internal testing it was found that setting the AUTOMOUNT parameter to 
  false disables BEFORE-MOUNT notifications. This is corrected.
- The sample JCL in NCS-PROCS is updated to prevent an SLS1203I error that can 
  occur after reconfiguration of the NCS server.

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.