Additional MODIFY Facilities

In this section:

Reference:

You can also instruct the request to perform other tasks:

You can design MODIFY requests using Case Logic, a method which divides requests into sections called "cases." The request can branch to the beginning of a case during execution. Case Logic, discussed in Case Logic, makes it possible for requests to offer the terminal operator selections and to process transactions in different ways.

You can design MODIFY requests that process multiple segment instances at one time. Multiple Record Processing is described in Multiple Record Processing, including the modification of several segment instances on one FIDEL screen.


Top of page

x
Reference: Notes on Using JOIN Syntax With MODIFY

For software that supports the MODIFY facility, note the following:

FOCUS offers a variety of other advanced features that facilitate use of the MODIFY command in more complex applications. These features are listed below and described in Advanced Facilities:

The rest of this introduction contains:


Top of page

x
Multiple User Access

Reference:

Suppose you need to update a particular data source, but three other users have been assigned to work on the data source at the same time. How can you be sure that one user's changes will not override or overwrite another user's changes? MODIFY, used in conjunction with the Simultaneous Usage (SU) facility, ensures data integrity under those circumstances.

To enter SU mode, you initiate a background job process called a FOCUS Database Server. The user ids running FOCUS or Host Language Interface programs are called source machines. The users (using their source machines) send requests and transactions to the FOCUS Database Server, which processes the transactions and transmits the retrieved data or messages back to the source machine. The following diagram illustrates the process:

Under SU, when you run a MODIFY request

  1. The request identifies the instance to be changed with MATCH or NEXT commands.
  2. The source machine forwards the transaction values to the FOCUS Database Server, which uses the values to retrieve the correct instance.
  3. The FOCUS Database Server retrieves the original data source instance, holds one copy, and sends another to the source (user id) that requested the data.
  4. The source machine updates its copy of the instance with the new field values, or marks the copy for deletion and sends the updated copy back to the FOCUS Database Server. The FOCUS Database Server compares the copy of the instance that it saved with the instance stored in the data source to check whether the data source instance has since been updated by another user.

    At this point, two courses of action are possible:

    • If the copy and the current instance in the data source are the same, FOCUS changes the instance using the copy from the source machine.
    • If the original and the current instance in the data source are different, SU signals a conflict and rejects the source machine copy.

Notice that a source machine may work on separate, locally controlled data sources.



x
Reference: SU Features

With SU you can display a list of the active source machine userids and the fields of the FOCUS Database Server data sources from your source machine, and record all user actions in a sequential data source called HLIPRINT. The HLIPRINT data source records each user action, the data source on which the action took place, the segment read or modified by the action, and the user id that issued the action. It can also include the:

Another SU feature is the FOCURRENT variable that alerts users to transaction conflicts. When you submit a MODIFY transaction in SU, FOCUS stores a value in a variable called FOCURRENT to indicate what happened to the transaction. You can design your MODIFY requests to test FOCURRENT and take different actions, depending on whether the transaction was accepted or rejected. The following request tests the FOCURRENT variable:

MODIFY FILE EMPLOYEE
PROMPT EMP_ID
GOTO NEWSAL
CASE NEWSAL
MATCH EMP_ID
    ON NOMATCH REJECT
    ON MATCH PROMPT CURR_SAL
    ON MATCH UPDATE CURR_SAL
    ON MATCH IF FOCURRENT EQ 0 GOTO TOP;
    ON MATCH TYPE
      "VALUE CHANGED. NEW VALUE <D.CURR_SAL>"
ENDCASE
DATA

The request prompts for an employee ID and then branches to the case NEWSAL. If the ID is in the data source, you are prompted for the current salary of the employee; the current salary is updated on the source machine copy. The transaction is submitted.

Next, the request tests the values of the variable FOCURRENT:

By testing the FOCURRENT variable, MODIFY requests can process transactions after they have been rejected because of conflicts.


Top of page

x
Managing Your Data: Advanced Features

In addition to the basic operations of the MODIFY facility, many other features are available to help you refine your MODIFY requests. This section describes them briefly.

Feature

Description

Absolute File Integrity

Causes FOCUS to write changes to the data source to another section of the disk rather than overwriting the data source. If the request executes normally, the new section of the disk becomes part of the data source. If the system fails, the original data source is preserved.

ACTIVATE

Activates an inactive transaction field. It declares a transaction field to be present so the transaction field can be used for matching, including, and updating. The MOVE option equates the transaction value of the transaction field to the corresponding data source field. The RETAIN option does not move the data source value to the transaction field.

DEACTIVATE (RETAIN)

Deactivates a transaction field. The DEACTIVATE command changes a transaction value to blank if alphanumeric, to zero if numeric, or to the MISSING transaction value for transaction fields described by the MISSING=ON attribute. It also deactivates the corresponding data source field. The RETAIN option deactivates the field without changing its value.

CHECK

Limits the number of transactions lost if the system fails when you are modifying a data source by identifying a checkpoint. CHECK activates the Checkpoint facility that enables FOCUS to write more frequently to the data source. (The point at which the transactions are written is called the "checkpoint.") The Checkpoint Facility is useful in cases when a system failure occurs while MODIFY requests are executing.

COMBINE

Enables you to modify multiple FOCUS, relational, or Adabas data sources in one MODIFY request.

COMMIT and ROLLBACK

Control the changes made to data sources and protect the data sources from system failures. COMMIT and ROLLBACK improve SU performance; here the ability to group individual transactions as one logical transaction reduces the number of individual transactions and the amount of communication needed between the FOCUS Database Server and source userids. COMMIT and ROLLBACK are used in lieu of CHECK.

COMPILE

Translates MODIFY requests into compiled code ready for execution.

COMPUTE

Enables you to modify incoming data field values and to define temporary fields.

DECODE

Enables you to compare transaction values against a list of acceptable and unacceptable values.

LOOKUP

Tests for the existence of non-indexed values in cross-referenced FOCUS, relational, or Adabas data sources and makes these values available for other computations.

ECHO

Displays the logical structure of MODIFY requests. This feature is a good debugging tool for analyzing a MODIFY request, especially if the logic is complex and MATCH and NEXT defaults are used.

FIND

Searches another FOCUS, relational, or Adabas data source for the presence of the transaction value.

LOG

Enables you to record transactions and error messages in separate files automatically, and to control the display of rejection messages at the terminal.

MULTIPLE RECORD PROCESSING COMMANDS

Enable you to process multiple segment instances at one time and are often used with CRTFORM. A few of the important commands used in multiple record processing are GETHOLD and REPEAT. GETHOLD retrieves transaction records from memory and uses them to modify a data source; GETHOLD collects and retrieves segment instances. REPEAT does re-iterative processing.

TYPE

Displays or stores messages in a separate file that you prepare.

VALIDATE

Enables you to reject transactions that contain unacceptable values.



x
MODIFY Command Syntax

The general syntax of the MODIFY command is

MODIFY FILE filename [ECHO|TRACE]
  .
  . 
statements  .
  .
DATA [ON ddname|VIA program]
  . 
incoming data  .
  .
[END]

where:

MODIFY FILE

Begins the request.

filename

Is the name of the FOCUS, relational, fixed format sequential, VSAM, or Adabas data source you are modifying. This name must be the same as the Master File of the data source. For information about modifying non-FOCUS data sources, see the appropriate data adapter documentation.

Note: Although you can use MODIFY to load a fixed format sequential file, the sequential data source must consist of a single segment, and data is loaded in the order in which it is input. Update and delete operations are not supported. To append data to an existing sequential data source with HiperFOCUS ON, the record format must be fixed.

ECHO

Invokes the ECHO facility, which displays the request logic (see Displaying MODIFY Request Logic: The ECHO Facility).

TRACE

Invokes the TRACE facility, which displays the name of each case that is entered during the execution of the request if the request uses Case Logic (see Tracing Case Logic: The TRACE Facility).

statements

Are the MODIFY statements in the request. Each statement must begin on a separate line.

DATA

Specifies the source of incoming data. Note that nothing should come between this statement and the END statement, unless you are supplying the incoming data in the request itself. In that case, place the data after the DATA statement.

ON ddname

Is a DATA statement parameter. See Specifying the Source of Data: The DATA Statement.

VIA program

Is a DATA statement parameter.

incoming data

Is the data you are using to modify the data source if you are supplying the data in the request itself.

END

Concludes the request. Do not add this statement if the request contains PROMPT statements (PROMPT statements are discussed in Prompting for Data One Field at a Time: The PROMPT Statement).


Top of page

x
Executing MODIFY Requests

How to:

You can enter and run a MODIFY request either by entering it at the terminal or by running it as a stored procedure (stored procedures are discussed in the Developing Applications manual). When you start execution of the request, FOCUS executes the request for each transaction until:



x
Syntax: How to Execute a Request as a Stored Procedure

To enter a MODIFY request as a stored procedure, type the request in a procedure file (procedures are discussed in the Developing Applications manual). If you are including the incoming data in the request (which you might do for testing purposes), place the data after the DATA statement in the stored procedure. End the request with the END statement unless the request contains PROMPT statements.

After saving the file, enter at the FOCUS prompt

EX focexec 

where focexec is the name of the stored procedure.

FOCUS responds with an echo of the file name, date, and time as follows:

filename ON date AT time

The request then either begins prompting you for data or starts reading the stored transactions.

When the request finishes execution, it displays the following statistics

TRANSACTIONS:  TOTAL  = n ACCEPTED  = n REJECTED = n 
SEGMENTS: INPUT       = n UPDATED   = n DELETED  = n

where:

n

Is an integer.

TRANSACTIONS

Are the transactions processed by the request.

TOTAL

Is the total number of transactions processed.

ACCEPTED

Is the number of transactions accepted by the request and used to maintain the data source.

REJECTED

Is the number of transactions rejected by the request.

SEGMENTS

Is the number of segment instances modified by the request.

INPUT

Is the number of new segment instances.

UPDATED

Is the number of instances updated.

DELETED

Is the number of instances deleted.

To suppress this message, include the following command in the procedure before the MODIFY request:

SET MESSAGE = OFF


x
Syntax: How to Execute MODIFY Requests Online

To execute a MODIFY request online, enter

MODIFY FILE filename 

where

filename

is the FOCUS name of the data source you are modifying.

FOCUS responds with an echo of the data source name, date, and time as follows:

filename ON date AT time 
ENTER SUBCOMMANDS:

Enter each MODIFY statement in the request (such as FIXFORM, MATCH, COMPUTE, TYPE) followed by a DATA statement and the incoming data (if the data is not coming from another data source or from the terminal). Then enter the END statement (unless the request contains PROMPT statements).

The request can then start prompting you for data, read from an external data source, or accept transaction records from the terminal (if the request contains FIXFORM or FREEFORM statements but does not specify the ddname of an external data source).

If it accepts transaction records from the terminal, the request appears:

START:

Start entering the data, one record at a time. Every time you enter a record, the request processes it and displays a message if it rejects the record. After you have entered the data, enter the END statement. This ends execution.

If you are entering a MODIFY request online and you want to cancel the request and start over, enter QUIT. This returns you to the FOCUS prompt.

If you enter a statement online that FOCUS considers an error, it will prompt you for a correction. This error correction facility is described in the Creating Reports manual.

You should not enter MODIFY requests online unless the requests are short. If you enter a statement you want to change, you must quit the request and start over.

The example below shows a sample MODIFY request being entered online:

>
modify file employee 
 EMPLOYEEFOCUS A1 ON 08/15/85 AT 16.36.05 
 ENTER SUBCOMMANDS:
freeform emp_id curr_sal
match emp_id
on nomatch reject
on match update curr_sal
data 
 START:
emp_id=071382660, curr_sal=21400.50, $
emp_id=112847612, curr_sal=20350.00, $
emp_id=117593129, curr_sal=22600.34, $
end

Notice that when the request finishes execution, it displays the following statistics:

TRANSACTIONS:  TOTAL= 3 ACCEPTED= 3 REJECTED= 0
SEGMENTS:      INPUT= 0 UPDATED=  3 DELETED=  0

These statistics are explained in the preceding section.


Top of page

x
Other Ways of Maintaining FOCUS Data Sources

Although the MODIFY command is one of the primary methods of maintaining FOCUS data sources, there are four other facilities for changing data in FOCUS data sources:

Unlike the FSCAN facility mentioned above, the MODIFY command allows you to make many changes with one execution. It can run in both interactive and batch modes. It will prompt you for the values it needs to make the changes, or it may read the values from a transaction data source. However, it cannot update key fields.

Note that although the FOCUS Report Writer can write reports from many kinds of non-FOCUS data sources (such as ISAM, VSAM, and IMS data sources), the MODIFY command maintains only FOCUS data sources, and with the proper interface, VSAM data sources, and SQL and Teradata tables.

You can only MODIFY one partition of a partitioned FOCUS data source at one time. You must explicitly allocate the partition to be modified. Alternatively, you can create separate Master Files for each partition for use in MODIFY procedures. For more information about partitioned FOCUS data sources, see the Describing Data manual.


Top of page

x
The EMPLOYEE Data Source

The examples in this chapter use the EMPLOYEE data source, a data source used to record employee information for a company. The Master File and the diagram of the entire data source structure are shown in Master Files and Diagrams. Most of the examples use three segments in the EMPLOYEE data source:


Information Builders