
This article is reprinted from the December 1990 edition of TechNotes/dBASE
IV.  Due to the limitations of this media, certain graphic elements such as
screen shots, illustrations and some tables have been omitted.  Where
possible, reference to such items has been deleted.  As a result,
continuity may be compromised.  

TechNotes is a monthly publication from the Ashton-Tate Software Support
Center.  For subscription information, call 800-545-9364.

From DOS to VMS
Porting dBASE IV programs

Portia Shao

dBASE IV programs written in the DOS environment are generally portable to
VMS; that is to say, once you translate your files to the VMS platform, the
dBASE commands between the two environments are, for the most part,
congruous. There are some areas, however, that are not portable and other
areas that should be changed for performance considerations.  

Setting Up the Environment

DOS environment variables meaningful in the VMS environment have equivalent
VMS logical names.  However, we do have a few which are VMS only.  All VMS
logical names used by dBASE IV are prefixed with DBASEIV with an underscore
suffix, for example, DBASEIV_PATH.  

dBASE System Files and File Compatability

The .res, .gen and .hlp files are considered to be dBASE system files. 
They must reside in the path defined by the DBASEIV_ PATH logical name. 
The first one found in the search list will be used.  This makes it
possible for each user to have his own private version of these system
files.  There should be no reason to have your own .hlp file.  

If you use the dBASE Template Compiler (DTC) to create your own .gen files,
then you may place the directory where they reside first in the search list
of DBASEIV_PATH.

You do not need your private dBASE IV resource files unless you use the
Applications Generator, and wish to save your own PRESETS.  You may use
DBSETUP to copy the dBase2.res and dBase3.res files into your directory, or
you may just issue the COPY command to copy them from DBASEIV_SYSTEM:. 
There should be no reason to have private dBase1.res.  

The potential problem with having your own .res files is that you may need
to re-copy them when a new version of dBASE IV is installed.  

All dBASE files, .dbo, .dbf, .mdx, etc, are binary-compatible between DOS
and VMS.  A few exceptions will be noted below.  

Networks Supported

You can use VMS as a network file server via DEC's PCSA, DEC's
VMS/Ultrix-Connection, or TGV's MultiNet NFS (and probably others not
tested by Ashton-Tate).  The files can reside on the VAX/VMS disk, and are
accessible to the PC user (using either DEC's PCSA or SUN's PC/NFS).  The
files are compatible and can be used by both the DOS and VMS dBASE user, no
conversion is necessary in this configuration.  

However, since there is no locking method common to all these different
network implementations, the files can not be shared concurrently between a
dBASE user on the PC, and a dBASE user on the VAX/VMS system.

On VAXcluster systems, running the Multi-user version of dBASE IV, you can
share files with other dBASE users on the same cluster as long as the VMS
file protection allows the access.  

Transferring Files To and From MSDOS

Many different communications facilities between MS-DOS and VMS exist. 
Your system or network manager should be able to tell you what is available
to you.

To migrate a binary data file, such as .dbf, .dbt, .mdx, .ndx, .qbe ,.scr,
.frm, .dbo, .app, and so forth, dBASE IV requires only that the
communications medium not change the data in the file in any way and that
the actual size of the file (in bytes) remain the same.  This generally
requires a binary or image type of transfer.  

Text files, such as program source (such as .prg, .frg, and .lbg) or ASCII
data may be transferred between MS-DOS and VMS as a text transfer.  

PCSA

If your VMS system provides MS-DOS services for the PC using PCSA, then you
can simply use the MS-DOS COPY command on the PC to copy the files from
your local hard or floppy disk to a network disk on the VMS PCSA server. 
PCSA preserves proper RMS Record Formats for PC files on VMS, requiring no
additional conversion for dBASE IV/VMS.  

NFS

If your VMS system provides NFS services through the VMS/Ultrix Connection
(UCX) product or TGV's MultiNet, and the PC is configured as an NFS client,
you may use the MS-DOS COPY command on the PC to copy the files from your
local hard or floppy disk to an NFS mounted filesystem on your NFS server. 
No conversion is necessary.  

DECnet

If your PC and VMS systems are connected via DECnet, then you may use the
NFT command on the PC to put the PC in File Access Listener mode, and copy
the files over  from the VAX using the VMS DCL command: 

                $ EXCHANGE/NETWORK-
                /FDL=dBASEIV_SYSTEM:STREAM -
                PCnode::file VAXnode::file

KERMIT

With MS-Kermit on the PC and Kermit-32 on the VAX, the following procedure
will transfer your binary and text files correctly.  Note that all the
attribute setting steps are necessary for Kermit to transfer the file
correctly.  Other utilities may require different settings.  

Use MS-kermit on your PC to log on the VAX, then run kermit on your VAX:

                Kermit-32> set file type binary
                Kermit-32> server

On the PC, enter

                MS-Kermit> set file type binary
                MS-Kermit> send xyz.dbf

or

                MS-Kermit> send xyz.*
                MS-Kermit> finish

On the VAX, enter

                Kermit-32> exit

Repeat the following for all files.

                $ CONVERT/FDL=DBASEIV_SYSTEM:UDF -
                xyz.dbf xyz.dbf
                $ DBASE/FILE/TYPE=STREAM xyz.dbf

If you are copying files from VAX to PC using Kermit, you must first set
the file attributes of the files using

                $ DBASE/FILE/TYPE=UNDEFINED/ATTR=NO/IMPLIED CC XYZ.*

                Kermit-32> set file type binary
                Kermit-32> server

On the PC, enter

                MS-Kermit> set file type binary
                MS-Kermit> get xyz.*

On the VAX, enter

                $ DBASE/FILE/TYPE=STREAM xyz.*

Others

You may try using other communications utilities to  transfer files.  dBASE
only requires that the data in the file and the actual size of the file (in
bytes) not be changed by the  file transfer utility.  This will likely
require that you specify a binary or image type of transfer.  Once the
files are on VMS, you should set the RMS Record Format of all files to
STREAM with

                $ DBASE/FILE/TYPE=STREAM filename

This procedure (binary transfer then force Record Format to STREAM) can be
performed for both text and binary files.

Please note that some communications programs may pad the records, pad
end-of-file to a block boundary, or do other bad things.

Filenames

dBASE IV keeps filenames in some files like .cat, .prf.  If the file is not
in the current directory, it places the directory path in the file also.   

dBASE IV on VMS will put VMS-style path in the file, and dBASE IV on  DOS
will put a DOS-style path in the file.  dBASE IV on VMS is capable of
translating DOS path to VMS equivalent, but dBASE IV 1.1 on DOS knows
nothing about VMS-style path information.  The lesson here is this: it is
best to keep all related files in the same directory, and use SET DIRECTORY
TO command to change  directories.  If not, the files containing VMS paths
will NOT  work for dBASE running on DOS.  This is a problem if the files
are on a VMS network file server, and the DOS user is using the file on
VMS.   

Let's have a quiz: what is the equivalent VMS filename for a filename
hardcoded as

                D:\ACCTNG\PAYABLE\ACCOUNTS.DBF?

The answer should be

                D:[ACCTNG.PAYABLE]ACCOUNTS.DBF

Now if [ACCTNG] is the top level directory on your disk DUA0:  (which you
must have a logical name D: defined to point to), and you have ACCOUNTS.DBF
in the [ACCTNG.PAYABLE] directory, all is well.  However, if you have no
control over where [ACCTNG] is  placed, you may want to define a rooted
logical name like  

                $DEFINE/TRANSLATION=CONCEAL -
                D DUA0:[USER.]

so [ACCTNG] will appear as the top level directory in drive D.

It is also possible that the .prg file contains explicit reference to a DOS
filename.  This will be translated to VMS filename at run time.   

Floating Point Precision

We use the VAX G-float format for floating point numbers on the VAX.  The
precision of G-float is 15 digits ranging from .56e-308  to .9e308.  This
is different from the IEEE long float format  used on IBM PCs and clones
(whose precision is also 15  digits with a range of 2.23e-308 to 1.8e308)  

For strict compatability, do not use FLOAT data or operations which will
result in FLOAT answers in any file.  All numbers in .dbf files are stored
in ASCII, but Float numbers are stored in FLOAT in .mdx files and converted
to BCD in .ndx files (NUMERIC  types are always in BCD format).  This means
that if you use a  FLOAT expression to index into a .mdx file, the result
may not be exactly the same between VAX and your PC.   

SET DECIMALS TO a number greater than 15 for float operations is not
meaningful.  Even though the DOS version may display more digits than the
VMS version.   

PROTECT and Encryption

PROTECT is implemented on VMS.  The DBSystem.db file and the  encrypted
.dbf and other files are binary compatible with ones created on VMS.  You
may just copy them over to VMS or share them  on the network.   

A Database Administrator with suitable privilege can create the DBSystem.db
file in DBASEIV_PROTECT directory.  Once PROTECT is  enabled, all users on
the VAX/VMS system must log in through PROTECT.   

Operating System Differences

There are differences in behavior due to the nature of VMS.  Some  of these
may affect the execution of your program.  The OS() function would return
the VMS version number so it can be used to conditionally execute DOS
specific commands like the ! or RUN command.   

The ! or RUN command

Due to fundamental differences between DOS and VMS, if you use the ! or the
RUN command in your program, you may have to  modify the command.  Some
commands may work on VMS unchanged,  like DIR *.TXT.  Some may require you
to write a DCL command procedure to emulate what the DOS command does. 
There are yet some commands which may seem easy to translate but would not 
behave as expected, like  

                !CD \MYDIR\FINANCE

A simple conversion to

                !SET DEFAULT [MYDIR.FINANCE]

will not work.  This is because the ! or the RUN command spawns a
subprocess on VMS, changing the default directory for the subprocess does
nothing for the main process.   

We have a special case RUN SPAWN command which just puts you in the spawned
subprocess (the child, not the grandchild process).   

Error Conditions

Some error messages which were results of a VMS system call may return
additional VMS-specific error message.  Some operations which are not
possible on DOS are permitted on VMS.  For example, with multiple file
versions, a basic VMS  file system feature, you may compile a new .dbo
right on top of  one someone else may be using.  Or you may rename the .dbf
file another user has open.  None of these are considered errors by dBASE
IV.  Better human awareness and cooperation is required to  prevent
problems.   

Screen and Keyboard Differences

There are some basic differences on the keyboard and screen between the DOS
and the VMS world.  For example, we ignore the  SET BELL TO command.  Not
all graphic characters are displayed like in the DOS version.  On the VAX,
the double line displays as a single line and many unprintable characters
are displayed as *.   

There are many occasions where Escape is used to interrupt a lengthy
operation on the PC.  On VMS, you need to use the Ctrl-C  combination to
issue the interrupt.   

The Alt and Ctrl keys on the PC can not be mapped to the normal VMS
terminal without change.  dBASE IV function keys have been  mapped from the
PC keyboard to the VT200/VT300 LK201 keyboard as  follows in the table
below.  
Keyboard Differences
PC                      LK201 equivalent
F1                      Help
F2                      F7
F3                      F8
F4                      F9
F5                      F10
F6                      F11
F7                      F12
F8                      F13
F9                      F14
F10                     F17
NumLock                 F20     *see note 3
Ctrl-End                DO
ESC                     PF1
Kctl                    PF2     *see note 1
Kalt                    PF3     *see note 1
Kshft                   PF4     **see notes 1 & 2
Ins                     Insert Here
Del                     Remove
PgUp                    Prev Screen
PgDn                    Next Screen
Home                    Find
End                     Select

(arrow keys are the same)

Note 1: On the PC, the Alt, Ctrl and Shift keys are used like the LK201
Ctrl key.  That is, you use the key with another key at the same time.  For
the LK201 KALT, KCTL, and KSHFT, however, you use them as a prefix.  In
other words, press KALT (PF3) followed by E to get the effect of Alt-E. 
Use KCTRL (PF2) followed by KP7 to get the effect of Ctrl-Home.  Please do
not confuse them with the familiar Ctrl and Shift keys normally used on
VMS.   

Note 2: The KSHFT (PF4) key is used to emulate the PC Shift key for
functions such as Shift-Tab.  It is not used to get upper case characters.

Note 3: Toggles between Numeric and Applications keypad, in application
keypad mode, the number keys on the keypad behaves according to the keypad
diagram.  In NumLock state, the number keys give you the numbers as
marked.   

The VMS version of dBASE IV 1.1 does not support color.  This means that in
general, color settings are ignored along with commands like SET DISPLAY TO
EGA.

The monochrome attributes are supported: * for blink, X for blank, + for
bold, U for underline, and I for inverse video.

It is quite possible that you have commands like

SET COLOR OF NORMAL      TO W+/B
SET COLOR OF HIGHLIGHT   TO GR+/BG
SET COLOR OF MESSAGES    TO W/N
SET COLOR OF TITLES      TO W/B
SET COLOR OF BOX         TO GR+/BG
SET COLOR OF INFORMATION TO B/W
SET COLOR OF FIELDS      TO N/BG

in your program.  What is wrong with these commands?  Remember that the
colors are ignored, but the + attribute is not ignored.  So you end up with
the color of NORMAL, HIGHLIGHT and BOX all being displayed in bold.  If the
color of NORMAL and HIGHLIGHT are the same, would you see any highlights? 
The effect would be no visible cursor.  

So, what should you do?  If your dBASE program is to be truly portable, it
should set the colors conditional on the value of ISCOLOR().  By the way,
the same applies to a monochrome PC.  

Screen Size and Performance

Most PC monitors have at least 25 lines.  Most VTxxx terminals have 24
lines.  If your program writes to the 25-th line on the PC, then it would
have problem doing the same on a 24-line VT200 terminal.  

To allow these programs to work on a 24 line terminal, we have a logical
name DBASEIV_25TH_LINE.  When defined (to be anything), you can toggle
screen such that the lines displayed are 1 to 24 or 2 to 25 with the 25th
line toggle key (F19).  This is probably not what you want in a delivered
application.  It is best to not write to the 25th line.  If your users use
the DECterm emulator under DECwindows, you can set the terminal window to
25 lines.  

Excessive screen writing is more annoying on a terminal than on a PC with
memory mapped display.  

Printing

While running dBASE under VMS, you can print to a file, a local printer
(connected to the printer port of your VTxxx), a QUEUE or a DDIF format
file.  The DOS device names such as LPT1, COM1, COM2 are treated as logical
names for queues.  Network destinations are not supported.  

If there is a SET PRINTER TO command in the program which references a DOS
device, or uses the \\ syntax, they would have to be changed to one of the
allowable VMS printer destinations.   

Multi-user vs. single-user

dBASE IV on VMS is multi-user by default.  It is possible to revert back to
the single user behavior by using the /NOMULTIUSER command qualifier when
you invoke dBASE IV.  This is the way to run your single-user applications
without having to change the programs to say SET EXCLUSIVE ON.  

Usually dBASE IV is installed with SYSLCK privilege, so it can use system
level locks necessary for sharing files between users.  The NETWORK()
function returns .T.  if running in multi-user mode.

It is not necessary to convert your .dbf files for multi-user applications
unless you want to use CHANGE() and LKSYS().  

Load and Call

Load and call of DOS bin files are obviously not supported.  In their place
you can write, in any VMS native language, a loadable shareable image.  

Infinite loops

What is wrong with the following code segment?

DO WHILE (.NOT.FILE("READY.FLG"))
ENDDO

This was used in a multi-user application to see if one user is ready to go
on by waiting for the file READY.FLG to appear in his directory.  This
works fine, just like other infinite loops people can write in other
programming languages.  This is a not a noticeable problem on a single user
PC, but on a VAX with more than one user, you would use up the entire CPU
doing this infinite loop.  Avoid them entirely or use INKEY(n) to force
dBASE to wait for n seconds between checks.  

Summary

In summary, dBASE IV programs and data files from DOS are easily ported to
the VMS environment.  If the porting guidelines are followed, VMS and DOS
versions of dBASE IV can share the same physical files using NFS or PCSA,
although not concurrently.  

dBASE programs can be written in a portable manner if the programmers are
aware of the issues described in this article. 
