Customer Software Release Notice for VS WANG SYSTEMS NETWORKING FILE TRANSFER MANAGER Version 9.08.00 Part Number: 195-4354-9 Model Number: VS-WSNS-FT-t-9 (t = K, P, T, V) July 31, 1998 Copyright Wang Laboratories, Inc., 1998 Disclaimer of Warranties and Limitation of Liabilities The staff of Wang Laboratories, Inc. has taken due care in preparing this document. However, nothing contained herein modifies or alters in any way the standard terms and conditions of the Wang purchase, lease, or license agreement by which the product was acquired, nor increases in any way Wang's liability to the customer. In no event shall Wang, or its subsidiaries be liable for incidental or consequential damages in connection with or arising from the use of the product or any related materials. Software Notice All Wang Program Products (software) are licensed to customers in accordance with the terms and conditions of the Wang Standard Software License. No title or ownership of Wang software is transferred, and any use of the software beyond the terms of the aforesaid license, without the written authorization of Wang, is prohibited. - i - TABLE OF CONTENTS Section Page 1.0 Release Abstract 2 2.0 Pre-Requisites 3 2.1 Hardware 3 2.2 Software 3 2.3 Installability 3 3.0 Restrictions and Special Considerations 4 4.0 Enhancements 15 5.0 Problems Corrected 15 6.0 Media Contents 19 7.0 Software Installation and Operation Information 20 - ii - 1.0 RELEASE ABSTRACT The Wang Systems Networking File Transfer Manager on the VS is responsible for controlling all supported file transfers between the VS and various systems. VS WSN File Transfer consists of five (5) main programs, three (3) subroutines, one (1) menu file, and one (1) installation procedure: The five main programs are: a. The TRANSFER utility which is a user interface. b. The File Transfer Manager, @FTMTSK@, which is a dedicated background task. c. The FTGMGMT utility which edits transfer groups (invoked via TRANSFER). d. The FTPRTLOG utility which prints the transfer log file (invoked via TRANSFER). e. The FTLOGDSP Utility which displays the Transfer Log File (invoked via TRANSFER). The three subroutines are: a. The FTACLGET program, which edits Access Control Lists in transfer groups (invoked via FTGMGMT). b. The FTACLINK and FTRACLNK subroutines, which accesses the Access Control Lists, called by the File Transfer Manager (@FTMTSK@). The menu file is: a. The FTLGMENU file which is the menu file for FTLOGDSP. The installation procedure is: a. The FTINSTAL procedure will transfer files from @SYSCOM@ library to the system library. Release 9.08 of FTM is Year 2000 compatible. Dates will continue to be displayed using a 2 digit year format (ie 00 for year 2000). PAGE 2 2.0 PREREQUISITES 2.1 Hardware a. Standard VS Configuration with at least 2048K of memory. b. An extended serial IOP (VS-85/90/100 with 22V27, VS5/6/15/25/45/65/300 with appropriate controller). c. A TCP (6554-n) with 1-4 TCB-1 (VS-TC) or TCB-3 (VS-TC-1) boards installed; or d. A 6550 Controller Board; or e. 25V76-1, or 25V76-2 internal communications controller board for the VS15/25/45/65. f. This release, with the new NAI 3.07.07, will not run on a CP3. 2.2 Software a. VS Operating System 7.53.00 or greater on the receiving side for SUBMIT/RUN option. If SUBMIT/RUN not used, VS Operating System 7.21.09 or greater. For Year 2000, VS Operating System 7.53.00 or higher is required. b. WSN NETCORE 9.20.00 or greater (Part Number 195-2927) c. At least one (1) VS WSN Transport System. 2.3 Installability a. WSN File Transfer Manager cannot be installed by the customer; a Wang support person must perform the installation. PAGE 3 3.0 RESTRICTIONS AND SPECIAL CONSIDERATIONS 1. All references in this document to "CNS" refer to Wang Systems Networking Advanced Functions (WSN/AF) as provided by WSN CNS 9.20.00 or greater. 2. In a non-CNS environment, VS systems running File Transfer version 9.07.17 or greater may experience corruption of some incoming data files. Customers are encouraged to run FTM in a CNS configured environment on their VS systems. Should they choose to continue running FTM in a non-CNS mode, they may want to evaluate the risk of running an unsupported release of File Transfer Service such as 9.07.16 versus the risk of corruption of some incoming data files. 3. If transfer disposition is PRINT, users will not be able to specify output file naming. The output file name namespace area in the VS system transfer queue is used to hold the transfer disposition option parameters (i.e. print/job, class, printer device #, etc.) not displayed to operator. 4. The "PRINT" transfer disposition is not allowed when transferring files from a VS to a PC. It is also not allowed when transferring documents to non-VS systems. 5. File Transfers between VS, VS/OIS, VS/PC, and VS/2200 systems are supported. Restrictions apply to transfers of data files between VS/PC and VS/OIS type systems. Document transfers of V2 type documents are supported between VS and Alliance systems. 6. When assigning file prefixes during Transfer Group creation, the user cannot specify the pound sign (#) character as the first character in the prefix. This character is reserved by the VS Operating System to denote work files which are deleted when the file is closed. 7. It is strongly recommended that System Administrators logically shutdown File Transfer Manager before running CNS shutdown procedures and IPLing the system. That is, file transfer service to all systems should be in the "inhibited" state. 8. As a security feature, @FTMTSK@ does not allow the retrieval of "pound sign " or "at sign" protected documents/files (# or @). Similarly, when a user is sending a file with REPLACE = YES, @FTMTSK@ on the receiving side does not allow the replacement of an existing document/file if it is "pound sign" or "at sign" protected. 9. @FTMTSK@ contains retry and disconnect timers. The retry timers cause @FTMTSK to attempt to start a session with a remote system more than once. The default values for retry are 5 attempts, approximately every 180 seconds. The disconnect timer causes @FTMTSK@ to close a session when there has been no transfer activity for 30 seconds. Transport timers start after @FTMTSK@ has shut down the transfer session. In order to modify the timer variables, please contact support. PAGE 4 3.0 RESTRICTIONS AND SPECIAL CONSIDERATIONS (CONT.) 10. File Transfer processes requests on a "work to do" basis. That is, it only attempts to establish a session with a remote system when it has a transfer request to process. File Transfer will attempt to establish a session 5 times. If it cannot reach the remote system, it will hold the file internally and wait for the remote system to call in. At this point, if the user hits PF key (7) from the Transmit/Retrieve Queue Screen to put the file back on hold, a message will be displayed indicating the "File is pending - must remove". User must either remove queue entry via PF key (12) or inhibit and re-allow service to the desired remote system via Manage Telecommunications from the operator's screen. 11. After IPL'ing the system with "released" entries on the queue, files sometimes do not start transferring to a specific system. This may be due to the fact that File Transfer has stopped trying to contact the remote system since it has exceeded its retry count. A message indicating that maximum retries have been attempted will be displayed on the Operator screen. The user may do one of the following to get transfers to the specific remote system started: a. Remove the first "released" entry for a specific remote system from the queue and then re-queue it using the TRANSFER program. OR - b. Inhibit and re-allow File Transfer service for the desired remote system. 12. While File Transfer is attempting to inhibit service, it is possible for the status in the Transmit/Retrieve queues and the system status to disagree. The system status may indicate that service is "inhibited" while the queue status indicates "xferring". This is due to the fact that System Task changes the system status to inhibited as soon as it receives the Inhibit Service Message. The Transmit/Retrieve queues are not updated until @FTMTSK@ indicates to System Task that it has completed or cleaned up. In a CNS environment it is possible for this clean up to take a long time, i.e. a couple of minutes, since it may be a multi-hop situation. This is due to the delays through the line and the other layers. 13. Transfers of files other than print files to and from PC systems are supported. Restrictions are as follows: a. Files originating on VS Systems: For WP documents created on the VS, the VS File Transfer Manager provides full support. PAGE 5 3.0 RESTRICTIONS AND SPECIAL CONSIDERATIONS (CONT.) For consecutive source files created on the VS, limited transfer support is provided when the file is sent from the VS to the PC and is then retrieved back to the VS. The support is limited in the sense that full source file functionality is lost when the file is sent to the PC. On the VS, a control block called the User File Block (UFB) is used by the Data Management System (DMS) for any I/O operations on the file. The UFB contains vital information concerning the internal structure of the source file. Since the PC does not support the use of the UFB, no UFB will be sent to the PC when sending a source file from the VS to the PC. Upon retrieval of the source file back to the VS, the information to restore the file to its original structure is not transmitted. For data files created on the VS which are going to be transferred to a PC, the file record size should be evenly divisible into 2048. If, for example, the file has a record size of 80 and is transferred to the PC, the file will contain garbage characters after byte 2000. This is due to the fact that the VS Disk Management System does not support block spanning of records and the VS File Transfer Manager performs block reads when reading the file for transfer. b. Files originating on PC Systems: For WP documents created on the PC, the VS File Transfer Manager provides full support when those documents are sent from the PC to the VS and are then retrieved back to the PC. For other files created on the PC, VS File Transfer has been enhanced so that transfers of files from the PC to the VS, then back to the PC can be supported. To provide such support, a new parameter (Record Size) has been added to the Transfer Group record. If a Transfer Group with this parameter set to '1' is specified when the file is transferred from the PC to the VS, the file will be stored in records 1 byte long. Therefore the file will contain the same number of bytes on the VS as on the PC. When this file is sent back to the PC, no additional bytes will be appended to it. This is the recommended method of storing PC files on the VS. VS File Transfer will not transfer indexed or program files to a PC. If a Transfer Group with the record size parameter not set to '1' is used, support for this type of transfer will be limited as in the past. The support is limited in the sense that the file created on the VS may have from 1 to 2047 bytes appended if the total byte count of the original PC file is not evenly divisible by 2048, due to the inherent differences in the disk structures of the VS and the PC. The PC stores files in a stream format, keeping count of the exact number of bytes in the file; the VS stores files as 256 byte records with 2KB blocks and keeps track of the logical size of the record and the number of records. The total number of records as stored on the VS will include any unused space in the last 2KB disk block. This unused space will be blank filled. PAGE 6 3.0 RESTRICTIONS AND SPECIAL CONSIDERATIONS (CONT.) The effects of this limited support is most evident when PC data files are sent to the VS for storage. In order to circumvent this limitation, it may be desirable for the PC user to programmatically add an End of Data or End of File marker. 14. Transfers to and from OIS systems support files other than WP documents and print files. The user may specify the file name in either a VS format or an OIS format. Files other than WP documents which are received from an OIS system will be assigned a WP organization and a record size of 256 bytes. In order to use these files on the VS, a user program may be required. Files which are received from an OIS and whose file size is not evenly divisible by 2048 will be increased to the next 2KB boundary and will be blank filled. See 12b above. 15. To reduce the amount of operator involvement required when allowing File Transfer Service, VS File Transfer automatically "attaches" to CNS under the following circumstances a. When File Transfer Service is allowed to any number of systems and CNS has not been started, @FTMTSK@ will attempt to attach to CNS. If @FTMTSK@ cannot attach, it will log the following message to the WSN log file. This message will only be logged once whether the operator is allowing service to one or all systems. "FTM Communications with Network Server failed" "Will try to re-attach to Network Server when its running" When @FTMTSK@ receives a message from CNS, FTM completes service activation, attaches to the Network Server, and starts processing any released entries on the Transmit/Retrieve queues. It is possible for @FTMTSK@ to attach to the network before receiving an "up" message from CNS. In this case, @FTMTSK@ will detach from the network and re-attach. The operator screen will show a status of "Inhibited" until @FTMTSK@ has attached to the network. b. If for any reason, communications between CNS and @FTMTSK@ fail, the following message will be logged to the WSN log file: "FTM Communication with Network Server failed" @FTMTSK@ will clean up any transfers in progress and put them on "Hold". @FTMTSK@ will then detach from the network and attempt to re-attach once. If it cannot re-attach, @FTMTSK@ will assume that CNS has crashed and the following message will be displayed: "FTM Communications with Network Server failed" "Will try to re-attach to Network Server when its running" PAGE 7 3.0 RESTRICTIONS AND SPECIAL CONSIDERATIONS (CONT.) @FTMTSK@ will then wait for an "up" message from CNS. During this time, the status on the operator screen for all active systems will indicate "no transfers in progress". 16. The VS File Transfer Manager has Session Retry Timers that work in a CNS environment as well as a non-CNS environment. In a CNS environment, a request will be retried if an open request was sent and an open reject was received. At the time the rejection is received, a message indicating the reason will be logged in the WSN log file. When the maximum retry count has been reached, an additional message will be logged as follows: "System VS2 is not reachable" (Example of reason why) "File Transfer Session cannot be Established" "Maximum session retries with VS2 reached" 17. WP Document and VS Source File Transfer Requests (VS/PC) An interactive workstation user can queue send and retrieve requests for the transfer of WP documents and VS source files between a VS and PC. For both Send and Retrieve requests, the user will not be allowed to specify a transfer disposition. A default transfer disposition of store will be supplied by the Transfer Utility. When specifying the name of a document or file that resides on a PC, users will be required to follow the following syntax rules: C:FILENAME.EXT True PC naming syntax is not supported by the Transfer Utility, i.e. users may not use slashes (/) in the file name specification. When sending a file to the PC, all output filenames must use the above format. The drive designator (C:) must be a single character, the FILENAME may be up to 8 alphanumeric characters, and the Extension (EXT) must be 1 to 3 alphanumeric characters. A specific subdirectory on a PC cannot be specified. 18 When using a procedure language to submit a password protected document for transfer, lower case libraries and lower case passwords must be enclosed in quotes. For example; DOCUMENT = "0007f" or PASSWORD = "name". 19. After the retry count is exhausted, transfer requests stays pending. That way, if the remote system establishes a session, local requests will be serviced. After the retry count has been exhausted, the user must either inhibit and re-allow service to that remote system or remove the entry. PAGE 8 3.0 RESTRICTIONS AND SPECIAL CONSIDERATIONS (CONT.) 20. When the disk is full a transfer attempt may fail with several possible messages in the log file. In order to understand why this can occur it is necessary to explain what @FTMTSK@ does when it attempts to create an output file. When @FTMTSK@ receives a file, it will first try to open an output file equal in size to the input file. This is done to avoid fragmenting a file when there is sufficient space on the output volume. If there is no space equal to the size of the input file, @FTMTSK@ will calculate a smaller initial extent based on the size of the input file. This is done on the theory that there will be enough other extents whose total size is large enough to hold the rest of the file contents. If this second attempt fails, the log file will say "DISK IS FULL - TRANSFER REQUEST CANNOT BE PROCESSED". Other reasons for unsuccessful attempts to open a file will show in the log as "I/O ERROR OCCURRED WHILE CREATING OUTPUT FILE - TRANSFER UNSUCCESSFULLY COMPLETED". 21. When the system has been IPL'd and the user has not inhibited communications, transmit and retrieve requests that were actively being transmitted at the time of the IPL are held on the queues with a status of 'HOLD' 22. When IPLing the system, be sure that a file named "NFTGLIST" in library @SYSTEM@ on the system volume does not exist. The existence of this file causes File Transfer Manager to crash. 23. When WSNSTOP has not been run and the system has been IPL'd, it is strongly recommended that WSNREORG be run to prevent any problems if the directory was left open. 24. A feature in the TRANSFER Utility allows sending a non-print file and have it printed at the remote site. A user can retrieve print files and print them locally. However, a user cannot retrieve a non-print file and specify a disposition of print. Note that such a request can be queued because the initiating system does not know if the specified file is a print file at the time it is queued. 25. When @FTMTSK@ runs in a CNS environment, the session may be rejected by the remote FTM. WSNMON indicates that the reason for the rejection is "Application Generated". When this occurs the following messages will be logged in the WSN log file: "Session establishment rejected by FTM at XXXXXXXX." "File Transfer Session Establishment Has Failed". PAGE 9 3.0 RESTRICTIONS AND SPECIAL CONSIDERATIONS (CONT.) Possible reasons for the session being rejected are: a. System passwords as defined in WSNEDIT do not agree b. System names incorrectly configured in WSNEDIT c. Maximum of 32 sessions to 32 systems already established d. Two systems attempt to establish a session to each other simultaneously but only one open request can be accepted. The other open request is rejected with the above messages. Note that the files queued by the system whose request is rejected will be transferred once the session is established. e. File transfer service is inhibited at the named system f. Session/service termination in progress 26. It is possible to configure and allow File Transfer Service to a maximum of 512 systems, depending on the version of the VS Operating System which is running. OS 7.21.09 or greater a. File Transfer Service may be allowed for a total of 2000 systems; these systems may be all CNS, all Non-CNS, or a combination of CNS and non-CNS systems. 27. It is possible to send DMS/TX files to remote systems via @FTMTSK@. Recovery blocks associated with a file are not actually sent but are re-created on the remote system when the output file is created. @FTMTSK@ will attempt to attach the file to a database of the same name as that to which it was attached on the originating system. If the attach fails, the file will still have been transferred and stored properly. When sending a DMS/TX file from a 9.04.08 version to a 9.06.11 or greater version, recovery blocks will be lost. When sending a DMS/TX file from a 9.06.11 or greater version of @FTMTSK@ to a 9.04.08 or greater version, recovery blocks will be allocated, although the file will not be attached to the database. 28. The number of concurrent sessions which are allowed is under the internal control of @FTMTSK@ and may vary depending on the run time environment. The current maximum on sessions is set to 32. For all session requests received by @FTMTSK@ after number 32, a round robin queueing scheme will be activated and sessions for those systems waiting on the queue will be started as in-process sessions terminate. 29. Logging has been enhanced to write Wang Office entries to both the regular log file plus a separate Wang Office file called @WOALOG@. PAGE 10 3.0 RESTRICTIONS AND SPECIAL CONSIDERATIONS (CONT.) 30. The log file is in ISAM format and the name of the file is @NOTIFY@. It is found in @SYSTEM@ on the IPL volume. When a user prints the log file and specifies PURGE = YES, the @NOTIFY@ file is renamed to @NOTIFY# (@SYSTEM@, IPLVOL). @NOTIFY# is deleted after the print file has been created. Please note that @NOTIFY# is a reserved filename. 31. If a user runs WSNSTOP, BACKUP and then WSNSTART without inhibiting File Transfer Service for CNS systems, there may be a conflict with the WSN Directory as follows: Prior to running WSNSTOP, the user did not inhibit file transfer service via the operator console. When @FTMTSK@ determined that CNS had been taken down, the task attempted to re-attach to CNS Service. During this re-attempt, @FTMTSK@ tried to read the directory and could not since BACKUP had the volume opened exclusively. When there is a conflict reading the directory, @FTMTSK@ will display an error message on the operator's console. After BACKUP is completed, and WSNSTART is run, it will be necessary to inhibit and re-allow File Transfer Service. In order to prevent this situation, it is recommended that, if operational procedures do not allow service to be inhibited, the procedure should wait 10 minutes between running WSNSTOP and starting BACKUP. 32. When specifying an OIS volume names, the Operating System restricts these names to be a maximum of six (6) characters. Longer names will be rejected. PAGE 11 3.0 RESTRICTIONS AND SPECIAL CONSIDERATIONS (CONT.) 33. The WANGOFFICE Transfer Group is not displayed when viewing the list of Transfer Groups while performing a retrieve operation. This Transfer Group is reserved for use by VS WANG OFFICE only. 34. Transfer Group record size should not be arbitrarily set to 1 for VS to VS communication. There are certain PC and/or ASYNC situations that necessitate specific transfer groups to be set to 1, but otherwise setting the record size to 1 could cause serious File Transfer problems. 35. No direct changes were made to VS File Transfer Services in order to support the transfer of DMS-Plus files. The only requirement at this time is that both the sending and receiving systems be running VS Operating System 7.21.09 or greater. Transferring DMS-Plus file to systems running earlier versions of the operating system can result in files that can be transferred but are not usable. DMS-Plus information contained in the UFB (User File Block) will be lost at the receiving system. This might also occur when sending large files to an older version of VS File Transfer (i.e. FTM 9.06.11 or earlier). 36. TRANSFER (P10F400447): The documentation on pages 2-9 of the Network Users Guide indicates that during OIS to VS transfers, a print file may be sent directly to the VS as it is in VS to OIS transfers. This is not the case as a print file will appear to transfer but actually is not. 37. TRANSFER: When printing documents on a remote system, File Transfer only allows page numbers, in the Start as Page Number field, to be in the range of 1-255. 38. @FTMTSK@ (P100002452): Under certain conditions, FTM on the local system ignores the maximum session retry count when communications between two systems are broken while transfers are in progress. As a result, the system message buffer is full of messages from FTM. This problem may occur in any of the following situations: * The session lost problem (P100000799) has occurred. The open session request is repeatedly rejected by the remote system. * FTM on the remote system is not attached to the Network Server due to task crash or hang. * The remote system is not reachable either due to a DLP problem or due to the remote system being brought down improperly (e.g., system crash). Inhibiting and reallowing communications with the remote system will put the transfer request on HOLD, so FTM will stop retrying. PAGE 12 3.0 RESTRICTIONS AND SPECIAL CONSIDERATIONS (CONT.) 39. @FTMTSK@ (P100002816): Files retrieved from an OIS are received in the incorrect organization. The user expects to receive files from the OIS organized as 'WP' files, however, the files are organized as 'Consecutive' files. 40. @FTMTSK@ (P100003895): When transferring from System A to a non-adjacent system in a non-CNS environment, an incorrect message is displayed on the Operator's screen at System A: "System B is unable to establish file transfer." "Maximum number of sessions per system has been reached." 41. @FTMTSK@ (P10F011946): FTM attempts to activate sessions based on the sequence of transfers queued (which is alphabetical - not chronological). If multiple pending transfers all require a single DLP, later pending transfers and their DLP's may not become active, as FTM can only manage 32 simultaneous sessions. 42. @FTMTSK@ (P10F224913): Intermittently, a File Transfer session may remain open after link came down (VS to VS session via 2 IBM Host nodes). 43. @FTMTSK@ (P10F008315): In some instances, a message in FTLOG stating that the transfer was aborted by either a local or remote operator, may be misleading. This message is generated under the following circumstances: a. Local or Remote operator inhibits File Transfer Service while session is open or transfer is in progress. b. In a Non-CNS environment: Disconnect is received from Local or Remote DLP while session is open or transfer is in progress. c. In a CNS Environment: Session is abnormally terminated while transfer is in progress or FTM application detached from CNS. 44. @FTMTSK@: Probe #P10F223247 Remotely log on from IDS to VS. Pressing PF15 to print causes entry on FTM Transmit queue with IDS as the destination. FTM to an IBM Host node is not supported. 45. @FTMTSK@: Probe #P10F228714 When 256 CNS sessions have been established on a system and Transfer is run from the system, the message "Insufficient resources at local system" is displayed followed by a system name. The system name that appears is that of the remote system. The system name displayed should be the local system. PAGE 13 3.0 RESTRICTIONS AND SPECIAL CONSIDERATIONS (CONT.) 46. @FTMTSK@: Probe #P10F228715 When 256 CNS sessions have been established on a system and TRANSFER is run, the message that appears in FTLOG is 'Transfer operation is aborted by a local operator". Message should state insufficient resources on local system". 47. @FTMTSK@: If CNS loses an Open Accept, it is possible for a destination @FTMTSK@ to think it has a session while the initiating @FTMTSK@ does not. When the initiating @FTMTSK@ retries to establish the session, it will receive a reject and WSNMON will indicate that it is application generated. CNS should eventually time out and close the session at the destination system. If the initiating @FTMTSK@ has exhausted its retries, the user will be required to inhibit and re-allow service. This problem is not a File Transfer problem, but is a CNS problem. 48. @FTMTSK@: Probe #P10F500860 Transfer will not allow you to transfer to a tape on another system. Transfer message tells you that the tape is not mounted. Customer would like to transfer to tape much the same way that you could with VSCOPY. Error message in Transfer log is incorrect - tape is mounted for SHARED use. The error message should indicate that this type of transfer is not supported. 49. @FTMTSK@: Probe #P10F501770 Any document that is sent with print=yes and scratch=yes will have residual data in the destination file name field of the FTM log if it is removed before it actually transfers. 50. @FTMTSK@/TRANSFER: Probe G410009336 In order to transfer a procedure with the run option the user must do so by issuing a Submit SVC within their own application (See VS Operating Systems Services Reference manual). There is NO PROVISION provided within the Transfer Utility to transfer a procedure with the run option. When submitting a procedure to run, the file name assigned on the remote system is derived from the DEFAULTXFGROUP group. The area in the submit record that held the remote file name is now used for the RUN parameters. 51. @FTMTSK@: PTR G200021598 Beginning with release 9.07.25 when two systems attempt to establish a file transfer session with each other simultaneously, both will be rejected. This is do to the state of FTM at the time indicating that an attempt is being made to open a session, and until that session is either closed or rejected, inbound sessions cannot take place. Following receipt of the reject, retry processing will take place. The possibility exists that both systems will retry at the same time and consistently be rejected until all retries are exhausted. In order to avoid the opens "crossing in the night" the system with the lowest system name (according to ASCII collating sequence) will only attempt three additional times, while the other system will attempt 5 additional times. This will allow for one system to attempt the connection two additional times and not experience the "crossing in the night situation". PAGE 14 4.0 ENHANCEMENTS 4.1 ENHANCEMENTS in FTM 9.08 FTM has been updated to be Year 2000 compatible. Dates will continue to be displayed using a 2 digit year format (ie 00 for year 2000). 5.0 PROBLEMS CORRECTED 5.1 PROBLEMS CORRECTED SINCE 09.07.00 TRANSFER 1. G410009336 Added "Proc Id" (Procedure ID) for SUBMIT/RUN option to the default group record. If the system administrator chooses to allow this option, they may enter a Proc Id of the appropriate security level for jobs remotely submitted through File Transfer. 2. P410009804/P200015988 When printing a WP document on a remote system, if the forms in the document was set to FORM 2, TRANSFER defaults to CONTINUOUS. @FTMTSK@ 1. M800023787, G200020173 An invalid data event was being received by File Transfer Manager when no additional data was present. This caused File Transfer Manager to write to the disk until the maximum allowable disk extents was reached. 2. G200021598 When two systems attempted to establish a File Transfer Session with each other simultaneously the sessions would be rejected, but the retry logic was not being executed. 3. A modification was made to the logic to tear down a session when a request was received to inhibit file transfer capability to a system. 4. M410011381 Files received from a PC that had fewer than 1024 bytes had a 128 byte header attached to them when they were stored on the VS. The header has been removed. PAGE 15 5.1 PROBLEMS CORRECTED SINCE 09.07.00 (CONT.) 5. M410011223 All code that deals with session counts, session pending counts and the hold/allow new sessions flag was consolidated into one location. The determination for how to set the hold/allow flag is now based only on the number of active sessions, not on the sum of the active and pending. 6. Internal Release Only A retry counter was added for a NAI blocked condition. If ten successive blocked conditions occur on any one session, an operator message is displayed indicating a return code of 8 was received on a NETSEND. 7. M410011060 When File Transfer was attempting a NETATTACH to CNS and a timeout occurred an attempt was made to display an operator message to that affect. Because of an error in the message table File Transfer would crash. @FTMTSK@ 8. M410010646 The maximum session count of 32 was not being adhered to by File Transfer Manager. Corrections were made so that when CNS is used as a link by File Transfer Manager the maximum session count is adhered to. 9. G410009336 When a remote SUBMIT/RUN request is received, @FTMTSK@ will now read the the new "Proc Id" (Procedure ID) field in the default group record (see TRANSFER above). If the Proc Id is not blank, the Proc Id is used when submitting the procedure. If the Proc Id is blank, the request is rejected. 10. M410010600 @FTMTSK@ would crash with a stack overflow while attempting to write to the log file (@NOTIFY@) which had already reached a boundry exception. When the log file hits 13 extents, @FTMTSK@ displays a warning message on the operators console. When the log file hits a boundry exception, @FTMTSK@ attempts to COPY the log file to a temprary file name (@@@@xxxx@ in library @SYSTEM@ on IPL volume) which is then renamed to the log file with 1 extent. 11. P500014002 Non-CNS only: multi-point and point-to-point transfer links configured to _______ use device numbers greater than 255 would not uninhibit after inhibiting during a file transfer on that link. 12. P500010254 Non-CNS only: specific data file length(s) transfered between a 9.06.xx _______ version of File Transfer to a 9.07xx version would be prefixed with 128 bytes of blanks. PAGE 16 5.1 PROBLEMS CORRECTED SINCE 9.07.00 (CONT.) @FTMTSK@ 13. P500017043/P500010278 Intermittently, if a print file being sent that is manually deleted prior to transfer, the log file (@NOTIFY@) will have incorrect information in the destination file fields. These fields are normally blank until assigned by the remote system upon successful file transfer session establishment. This problem was caused by SYSTSK not clearing the fields in the transfer request to @FTMTSK@ and has been corrected in Operating 7.40xx and above. 14. P410008247 In some cases, @FTMTSK@'s internal session count will be negative after completing retry attempts specified on sessions that have failed and little FTM activity is in progress. Code has been added to prevent the 'ALL CIRCUITS BUSY' message from appearing or interrupting further transfers at this time of little activity. (Note: the message 'ALL CIRCUITS BUSY' will still be display when the FTM 32 session limit is being exceeded). 15. P410006079 Intermittently, @FTMTSK@'s would reject sessions on a specific link with an "Application Generated" error message caused by an NAI OPEN error return code. Additional error messages for the return codes have been added to @FTMTSK@ and the new NAI 3.07.06 has been linked to this release. 16. P410009674 If an indexed file is sent to a volume with enough space for the file although not enough in the first extent, the transfer would be completed and logged as successful but @FTMTSK@ would incorrectly write zero records in the file's label (thus the file would need to be reorg'd). 17. C410004267 @FTMTSK@ in some cases would not always correctly calculate the internal session count when retry attempts on sessions that were rejected. Also WPOPEN (2.01.07) was linked in on this version (see 09.07.01). 18. P200014821 @FTMTSK@ in some cases would not always complete the correct number of retry attempts on all sessions that were unreachable or session rejected. PAGE 17 5.1 PROBLEMS CORRECTED SINCE 9.07.00 (CONT.) @FTMTSK@ 19. P200014885 @FTMTSK@ on a 6.43xx operating system would crash when attempting to transfer to unreachable PC (powered off, communication not set, etc.). 20. P200014733 After a data line failure, in some cases CNS does not terminate the remote FTM session. The sending FTM closes the existing session and tries a new session when the data line is working but gets rejected by the remote side as application rejected. @FTMTSK@ has been modified to accept subsequent session requests from a given site and abort the previous/existing session with that site. 21. P200013943 @FTMTSK@ has been modified to abort the file if the received data length is greater 1024 byte or 1920 bytes depending on the version. Error message (28 - Transfer Aborted) is recorded in the transfer log (@NOTIFY@). This version should be used in place of FTM 9.07.03. 22. P200009320 The sending DLP is corrupting the PPU header causing @FTMTSK@ to loop while creating the work file (13 extents) and monopolize the system. @FTMTSK@ has been modified to abort the file if the received data length is greater 1024 byte with a message (180 - Communication Error) recorded in the transfer log (@NOTIFY@). *** HARDWARE MALFUNCTION *** This problem is caused by a DLP Failure. The sending DLP in error should be identified and replaced. During the interim, VS File Transfer, Version 9.07.04 can alleviate some of the effects of the problem. 23. P200011097 @FTMTSK@ would crash when an invalid command IOSW (208080) was received (ERROR 9970 COMMUNICATION ERROR REPORTED IN THE IOSW) from the DLP, which had been previously deactivated before @FTMTSK@ had been notified. 24. P200010980 WP documents being transferred with a disposition of PRINT would not print if the target document volume name was less than exactly six (6) characters. This is a known anomaly in WP Document Access Subroutines, WPOPEN subroutine (version 2.01.05), to which @FTMTSK@ 9.07.00 is linked. @FTMTSK@ 9.07.01 is linked to the corrected version 2.01.07 of WPOPEN. PAGE 18 6.0 MEDIA CONTENTS Library = @SYSCOM@ ** = Changed since last release Module Release Protection Blocks Name Number Class Description Allocated @FTMTSK@ 09.08.00 ** @ VS File Transfer Manager 249 Dedicated System Task FTPRTLOG 09.07.25 @ File Transfer log; creates 93 printable log; run from TRANSFER FTGMGMT 09.07.25 @ File Transfer Transport 17 Group Maintenance Utility run from TRANSFER TRANSFER 09.07.25 @ File Transfer Utility 46 FTACLGET 09.06.67 @ Access Control List Module 1 FTACLINK @ Access Control List Module 34 FTRACLNK @ Access Control List Module 34 FTLOGDSP 00.00.07 ** @ Transfer Log Display 197 FTLGMENU ** Menu File for LOGDISP 10 FTINSTAL 01.00.00 Installation procedure 3 @FTMTSK@ The procedure to find the release number is to run FTGMGMT DISPLAY and search for 'VERSION' TRANSFER FTPRTLOG Library = CSRNLIB SOFTWARE RELEASE NOTICE FILE Module Release Protection Blocks Name Number Class Description Allocated WSNFTM98 09.08.00 $ On-line Customer Release 25 Notice. To find the version number of WSNFTM98 run display and look at the first screen. PAGE 19 7.0 Software Installation and Operation Information 1. A full backup of the user's networking software volume prior to installation of any networking software packages is always highly recommended. 2. WSN NETCORE 9.20.00 or greater software must be placed into the Networking Software library @SYSCOM@ on the volume desired prior to Installing VS File Transfer software. INSTALLING VS File Transfer SOFTWARE 1. IPL without specifying a Communications Configuration File (COMMFILE = "blanks"). 2. Logon as a Security Administrator. 3. Perform a Library BACKUP/RESTORE of the Library = @SYSCOM@ on the Installation Diskette to the User's networking software volume, making sure to specify CLEAR = NO on the OUTPUT screen, and DUPFILES = SCRATCH on the BACKUP screen. 4. Run FTINSTAL from networking software library @SYSCOM@; this will perform VS File Transfer installation. TRANSFER, FTGMGMT, FTPRTLOG, FTLOGDSP, FTACLGET, FTACLINK, FTRACLNK, and FTLGMENU will be installed in library @SYSTEM@ on the IPL volume. 5. Run SECURITY and assign Security Administrator Privileges to the TRANSFER, FTGMGMT, and FTLOGDSP programs which reside in @SYSTEM@ on the IPL volume. Also assign Inter-Security Access Privileges for configured Remote Systems for which File Transfer Service is configured. 6. IPL with the appropriate Communications Configuration File. 7. Run TRANSFER and create at least one default transfer group using the name specified when defining File Transfer Service for the Local System. If using the SUBMIT/RUN option, check or enter the "Job Id" (see Problems Corrected; TRANSFER item #2). For more information refer to: VS Network Configuration and Operations Guide VS Network User's Guide to File Transfer and Remote System Access - (800-1316-D). WSN VS Network Core Software Bulletin Release 8.31 - (715-0542.01). PAGE 20