Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 Unisoft-Cosmos; site micropro.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!well!micropro!edg
From: edg@micropro.UUCP (Ed Greenberg)
Newsgroups: net.micro.cpm
Subject: Re: Chaining programs
Message-ID: <222@micropro.UUCP>
Date: Mon, 20-Jan-86 13:45:40 EST
Article-I.D.: micropro.222
Posted: Mon Jan 20 13:45:40 1986
Date-Received: Thu, 23-Jan-86 08:47:54 EST
References: <60@ucdavis.UUCP> <306@vger.UUCP>
Reply-To: edg@micropr.UUCP (Ed Greenberg)
Distribution: net
Organization: MicroPro Int'l Corp., San Rafael, CA
Lines: 47

In article <306@vger.UUCP> jparnas@vger.UUCP (Jacob M. Parnas) writes:
>In article <60@ucdavis.UUCP>, u557593877ea@ucdavis.UUCP (Bruce K. Martin Jr.) writes:
>> Fellow netlanders--
>>   I am looking for a quick and dirty way to get one CP/M program to execute
>> another.  I have been told (by someone who didn't have the details) that
>> it is possible to have the CCP perform this function (thereby relieving me
>> of the problem of writeing a loader).  If anyone has done this or could give
>> me a pointer to some information, I would appreciate the help.
>
>The best example that I have of this is contained in the source code to
> ...

An easier way to do this is to write a $$$.SUB file onto the A drive of
the system, then warm boot.  

A $$$.SUB file is usually the result of running SUBMIT.  The format is
to have all the commands (with arguments expanded) in REVERSE order with
each command occupying a 128 byte record.  Thus record 0 of the file
will contain the last command to be executed and record N-1 will contain
the first command, where there are N commands.

The format of each record is a count byte at offset 0, then the command
line to be executed at offset 1, then a 0 byte immediately after the
command (no CR or LF).

You can examine an existing $$$.SUB by running a long submit, pressing
the reset button halfway through, then booting from ANOTHER boot disk
and loading the original boot disk in B:.  Then use DDT on the existing
$$$.SUB file.  Be sure to delete this file before putting the boot disk
back in A: or you will keep going where you left off the next time you
warm boot.

DBASE II uses this method of program chaining, to execute something,
then return to DBASE.  You can too.  You don't have to worry about
overwriting the CCP or anything.  

Another trick is to reload your program at the end of the chain
procedure with some argument that tells it that it is being rerun.
Thus, you might get dates and other parameters from a file rather than
the user...  Avoid copyright messages, etc.

Let me know if you want to discuss this sort of thing further.
						-e
-- 
Ed Greenberg			| {hplabs,glacier}!well!micropro!edg
MicroPro International Corp.	|  {ucbvax,decwrl}!dual!micropro!edg
San Rafael, California		|       {lll-crg,ptsfa}!micropro!edg