Skip to content

Creating Script Methods

The Script-IV language features and facilities are largely based on the Script-IV language, but some differences do apply. For the convenience of developers who have Script-IV experience, these differences are outlined below. The Associated Systems section of this manual provides a full guide to migrating existing Dictionary-IV applications to OPENworkshop. For more information, see the Script-IV Language Reference.

  • OPENworkshop introduces a new UPDATE directive to the Script-IV language. UPDATE operates essentially as a CHANGE directive, except that it causes a trigger method associated with the link to be executed. For more information, see the UPDATE command section later in this manual.
  • OPENworkshop no longer supports Type 1 or Pre/Post Processing scripts. However, any existing scripts of these types can very easily be changed to methods.
  • While continuation scripts, overlays and public scripts may still be used, the way that OPENworkshop encourages code to be developed in small, independent methods makes them unlikely to be needed. The data environment and behavior on termination of continuation scripts and overlays is different from that of the Dictionary-IV environment. For more information, see the Script execution environment section later in this manual.
  • OPENworkshop introduces local and global formats. For more information, see the local versus global formats section later in this manual.
  • A comprehensive debugging environment.
  • Full cross-referencing between all classes, methods and where they are used.

Thoroughbred Source-IV is a source code development and control system. In addition to library management and a context sensitive editor, Source-IV offers version control and the ability to recover any previous version of your source. This manual assumes that you will be using Source-IV for your development. For more information, see the Source-IV Reference Manual.

Once created, scripts must be compiled before they can be run.

Scripts are divided into two sections, the Data Environment section, and the Procedures section.

The Data Environment section is located at the beginning of the script method before any procedures and is optional. It is used to declare the dictionary definitions such as format, screen, view, and link to be used by the script. The section is only necessary if Dictionary-IV definitions are going to be used by the script.

The Procedures section consists of one or more independent procedures containing Script-IV commands.

Readability can affect long-term maintenance costs and affect the overall profitability of a software product. Script-IV is a self-documenting language designed for readability and easy maintenance. The commands and clauses are written in a simple, descriptive language and parameters are always identified by specific phrases. In addition, comments or remarks may also be included in a script to enhance the readability. This section describes several ways to enhance the overall readability of a script.

However, some software developers prefer a terse, less wordy language and are willing to sacrifice some readability in exchange for shorter commands. The Script-IV language is flexible enough to allow for this preference without detracting from the overall understanding of the commands. This is accomplished, in part, by optional syntax elements that do not affect the command function and are available only as readability aids.

Given the choice between readability and terseness, it is very important that you select your style and be consistent in the use of the various readability options. Some thought should also be given to the design and organization of procedures in your scripts. The increase in productivity offered by Script-IV can be enhanced by spending additional time in the analysis and design phase of product development. This will not only benefit development during the implementation but will contribute to the readability and long-term maintenance of your scripts.

Comments

Comment or remark lines can be included in a script and are not compiled. Any line that contains an * (asterisk) in column 1 is treated as a comment line. You can use comment lines as dividers to separate or set off a group of procedures or other segments within a script. For example:

*---------------------------------------------
* Customer Record Maintenance
*---------------------------------------------

Optional Syntax

This refers to optional syntax elements that do not affect the command function and are purely available as readability aids. Three common ones are: IS, ARE, and PROCESS. For example, the following two clauses perform the same function:

MISSING KEY PROCESS IS
TOTALS-PROCEDURE
MISSING KEY TOTALS-PROCEDURE

Exception: Readability options, such as IS or ARE, must be used to separate two expressions in a script.

For example, the first line below causes a compile error, while the second does not:

READ LMINDD USING KEY SORT 1 "5"
READ LMINDD USING KEY SORT 1 IS "5"

Optional Punctuation

The ; (semicolon) and . (period) can both be used to enhance command readability by marking the end of a command. The script compiler ignores these two punctuation marks.

The period can be used to show the end of a command in the same way it shows the end of a sentence. This helps to identify the beginning and end of commands, especially when a command is indented or broken up on several lines.

CHANGE APCKREG USING KEY CHK-NO
MISSING KEY PROCESS IS ADD-CHECK
PROCESSING IS WRITE-CHECK.
PRINT SCREEN APCHECKS. INPUT SCREEN
APCHECKS.

The semicolon can be used to separate commands that appear together on a single line, or to separate clauses within a command.

OPEN SCREEN POSCN1; OPEN SCREEN
POSCN2; OPEN SCREEN POSCN3; ADD
CUSFIL USING KEY CUS-CODE; DUPLICATE
KEY IS CHANGE-CUS; ERROR IS
ERROR-LOG.

Again, the important thing is to be consistent in your usage.

Optional Line Spacing

Blank lines can be used to separate logical segments of your script. You may want to separate procedures or groups of procedures from each other, or even separate individual commands. Blank lines are not compiled, and since scripts are compressed before being stored on disk, blank lines do not require storage space.

Optional Indention

Although commands and their clauses can be strung together one after the other without placing the beginning of each command on a new line, this would make a very tight and hard-to-follow script. It is a good idea to indent commands to highlight clauses and reflect any hierarchy in processing. If you develop and follow your own standards for indenting, it can greatly strengthen the structure of your scripts and aid readability.

We recommend that you start the beginning of each command on a new line. You may also want to use standard indention for commands such as the following:

CHANGE CUSFIL USING KEY CUS-NUMBER
BUSY PROCESS IS BUSY-MESSAGE
END PROCESS IS END-OF-FILE
PROCESSING IS UPDATE-CUS
TEXT "A"
WINDOW LINE IS 15
COLUMN IS 0
CHARACTERS PER-LINE ARE 60
NUMBER LINES ARE 6
IF CUS-NUMBER > "T0000" THEN
PRINT SCREEN CUSSCRN1 CLEAR
DO LOCAL-CUSTOMERS
ELSE
DO COUNT-MAIL-ORDER-CUSTOMERS
IF COUNT1 > 1000 THEN
PRINT MESSAGE "N,150"
IF MAIL-ORDER-FLAG = "y" THEN
DO BULK-MAIL
ENDIF
ENDIF
DO CLOSE-MAIL-ORDERS
ENDIF

You can also use a combination of indention and punctuation.

The following example demonstrates lack of structure and poor readability:

IF SORT-NO = 0 THEN
CHANGE ATAPMSTR USING KEY NEXT
PROCESSING IS EDIT-RECORD;BUSY IS BUSY-RECORD;END IS
END-OF-MAIN-FILE
ELSE CHANGE ATAPMSTR USING KEY SORT SORT-NO NEXT
PROCESSING IS EDIT-RECORD;BUSY IS BUSY-RECORD;
END IS END-OF-MAIN-FILE
ENDIF

The following example uses the same command and demonstrates how structuring a script can improve readability:

IF SORT-NO = 0 THEN
CHANGE ATAPMSTR USING KEY NEXT
PROCESSING IS EDIT-RECORD
BUSY IS BUSY-RECORD
END IS END-OF-MAIN-FILE
ELSE
CHANGE ATAPMSTR USING KEY SORT SORT-NO NEXT
PROCESSING IS EDIT-RECORD
BUSY IS BUSY-RECORD
END IS END-OF-MAIN-FILE
ENDIF

From the OPENworkshop Reference, version 8.9.1. Open this page in the PDF