
Note from Bruce Morgen:

                        dBaseII's $$$.SUB Placement


Under ZCPR versions 3.3 and 3.4, the submit command file $$$.SUB is executed
only from directory A0: instead of from the current user area in drive A. 
That causes a problem with command chaining under dBaseII, which uses
$$$.SUB files for its chaining.  Here is a suggestion from Bruce Morgen. 
You can solve the problem from dBaseII using the dBaseII machine code
interface before the "QUIT TO ????".  The following line should do it:

        ORG     0A400H
        MVI     C,32  
        MVI     E,0   
        JP      5     
        END           

That way dBaseII will temporarily be logged into user 0 when it writes
$$$.SUB.  On exit, the CCP will reassert the entry drive and user, so all
will be OK under Z33/Z34.

          --------------------------------------------------

Additional comments from Lindsay Haisley:

Message;	#340
Date:		04/30/91
From:		LINDSAY HAISLEY
To:		ALL
Subject:	NZCOM - DBASE II WARNING.....

   I just reviewed Bruce Morgen's suggestion for solving the problem of  the
placement of the $$$.SUB file when using dBase II with ZCPR 3.3 and ZCPR
3.4.  This suggestion came packaged with a recent release of NZCOM and
suggests that the user use a small binary file with the dBase CALL command
which will switch to user 0 prior to exiting dBase with the "QUIT TO"
command.  Bruce correctly points out that switching to user 0 will cause
dBase to write the $$$.SUB file to a0:, which is where ZCPR 3.3 and 3.4 look
for it.

   THIS METHOD SHOULD BE USED WITH >>EXTREME CAUTION<<.  dBase II maintains
internal buffers containing database information and does a certain amount
of housekeeping -- including disk writes -- on exit.  If the user area has
been changed, databases can be lost or corrupted.  IF YOU USE THIS
PROCEDURE, BE SURE TO EXPLICITLY CLOSE ALL OPEN FILES PRIOR TO CHANGING USER
AREAS.  The USE command, with no arguments, applied to both the primary and
(if any) secondary databases will accomplish this, and I would advise using
the CLEAR command as well.

                                    Lindsay Haisley
                                    (Sysop, Z-node 77)
                                                       