Dec 192017
PosCheck v1.2 from Novell checks corrupted Btrieve position blocks, gives a trace log of Btrieve calls. Compares block between two Btrieve calls to check whether host application is modifying/corrupting blocks.
File POSCHECK.ZIP from The Programmer’s Corner in
Category Network Files
PosCheck v1.2 from Novell checks corrupted Btrieve position blocks, gives a trace log of Btrieve calls. Compares block between two Btrieve calls to check whether host application is modifying/corrupting blocks.
File Name File Size Zip Size Zip Type
POSCHECK.DOC 4903 1806 deflated
POSCHECK.EXE 12059 5736 deflated

Download File POSCHECK.ZIP Here

Contents of the POSCHECK.DOC file


POSCHECK v 1.2 - Position block checker
Copyright (c) 1990, 1991, 1992 Novell, Inc.


Basic information

POSCHECK is a TSR that checks for corrupted Btrieve position blocks and
provides a trace log of Btrieve calls.

POSCHECK intercepts Btrieve calls, compares the position block
after the last Btrieve call to the position block before next
Btrieve call and checks for changes made by the host program,
presumably by an erroneous memory overwrite.

POSCHECK ignores Btrieve functions 17-21, 25, 26, and 28 since the
position block is unaffected by these functions.

POSCHECK can print the entire position block, up to 70 bytes of the
data buffer, and the time/date of each call, before and after.


POSCHECK can only be loaded after Btrieve.

POSCHECK requires about 11k of RAM.

POSCHECK can only be loaded once.

POSCHECK has five command line options

/d : Disable printing of Data Buffer
/f : Disable output to POSCHECK.OUT
/p : Disable printing of full Pos Block
/t : Disable printing of time stamp
/v : Disable video display of Pos Block corruption
/o : Specify the output file/path
(Example - /oc:\output\poscheck.out)

The default output file is POSCHECK.OUT in the current directory,
the default for all other options is ON.

The following applies only if you do not use /o or if you specify a
relative path:

*** You MUST either have POSCHECK in the same directory as the application
*** you are testing, or call POSCHECK from that directory (e.g. invoke
*** POSCHECK with C:\UTIL\POSCHECK while you are in your application's
*** directory D:\MYAPP). POSCHECK will not work otherwise.
(This applies only if output printing is enabled)

Unloading POSCHECK

POSCHECK will unload when Btrieve is unloaded.

Output from POSCHECK

When POSCHECK detects that the position block has been corrupted, it
will either alert the user with a screen message, or beep if visual
alerts were surpressed with the "-n" command line option. And a
comment will be made in the output file.

POSCHECK creates a file POSCHECK.OUT which contains information about
every call made to Btrieve. Each call is listed sequentially.

The structure for POSCHECK.OUT is as follows (all numbers in hex):

Fn St F0 F1 F.Name ChekP Chek0 Chek1 Pos Block Comment
00 00 00 01 01 1234.dat 00 00 00 00 00 00 00 00 00 00 File opened

Fnc - Btrieve function number
St - return status
F0 - internal file ID before Btrieve call
F0 - internal file ID after Btrieve call
F.Name - first 8 bytes of file name
ChekP - position block checksum that Chek0 was compared against
Chek0 - position block checksum after the previous call
Chek1 - position block checksum before the current call
Pos Block - first 4 bytes of current position block
Comment - comment from POSCHECK

An output of "--" indicates the value is not applicable at that time.
Question marks indicate the value is not known at that time.

The ChekP value refers to the Chek1 value for the previous Btrieve call
on the current filename. ChekP and Check0 are the two checksums POSCHECK
compares to determine if a position block was corrupted. When they are
different, the position block is corrupted (this will also be noted in the
comment field). It is not new information, but listed for convienence.
If Video Display is enabled, a message will pop-up on the screen as well.

If Pos Block Printing is enabled: Underneath the status line, POSCHECK
will write the full (excluding the archaic FCB) position block before and
after the Btrieve call.

If time stamp printing is enabled: After the last line of each position
block (before and after) POSCHECK will write the date and time the call
was made, up to 1/100 of a second. Because of the 1/18 second
granularity of the CPU clock however, there is an error rate of
approximately +/- 5/100 of a second.

Miscellaneous information

POSCHECK can work with a maximum of 100 file names per session.

POSCHECK continues to update the file until Btrieve is unloaded,
but the file is accessible (closed) between calls.

When POSCHECK is first loaded, the contents of the previous POSCHECK.OUT
will be erased.

 December 19, 2017  Add comments

Leave a Reply