No announcement yet.

Shell/Execute/Run Question

  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...


  • #2
    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.

    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]


    • #3
      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
      2. MARK, FMARK, and RELEASE
      3. MARKNET and RELNET
      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]
      Mike Luther
      [email protected]