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.
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:
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
At this point, two courses of action are possible:
Notice that a source machine may work on separate, locally controlled data sources.
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.
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. |
The general syntax of the MODIFY command is
MODIFY FILE filename [ECHO|TRACE] . . statements . . DATA [ON ddname|VIA program] . incoming data . . [END]
where:
Begins the request.
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.
Invokes the ECHO facility, which displays the request logic (see Displaying MODIFY Request Logic: The ECHO Facility).
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).
Are the MODIFY statements in the request. Each statement must begin on a separate line.
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.
Is a DATA statement parameter. See Specifying the Source of Data: The DATA Statement.
Is a DATA statement parameter.
Is the data you are using to modify the data source if you are supplying the data in the request itself.
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).
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:
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:
Is an integer.
Are the transactions processed by the request.
Is the total number of transactions processed.
Is the number of transactions accepted by the request and used to maintain the data source.
Is the number of transactions rejected by the request.
Is the number of segment instances modified by the request.
Is the number of new segment instances.
Is the number of instances updated.
Is the number of instances deleted.
To suppress this message, include the following command in the procedure before the MODIFY request:
SET MESSAGE = OFF
To execute a MODIFY request online, enter
MODIFY FILE filename
where
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.
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.
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 |