HP 3000 Manuals HP 3000 Manuals
Database Management
Deleted Control Statements
The following statements are not supported in HP Business BASIC/XL:
DBCREATE
DBERASE
DBMAIN
DBPASS
DBRESTORE
DBSTORE
READ/WRITE DBPASSWORD
XCOPY
The functionality of many of these statements is contained in stand-alone
programs on the HP 3000, such as DBUTIL and DBSTORE. Refer to the
IMAGE/3000 manuals for more information. These statements will be marked
by the migration aid, and changed to comments if they are read into the
HP Business BASIC/XL interpreter.
IN DATA SET
Unsupported Statements. Several forms of IN DATA SET are not implemented
in HP Business BASIC/XL, and so their use should be avoided. Many of
these statements are very costly at run-time on the HP 260, so using
alternatives may improve performance there as well. The unsupported
statements are:
IN DATA SET DIM ALL
IN DATA SET USE ALL
IN DATA SET IN COM
IN DATA SET USE REMOTE LISTS
IN DATA SET LIST
IN DATA SET FREE
Static vs. Dynamic Statement. The IN DATA SET statement in BASIC/260 is
a dynamic, run-time binding of the data set to DBGET, DBPUT, SEARCH, SORT
and other database statements. In other words, these statements use the
most recently executed IN DATA SET for determining which data set to read
or write.
HP Business BASIC/XL does not support this usage. Instead the DBGET
USING, SORT, SEARCH, and other statements refer to IN DATASET statements
via statement labels (just as PRINT USING refers to an IMAGE). This is
done so that the statements can be compiled.
The change from dynamic to static IN DATASET statements must be done
manually. In order to help yourself do this, document which IN DATA SET
statement is used by each database statement. An additional aid is to
put a line label on each IN DATA SET statement. At migration time, the
database statements can be changed to use the IN DATA SET statement
indicated by the comment.
Typical HP 260 Program:
Ids1: IN DATA SET "XYZ" USE A, B, SKP 5, C
DBGET (Dbas$, Dset$,......, Buf$) ! Uses Ids1
.
.
Ids2: IN DATA SET "ABC" USE A, B, SKP 6, D
DBGET (Dbas$, Dset$,...., Buf$) ! Uses Ids2
After Conversion:
Ids1: IN DATA SET "XYZ" USE A, B, SKIP 24, C
DBGET Dbas$ USING Ids1;....
.
.
Ids2: IN DATASET "ABC" USE A, B, SKIP 30, D
DBGET Dbas$ USING Ids2;....
Difficult HP 260 Program:
IN DATA SET "ABC" USE A, B
GOSUB Dbase_get
...
IN DATA SET "XYZ" USE A, Z$
GOSUB Dbase_get
...
Dbase_get:
DBGET(Dbas$, Dset$, mode, S(*), Buf$, Arg)
In the last example, the DBGET could work on any number of data sets and
retrieve vastly different data. Portability demands that this type of
coding be avoided. In this case, replace the GOSUB with a specific DBGET
statement, using the IN DATASET beside it. Alternatively, only use the
DBGET with specific PACK/UNPACK statements.
The section on DBGET below discusses some specific problems caused by the
differences in IN DATA SET.
Replacement Considerations. Many HP 260 programmers use DIM ALL or USE
ALL for use with all database statements, usually without considering the
cost. These statements are very costly at run time. In addition, the
statements are not accepted by HP Business BASIC/XL.
Although an IN DATA SET LIST with all variables may be used to replace
the statements above, this is probably not a good idea. In many cases,
unpacking or packing all the variables is unnecessary and causes poor
performance. Instead, define IN DATA SET statements which refer only to
those variables needed from the database. (This applies to SEARCH and
SORT as well as the DB statements.) In HP Business BASIC/XL, this can
result in very large code savings.
In addition, try to use the same IN DATA SET statement repeatedly,
especially after migration. HP Business BASIC/XL associates code with
the statement if it is used multiple times. The more the IN DATASET is
used, the greater the potential savings.
PACK/UNPACK
PACK/UNPACK provides the most compatible way of packing and unpacking
variables into a database buffer. These statements will work the same in
both versions of BASIC. As with IN DATASET, it is not necessary to PACK
and UNPACK every variable every time; better performance can be obtained
by specifying only the variables needed in the PACKFMT statement. Also,
using the same PACKFMT or IN DATASET repeatedly will save code space.
Programs are more portable when using PACK/UNPACK than when using DBGET
USING.
NOTE One very common source of errors with PACK is to forget to SKIP to
the end of the buffer after the last variable. This clears the
remainder of the buffer instead of keeping the old contents. Be
sure that the PACK really packs what you expect it to!
DBGET/DBUPDATE
There is a compatibility problem with a common DBGET/DBUPDATE sequence
when translated to HP Business BASIC/XL. A BASIC/260 program often uses
an IN DATA SET for all the variables a program needs, usually most of a
dataset; these variables are put into a buffer and implicitly unpacked.
Sometime later, a new IN DATA SET is activated which has only those
variables which have changed. A DBUPDATE is then issued to update the
database. IMAGE/260 only updates the variables mentioned, even if a SKIP
is not included at the end of the IN DATA SET.
IN DATA SET "XYZ" USE A, B, SKP 5, C
DBGET (Dbas$, Dset$,..., Buf$)
...
<update variables>
...
IN DATA SET "XYZ" USE <changed variables only>
DBUPDATE$ (Dbas$, Dset$,..., Buf$)
However, DBGET USING creates a temporary buffer to do the unpacking; at
the end of this statement, the buffer is thrown away. This means that
the DBUPDATE statement can not replace only the changed variables; the
buffer it uses will have random data for the other variables.
To be compatible, do not use the above technique in a DBGET/DBUPDATE
sequence. Always use DBGET without an IN DATA SET and do explicit
unpacking; use explicit packing for the DBUPDATE. This method will be
fully compatible.
DBINFO
IMAGE/260 allows the user to spread the database files over multiple
volumes. There is no analogous concept in IMAGE/3000. Associated with
this, the DBINFO statement of IMAGE/260 has a "400" class of inquiries
about volumes that is not supported in IMAGE/3000. (IMAGE/3000 uses mode
401 to get logging information.)
When migrating to HP Business BASIC/XL, check all programs containing
DBINFO statements, as the information returned is not always in the same
format as BASIC/260. There is no way to be completely compatible. The
best that can be done is to keep DBINFO well documented and in well
defined places.
DBCLOSE
IMAGE/3000 does not allow an empty database name in DBCLOSE, so HP
Business BASIC/XL gives an error for this condition. Always specify the
database name in order to increase portability.
DBCLOSE using mode 4, which causes buffers to be flushed in IMAGE/260, is
not available at all. The intrinsic DBCONTROL must be used instead.
There is no HP Business BASIC/XL statement to do this.
DBFIND
BASIC/260 allows the argument value for the KEY to be of any type. HP
Business BASIC/XL requires that the key variable be the same type as the
key item in the database. A status error 53 results if this requirement
is not met.
For portability, make sure that the argument value is the exact type
needed. Alternatively, use the type builtins when passing the key to the
database; this requires manual change to the DBFIND statement.
DBLOCK
As mentioned previously, the HP 3000 does not automatically allow
successive calls to DBLOCK without a prior DBUNLOCK. The user must have
MR capability to do this at all, and many users prefer not to have this
set, as it allows for a deadlock situation. Only a system shutdown can
free the processes. Try not to write programs which will require MR
capability to use multiple locks.
The PREDICATE statement does provide for multiple locks within one DBLOCK
statement. This works on both the HP 260 and the HP 3000. Applications
which do not currently use PREDICATE can benefit from its use.
A small incompatibility exists between IMAGE/260 and IMAGE/3000. On the
HP 260, a second DBLOCK statement can be issued to lock a subset of the
first DBLOCK. For instance, a DBLOCK may lock an entire dataset; a second
DBLOCK can be issued to lock a single entry of that dataset. IMAGE/260
recognizes that the second DBLOCK is already fulfilled and grants the
lock; IMAGE/3000 does not recognize this. The status word returned by
IMAGE/3000 reports error 23, meaning the dataset is already locked.
Avoid this problem by not using DBLOCK for finer granularity, or do a
DBUNLOCK before issuing the second DBLOCK.
PREDICATE
IMAGE/3000 restricts the PREDICATE operators to the =, >=, and <=
relations. Use only these operators in order to maintain portability.
Some BASIC/260 applications use a central database locking routine; such
routines are generally passed the relational operator and the item value.
However, two aspects of HP Business BASIC/XL may force the program to be
changed.
First, HP Business BASIC/XL syntax includes the relation operator
directly, as opposed to the string used in BASIC/260. Thus the new
routine must have several PREDICATE statements, with some way to choose
the correct statement. A SELECT block is useful for this purpose.
Second, the expression for the item value must be the same type as the
actual item. This may require the addition of some type of migration
code in the generalized routine.
HP 260 Subunit:
SUB Set_up_pred(Pred$, Relation$, INTEGER Value)
PREDICATE Pred$ FROM "MYSET","PART-NO",Relation$,Value
SUBEND
HP Business BASIC/XL Subunit:
SUB Set_up_pred(Pred$, SHORT INTEGER Relation, Value)
SELECT Relation
CASE 1
PREDICATE Pred$ FROM "MYSET" WITH "PART-NO">=Value
CASE 2
PREDICATE Pred$ FROM "MYSET" WITH "PART-NO"=Value
CASE 3
PREDICATE Pred$ FROM "MYSET" WITH "PART-NO"<=Value
CASE ELSE
DISP "Selected relation not allowed."
ENDSELECT
SUBEND
Status Array
The status array must be exactly ten elements long. Either declare the
array explicitly, e.g. S(1:10), or use OPTION BASE 1 (with declaration
S(10)).
Many of the values in the status array will be different. This is due to
the differences between IMAGE/260 and IMAGE/3000. However, programs must
still be modified to use these changes. Some specific changes are given
here. Refer to the HP Business BASIC/XL Reference Manual for more
information.
Word 7 of the status array no longer returns the erroneous line number
when a database error occurs. This is because IMAGE/3000 is a standalone
subsystem. Avoid use of this word in order to be more portable.
Since IMAGE/3000 can have more than 65535 entries in a data set, it must
use 2 words in the status array for addressing. Fortunately, IMAGE/260
does not use these words and leaves them zero. Thus, HP 260 programs can
be modified to be completely compatible with HP Business BASIC/XL.
Words 4, 6, 8, and 10 are used by HP 260 as database pointers.
IMAGE/3000 uses 2 words for each of these. For instance, words 3 and 4
represent the current record pointer. So, to provide correct access, use
the following formula:
For S(4), substitute
S(3)*65536 + FNCorrect(S(4))
(FNCorrect is the correction routine for negative numbers; refer to the
IMAGE/260 manual.)
Naturally, one can define a function (either single line or multiline) to
perform this calculation. With such a function, the desired status array
word can be passed as a parameter. For example:
DEF INTEGER FNDb_stat_val(SHORT INTEGER S(*), Stat_word)=
S(Stat_word-1)*65536+FNCorrect(S(Stat_word))