HP 3000 Manuals HP 3000 Manuals
Appendix A Migration Checklist
This appendix contains a checklist to help you migrate Pascal/V programs
on MPE V to HP Pascal/XL on MPE XL. There should be few, if any, changes
to make in migrating a program to an MPE XL based system if there is not
much reliance on HP extensions or machine-dependent features in the
existing code.
Programs that conform to the HP standard should run on MPE XL systems
with no errors. If you have any doubts, use the following checklist to
double-check your programs.
1. Use the MPE STORE and RESTORE commands to transfer your
Pascal/V source files on MPE V by tape to the MPE XL
based system.
2. Check each Pascal/V program by answering the following
questions. Does the program
| a. | Depend on data overlays | yes no ?
| b. | Depend on a particular data alignment | yes no ?
| c. | Call intrinsics using EXTERNAL rather than | yes no ?
| | INTRINSIC |
| d. | Call intrinsics that have function returns | yes no ?
| | that were 16-bit integers on MPE V, such as |
| | FOPEN |
| e. | Have its own intrinsic file | yes no ?
| f. | Call external routines written in other | yes no ?
| | languages |
| g. | Use data files shared by non-migrating | yes no ?
| | applications |
| h. | Use other subsystems such as VPLUS or Image | yes no ?
| i. | Use existing non-text Pascal data files | yes no ?
| j. | Depend on any non-detection of a Pascal error | yes no ?
| k. | Use GETHEAP and RTNHEAP | yes no ?
| l. | Call external routines in an SL | yes no ?
3. If you answered "no" to all the above questions, compile
your program and try to run it without changes. It
should run.
4. If you answered "yes" to any of the above, take the
following actions. Each action has an alphabetic
correspondence to one of the preceding questions.
a. If the overlays are not in structures with pointers or files, you can
compile the program with HP3000_16. Otherwise, the program must be
modified for the packing differences or run in compatibility mode.
b. If pointers or files are not used in the structures that have the
dependency, HP3000_16 can be used. Otherwise, the program must be
modified for the packing differences or run in compatibility mode.
Also, in many cases it is possible to devise different type
definitions that cause the same layout in both Pascal/V and HP
Pascal/XL.
c. The program must be modified to change "EXTERNAL" to "INTRINSIC" .
This is necessary, because in many cases the actual parameters passed
to the INTRINSIC have changed even though the interface looks the
same. The compiler gets the "real" definition from the intrinsic.
d. The intrinsic return type must be changed to the predefined type
shortint. Remove any definitions of shortint from the program.
e. The intrinsic file must be ported. It needs to be rebuilt in the HP
Pascal/XL compiler using BUILDINT. Also, the routines in the
intrinsic file need to be ported to native mode or have native stubs
created for them. This is necessary if the SPL routines cannot be
ported or if they are shared by programs being run in compatibility
mode. Refer to the Switch Programming manual for information about
the creation of native mode stubs.
f. The interfaces to routines written in other languages need to be
examined for compatibility problems caused by data alignment changes.
In general, simple parameters such as integers, reals and so on are
not affected. If structures, such as records, are being passed that
other routines know about, the structures must be checked for correct
layout. HP3000_16 may or may not solve the problem, depending on
what is changed in porting the other routine. Problem areas include:
* Strings (32-bit current length rather than 16 bits)
* Sets
* Integer subranges by VAR are 16 bits in Pascal/V. In HP
Pascal/XL, 8-bit or 32-bit values may now be passed. If 16 bits
are still required, use the predefined type shortint. This is a
16-bit signed integer on HP Precision Architecture machines. The
subrange 0...n (where n > 255 and <= 65535) is also allocated 16
bits.
g. HP3000_16 guarantees that the layout is the same, assuming that there
are no pointers in the file.
h. Changes may have to be made for the respective subsystem. Refer to
the appropriate subsystem document for information on necessary
changes.
i. If the type of the file has the same layout and does not contain
strings, sets, pointers, reals, or user-defined subranges, the same
file can be used with no changes. Otherwise, there is a choice.
Either access the file using HP3000_16 or convert the file as
described in Chapter 3.
NOTE Accessing the file using HP3000_16 does not work if the file type
contains pointers (see the note in Chapter 3).
j. The most common non-detected errors involve turning
parameter or range checking off, as well as dependence
on data overlays. Non-detection of an error does not
imply that you can successfully compile your Pascal/V
program on an MPE XL based system using HP Pascal/XL.
The results are unpredictable. The Pascal/3000
Reference Manual and the HP Pascal Programmer's Guide
contain information on non-detected errors.
k. No change is necessary. GETHEAP and RTNHEAP are
provided in the HP Pascal/XL run-time library. However,
you may wish to change the code to call the new routines
P_GETHEAP and P_RTNHEAP. The new routines have increased
functionality, allowing the caller to specify the
alignment of the area requested.
l. The routines in the SL need to be moved to a native mode
XL. If they are not written in Pascal, the same action
is required as in item f. If the routines must be left
in compatibility mode, the stubs must be created for
them. There are some differences between SLs and XLs
that can cause problems in porting. SLs cannot have
global data, whereas XLs can have their own global data
separate from the calling procedure. However, a routine
in an SL can have access to the calling procedure's
global data if the shared data happens to be at the same
DB location. This can be done by compiling the program
and the SL routine with the same outer block. The
routine that goes in the SL is compiled with
$SUBPROGRAM$.
NOTE The practice described above is rarely done on MPE/V because it is
no different than initially compiling the routine as part of the
program.
Some Pascal/V users have taken advantage of the fact that program
parameters such as INPUT and OUTPUT share the same DB location if
declared in the same order. Routines compiled this way in the SL can do
Pascal I/O to INPUT and OUTPUT if called by a Pascal process that
declares INPUT and OUTPUT in the same order.
The above cannot be done on MPE/XL. The linker will produce an error
message when putting the routine into an XL. To solve the problem, do one
of the following:
* Put the routine in an RL instead of an XL.
* Link the routine with the program.
* Rewrite the routine to pass a file in.
NOTE Leaving the routine in the CM SL and writing a switch stub will not
work.
1. Each type of action recommended in step 4 is classified
below:
| a,b | - - | Program inspection is required.
| c | - - | The program does not load. There is a loader error on
| | | the named external.
| d | - - | An error is reported when the program is compiled. This
| | | identifies the places that need to be changed. Make sure
| | | shortint is not declared in the program. If so, this
| | | declaration must be removed or changed to something else.
| e | - - | Program does not compile because the intrinsic file could
| | | not be found or read.
| f | - - | Program inspection is required. You should declare them
| | | External <lang>. Such declarations are easy to find with
| | | an editor.
| g | - - | Decide if HP3000_16 can be used.
| h | - - | Can be determined by editor inspection. Hopefully, you
| | | have declared them as Intrinsic.
| i | - - | Can be determined by editor inspection for the
| | | declaration. Generally, files exist if they are passed
| | | in as program parameters and opened with RESET, APPEND,
| | | or OPEN. Also, they may be opened with RESET, APPEND, or
| | | OPEN using a file name parameter.
| j | - - | Turn all checking back on. Inspect variant records,
| | | especially those with tagless variants for their use.
| k | - - | No action is necessary.
| l | - - | An error occurs at link time or when a procedure is added
| | | to an XL.
2. If you still have problems, here are some helpful hints:
a. Uninitialized variables - - The stack area in memory on MPE V based
systems is initialized to zero at the beginning of program execution.
On MPE XL systems, the stack area is not initialized. Any undefined
variable can be assigned a non-zero value. This is particularly
troublesome if you use string data types and do not initialize the
string to the null string before doing a StrWrite or StrMove.
b. Alignment problems when passing parameters - - If checking is turned
off using CHECK_ACTUAL_PARM or CHECK_FORMAL_PARM, a parameter can be
passed on an MPE XL system that will fail a run-time or compile-time
alignment check. In general, you cannot pass an actual parameter
that is less strictly aligned than the formal reference parameter.
Something byte aligned cannot be passed to a word aligned parameter.
However, something word aligned can be passed to a byte aligned
parameter.