Creating Script Methods
New Script-IV Facilities
Section titled “New Script-IV Facilities”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.
Source-IV
Section titled “Source-IV”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.
How to structure a script method
Section titled “How to structure a script method”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
Section titled “Readability”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-PROCEDUREException: 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 SCREENPOSCN2; OPEN SCREEN POSCN3; ADDCUSFIL USING KEY CUS-CODE; DUPLICATEKEY IS CHANGE-CUS; ERROR ISERROR-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 6IF CUS-NUMBER > "T0000" THEN PRINT SCREEN CUSSCRN1 CLEAR DO LOCAL-CUSTOMERSELSE 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-ORDERSENDIFYou 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-FILEENDIFThe 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-FILEELSE CHANGE ATAPMSTR USING KEY SORT SORT-NO NEXT PROCESSING IS EDIT-RECORD BUSY IS BUSY-RECORD END IS END-OF-MAIN-FILEENDIFFrom the OPENworkshop Reference, version 8.9.1. Open this page in the PDF