JES: Just Educational Services

Jonathan E. Sisk's
Pick/BASIC: A Programmer's Guide

Chapter 18 - Additional PICK/BASIC Concepts

Click to enlarge

This chapter covers a variety of topics which were touched on lightly, or not at all, during the tutorial portion of the book. These include structured programming and programming standards, common PICK/BASIC instructions not used in the tutorial, and dealing with the Dictionary level of your BP (Basic Programs) file.


The phrase structured programming has been used to mean a collection of programming techniques designed to make programs better. Programmers disagree on what constitutes "better." Does it mean faster? Easier to analyze? Or something else? Some programmers prefer the term "programming standards," which doesn't limit the concept to control structures. Some common programming standards include the following:

  1. Restricting the size of program structures. The idea is that something that is smaller is easier to understand. For example:
    1. Limiting the size of separately compiled programs.
    2. Limiting the size of local subroutines, for instance to one printer page, so that an entire programming function may be viewed at once.
    3. Limiting the size of loops. One guideline limits loops to 20 lines, thus making it possible to easily see the scope of the loop.
  2. Restricting the numbers and kinds of program structures. For example the LOOP construct allows many syntactical forms; limiting the choices to one (or two) forms keeps things consistent.
  3. Avoiding the GOTO statement. Some experts believe that the real idea behind avoiding the GOTO statement is to do the following:
    1. Never branch into or out of an IF statement.
    2. Never branch into or out of a loop.

Whether or not you are a newcomer to programming, you would do well to adopt some programming standards when you write programs.


Some instructions were not discussed during the course of this book. Those instructions follow in this section, along with a short, summary explanation of how they are used. The syntax for these instructions, as well as all of those covered in the text is found in Appendix A.

The CHAIN Statement

The CHAIN statement is somewhat similar to the EXECUTE statement, in that it allows any TCL expression to be executed. The one major difference between CHAIN and EXECUTE is that the EXECUTE statement is capable of returning to the program that issued the statement, and retaining all of the program variables. The CHAIN statement does not return to the program that executes it.

The COM or COMMON Statement

The COM or COMMON statement is used to declare variables that are to be "shared" among external subroutines. This is the alternative to passing variables into an external subroutine as arguments (immediately following the program name on the line that executes the CALL statement).

The common opinion about COMMON is: Don't use it. Using it makes program maintenance much more tedious, because each time a new variable is added to one program, it must be added to all the other programs that also will use it.


The concept of group locks was discussed earlier in the text. The statement for reading a dynamic array is, of course, the READ statement, and the dimensioned array equivalent is the MATREAD statement.

The READU and MATREADU forms of these statements cause the group in which the requested item is found to be "group locked." These group locks remain in effect until:

  1. The item is written with the appropriate "write" statement. (WRITE or MATWRITE).
  2. The program terminates.
  3. A RELEASE statement is issued.

Note that many of the implementations are now supporting item locks instead of just group locks.


The WRITEU and MATWRITEU statements differ from their "normal" counterparts in that they keep the group lock set even after the WRITE statement.

The ON-GOTO Statement

This statement is exactly like the ON-GOSUB statement discussed earlier, but with the difference that execution does not automatically return to the next line after completion.

The PROCWRITE Statement

The PROCWRITE statement provides PICK/BASIC the ability to "write" a string of characters, each of which is delimited by a space (except on Ultimate and McDonnell Douglas systems, where it is treated as a dynamic array), over the previous contents of the Primary Input Buffer.


The READV statement is typically used by those who don't understand it. Rather than reading an entire item in one trip to disk, like the READ or MATREAD statement did, this reads items one attribute at a time. It has the general form:

READV FROM file.variable, id.expression, ...
 ... amc.expression {THEN statement(s)} ELSE statement(s)

Note the amc.expression following the id.expression. This tells the statement which attribute from the array to read and store in the specified variable. This tends to be extremely wasteful. The only time it is allowed is when you only need one attribute from an item.

The RELEASE Statement

The RELEASE statement is used to release one or more group locks set by the current process.

It has two general forms:


releases all group locks set by the current process.

RELEASE file.variable,id.expression 

releases the group lock set on the group that the specified item resides in.

The SYSTEM Function

This intrinsic function has quite a few powerful features that come in handy from time to time. Unfortunately, it is not consistent across all Pick systems, so consult your PICK/BASIC manual for more information.

To illustrate some of its features, as found in "generic" Pick, here are two of the functions of SYSTEM:

SYSTEM(2) Returns the current page width as defined by the TERM statement:

IF SYSTEM(2) > 80 THEN ...

SYSTEM(14) Returns the number of characters awaiting input in the input buffer.


The NULL Statement

The NULL statement is used almost exclusively as a mate for the THEN clause in an IF-THEN-ELSE statement. The NULL statement does absolutely nothing (this is what technical types call a "no-op"). It can be used as follows:

IF conditional. expression THEN NULL ELSE statement

Nested IF-THEN-ELSE Constructs

There are cases where "nested" IF statements are needed (Fig. 18-1 ). Special caution must be applied in terminating all of the initiators. Inevitably, you will run into something that appears even worse than this example. This is why there is the CASE statement, which simplifies these situations.

This brings up an important point. With a syntactical structure that is so flexible, some problems may crop up elsewhere; these problems typically occur by having one too many, or one too few END statements. For example, consider this case:

IF conditional.expression THEN <cr>     (starts level 1 )
IF conditional.expression THEN <cr> (starts level 2)
IF conditional.expression THEN <cr> (starts level 3)
END ELSE (ends level-3 THEN)
statement... (level-3 ELSE)
statement(s) (more code may go here)
END ELSE (ends level-2 THEN)
statement... (level-2 ELSE)
statement(s) (more code may go here)
END ELSE (ends level-1 THEN)
statement (level-1 ELSE)
END (ends level-1 ELSE)

Fig. 18-1, Nesting IF-THEN-ELSE structures.

001 IF conditional.expression THEN statement
002 IF conditional.expression THEN statement
003 IF conditional.expression ELSE statement
004 statement
005 statement
006 END
007 END
008 more code
009 more code
010 END

The programmer may have forgotten one of the critical END statements in the nested IF-THEN. The effect is that the compiler erroneously thinks that the first END statement (at line 6) belongs to the third level, that the second END statement (at line 7) belongs to the second level, and that the third END statement (in this case, at line 10) belongs to the first level. This sneaks through the compiler without any problem, other than the effect of not working properly.

The PRECISION Statement

The PRECISION statement declares the number of positions to be carried in mathematical calculations. It needs to be declared only once. The normal default setting on most systems is 4 (four), if left undeclared. The maximum varies from system to system. Ultimate now allows a maximum of 9, McDonnell Douglas allows 6, and the rest of the generic machines (unless they have been changed) allow 4.


In Chapter 2, comment sections were introduced. Many other useful pieces of information could have been included in the comment section, but only the first four lines were used throughout the examples. Among the other kinds of information which could be included are:

  • Any external subroutines called by the program
  • A list of files affected by the program
  • A list of input variables (variables passed to a local or external subroutine)
  • A list of output variables (variables returned from a local or external subroutine)
  • Any special processing considerations, such as the need for special forms, a tape, an external select, etc.
  • Security restrictions: port number, account name, time, date, security clearance level, etc.
  • Revision history. This is simply a list of the last batch of changes made to the program, along with the date and initials of the programmer who made the changes.


Now that you have diligently followed the convention of filling out the comments section in each of your programs, they may be put to some practical use. This involves using the Editor to build attribute definition items in the DICT (dictionary) level of the BP file, as shown in Fig. 18-2.

Since these three attributes are the only ones that are of interest for the moment, these attribute definition items will suffice. Naturally, if you decide to use any of the other suggested items in your templates, attribute definition items should be placed in the dictionary to correspond with them.

Now build the "implicit" attribute defining items, which show themselves automatically.


TO:1 2 3<cr>

ACCESS sentences may now be used on the BP file. For example:


or, for the report in order by program name:

>SORT BP<cr> 

or, to direct the output to the printer, simply add a (P) option:

>SORT BP (P)<cr>


001 A
002 2
008 T3,80
009 T
010 30

Item id: DATE

001 A
002 3
003 DATE
007 D2/
008 T3,8]DI  (The "]" character is a value mark.
009 R
010 8

Item-id: AUTHOR

001 A
002 4
008 T3,3
009 L
010 3

Fig. 18-2. Attribute definitions in the DICT portion of the BP file.

Previous chapter Next chapter Top


Creative Commons License
Jonathan E. Sisk's "Pick/BASIC: A Programmer's Guide" by Jonathan E. Sisk is licensed under a Creative Commons Attribution 3.0 Unported License.
Based on a work at