The creator of the note pad specifies the TRACKTAG keyword to indicate whether XCF needs to track the maximum note tag value. If tag values are to be tracked, TRACKTAG also indicates the set of notes to be considered when determining the maximum tag value. The maximum tag value can be obtained by issuing a query note pad request with an answer area. As determined by the TRACKTAG specification, XCF will either not report the maximum tag value at all, report the maximum tag value of all the notes that exist in the note pad at the time of the query, or report the maximum tag value assigned to any note that ever existed in the note pad. The answer area stored by the query note pad request has a flag to indicate whether the content of the field containing the maximum tag value is valid for use.

In cases where the user is responsible for assigning tag values (TAGGING=USER), the TRACKTAG specification can lead to additional considerations for your program. Some TRACKTAG specifications impose requirements that must be met when a note request sets the tag value. Some TRACKTAG specifications have the potential to create additional overhead for note processing.

Do not track maximum tag value (TRACKTAG=NO)

XCF need not track the maximum tag value. Query note pad requests will not report a maximum tag value. The answer area will always indicate that the maximum tag value is not available.

For user assigned tags (TAGGING=USER), any value can be assigned to the tag when writing, replacing, or deleting a note. In particular, the new tag value for the note can be less than, equal to, or greater than the current tag value of the note.

Requests to create, replace, write, or delete a note will not incur any additional overhead related to tracking the maximum note tag value.

Track current notes (TRACKTAG=CURRENT)

XCF is to track the maximum tag value. Query note pad requests will report the maximum tag value of all the notes that exist in the note pad at the time of the query. If the note pad does not have any notes at the time of the query, the answer area will indicate that the number of notes is zero and the maximum tag value is not available. Note however, that the tag value might not be available because the note pad was not accessible at the time of the query. In this case, the answer area will indicate that neither the number of notes nor the maximum tag value are available.

For user assigned tags, the tag value assigned to an existing note must be greater than or equal to the current tag value of the note. A request to write, replace, or delete an existing note is rejected if the new tag value is less than the current tag value of the note.

Requests to create, replace, write, or delete a note will not incur any additional overhead related to tracking the maximum note tag value.

Lifetime tracking (TRACKTAG=LIFETIME)

XCF is to track the maximum tag value. Query note pad requests will report the maximum tag value of all the notes that ever existed in the note pad at the time of the query. To accomplish this, XCF maintains a record of the maximum tag value ever assigned to a note. This record is initialized to zero when the note pad is created. When a note is deleted from the note pad, XCF updates this record as needed. The maximum tag value reported by a query note pad request will either be the maximum tag value of all the notes that exist in the note pad at the time of the query, or this retained maximum tag value, whichever is greater. If the note pad does not have any notes at the time of the query, the retained maximum tag value is reported. If the note pad never had any notes, the maximum tag value is reported as zero since the retained tag value is initialized to zero. Note that the maximum tag value might not be available because the note pad was not accessible at the time of the query.

For user assigned tags, the tag value assigned to an existing note must be greater than or equal to the current tag value of the note. A request to write, replace, or delete an existing note is rejected if the new tag value is less than the current tag value of the note.

When XCF is responsible for setting tag values, there is no additional overhead associated with tracking the maximum tag value for the life of the note pad.

However, tracking the maximum tag value for the life of the note pad is not without cost when your application is responsible for setting tag values. When deleting a note, XCF might have to defer deletion of the note until the maximum tag value can be recorded. In such cases, the note is said to be pending delete. The delete is said to be a deferred delete. XCF marks the note as logically deleted and launches asynchronous processing to physically delete the note after the maximum tag value is appropriately recorded. The existence of a note that is pending delete might impact your program in the following ways:

• A note that is pending delete is still included in the count of the total number of notes in the note pad until such time as the note is physically deleted. So a pending delete could be observed as an unexpectedly high note count being returned by a query note pad request.
• A note that is pending delete might collide with a subsequent note request, causing that new request to incur additional overhead to resolve the pending delete.

  For example, consider a create note request. Since a note that is pending delete still exists in the note pad, the coupling facility would reject the create note operation. XCF recognizes that the existing note is pending delete. Logically, the create request should have worked, and it would have worked had the asynchronous XCF processing finished deleting the note in time. Rather than waiting for the asynchronous processing to complete, XCF finishes the deferred delete while running under the create note request thread. After doing so, it resends the create operation to the coupling facility. Functionally, the create note request works as expected. However, it incurred additional overhead because it was issued before the asynchronous XCF processing launched by the prior delete note request was able to physically delete the note. Not to worry, the asynchronous XCF processing will not delete the newly created instance of the note if it should happen to run (finally!) after the new note was created in the note pad.

From a functional perspective, the implementation of your program is not impacted by notes that are pending delete. XCF automatically detects and resolves any conflicts that might arise due to the physical existence of the logically deleted note. From a performance perspective, your program is not impacted if the asynchronous XCF processing finishes deleting the note before a subsequent request tries to process the same note. In general, this will likely be the timing. In cases where it does not work out that way, the response time for the requests that collide with a logically deleted note might be elongated.