No announcement yet.

Shell/Execute/Run Question

  • Filter
  • Time
  • Show
Clear All
new posts

  • Mike Luther
    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:

    rem "* Required for proper loading of BTRIEVE"
            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:

    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

    Table of Contents
    1. Introduction
    4. WATCH and DISABLE
    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
    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
    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]

    Leave a comment:

  • Michael Mattias
    Doesn't BTrieve run as a TSR?

    If so, I think you are SOL.. TSR's must be loaded BEFORE the program in which they are used is loaded.


    Leave a comment:

  • Chris Borgers
    started a topic Shell/Execute/Run Question

    Shell/Execute/Run Question

    I'm supporting an existing 16-bit PB application that uses
    Btrieve for a database and I'm trying to eliminate the need
    for a batch file to start Btrieve prior to starting the PB app.

    "Shell"ing won't work because it's not run in the same
    DOS instance and "Run" and "Execute" both dump you out to DOS
    and don't return you to the application.

    Thanks in advance for any help...