HP 3000 Manuals

Program Control [ HP Business BASIC/XL Migration Guide ] MPE/iX 5.0 Documentation

HP Business BASIC/XL Migration Guide

Program Control

This section discusses aspects of program control that are different in
HP Business BASIC/XL, including differences in statements and differences
in source code management methods. Statement differences are usually
small. Source code management methods must often change during
migration.

Statement Differences Used in Program Control

The following program control statements are different in HP Business
BASIC/XL.

FOR-NEXT. BASIC/260 FOR and NEXT statements can occur anywhere,
including on a single line IF statement. This means a program can have
more FOR statements than NEXT statements and vice-versa. These
statements are matched during run time.

HP Business BASIC/XL FOR-NEXT statements are structured statements,
similar to WHILE-ENDWHILE statements; FOR and NEXT cannot appear in a
single line IF statement and each FOR must have exactly one matching
NEXT. As with the other structured statements, the end of the loop cannot
overlap another structured statement.

Manually change FORs and NEXTs that appear in single line IF statements.
A simple change is shown below; programs that actually use this construct
are often more difficult to follow and should be examined closely.

Table 17-4. Example of FOR NEXT Change

---------------------------------------------------------------------------------------------
| | |
| BASIC/260 Program Segment | HP Business BASIC/XL Program Segment |
| | |
---------------------------------------------------------------------------------------------
| | |
| IF Debugging THEN FOR I=1 TO 10 | IF Debugging THEN FOR I=1 TO 10 ... ENDIF |
| | |
---------------------------------------------------------------------------------------------
| | |
| IF X THEN NEXT J | IF X THEN Nextj ... Nextj: NEXT J |
| | |
---------------------------------------------------------------------------------------------

For increased compatibility, do not use FOR or NEXT on a single line IF
statement.

EXIT IF. The EXIT IF statement, which exits a LOOP-ENDLOOP structure, is
part of the structured statement in HP Business BASIC/XL. This situation
is similar to the ELSE of the IF-ELSE-ENDIF structure. EXIT IF
statements cannot appear in a single line IF statement in HP Business
BASIC/XL. A translation is shown here:

Table 17-5. Example of EXIT IF Change

To be compatible, change the BASIC/260 EXIT IF statement so it uses an
AND instead of a single line IF statement.

ON DELAY and INPUT. HP Business BASIC/XL does not have an ON DELAY
statement. The HP 3000 does not support the construct. However, ON
DELAY is often used for timed inputs in BASIC/260. HP Business BASIC/XL
provides a new statement, TINPUT, for timed inputs. In addition, HP
Business BASIC/XL has a TIMEOUT clause in the ACCEPT statement that
allows timed input.

The ON DELAY statement is marked "untranslatable." Examine marked ON
DELAY statements to see if the statement is for a timed input or for
another purpose. Table 17-6 shows corresponding BASIC/260 and HP
Business BASIC/XL timed input:

Table 17-6. Corresponding BASIC/260 and HP Business BASIC/XL Timed Input

Document ON DELAY and OFF DELAY statements; indicate that the statements
are used for a timed INPUT. This makes the migration easier.

COMMAND. The COMMAND statement is not allowed as a command in HP
Business BASIC/XL. The COMMAND statement is only allowed in program
lines. Nested COMMAND statements are not allowed.

In addition, the COMMAND statement is not compilable. The interpreter's
performance is often too slow for production programs, so avoid using
COMMAND. If you can not avoid using this statement, consider using a
compiled application to do a SYSTEMRUN of the interpreter; then you can
have this process use the COMMAND statement when needed. The two
processes can communicate either through the INFO string or through
files.

Document every COMMAND statement, particularly those with HP 260-only
statements. The migration aid can not translate or flag the commands
because literals are ignored and variable values are unknown.

Flow Control

The GET, MERGE, and LINK statements are not compilable. Do not use these
statements in final production programs. Manual changes are usually
needed to produce better programs.

CALL and GOSUB. BASIC/260 CALLs and GOSUBs remember which line was after
the calling line. This line executes upon return from the subroutine or
subprogram. However, if you add lines between the calling line and the
remembered line, the remembered line will not execute upon return from
the call.

HP Business BASIC/XL remembers the actual calling line; you can add or
merge lines immediately after the CALL or GOSUB. These lines execute upon
return from the subroutine or subprogram. CALLs and GOSUBS.

CALLs and GOSUBS are only incompatible if they MERGE lines immediately
after the CALL or GOSUB statement while the CALL or GOSUB is still
active. Avoid these kinds of dependencies.

GET/MERGE/LINK. HP Business BASIC/XL and BASIC/260 work differently with
the GET, MERGE, and LINK commands. The difference is which line executes
after the command has finished. The processes are the same.

In HP Business BASIC/XL, the MERGE statement does not execute a line that
replaces a MERGE statement; instead, the next line executes. BASIC/260
executes the line that replaces the MERGE. This difference is only
noticeable if MERGE does not specify an explicit line number to resume
execution at.

HP Business BASIC/XL MERGE statements can overwrite themselves.

In HP Business BASIC/XL, a programmatic GET always starts execution at
the first line of the program. This is true even if the GET appears in
the MAIN of the program and some lines are not deleted. BASIC/260
executes the line that replaces the GET (or the line after the GET) if
the statement is in the main program unit. This also applies to the LINK
statement.

To be compatible, always specify the line number to resume the MERGE
statement at. Always replace the entire program when you use a GET
statement, even if that requires extra code in the program you are
getting.

ON DELAY. This statement is not implemented in HP Business BASIC/XL.
When used only for timed INPUT, a translation is available (see previous
description). Otherwise, modify the program another way so it works
correctly.

Always document the purpose of ON DELAY. If you are using ON DELAY for
timed INPUT, you can use the change shown previously. If you are using
ON DELAY for another reason, the comments will indicate that you might
need to redesign the segment.

COMMON Used in Program Control

There are substantial differences between the BASIC/260 COMMON statement
and the HP Business BASIC/XL COMMON statement. The COMMON statement
works the same in a single program file, but works differently across a
GET.

Be sure to read every section about common blocks in the HP Business
BASIC/XL Reference Manual. These describe the details of working with
multiple programs and multiple common blocks.

Named Common. HP Business BASIC/XL supports named commons. A single
program file can use up to 10 named areas, plus unnamed (or blank) common
areas. Applications that use multiple program files might be able to
take advantage of these names to enhance communication or to reduce the
storage needed by programs.

Definitions. Each program in an application that uses COMMON must fully
define the COMMON in its main program unit. In BASIC/260, the length and
dimension information is not maintained; in HP Business BASIC/XL, length
and dimension information is required in each main program unit. You can
not define new common blocks in a SUB or in a multiline function.

To be more compatible, always fully define COMMON in the main program
unit of every program. Programs that only contain SUB definitions are
easy to fully define. The LOAD SUB statement does not load any code from
the main unit. To aid in this process, put the common definitions in a
file and merge it with each program that needs the definitions.

Common Block Growth. HP Business BASIC/XL does not allow commons to grow
after they are defined by the main program unit of the application's main
program. BASIC/260 lets the common grow and shrink across programmatic
GET statements.

To work around this, consider using a named common for the new area. You
can only use this new common in the program you GET. Or it can be defined
in the main program and the new program. This approach will help isolate
variables needed for specific areas of an application.

Source Management in Program Control

Terminology. An application is a set of one or more programs that the
you run. Each program is called a subprogram. Each subprogram resides
in its own file. The subprogram that starts the application (often a
menu controller) is called the main subprogram.

Each program file includes a normal HP Business BASIC/XL program. This
program consists of one or more subunits. There is always a main
subprogram. There can also be sub procedures and multiline functions
(also called multiline DEF's).

On the HP 260, LOAD moves from one subprogram to another. LOAD SUB reads
subunits (except for a MAIN subunit) from a program file and appends them
to the current program. In HP Business BASIC/XL, use GET and GETSUB
instead.

External Declarations. The compiler only knows about the names of
subunits within the current program. In order to call a subunit (or a
subprogram) in an SL file, an external declaration is required. This
external declaration can be local to the subunit or a global external).
You can not include these declarations as code in a BASIC/260 program,
but including these externals as comments not only provides easier
migrations, but provides useful documentation for BASIC/260 calls.
During migration, manually remove the comment marker (REM or !) and the
external is declared.

GET Statement. Statements that change the source lines in a program
cannot be compiled. These statements include both GET and GETSUB.
However, you do not need GETSUB in compiled programs because every
subunit is compiled into the application (or into a library used by the
application).

Change the GET statement into a CALL. The CALL is made to the main
subunit of the subprogram. All data from the current program is retained
and stack space is still used. This is different from a GET, which does
not retain local variables and resets the call stack in the interpreter.
Also, the called subprogram returns; you might want to include a STOP
after the CALL statement. For example:

Interpreted Program ABC: (main subprogram)

10 CALL A
20 GET "MYSUBPG"
100 SUB A
110 PRINT "In sub A"
120 SUBEND

Interpreted Program MYSUBPG: (subprogram)

10 PRINT "In MYSUBPG"
20 CALL B
30 END
100 SUB B
110 BEEP
120 SUBEND

In the interpreter (or on the HP 260), when ABC runs, the message "In sub
A" prints and control moves to MYSUBPG. Program ABC is gone; so are any
local variables it used. The local variables for the main subunit in
MYSUBPG were created. As the program continues, a BEEP executes. When
END executes in MYSUBPG, everything stops and MYSUBPG stays in the
interpreter.

The migrated programs follow. A description of the flow control for the
compiled programs appears afterward.

Interpreted and Compiled Program ABC: (main subprogram)

10 CALL A
20 IF INTERPRETED THEN
30 GET "MYSUBPG"
40 ELSE
50 EXTERNAL Mysubpg ALIAS "MYSUBPG"" ! Call the MAIN subunit
60 CALL Mysubpg
70 STOP ! Because calls return
80 ENDIF
100 SUB A
110 PRINT "In sub A"
120 SUBEND

Interpreted and Compiled Program MYSUBPG: (subprogram)

10 PRINT "In MYSUBPG"
20 CALL B
30 END
100 SUB B
110 BEEP
120 SUBEND

Notice the external definition in program ABC. For main subunits, HP
Business BASIC/XL uses the filename of the program and appends two single
quotes. The EXTERNAL statement relates a legal subunit name to the name
that MPE knows, so it can be called.

After the message "In sub A" appears, the compiled program makes a CALL
to MYSUBPG. The local variables from ABC still exist, and the call stack
is not cut back. The compiled program MYSUBPG" executes, calling subunit
B. However, when the END statement at line 30 executes, the application
does not stop. Instead MYSUBPG returns to its caller, ABC. For this
reason, ABC executes a STOP after the call.

If you wanted the program, MYSUBPG, to return to ABC, you would use a GET
in the interpreted source. However, the compiled program does this
automatically, so you can leave the GET out of MYSUBPG. Removing the STOP
in program ABC lets the main subprogram continue executing.

MPE/iX 5.0 Documentation