JPH0420033A - System for managing activity identifier - Google Patents

Abstract

PURPOSE:To prevent the occurrence of duplicate utilization of an activity identifier by setting a condition of updating the activity identifier with its own system set to the start side to a minimum range only at retrial-out of error recovery processing. CONSTITUTION:A file is transferred between a starting side data processing section 1 and a response side data processing section 7. An activity identifier control section 3a of the starting side data processing section 1 does not update the activity identifier at the end of file transfer independently of the normal end or the abnormal end but uses a same value (current value) again, and updates the activity identifier when the error recovery processing is in retrial-out and uses a succeeding value (current value + increment). Thus, the occurrence of duplicate utilization is prevented by sending the activity identifier stored at the response side after the retrial-out of the error recovery processing from the starting side is prevented.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a method for managing activity identifiers in a system implementing error recovery based on O3IFTAM.

[Prior art] Regarding file transfer based on O3IFTAM, I
So 857] FTAM PART3, 13.1
．． In addition to normal file transfer, Section 1 specifies file transfer using error recovery processing.

File transfer using error recovery processing means that the open regime (established for each file) that was destroyed due to some failure during normal file transfer is regenerated by automatic retry within the system, and file transfer is then performed. It is completed by the recovery functional unit.
It is valid only if the In this case, it is necessary to determine in advance any of the above-mentioned failures as the type of error. Also, depending on the type of error,
Each error class is defined and typically if a recovery functional unit is negotiated, Class ■ Open regime or Selection regime damage and Class M Loss of association errors are implemented. Furthermore, in order to perform error recovery processing, it is necessary to hold information regarding transfer, and one of such information is the above-mentioned activity identifier.

The activity identifier is the I So 8571 F
TAM PART 3, Section 13.11 specifies a clear identifier for the file activity that takes place in the open regime, and assigns a different activity identifier value to each activity of the initiator and responder entity pair. It is used to re-establish a data transfer receipt after an error occurs. In other words, the activity identifier is a key for the responding side to identify the file waiting for error recovery. This means that in normal file transfer, the virtual file name is the key, but in error recovery processing, the virtual file name is not sent from the initiator, so the activity identifier is the key.

[Problem to be solved by the invention]

However, in IS and O8571FTAM, there are no regulations regarding update conditions and update triggers for activity identifiers, which are left to the implementation, and the trigger for deletion is also partially left up to the implementation. In other words, it is specified that the file is to be deleted in the file selection/open regime release processing, but if the class m error mentioned above occurs and the error recovery processing retries out without removing the cause of the error, the activity Since no identifier deletion processing is performed, there was no opportunity to delete the activity identifier.

In the end, in the above-mentioned conventional technology, the conditions for updating the activity identifier used on the initiating side during the 5 recovery process and its trigger, or the update conditions on the responding side when a class m error occurs and the error recovery process retries out. Since no consideration has been given to the trigger for deletion of an activity identifier, depending on the processing method, there may be duplicate use of the activity identifier after an error recovery retryout, mismatch in the memory state of the activity identifier on the initiator and responder, or activity caused by the operator. There were problems such as the need to reset and delete the identifier.

The present invention has been made in view of the above-mentioned circumstances, and its purpose is to solve the above-mentioned problems in the conventional technology, so that the data processing unit on the initiating side can retain data held by the responding side after error recovery retryout. An object of the present invention is to provide a management method for activity identifiers that can prevent duplicate use of transmitting activity identifiers.

[Means for Solving the Problems] The above-mentioned object of the present invention is to provide an activity identifier storage section that stores the value of an activity identifier, an activity identifier control section that controls assignment of the value of the activity identifier, and an activity identifier storage section that stores the value of the activity identifier. In a system that performs file transfer between an initiating data processing unit and a responding data processing unit that implement error recovery based on O3I FTA~1, including an interface unit that controls an interface between an identifier storage unit and an activity identifier control unit,
At least, the activity identifier control unit of the data processing unit on the initiating side does not update the value of the activity identifier when the file transfer ends, regardless of whether it ends normally or abnormally, and reuses the same value (current value). This is achieved by an activity identifier management method characterized in that when the recovery process is retried, the value of the activity identifier is updated and the next value (current value main increment value) is used.

[Operation] In the activity identifier management method according to the present invention, the activity identifier control unit on the initiating side reuses the current value as the value of the activity identifier during file transfer (regardless of normal termination or abnormal termination). In order to update the current value to (current, current value + increment value) when the error recovery process retries out, the initiating side must send the value of the activity identifier held on the responding side after the error recovery process tries out. It is possible to prevent the occurrence of double usage due to

In addition to this, if the activity identifier control unit on the initiating side uses the initial value again if the current value of the activity identifier exceeds a pre-given upper limit n when updating the current value of the activity identifier, , the value of the activity identifier can be automatically reset without using a reset (deletion) processing means such as operator intervention. On the other hand, if the activity identifier control unit on the responding side receives the same new activity identifier from the invoking side while the responding side is recovering from an error and is waiting for a request from the invoking side, the activity identifier control unit on the responding side updates the information on the previous activity identifier. If the error recovery state is resolved by deletion, the storage status (value and number) of activity identifiers will be deleted on both the initiator and the responder.
This can prevent mismatches.

〔Example〕

Embodiments of the present invention will be described in detail below with reference to the drawings.

Figure 1 shows an embodiment of the present invention.
1 is a block configuration diagram of a file transfer system implementing error recovery based on -. In the figure, 1 is the initiating side data processing unit, 2 is the FTAM file service user implementation unit, 3 is the FTAM error recovery protocol machine implementation unit, 4 is the FTAM basic file protocol machine implementation unit, and 5 is the FTAM basic file protocol machine implementation unit. A lower layer service providing implementation unit of the 6th layer and below including the 7th layer AC3E, and 6 denotes an activity identifier storage unit that stores an activity identifier as information necessary for error recovery. Furthermore, the error recovery protocol machine implementation unit 3 of the FTAM has an activity identifier control unit 3a that initializes and updates the activity identifier.
and an activity identifier storage interface unit 3b that performs an interface process between the activity identifier control unit 3a and the activity identifier storage unit 6.

Further, reference numerals 7 to 12 refer to a response side data processing unit existing in a pair with the above-mentioned initiating side data processing unit, and an FTAM file service user implementation unit 8. FTAM error recovery protocol machine implementation part9. FTAM basic file protocol machine implementation part 10. Lower layer service provision implementation unit 11 for layers 6 and below including AC3E in the 7th layer. Each shows an activity identifier storage unit 12 that stores an activity identifier as information necessary for error recovery. The error recovery protocol machine implementation unit 9 of the FTAM also includes an activity identifier control unit 9a that initializes and updates an activity identifier, and an activity that performs interface processing between the activity identifier control unit 9a and the activity identifier storage unit 12. An identifier storage unit interface unit 9b is provided.

In addition, in FIG. 1, the FT of the starting side data processing unit l
FTAM error recovery protocol machine implementation unit 3 of AM
File service user implementation section 2 and FTA Ni
However, this is just an example, and the error recovery protocol machine implementation unit 3 of FTA NI is positioned between the basic file service user implementation unit 2 of FTA~1 or It is also possible to implement an implementation in the basic file protocol machine implementation section 4 of FTAM, and the actinity identifier storage section 6 may also be an internal table in memory instead of a file. Of course, the same applies to the internal configuration of the response side data processing section 7.

Next, the basic sequence during normal file transfer and during error recovery will be explained using FIGS. 2 and 3.

FIG. 2 is an explanatory diagram of the file transfer sequence of FTA-1. Note that the sequence during normal transfer is as shown in FIG. 2, regardless of whether error recovery is implemented or not. In a file transfer system that implements error recovery, the initiator performs file selection/open regime establishment processing (22a) after establishing an association (21a).
) sends the activity identifier to the responder,
If no failure that is subject to error recovery processing occurs in the subsequent data transfer, deletion of the transmitted activity identifier is notified in file selection/open receipt release processing (23a).

On the other hand, the responding side performs the association establishment (21
After b), store the activity identifier received from the invoking side (22b)L, and if no failure that is subject to error recovery processing occurs in the subsequent data transfer, file selection/open receipt release processing (23b) in,
The stored activity identifier is deleted according to instructions from the initiator.

FIG. 3 is an explanatory diagram of the FTAM file transfer sequence when a failure that is subject to error recovery processing occurs during transfer. The initiating side releases the association when a failure that is subject to error recovery processing occurs during data transfer (in this case, it is assumed that it is a class m error failure specified in 031 FTAM error recovery) (33a). Therefore, the association is re-established on the responding side (34a). Next, in the regime recovery process, the previous file selection/open regime establishment (32
The same value as the activity identifier sent in a),
It is sent to the responder (35a). Note that, after the regime recovery process, if a failure (class m error failure) that is the target of the error recovery process occurs again during data transfer, the above-mentioned processes 34a and 35a are retried a fixed number of times. The number of retries may be a fixed value or an arbitrary value specified by the user. If the retry process fails for a certain number of times, the initiating side resolves the error recovery state, removes the failure, and then establishes a normal association (36a) and file selection/open regime (37a).

On the other hand, if a failure that is subject to error recovery (class M error failure) occurs during data transfer, the responding side
Since the association is released, an error recovery request from the initiator is awaited, and the association is re-established (34b
), the system waits for regime recovery processing (34b). Here, since the responder cannot necessarily grasp how many times the initiator has retried, the responder must accept error recovery requests from the initiator at any time without being aware of the number of retries. On the other hand, in the case of a line failure, etc., the timing of the initiator's glue tryout cannot be detected, so it is necessary to be able to receive normal transfer requests for files (open seams) that are waiting for a recovery request ( 36b, 37
b).

At this time, the activity identifier received in the regime recovery process is used as a key to identify the file (open regime) that is waiting for an error recovery request.

FIG. 4 shows an example of the configuration of an error recovery processing information table that manages information such as initial values and increment values of activity identifiers necessary for error recovery processing in the activity identifier control unit 3a or 9a. be. In addition,
The error recovery processing user specified number of times and the error recovery processing retry execution number of times in this error recovery processing information table are used when checking whether or not the error recovery processing has been retried.

Hereinafter, specific operation examples of the activity identifier control unit 3a and 9a shown in FIG. 1 will be explained as shown in FIGS.
This will be explained based on the diagram. Note that error check processing is omitted in the operational flowcharts shown in FIGS. 5 and 6.

First, the operation of the activity identifier control section 3a on the activation side will be described with reference to FIG.

Error recovery protocol machine implementation unit 3 of FTAM on the initiating side
is the upper layer FTAM file service user implementation @
Determine the request to the responder received from 2 (step +
00 and step 103) L. If it is an association establishment request or an association release request, the activity identifier is read from the activity identifier storage unit 6 via the activity identifier storage unit interface unit 3b (step +01 and step 104).
. If the request is an association establishment request, the value of the read activity identifier is set in the file selection/open regime establishment process parameter (step 102). At this time, it is assumed that the value of the activity identifier has already been set to an initial value in the initial setting process of the system.

In addition, in error recovery based on ○5 IPTA)vi, the activity identifier specifies [a clear identifier for file activity performed in the open regime], and is unique for each file, that is, the open regime, so the value of the activity identifier cannot be updated. Although it is written that the processing needs to be done on a file-by-file basis,
In this embodiment, the process of updating the value of the activity identifier is performed on an association basis. The reason for this is that, not only when one association performs only one file transfer, but also when one association performs multiple file transfers, if no error recovery target failure occurs in each file transfer, file selection/ This is because activity identifiers with the same value are not held in multiple files, and as a result, the uniqueness of the activity identifier value is guaranteed. On the other hand, if a failure occurs that is the target of error recovery, there is no problem because it is necessary to perform error recovery processing using activity identifiers with the same value.

Also, if the request is an association release request,
After reading the activity identifier from the activity identifier storage unit 6 (step 104), it is checked whether the association has been released due to the occurrence of a failure targeted for error recovery (step 105); in the former case, whether the error recovery process has retried or not. (Step 1)
06). Here, if the error recovery process is a retryout, the activity identifier is updated as follows, and if the results of the determination processes in steps +05 and 106 are NO, the update process is not performed.

When performing the update process, first check whether the read value is an arbitrary upper limit value n preset in the system (step 107), and if it is the upper limit value n, it is initialized as the next value. A value Q is set (step 108).

Nao, O12FTAM implementation regulations do not specifically specify the upper limit of the activity identifier value, but only specify a positive integer or O, so when the local system is the initiator, the system can set an arbitrary upper limit. Make it configurable. This allows, for example, systems that can only receive activity identifier values up to a maximum of 127 (i.e.
File transfer is possible with the storage area (minimum 1 byte).

Also, if the value of the activity identifier is smaller than an arbitrary upper limit value, simply increase the value of the activity identifier to +m(
(m is an increment value, which is a positive integer of 1 or more) Update processing is performed (step 109).

By the operation described above, by specifying the update condition and trigger of the activity identifier as when the error recovery process retries out, the initiating side can update the value of the activity identifier held on the responding side after the error recovery process has tried out. The effect is that it is possible to prevent double usage caused by transmission. Further, by giving an arbitrary upper limit value to the activity identifier and cyclically allocating it, it is possible to obtain the effect that a means for resetting (deleting) the activity identifier by operator intervention or the like is not required on the starting side.

Next, based on FIG. 6, the operation of the activity identifier control unit 9a on the responding side will be explained.
The error recovery protocol implementation unit 9 of ~1 determines the content of the request to the response side received from the initiating side (step 200).
．． 205. 207). If the request from the initiating side is a normal transfer request, that is, a file selection/open regime establishment request is received after receiving an association establishment request, check whether the corresponding file in the local system is waiting for an error recovery request. Check (step 201
．． Do 1. If the corresponding file in the own system is waiting for an error recovery request, the activity identifier held in the activity identifier storage unit 12 is deleted (step 202), and then the error recovery request waiting state is resolved in step 203. ), writes the newly received activity identifier into the activity identifier storage unit 12 (step 204).

In addition, if the request from the initiating side is an error recovery processing request, that is, a regime recovery establishment request is received after receiving an association establishment request, the file (open regime) that is waiting for error recovery is retrieved from the received activity identifier. Identify and perform error recovery processing (Step 2)
05. 206). The request from the startup side is file selection/
If it is an open regime release request, the activity identifier held in the activity identifier storage unit 12 is deleted (steps 207 and 208).

Through the above-mentioned operation, the responding side receives the activity identifier even if a class m error occurs and the error recovery process has retried, that is, even if it has not received a file selection/open regime release request. Since there is an opportunity to delete the activity identifier, it is possible to prevent the storage states (values and numbers) of activity identifiers from becoming inconsistent between the initiating side and the responding side.

It goes without saying that the above embodiment is shown as an example of the present invention, and that the present invention is not limited thereto.

[Effects of the Invention] As described above in detail, according to the present invention, when the local system is the initiator, the activity identifier update process is performed on an association basis, not on a file nesting basis, and the update conditions are set. By limiting the error recovery process to the minimum range only during the tryout, it is possible to minimize the overhead due to activity identifier update processing, and the initiator can update the activity held on the responder after the error recovery process tryout. This has the remarkable effect of being able to prevent the occurrence of duplicate use due to the transmission of identifier values.

In addition, when the local system is the responding side, by specifying the trigger for deletion of the activity identifier when a class m error failure occurs, it is possible to avoid discrepancies in the storage state of the activity identifier between the initiating side and the responding side. At the same time, it is possible to prevent unnecessary activity identifier information from remaining in the activity identifier storage unit, which eliminates the need for resetting (deleting) unnecessary activity identifiers by operator intervention, etc. This has the remarkable effect of making it possible to effectively utilize the identifier storage section.

[Brief explanation of the drawing]

Fig. 1 is a block configuration diagram of a file transfer system implementing error recovery based on O8I FTAM, which shows an embodiment of the present invention, Fig. 2 is an explanatory diagram of the FTAM file transfer sequence, and Fig. 3 shows errors during transfer. An explanatory diagram of the FTAM file transfer sequence when a failure that is subject to recovery processing occurs. Figure 4 is a diagram showing a configuration example of an error recovery processing information table. Figure 5 is the operation of the activity identifier control unit on the initiating side. Flowchart FIG. 6 is an operation flowchart of the activity identifier control unit on the response side. l: Invoking side data processing unit, 2: Invoking side FTAN4 file service user implementation unit, 3 Initiating side FTA~1 error recovery protocol machine implementation unit, 3a Activity identifier control unit, 3b Activity identifier storage interface unit, 4 ．． FTAM basic file protocol machine implementation section on the initiator side, 5 Lower layer service provision implementation section on the initiator side, 6 Activity identifier storage section on the initiator side, 7゜Response side data processing section, 8: FTA on the response side \1
File Service II #J Practical Department, 9I7:, FTAN1 Error Recovery Protocol Machine Practical Department on Each Side, 9a.
Activity identifier control unit, 9b/activity identifier storage interface unit, 10° response side FTAM
Basic file protocol machine implementation unit, ll response side lower layer service provision implementation unit, 12. Activity identifier storage. Figure <7 steps during normal transfer> File user (initiator) File provider (responder) Figure <Sequence when an error occurs> File user (initiator) File provider (responder)

Claims (1)

[Claims] 1. An activity identifier storage unit that stores the value of an activity identifier, an activity identifier control unit that controls assignment of the activity identifier value, and an interface unit that controls the interface between the activity identifier storage unit and the activity identifier control unit. In a system that performs file transfer between an initiating data processing unit and a responding data processing unit that implement error recovery based on OSIFTAM, at least the activity identifier control unit of the initiating data processing unit Regardless of whether the file transfer ends abnormally, the activity identifier value is not updated and the same value (current value) is reused, and when error recovery processing retries out, the activity identifier value is updated and the next An activity identifier management method characterized by using a value (current value + increment value).