What is the file PBVMS.$$$ for in the WIN/TEMP directory?

[Mike Luther]

There are rare times when the PB 3.5 IDE will totally abend
an OS/2 entire box during interactive keyboard I/O. The event
is so rare and catestrophic that it would be virtually impossible
to ever submit it for debugging, or ever even trace anything
about it .. except for one curious deal!

The event always leaves the tiny, apparently empty file snippet
called PBVMS.$$$ in the WIN/TEMP directory. A total hard abend
of an OS/2 box is a *VERY* rare failure, which, of course, leaves
the dirty bit flag on. This forces a complete detailed CHKDSK of
the box, just like in a WIN system. In each and every instance
of the failure. CHKDKS32 reports an "allocation adjustment" for this
tiny snippet!

It apparently is placed in the directory contemporaneously with
the initial compilation of the source prior to IDE use. It remains,
as far as I can see there until the PB IDE is closed. That's how
I get to see it as seen as corrupt during the cleanup of the box
during the re-boot.

I've attempted to look at it off and on during use of the PB IDE
tool, an never seen it ever apparently hold any data. But it might!
Or is it simply a flag or semaphore file which is used for process
checking of some kind? I'd have never even likely known about it
except for the abend cleanup process.

If I knew what it was and what it is for, it just might give me
some insight into why this rare failure is happeing. I doubt it,
but the deal you always lose is the one you don't investigate

Thanks ..


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

[Lance Edmonds]

In the case where the IDE does not have enough memory available during compilation, it may use a "private swap" file (I'm really stretching my memory here - I'll have to double check this).

Also, your app can create a swap file if you use UltraSHELL (a 3rd-party SHELL utility) or during a POPUP (as in a PB TSR app).

If this file happens to be open when a crash occurs, it is possible that disk caching may render the file "incomplete", and hence the OS/2 disk manager report.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Michael Mattias]

I've gotten a 'file conflict' error on that file when I've acceidentally started a second copy of PB/DOS. Didn't happen just now on Win98 (it used to happen on my DOS 6.22/Win3 box), but I didn't compile anything.

MCM

[Wayne Diamond]

If I have PBDOS running in one window and its help system is open (F1), if I launch pbdos in another command prompt window I get this error:
Cannot access temporary file:
C:\TEMP\PBVMS.$$$
Check environment variable. Press ESC.
I cant load the 2nd PBDOS.EXE then until I close the 1st which loaded the help system
No dramas though


------------------

[Lance Edmonds]

Ah yes, spot on - it [also] used with on-line help.

From the on-line file:

Variable: PBTEMP

Purpose: Specify the drive and sub-directory for temporary storage

Syntax: SET PBTEMP=pathspec

Example: SET PBTEMP=E:\RAMDRIVE

In the course of compiling a program, PowerBASIC will use real mode
memory, expanded memory (EMS), and then extended memory (XMS) for
temporary storage of symbols and other data. However, if that is
still not enough to complete the compilation, it will use virtual
memory on disk. If this becomes necessary, PBTEMP is used to
specify the drive and sub-directory to be used, so the fastest
medium is chosen. If PBTEMP is not found, the compiler looks for
TEMP instead. If neither is found, the default drive/directory is
then used.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Luther]

Thanks Lance and all the others for the reply.

The thought that the disk swap file during compile is important.
Again, I'm not complaining at all that there is anything wrong with
PB 3.5 here. But the picture is focusing. You are correct that
if that file is open and un-cached, you'll get the allocation error
from CHKDSK32 in OS/2. That it is or may be associated with a
help issue is strangely co-incident with what you see from evem
an OS/2 help issue! Virtually every time you run CHDKSK32 on the
boot partition, which, incidentally, in OS/2 has numerous files
locked at boot time so they can't be pranged by viruses etc.,
you will find that the file CACHE.DB0 is reported the same way!

Turns out that this file is the on-going HELP pointer for the
sniffer for help that OS/2 is doing while you cruise the desktop!
Taught by you and your 'skill' level with OS/2, after installation
and use, it follows your every move. When you reach a 'level of
skill' that it thinks you've never hit doing something with the
desktop, it pops up HELP for you! Most folks disable it by saying
I'm a super-smart OS/2 user. I think, but am not sure that it has
also some fuzzy logic built in so that after a while it learns what
you know and just sulks in the background!

If this PB file is being opened for help, or the anticipated cache
needed for spill over memory requirements in compilation, and, by
odd chance, DIRECT DISK WRITES are used by PB in it, in the effort
to gain speed when needed, recall that OS/2 is a PRE-EMPTIVE op
op system!

One of the things we hit hard-on with it in communications apps for
example, is that the COMM ports, in reality, as well as EVERYTHING
in OS/2 .. are only OBJECTS, in that sort of thinking. Oh sure, at
core level, that's obviously not so. But at the level we see every
little nuance in a DOS-VDM session, it is. That session is an
object of adoration by the user! Huge grin!

OS/2 is also THREAD oriented for CPU orchestration! It is not as,
so others tell me, PROCESS oriented for CPU orchestration like the
WIN operations. No, I do not use more than one CPU here in this
box, but the thread issue goes far deeper than one might think. If,
for example, during CPU thread orchestration, as I am told, but
personally don't have the skills to use or verify, OS/2 wants there
to be a COMM port, you have one! If it needs to take it away for
its own internal use for an instant and slush data for that operation
and return it where it left off ... it does it!!

The same holds, I'm taught, for disk I/O as well. Objects in the
foreground normally always have priority to the hard disk for any
pre-emptive thread use, unless ... Here is where it gets interesting!
If you are running communications port applications in OS/2, then
there is always the possibility that the BACKGROUND session processes,
note that's not just THREADS, really need hard disk I/O priority!

That's because you simply can't tell a satellite, for example, to
shut up downstream data which a comm app may be running in a
background session! So in OS/2 we have the option of telling the
box that SET DISKPRIORITY=NO in CONFIG.SYS will tell the box that
all background sessions should have equal priority with the foreground
session for hard disk I/O. Curiously, that leads to another
problem .. for DOS-VDM users only!

The keyboard obviously comes into play with its threading and interrupt
work. There *ARE* times, when keyboard syncronization, in a DOS-VDM
session, get scrambled in the OS/2 DOS-VDM sessions, as a result
of background communications thread requirements for boxes with
the DISK PRIORITY set to NO. What happens, in that the FOREGROUND
session, the IDE operation for PB 3.5, for example, will lose the
SHIFT STATE or CONTROL STATE of the keyboard and REVERSE the
logic! You hit an "E" for example. But when this fault happens,
it is not an "E" you get! Instead, you get a <CTRL E> or, perhaps an
<ALT E> and you do *NOT* get plain <E>... !!!!

It is a long outstanding and we are told by IBM, uncorrecable fluke in
task switching that was brought on by Gates doing someting with an
assembler instruction that was supposed to be reserved for INTEL for
CPU semaphore operations, but he used it the way he wanted it, in
the legends about this thing. Do *NOT* ask me, it's way beyond me!
So said, in rare semaphore patterns, and rare use of what is needed
for all WIN and DOS multitasking in a pre-emptive state, either in
OS/2 or WIN or whatevere .. you will hit it.

The problem is statial. Once the keyboard state shift has taken
place it is GLOBAL on the box, not SESSION oriented. Thus, every
key you hit is, perhaps an <ALT something>... Wow ..

Yes, that is means every single session has the issue. The actual
box-level OBJECT for the keyboard is pranged. That's not nice.

You can get rid of it, at least in OS/2, we've found out, by simply
holding down the left CRTL key, the left SHIFT key, and then bashing
the SF2 key repeatedly for a while and the keyboard will revert to
the normal state! This deal is so rare that most folks never see it,
but I can for a reason like this. Suppose we are running a keyboard
intensive I/O operation simultaneously with comm ports running such as
a contest logging and network control program for a multi-terminal
networked application of PB in DOS-VDMs in a ham radio contest! There
are many ops pounding away at keyboards as fast as their pinkys
can pound! The application will be loaded and pounded 24 or 48
hours straight! THAT's one way to test a PB application!

Suddenly your keyboard is locked producing <ALT E> instead of <E>.
In a rage you pound on the keyboard thinking you have lost all your
contest data for that year! Abort, abort, abort .. scowl.

Surprise, you stumble on a keystroke combo that will 'reverse it'
A whole year's worth of work, literally work you won't get to test
in real-time again for a full year .. is saved. Bless Mother!



Recall that my box is totally consumed with telecommunications apps
which are running all the time on every comm port plus the whole
nine yards for TCP/IP against a cable modem as a server whiile I'm
doing all the PB development work on it simultaneously! Thus, if
I take a SHIFT STATE error and think I'm editing the source code in
that PB IDE session, instead, my bet is that I'm "instructing" the
PB IDE to do something .. and it is "God Knows What!"

It is *NOT* a flaw in PB at all.

However the RESULTS of this may be a little worse. It all depends
on how an application is coded to work with DISK I/O, (or video,
acutally, if the truth be told!)

What then may happen is that PB may attempt to do something which
uses a direct disk write .. Recall that PB isn't coded for any
special awareness of OS/2 DOS-VDM's, although I'm told that at one
time Bob was VERY much more oriented toward a release of PB for
OS/2 .. Until IBM wasn't kind to him at COMDEX one year.. So as
PB is now coded, it may or may not be within OS2's orientation for
thread orchestration pre-emptive priority for that instant in time,
if it did not go through the thought to be acceptable cache operations
for pre-emptive multi-tasking for DOS sessions at all. Thus, who knows
where in Hades the buffer is over-run with what that disk I/O has
sought for a memory vector .. and

POOF box is gone.

You will not find it. We will not find it. IBM will not find it.
And within the economic limitations of what has to be done at PB just
to stay afloat, Bob won't find it either.

As well, I doubt that very many people here are running boxes with
all the serial ports active at all times, as well as the whole TCP/IP
game simultaneously in real-time on development boxes with PB as
well. And I assure you I don't have the mental awareness to even
start at it!

I can tell you that I have *NEVER* seen it in a production release
of any PB code. Thus the issue is *NOT* a critical issue, as far
as I can see for any ultimate user for produced code.

All I've tried to do is explain what little I know about how it
happens, and why what that file might be doing so I could perhaps
get at the logic behind the failure. It does, I think, now give us
a little more insight into how on very rare instances, a box leaves
our little circle of amusement when working with the PB IDE.

I post this only to help people understand why all this is so darned
frustrating and complicated to figure out. Not in any way to
say that PB is at all wrong or in error ..

It's like unloading cows from the lorry to the pen. Through a
comedy of errors we have yanked the chute for a moment out
from under the operation. A few cows fall on the ground! Or
one jumps over the chute and swims off down river! Moo!
Don't worry about 'er, matey. She's not worth going after
and besides, if she was smart enough to avoid the ax, let 'er
live in peace! Omain.


Thanks!



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

[Lance Edmonds]

To the very best of my knowledge, PowerBASIC does NOT do "direct disk writes" since that would cause problems with some operating systems. All reads/writes are done through the standard DOS file services.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Luther]

And that last post ..

is the one I wanted most of all, Lance.

That clears the entire issue in my mind about what is going on
in this box lock deal. You may be interested to know that
once I switched from the old CLASSIC Pentium CPU with the old
F0 very for real bug problem they all have ..

I have never again had a disk demolition derby
out of this PB IDE collapse deal

The issue with not being able to break the keyboard bashing I
get in the PB IDE which I cannot, with any slicer or tool I've
ever found in an OS/2 DOS-VDM is still there. It absolutely
destroys the box pre-emption for everything in thread orchestation
for even the native OS/2 applications any time the IDE debug
window is in focus.

Sure I wish in the next incantation of PB for DOS we'd get some
way to tame it.

But since the replacement of the CPU off the old CLASSIC one, the
only thing that ever happens is the hard box lock. A re-boot clears
it, of course, after CKHDSK32 gets things cleaned up.

As far as I am concerned, the statement that no oblique disk
I/O is used closes the issue for me.

I think it all goes back to the issue of the fact that DOS was
never meant to be re-entrant. As we both know there have been
a number of messages and conversations about TRS's and all
about this too, grin.

Much of this is all still focused on the fact that in creating
a DOS-VDM for OS/2, that is .. pre-emptive, IBM has to make, as
I understand this, concessions for this and that and timing.
DOS in a DOS-VDM is a far better DOS than DOS, indeed! Perhaps
the real reason OS/2 didn't have market penetration like it
should have at the time, was simply that you couldn't play games
on it! It was just too darned fast and you couldn't shoot the
cow before it mowed you down jumping over the chute!

We still, and WIN users who do use this stuff in WIN-9x upwards,
as part of PB 3.5, still face occaisional glitches that are beyond,
I think, the control of any application like PB 3.5. Bob and
your crew have done a fantastic job in integrating the past
with the future as far as I am concerned.

That no out-of-hand disk writes were used is crucial at cementing
that friendship with the op systems. It was the re-assurance I
think many readers here will appreciate and come to respect more
and more as they grow in their awareness of all this.

I know sometimes that it doesn't seem to look like it, but I
happen to be one of your strongest supporters for PB. There
are many who simply do not believe what can be done with it,
even in plain old DOS .. but you can!

You can.

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