level upgrade notification - hulft

HULFT for Linux Ver.6.3.2B

HUL6-LINUX-HULE-002-E-01 Saison Information Systems CO.,LTD. 1/23

Level Upgrade Notification

[Product List] Product Name Version

HULFT for Linux Type L-E 6.3.2B

[Target OS] Red Hat Linux, SUSE Linux

[Added Functions] ○ HULFT

M/ment No. Contents Chapter to be consulted.

1 Setting of Send Process Multiplex Level by Host 1.2 (22)

2 Function to View Directory via HULFT Manager 1.2 (23)

14 Restoration of Communication File Between Send Processes (fifo File) 1.3.2 (4)

15 Displaying Transfer Size in the Transfer Status List on the Management screen -

[Function Improvements] ○ HULFT

M/ment No. Contents Target Ver.

Chapter to be consulted

3 Increase of Send and Receive File Name Length From 5.0.7 to 6.0.6 2.2 (17)

4 Extending Conversion Rules of Em-size Space of KEIS Kanji code

From 5.0.7 to 6.0.6 2.2 (18)

5 Improvement in Resend Queue From 5.0.7 to 6.0.6 2.2 (19)

6 Displaying Send Acknowledge Date From 5.0.7 to 6.0.6 2.2 (20)

7 Enhancement in Setting of Socket Buffer Size From 5.0.7 to 6.0.6 2.2 (21)

8 Measures for Communication Timeout (On executing Send Request and Remote Job)

From 5.0.7 to 6.0.6 2.2 (22)

9 Improvement in Job Monitoring Function From 5.0.7 to 6.0.6 2.2 (23)

10 Improvement in Cancellation on HULFT Management Screen or via HULFT Manager

From 5.0.7 to 6.0.6 2.2 (24)

11 Enhancement in Management Screen Security From 5.0.7 to 6.0.6 2.2 (25)

12 Improvement of Communication Method between Send Processes

From 5.0.7 to 6.0.6 2.3.2 (1)

13 Improvement of Send Process Structure From 5.0.7 to 6.0.6 2.3.2 (2)



22 Improvement in Locking Method of Receive File From 5.0.7 to 6.0.6 2.3.2 (3)

23 Improvement in timing of changing owner, group, or permission of Receive file

From 5.0.7 to 6.0.6 -

29 Enhancing throughput of processing in Receive system and Request Acknowledge system

From 5.0.7 to 6.0.6 -

32 Omission of version information of Option in Product Confirmation command (hulverinfo) 6.0.6 -

[Bug List] ○ HULFT

• Common M/ment No. Contents Target Ver.

201 Forcible Termination of Send and Receive Processing in Progress due to external factor may not Terminate the Processing on the Partner Side 6.0.6

243 Outputting to identical Trace Log file by multiple processing sessions may corrupt format or fail to switch Trace Log file 6.0.6

244

HULFT fails to detect failure in outputting Trace Log immediately before the execution of subsequent job. Thus, the application executes the jobs that follow after as they are, which may cause inconsistency in the result of receiving result.

6.0.6

251

In Receive Daemon or Request Acknowledge Daemon, delay of 30 seconds for the next packet after the establishment of request connection causes timeout. This makes all other connections that follow after wait during that time and causes further delay in those processing as well

6.0.6

256 Specifying Trace Log Output while operating HULFT by user account type other than superuser (root) may cause failure in activating daemon 6.0.6

• Sending Function

M/ment No. Contents Target Ver.189 HULFT may carry out Send File without executing Pre-send Job 6.0.6

197 A value in Record Count after the transfer completion of Send data on the Send Status List may be lower than actual counts 6.0.6

210

After the transfer of Send data is completed, occurrence of an error while the application is waiting for the completion of receiving by partner host causes termination with an error code ‘302-000 (file read error)’, which indicates an error in socket

6.0.6

213 When forcible termination of Send daemon or Send process due to external factor occurs, the application may not execute Send processing after restart of Send Daemon

6.0.6

229 Despite successful termination of Sending, the value of environment variable $STATUS may become ‘308 (disk access error)’ 6.0.6

230 HULFT may complete transfer successfully even when Send file is deleted or modified during sending (Incompatible) 6.0.6

257 When HULFT is carrying out multiple sending, the application may fail to update Send Status file ($HULPATH/sddsendlist.dat) and it is terminated abnormally with an error code ‘303 (file write error)-0.’

6.0.6



• Receiving Function


111 During CSV Interface, Executing Transfer of an identical Receive file in a row may corrupt the CSV file

From 5.0.7 to 6.0.6

182 When Communication Timeout occurred during Receive processing, the completion of processing may require twice as long as the specified time in Socket Read Timeout

6.0.6

193 Even if the specification of Error Recovery in Receive Management information is set to ‘Restore,’ the application may fail to restore Receive file when an error occurs

6.0.6

195 On binary transfer, the application may be terminated abnormally with an error code ‘301-352 (gaiji code set error.)’ in some cases

From 5.0.7 to 6.0.6

204 An error of Receive Process Multiplex Level Over may occur despite margin 6.0.6

214

Forcible termination of Receive process due to external factor during Format or Multi Format transfer may cause abnormal termination of the transfer sessions that follow after with an error code ‘303-312 (format file disk full.)’ in some cases

From 5.0.7 to 6.0.6

216

When you execute transfer to an identical Receive file while setting Error Recovery to ‘Restore’ an occurrence of an abnormal termination in the transfer carried out immediately before may corrupt Receive data in the transfer of the next session

From 5.0.7 to 6.0.6

219

Applying Generation Management while Registration Mode of Receive file is set to New Creation, the application may terminate abnormally with an error code ‘205-000 (file already exist),’ even though there is no existing Receive file in fact

6.0.6

221

On the occurrence of communication timeout due to network error, incidental agreement of the transferred data to Stop protocol of HULFT may cause termination of Receive daemon or Receive process due to malfunction

6.0.6

235 Despite the setting of ‘Restore’ in Error Recovery, HULFT does not restore the attribute of a Receive file

From 5.0.7 to 6.0.6

• Request Acknowledge Function


273 HULFT may carry out Send File without executing Pre-send Job From 5.0.7 to 6.0.6

• Utility


206 On executing line feed code deletion processing of File Record Edit command (utllf), absence of line feed code may cause termination with an error (Incompatibility with Ver.5)

6.0.6

• Management screen


220 Despite the presence of Format ID in Format Information List, viewing, updating or deleting the information may not be available in some cases 6.0.6



○ HULFT ManagerConnection Option


208 Occurrence of disconnection while connecting with HULFT Manager remains processes not terminated

From 5.0.7 to 6.0.6

217 When you issue Send File that accompanies Pre-send Job via HULFT Manager, Communication error or inability to return control may occur on the side of HULFT Manager

From 5.0.7 to 6.0.6

“Chapter to be consulted”

For details, refer to “HULFT Ver.6 New Functions and Incompatibility Manual second edition.”

“Target Version” If the “Target Version” includes Ver.5, the improvement or measure for the bugs may have been provided as a revision upgrade of HULFT Ver.5. Otherwise, a measure will be taken in the future.

For the detail of improvements and faults, refer to the following Improvement Report and Bug Report.



[Added Function]

○ HULFT

15 Displaying Transfer Size in the Transfer Status List on the Management screen

HULFT now displays transfer size of sending and receiving in byte on the Transfer Status List of the Management screen. This enables end users to view the progress in transfer minutely.

[Function Improvements]

○ HULFT

23 Improvement in timing of changing owner, group, or permission of Receive file

HULFT creates a Receive file with owner, group, or permission specified in Receive Management Information. HULFT used to carry out such change in the attribute of a Receive file after the completion of Receive data transfer. This used to cause following problems: 1) Deletion of the Receive file during receiving causes abnormal termination with an error code

‘325(unable to change mode)-zero,’ which is actually different from the phenomenon in question.

2) Forcible termination of Receive process due to external factor such as an error in OS or issuance of kill command, the attribute of the remaining Receive file is created by startup user of Receive daemon.

3) Execution of transfer to an identical file in succession while system is choked up may cause an abnormal termination with an error code ‘325 (unable to change mode)-zero.’

Now HULFT has improved to modify the timing of changing attribute of a Receive file to ‘after opening the file.’ This improvement solves all the above-mentioned problems. * Regarding 1), the application now terminates the operation with an error code ‘225 (receive file not exist)-0.’

29 Enhancing throughput of processing in Receive system and Request Acknowledge system

In Receive system and Request Acknowledge system, HULFT has now improved to be able to handle multiple connections that are accepted simultaneously. This increases the number of connections that the application can handle; the number of transfers or the number of processing of Request Acknowledge per unit time has improved about three to five times* more than those of old revision. *The figure is calculated by measuring the number of Receive processing handled in a second and comparing the average with old version. The result is subject to change according to the environment.



32 Omission of version information of Option in Product Confirmation command (hulverinfo)

HULFT has now improved to omit the version information displayed by Product Confirmation command (hulverinfo) regarding following product, because the version of the option is identical to the version of HULFT main body.

• HULFT ManagerConnection Option for Linux

[Bug Report]

○ HULFT

• Common

201 Forcible termination of Send and Receive processing in progress due to external factor may not terminate the processing on the partner side

[1] Phenomenon On forcible termination of Send process during transfer, the error is not notified to the receiving partner and the host on the receiving side does not end its operation still waits for the termination of the process instead.

[2] Target Version Ver. 6.0.6

[3] Occurrence condition This phenomenon occurs when the Receive process is in the following state, and the process is forcibly terminated due to external factors such as error in OS or issuance of kill command. This phenomenon occurs in sending where: • The application is in the middle of jumping to the checkpoint during Checkpoint Resend

File or Checkpoint Resend Request This phenomenon occurs in receiving where: • The application is waiting for the unlocking of a Receive file • Checkpoint Resend File or Checkpoint Resend Request • The application is executing successful Job according to the specification of Receive

Completion Notification as Successful Job Completion • The application is executing CSV Interface

*Checkpoint Resend File or Checkpoint Resend Request counts the data to the point where the application has received the data to seek a file.

[4] Alternate method None

[5] After modification The processing on the partner side has now improved to terminate the operation, even if Send or Receive process in progress is forcibly terminated.



243 Outputting to identical Trace Log file by multiple processing sessions may corrupt format or fail to switch Trace Log file

[1] Phenomenon This phenomenon may occur where multiple processing sessions (namely, Send, Receive, or Request Acknowledge) are outputting to an identical Trace Log file under following circumstances: 1) Trace Log Format has corrupted 2) Failed to switch Trace Log file

*In this case, the process that failed to switch the log may terminate its operation with an error ‘305 (link file error)-0.’ For details, refer to No. 244 in the Bug List.


[3] Occurrence condition The phenomenon occurs when all of the following conditions are fulfilled:

• Multiple processing sessions (namely, Send, Receive, or Request Acknowledge) specify an identical log upon starting up daemon. (That is, specify an identical Trace Log File Name upon starting up daemon, or set “Trace Output File Name (tlogfile)” in System Environment Settings to output the specified name to the trace log.) • The value specified in “Trace Output Mode (tlogmode)” in System Environment

Settings is ‘1’ or higher. If the phenomenon falls into 1), there is an additional condition to be fulfilled:

• Multiple processes output to the file simultaneously If the phenomenon falls into 2), there are additional conditions to be fulfilled:

• The log count specified in “Log Switch Count (logdelcount)” in System Environment Settings is ‘1’ or higher.

• The size of Trace Log file swells and multiple processes access to the log simultaneously with the timing of the switchover of the log.

[4] Alternate method

None [5] After modification

The locking method of Trace Log file has been improved so as not to allow multiple processes to access the log simultaneously. With this improvement, the phenomenon explained above will not occur.



244 HULFT fails to detect failure in outputting Trace Log immediately before the execution of subsequent job. Thus, the application executes the jobs that follow after as they are, which may cause inconsistency in the result of receiving result.

[1] Phenomenon After the termination of data transfer processing, failure in outputting of Trace Log immediately before the execution of the registered subsequent jobs (namely, Successful job, Unsuccessful job) carries out these jobs unintentionally, which should not be carried out according to the original design.*1 In addition, where multiple jobs are registered, an occurrence of an error immediately before the execution of these jobs also executes the jobs until the end, which should not be carried out according to the original design. *1 Transfer processing will continue in the case of a failure in outputting Trace Log

output during data transfer. Besides, if the Receive Completion Notification is set to ‘J,’ namely, the notification is issued at the successful Job Completion, execution of the jobs yields inconsistency in transfer results as shown in the table below.

[Table] Transfer Result when the application failed to output the Trace Log immediately before the execution of Post-receive Job

Receive Completion Notification in Receive Management Information

Receive Completion‘T’ Successful Job Completion ‘J’

Log (Error Code) ‘0’ Successful

Completion

Abnormal Completion (*2)

Environment Variables $STATUS in Subsequent ‘0’ ‘0’

*2 Failure in such case ends operation with an error that indicates the error is related to

access to the file [2] Target Version

Ver. 6.0.6 [3] Occurrence condition

This problem occurs when an attempt to access Trace Log File fails immediately before the execution of subsequent jobs (namely, Successful job, Unsuccessful job) and the application is unable to output the Trace Log. This phenomenon also occurs when the application fails to switch Trace Log because of the phenomenon stated in No.243 in this Bug Report.


[5] After modification HULFT now ends execution of jobs when an error occurred on the execution of Subsequent Job. Similarly, HULFT regards the failure in outputting Trace Log occurred immediately before the execution of subsequent job as an error during the job execution. This makes HULFT end the execution of the jobs.

Receive completion Notification

Transfer Result



251

In Receive Daemon or Request Acknowledge Daemon, delay of 30 seconds for the next packet after the establishment of request connection causes timeout. This makes all other connections that follow after wait during that time and causes further delay in those processing as well

[1] Phenomenon In Receive daemon or Request Acknowledge daemon, delay of 30 seconds in the next packet after the establishment of request connection causes timeout. If the packet does not reach to the partner, HULFT disconnects the socket. This makes all the other subsequent connections wait, which causes further delay in processing. Because the delay is occurred on the side of daemon, a timeout error in the utilities on the source host that issued requests may occur. (See No.256 in this Bug Report)


[3] Occurrence condition This phenomenon is occurred where the next data does not come due to network setting (such as firewalls and the like) or network error.


[5] After modification Receive daemon and Request Acknowledge daemon are now improved to handle multiple socket connections and thus HULFT does not make subsequent processing wait nor cause further delay. Regarding the connection, during which a packet delayed, HULFT waits according to the value of “Socket Read Timeout (socktime)” in System Environment Settings before it disconnects the socket. (The output of IP address of the disconnected connection source to the Trace Log file of the daemon that accepted the connection is now available.)



256 Specifying Trace Log Output while operating HULFT by user account type other than superuser (root) may cause failure in activating daemon

[1] Phenomenon When you try to start a daemon with a user account other than superuser (root) such as general user , Receive daemon, or Request Acknowledge daemon may be terminated abnormally with a code ‘15’ (Failed to initialize a file for trace) and you cannot start up the daemon.


[3] Occurrence condition This phenomenon may occur when all of the following conditions are fulfilled:

• When general user not superuser (root) activates Receive daemon, or Request Acknowledge daemon

• Multiple processing sessions (namely, Send, Receive, or Request Acknowledge) specify an identical log upon starting up daemon. (That is, specify an identical Trace Log File Name upon starting up daemon, or set “Trace Output File Name (tlogfile)” in System Environment Settings to output the specified name to the trace log.) • When Send daemon is started first

*Send daemon behaves as if superuser started up the daemon even if general user actually activates the daemon, because sbit is added. This may cause other daemon activated by a general user is unable to access Trace Log file in some cases.


[5] After modification Trace Log File is now always created with the access permission ‘666.’ This does not let above problem occur.



• Sending Function

189 HULFT may carry out Send File without executing Pre-send Job

[1] Phenomenon When an end user that executes Send File (utlsend) does not have permission to read or write Send Management Information file (hulsnd.db.idx/dat), HULFT may carry out Send File without executing Pre-send Job.


[3] Occurrence condition The phenomenon occurs where there is a definition of Pre-send Job and an end user that executes Send File (utlsend) does not have permission to read or write the Send Management Information file.

[4] Alternate method Send File should be issued by an end user who has permission to read or write the Send Management Information. Otherwise, modify access permission to the Send Management Information.

[5] After modification HULFT does not permit Send process under above circumstances.

197 A value in Record Count after the transfer completion of Send data on the Send Status List may be lower than actual counts

[1] Phenomenon A value in Record Count after the transfer completion of Send data on the Send Status List may be lower than actual counts.


[3] Occurrence condition The phenomenon occurs while a partner host on the receiving side is waiting for the following process after the completion of Send data transfer: • “Completion of successful Job” where Receive Completion Notification is set to

Successful Job Completion • CSV Interface is in progress • XML Interface is in progress

The difference from the actual record count is subject to Transfer Block Length and Transfer Block Count.


[5] After modification HULFT has now improved to display the correct record count.



210

After the transfer of Send data is completed, occurrence of an error while the application is waiting for the completion of receiving by partner host causes termination with an error code ‘302-000 (file read error)’, which indicates an error in socket

[1] Phenomenon After the transfer of Send data is completed, occurrence of an error while the application is waiting for the completion of receiving by partner host causes termination with an error code ‘302-000 (file read error)’, which indicates an error in socket.


[3] Occurrence condition The phenomenon may occur where an error is occurred in network or ton the receiving side while the application is in the completing process that waits for the completion on the receiving side. Example) The possibility of occurrence will increase when an error is occurred while the application is carrying out following Receive processing: • “Completion of successful Job” where Receive Completion Notification is set to

Successful Job Completion • CSV Interface is in progress • XML Interface is in progress


[5] After modification HULFT has now modified to terminate its operation under above circumstances with following error code: ‘525-000 (End telegram recv error)’ Description: Termination status of the receiving side could not be acquired. The receiving

side may be successfully terminated. Measure: Check the status code of receiving side.



213 When forcible termination of Send daemon or Send process due to external factor occurs, the application may not execute Send processing after restart of Send Daemon

[1] Phenomenon When the Send Process status is ‘Connect’ or ‘Standby,’ while the transfer status is in the ‘Auto Resend,’ a forcible termination of Send daemon and Send process fails to carry out Send process after the restart of Send daemon. In addition, on starting Send daemon, Send Status Information of above status categories will be deleted.


[3] Occurrence condition The phenomenon occurs where Send daemon and Send process are forcibly terminated due to an external factor such as error in OS or issuance of kill command.


[5] After modification HULFT has improved to be able to carry out the sending in the status of ‘Connect,’ ‘Standby,’ and ‘Auto Resend’ as well as ‘SND’ and ‘Send Queue.’ The application now deletes above transfer status only when you specify the option ‘-d’ (Delete information on Send status on start-up) upon activation of Send daemon.

229 Despite successful termination of Sending, the value of environment variable $STATUS may become ‘308 (disk access error)’

[1] Phenomenon Despite successful termination of Sending, the value of environment variable $STATUS may become ‘308 (disk access error).’


[3] Occurrence condition This phenomenon occurs when environment variable $STATUS is used in the Successful Job under following conditions:

• When there is no Send Log • When you specify the value other than ‘0’ for “Log Switch Count” in System Environment Settings


[5] After modification The value of environment variable $STATUS is now ‘0.’



230 HULFT may complete transfer successfully even when Send file is deleted or modified during sending (Incompatibility)

[1] Phenomenon Where a Send file is deleted for some reasons, HULFT may complete transfer successfully even if Send file is deleted or modified during sending. Similarly, HULFT may complete transfer successfully where the contents of the Send file is modified. Actual Receive file is created normally, yet the transfer log will be inconsistent with Ver.5 (Ver. 5.0.9 or later).

[2] Target Version Ver.6.0.6

[3] Occurrence condition The occurrence conditions differ depending upon how to handle the Send file, namely whether the file is deleted or modified: 1) Where the Send file is deleted:

The error occurs depending upon the setting of “Send File Mode” in Send Management Information.

Send File Mode Completion Status of Sending

Keep (K) Successful Completion with ‘000-000’

Clear (C) Abnormal Termination with ‘256-220’ or Successful Completion with ‘000-000’*

Delete (D) Abnormal Termination with ‘256-220’ or Successful Completion with ‘000-000’*

Lock (L) Successful Completion with ‘000-000’

*Where the Send File Mode is set to either ‘Clear (C)’ or ‘Delete (D)’ Completion Status differs depending upon the value of Send Transfer Error Recovery

‘0’: The transfer is terminated abnormally with an error code ‘256 (file clear or delete error) -220 (Sending file clear or delete error)’ (The operation on the receiving side terminates successfully.)

‘1’: The application maintains synchronization between sending side and receiving side and the operation on the receiving side completed successfully as well.

2) Where the contents of Send file is modified: The error occurs where the Transfer Type on Send Management Information is set

to ‘Text Transfer.’ [4] Alternate method’


HULFT has improved to check Send file at the time of completion of Send data transfer. This improvement makes HULFT terminate its operation with following error codes, if Send file is deleted or modified during transfer of Send data. 1) Where the Send file is deleted:

Sending is terminated with the following error code regardless of the setting of Send File Mode or the value of Send Transfer Error Recovery in System Environment Settings. ’308 (disk access error) -201 (sendfile open error)’ *at this time, operation on the receiving side is terminated with an error ’209 (client error)-308,’ which indicates an error on the sending side.



2) Where the contents of Send file is modified:

Sending is terminated with the following error code regardless of the setting of Transfer Type or even when the transfer is Text format, where the file size of a Send file is modified during sending. ‘252 (all data length no match) -0 ’ *at this time, operation on the receiving side is terminated with an error ‘209 (client error)-252,’ which indicates an error on the sending side. The transfer other than text format used to terminate with different error codes, however from now on the code will be changed to above one.

However, if the Send data is deleted or modified after the completion of Send data transfer, (In the case such as the application on the receiving side is in the middle of executing Successful Job where the Successful Job Completion on the receiving side is specified, or the application is executing CSV Interface), the result is the same as Ver.6.3.0A or lower.

257 When HULFT is carrying out multiple sending, the application may fail to update Send Status file ($HULPATH/sddsendlist.dat) and it is terminated abnormally with an error code ‘303 (file write error)-0.’

[1] Phenomenon When HULFT is carrying out multiple sending, the application may fail to update Send Status file ($HULPATH/sddsendlist.dat) and it is terminated abnormally with an error code ‘303 (file write error)-0.’


[3] Occurrence condition This error occurs where OS is executing vast amount of sending under choked up state. The possibility that this problem may occur increases where frequent switching of Send process is observed. (Where OS accepts vast amount of Send File yet the each transfer completes in a short time)


[5] After modification HULFT now terminates the operation successfully under above circumstances.



• Receiving Function

111 In CSV Interface, Executing Transfer of an identical Receive file in a row may corrupt the CSV file

[1] Phenomenon In CSV Interface, Executing Transfer of an identical Receive file in a row may corrupt the CSV file.

[2] Target Version From Ver. 5.0.7 to Ver. 6.0.6

[3] Occurrence condition This phenomenon occurs where you execute transfer under following conditions:

• During CSV Interface (Specify CSV Transfer on the sending side) • Receive Completion Notification in Receive Management Information is set to ‘Receive Completion’

[4] Alternate method Specify the Receive Completion Notification in Receive Management Information as ‘Successful Job Completion.’

[5] After modification HULFT has now improved to create CSV file normally by improvement in locking method of Receive file (Improvement No.22).

182 When Communication Timeout occurred during Receive processing, the completion of processing may require twice as long as the specified time

[1] Phenomenon When transfer is terminated abnormally due to Communication Timeout, HULFT is supposed to terminate its operation with an error ‘333 (timeout)-334 (socket read error) after the expiration of the specified time in Socket Read Timeout in System Environment Settings. However, if an end user has set Unsuccessful Job, outputting Receive Log and execution of Unsuccessful Job come after the Socket Read Timeout, which requires twice as long as the usual time until the completion of processing. Besides, completion time of the transfer output to Log also requires twice as long as Socket Read Timeout. Example) Where Socket Read Timeout (socktime) is set to 3600 (seconds) and no communication has occurred since 12:00:

• HULFT outputs Receive Log at: 14:00 (Elapsed twice as long as 3600 seconds) • HULFT activates Unsuccessful Job at: 14:00 (Elapsed twice as long as 3600 seconds) • End Time in Receive Log: 14:00 (Elapsed 3600 seconds)


[3] Occurrence condition This phenomenon occurs when the host on the receiving side timed out in communication due to an error in network during transfer and Unsuccessful job is specified.


[5] After modification The output time to Receive Log, startup time of Unsuccessful Job, and End Time that is output to Receive Log after no communication occurred will come after the expiration of Socket Read Timeout.



193 Even if the specification of Error Recovery in Receive Management information is set to ‘Restore,’ the application may fail to restore Receive file when an error occurs

[1] Phenomenon Even if the specification of Error Recovery in Receive Management information is set to ‘Restore,’ HULFT may fail to restore the Receive file that already exists at the time of error occurrence and delete the file instead.


[3] Occurrence condition This phenomenon occurs when an error occurs under following conditions:

• Error Recovery in Receive Management Information is set to ‘Restore’ • Registration Mode in Receive Management Information is set to ‘New Creation’ • Receive file already exists


[5] After modification HULFT has now improved to restore Receive file instead of delete it under above circumstances.

195 On binary transfer, the application may be terminated abnormally with an error code ‘301-352 (gaiji code set error.)’ in some cases

[1] Phenomenon On binary transfer, the application may be terminated abnormally with an error code ‘301-352 (gaiji code set error.)’ in some cases, although HULFT does not execute code conversion.


[3] Occurrence condition This phenomenon occurs where all of the following Conditions are fulfilled: Receiving Side (UNIX/Linux)

• ‘External Character Table Mode’ in System Environment Settings is set to either ‘1: Use external character table’ or ‘2: Use external character table by priority.’

• External Character Table is not registered. Sending Side (On the side of Partner Host)

• Where the hosts on the receiving side run on any of the following platforms: Mainframe, OS/400, Windows, K, (Models other than UNIX/Linux, Himalaya) • Transfer Type in Send Management Information is set to ‘Binary Transfer’ • Code Conversion is set to ‘On Receiving side’* * Fundamentally, setting of Code Conversion is not valid at the time of binary transfer.

[4] Alternate method When you do not use External Character Table, specify ‘ 0: Do not use external character table.’

[5] After modification HULFT terminates binary transfer successfully under above circumstances, regardless of the setting of Code Conversion



204 An error of Receive Process Multiplex Level Over may occur despite margin

[1] Phenomenon Despite margin in Receive Process Multiplex Level, HULFT terminates its operation with an error ‘516-000 (connect max over.),’ which is an error in Receive Process Multiplex Level.


[3] Occurrence condition The phenomenon occurs where all of the following conditions are fulfilled:

• Where you specify ‘Receive Process Multiplex Level’ in System Environment Settings

• Where Receive process is forcibly terminated due to external factor such as error in OS or issuance of kill command • Where the sum of the number of Receive process that were forcibly terminates and that of the Receive processes of which transfer are in progress exceeds the value of Receive Process Multiplex Level

[4] Alternate method If the HULFT of the partner host is Ver.6 or higher, specify Receive Process Multiple Level Over Retry in System Environment Settings to make HULFT to retry receiving. When you connect to the partner host again, HULFT does not handle the state as Receive Process Multiplex Level Over and the application start receiving process normally.

[5] After modification HULFT has now improved to execute receiving process normally, even if it is the first attempt for connection.

214 Forcible termination of Receive process due to external factor during Format or Multi Format transfer may cause abnormal termination of the transfer sessions that follow after with an error code ‘303-312 (format file disk full.)’ in some cases

[1] Phenomenon Forcible termination of Receive process due to external factor during Format or Multi Format transfer may cause abnormal termination of the transfer sessions that follow after with an error code ‘303-312 (format file disk full.)’ in some cases.


[3] Occurrence condition The phenomenon may occur where all of the following conditions are fulfilled:

• Where Format Transfer or Multi Format Transfer is executed • Where Receive process is forcibly terminated due to external factor such as error in OX or kill command and temporary file ‘rcvtmp.pid,’* which is used in Receive processing remains • Where the process ID of Receive process corresponds to that of above temporary file in subsequent transfer

*A temporary file named ‘rcvtmp.pid’ that had been used in Receive Process is created for each process ID. The file is created under ‘Work File Generation Path (tmpdir)’ specified in System Environment Settings. HULFT usually deletes the file when Receive process is terminated.

[4] Alternate method Stop Receive daemon and delete all the Receive temporary files ‘rcvtmp.pid’ under Work File Generation path.

[5] After modification HULFT has now improved to terminate the Receive process normally.



216 When you execute transfer to an identical Receive file while setting Error Recovery to ‘Restore’ an occurrence of an abnormal termination in the transfer carried out immediately before may corrupt Receive data in the transfer of the next session

[1] Phenomenon When you execute transfer to an identical Receive file in a row, an occurrence of an abnormal termination of the previous transfer may corrupt Receive data in the next transfer.


[3] Occurrence condition This phenomenon occurs where all of the following conditions are fulfilled: 1) When the setting of Receive Management Information is as follows:

• Error Recovery is set to ‘Restore’ • Registration mode is set to ‘Append’ • Receiving mode is set to ‘Single’ • Receive Completion Notification is set to ‘Receive Completion’

2) Where the previous transfer is terminated abnormally and transfer of the identical Receive file Name is carried out before the completion of restoring process of Receive file


[5] After modification HULFT has now improved to create Receive file normally by improvement in locking method of Receive file (Improvement No.22).

219 Applying Generation Management while Registration Mode of Receive file is set to New Creation, the application may terminate abnormally with an error code ‘205-000 (file already exist),’ even though there is no existing Receive file in fact

[1] Phenomenon Applying Generation Management while Registration Mode of Receive file is set to New Creation, the application may terminate abnormally with an error code ‘205-000 (file already exist),’ even though there is no existing Receive file in fact


[3] Occurrence condition This phenomenon occurs where all of the following conditions are fulfilled:

• HULFT on the sending side is Ver.5 or lower • Registration mode is set to “New Creation” and Generation Management is set to “Enabled” • Where the File Name specified in Receive File Name (Receive File Name without extension of Generation Management Number) already exists

[4] Alternate method Delete the File Name specified in Receive File Name (Receive File Name without extension of Generation Management Number).

[5] After modification HULFT now terminates receiving under above circumstances successfully.



221 On the occurrence of communication timeout due to network error, incidental agreement of the transferred data to Stop protocol of HULFT may cause termination of Receive daemon or Receive process due to malfunction

[1] Phenomenon On the occurrence of Communication Timeout due to network error, incidental agreement of the transferred data to stop protocol of HULFT may cause termination of Receive daemon or Receive process due to malfunction. In such case, the application does not output Receive Log.


[3] Occurrence condition This phenomenon occurs where all of the following conditions are fulfilled:

• Communication Timeout* has occurred during receiving due to network error *Communication Timeout has occurred in the processing by HULFT, yet you cannot confirm the phenomenon because log is not output • Where a part of transfer data remained in socket incidentally agrees to Stop protocol of

HULFT [4] Alternate method


HULFT now does not terminate Receive daemon or Receive process due to malfunction.

235 Despite the setting of ‘Restore’ in Error Recovery, HULFT does not restore the attribute of a Receive file

[1] Phenomenon Setting of ‘Restore’ in Error Code Recovery restores a Receive File when a Receive process is terminated abnormally, yet the attribute of the file (Owner/Group/Permission) is not restored.


[3] Occurrence condition This phenomenon occurs where Receive process is terminated abnormally under following settings in Receive Management Information

• Error Recovery is set to ‘Restore’ • Registration Mode is set to ‘Append’

Besides, the phenomenon also occurs where startup owner or startup group of Receive daemon differs from those specified in Receive File Attribute in Receive Management Information.


[5] After modification HULFT has now improved to restore the attribute of Receive file under above circumstances.



• Request Acknowledge Function

273 HULFT may carry out Send File without executing Pre-send Job

[1] Phenomenon When an end user that activates Request Acknowledge daemon (hulobsd) does not have permission to read or write Send Management Information file (hulsnd.db.idx/dat), HULFT may carry out Send File without executing Pre-send Job.


[3] Occurrence condition The phenomenon occurs where there is a definition of Pre-send Job and an end user that activates Request Acknowledge daemon (hulobsd) does not have permission to read or write the Send Management Information file.

[4] Alternate method Send File should be issued by an end user who has permission to read or write the Send Management Information. Otherwise, modify access permission to the Send Management Information.

[5] After modification HULFT does not allow Send process under above circumstances.

• Utility

206 On executing line feed code deletion processing of File Record Edit command (utllf), absence of line feed code may cause termination with an error (Incompatibility with Ver.5)

[1] Phenomenon On specifying record length (utillf-d-lxxx) of line feed code deletion processing of File Record Edit command (utllf), HULFT Ver.5 terminates the operation successfully despite the absence of line feed codes, yet HULFT Ver.6 gets an error ‘95(illegal data).’


[3] Occurrence condition This phenomenon occurs where an input file does not contain a linefeed code at the position of record length specified by the command.


[5] After modification HULFT now terminates the operation successfully, as well as Ver. 5.



• Management screen

220 Despite the presence of Format ID in Format Information List, viewing, updating or deleting the information may not be available in some cases

[1] Phenomenon Despite the presence of Format ID in Format Information List, viewing information may not be available in some cases. In such case, an end user can neither update nor delete the Format ID.


[3] Occurrence condition This phenomenon occurs when you enter only Format ID and leave other fields blank, and then press the Enter key on Format Information Update screen.

[4] Alternate method In the Format ID that you cannot view any information, no information is registered. To delete such Format ID, issue Management Information Parameter File Generation command or Management Information Batch Registration command (utliupdt) to set the Management Information again, as shown below. 1) Retrieve all the format Information by using utliupdt

# utligen -f filename -i fmt -id ”*” 2) Delete Format Information file

# cd $HULPATH # rm hulfmt.db.idx # rm hulfmt.db.dat # rm *.fmt

3) Register the retrieved Management Information again # utliupdt -f filename

[5] After modification If you follow the procedure shown in above occurrence condition, HULFT returns an error message that read ‘Unentered field exists.’ This disallows you to register information. Therefore above phenomenon will not occur.



○ HULFT ManagerConnection Option

208 Occurrence of disconnection while connecting with HULFT Manager remains processes not terminated

[1] Phenomenon When the network is disconnected while connecting to HULFT Manager, Manager Connection process (huladmin) terminates after the expiration of “Request Acknowledge Timeout (socktime)” specified in System Environment Settings, yet Request Acknowledge process (hulobsd) remains without termination.


[3] Occurrence condition This phenomenon occurs where socket connection is disconnected due to cut-off in network, such as cut-off of LAN cables.


[5] After modification Request Acknowledge process now terminates after the expiration of Request Acknowledge Timeout.

217 When you issue Send File that accompanies Pre-send Job via HULFT Manager, Communication error or inability to return control may occur on the side of HULFT Manager

[1] Phenomenon When you issue Send File that accompanies Pre-send Job via HULFT Manager, communication error or inability to return control may occur on the side of HULFT Manager.


[3] Occurrence condition This phenomenon occurs when the executed Pre-send Job that uses standard input or standard output.

[4] Alternate method Redirect the standard input or standard output to any file in Pre-send Job so that the job does not use standard input or standard output.

[5] After modification HULFT has now improved to execute Send File normally, even if you set Pre-send Job that uses standard input or standard output.

level upgrade notification - hulft

Documents