Shell/Execute/Run Question

Chris ...

I don't think it can be done. Version 6.52, if memory is correct is
very heavily in use here. Under OS/2's DOS-VDM sessions I have
run as many as I think six different sessions of it at the same
time in the same box with PB 3.5 code. Every single one of them,
in my case, uses a DIFFERENT 'AUTOEXEC.BAT' file under a different
name, which includes the loader line for Btrieve.

Part of the reason for that different name, such as ZLOGEXEC.BAT or
ZLOGEXE1.BAT, instead of AUTOEXEC.BAT, is because my version of
Btrieve uses "lock" files to tell itself that this or that instance
of Btrieve is using a particular file. Like PB, but, in some cases,
a much more complicated way, many different units of Btrieve, on a
network, and/or in my case, on the same box, have to be aware of
the fact that a different 'user' of Btrieve is working with a file.

Your .BAT file thus is the starting place where you begin the Btrieve
operations that will create at least one different user accounting
and control file for each instance of Btrieve being run. As an
example, a .BAT file loader line of:

Code:

rem "* Required for proper loading of BTRIEVE 6.1.5.952"
        loadhigh btrieve /t:15:c:\temp\bout1.trn

tells Btrieve it will use a control file of "bout1.trn" in that directory
c:\temp for this file. My .BAT file ZLOGEXE1.BAT will and MUST use
a different name for that file, such as, "bout2.trn" instead. The
other parameters in there, number of buffers needed, other things
are all part of the documentation for Btrieve.

You will notice that the technique "loadhigh" was used! In this version
of Btrieve, there are actually two components of the process that are
not normally visible to the user in the load process. One of them
loads what I'll call a special memory manager which was written by
the Tenberry folks that is known as the Rational 4G product. That engine
has a complete interface which has to be emplaced before the Btrieve
took itself and part of this process involves a tool called PMSWITCH which
actually is loaded before the Btrieve engine itself.

There are two kinds of basic uses of Btrieve which take and use memory
in far different ways. There is a stand-alone client version. It
can be loaded on a box all by itself and thoroughly keep track of
all parts of the operation for even network shared uses of files,
but requires, I think, more memory of the user box than the other.

For speed of operation in networked use, there is also a SERVER version
of Btrieve. It loads on the network SERVER and then the client goes
through this same sort of process to load just the REQUESTER for
Btrieve. However the .BAT file deal is still the same sort of deal
as you ask about. It's just a differnt kind of kitty cat.

The whole process takes varying amounts of memory which in most cases,
can be loaded in about 64K of memory, but can be larger. The code can
and does attempt to load "high" as is. But often one has to load it
in a specific optimized mix in the .BAT file ... or ... in the case of
a pure DOS box, even as part of a WELL PLANNED custom version of even
the CONFIG.SYS file. That is to thoroughly optimize the load order and
fit of every single little bit of code which uses any portion of upper
memory, expande, extended, whatever.

If that is not done and carefully done, the amount of free memory available
to the user for ordinary code work is far less. In my personal view of
all this, and from my long, long experience at this, I think you will
find that getting the exact precise best use of high memory cannot be done
at all with the standard Microsoft upper memory management tools. For
years, the only optimal process I've ever found in pure DOS that will let
you really customize every last bit of upper memory and gain control of
all the little tricks Btrieve can use ... is the Quarterdeck QEMM product.

There is also a version of QEMM for WINDOWS of older kinds which has, as
I've been able to determine, this far better control of memory even when
attempting to use Btrieve in a WIN box environment. Don't tell anyone here,
or they'll faint, but someone once left an old IBM 755 laptop on my doorstep
in pity one day with WIN-95 on it. The only way I could even come close to
gaining enough memory to do any tests on it with the PB compiler was to
install QEMM on it for the version 8 and the updates to version 8 for
the WIN world.

Then you run OPTIMIZE and MANIFEST which are part of the QEMM world to tweak
and tune each part of the .BAT file and CONFIG.SYS for all the tricks that
are needed to get where you need to go. In my experience.

Some of the nuances for use of Btrieve that become part of the .BAT file
experience for some users are things like:

Code:

rem "* Required for ALL BTRIEVE in ZLOG"
        set dos16m=:2m
        set timerint=8

In other words, such things as buffer size levels, priorities, and the use
of whether or not the HARDWARE timer interrupt is actually touched or not
by the Btrieve Engine all must be thought about carefully and set during
use of Btrieve, at its best, in even a single user DOS box! That is because
we all know and love and use TSR's as well which are a low level part of
what became, are .. WIN and OS/2 and so on!

I know of now way to alter that process, to control this as par of the
DOS Environment, to get them set BEFORE you load the Btrieve engine, unless
they are put either in the AUTOEXEC.BAT file (Whatever the name!), or in
CONFIG.SYS, if any of this is applicable or can be controlled there.

I do know of ONE tool which might help you if you write a REAL NICE batch
file for your total envelope. There is a free utiltiy that is available from
some of the old time BBS systems which is called TSR. From the DOC's I quote:

TSR Utilities Version 3.5
Kim Kokkonen
TurboPower Software
10/18/93

Table of Contents
---------------------------------------------------------------------
1. Introduction
2. MARK, FMARK, and RELEASE
3. MARKNET and RELNET
4. WATCH and DISABLE
5. MAPMEM, RAMFREE, and DEVICE
6. EATMEM
7. Known Limitations
8. Version History
9. Copyright and License Information

1. Introduction
---------------------------------------------------------------------
The TSR Utilities are a collection of programs useful for managing DOS
memory, particularly for managing memory-resident programs, also known
as TSR's. TSR stands for "Terminate and Stay Resident". The most
popular use of these utilities is for removing TSR's from memory
without rebooting the PC. There are many other uses, however,
especially if you are a software developer.

The TSR Utilities have grown to include 11 programs. Here's a quick
overview of each one:

MARK marks a position in memory above which TSR's can be
released.
RELEASE removes TSR's from memory.
FMARK performs the same function as MARK but uses less memory.
MARKNET like MARK, but saves a more complete picture of system
status.
RELNET removes TSR's marked with MARKNET.
WATCH a TSR itself, it keeps records of other TSR's.
DISABLE disables or reactivates TSR's, leaving them in memory.
RAMFREE shows how much RAM memory is available.
MAPMEM shows what memory resident programs are loaded.
DEVICE shows what device drivers are loaded.
EATMEM uses up memory for controlled program testing.

These programs are described in detail in the following sections. If
you haven't used them before, be sure to read the documentation: All
of the programs are command line driven, and unexpected events may
occur if you just start typing the program names at the DOS command
line. Also be sure to read section 7, "Known Limitations".

The most notable feature of TSR Utilities version 3.5 is support for
MS-DOS 6.0 and TSR's loaded in high memory. This version uses a new
algorithm for finding the first block in high memory; this algorithm
works with the most recent versions of EMM386, QEMM, and 386MAX. If
you're using QEMM 7.0, be sure to put DOS=UMB in your CONFIG.SYS, or
you will have lots of nasty problems with the TSR Utilities. If you
are using QEMM 7.0's DOS-UP feature, you must use the /U option of
RELEASE and RELNET, or you will have trouble.

and ... much more snipped!

With it, you can MARK a particular place in memory as you go through
your .BAT file doing 'dis and 'dat. Then at a LATER time, you can run
a special little command in that file and TOTALLY BLOW AWAY EVERYTHING
you have done in that .BAT file in memory. You return to exactly the
place you were at the desired marked spot and can start all over an
play games with a new code partner with no memory at all of the last
jouous romp!

Many TSR's simply do not release everything properly, could never be
or permit your to abort, such as Btrieve in your box after load, or
anything like that, on their own. For example, the old ZFAX voice,
fax, and data engine that lets you use only one phone line for all
those separate tools in pure DOS with QEMM on a box and ZyXel modems
requires this technique to abort a voice session if needed!

This provides a crude form of 're-entrancy' for DOS for some uses which
you can actually evoke, in simplistic fashion, if needed. It may help
you do what else you want from this box and one .BAT file in pure DOS.

However as to Btrieve, the Engine itself, can be cleanly unloaded, as
long as you haven't loaded another TSR on top of it. You just use one
of the many command line switchs of the program BUTIL as the "/U" and
it is gone. After which it can be re-run as needed in that same batch
file or looped to, to get where you want to know.

However ... and I'm serious about this. I'm no expert at Btrieve. It's
a LOT bigger and better story than all the above, complete with full
transaction concurrency and roll forward and roll backward file protection
for you.

Another lifetime awaits you if you really want to get creative in the
use of that .BAT file and optimized and alternate CONFIG.SYS files at load
time with QEMM....

FWIW ...

------------------
Mike Luther
[email protected]

Announcement

Leave a comment: