No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

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

    Leave a comment:

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

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

    Leave a comment:

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


    Mike Luther
    [email protected]

    Leave a comment:

  • 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


    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.
    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Leave a comment:

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


    Leave a comment:

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


    Leave a comment:

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

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

    Leave a comment:

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

    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]