Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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]
    Mike Luther
    [email protected]

  • #2
    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>
    Lance
    mailto:[email protected]

    Comment


    • #3
      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

      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        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


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

        Comment


        • #5
          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>
          Lance
          mailto:[email protected]

          Comment


          • #6
            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]
            Mike Luther
            [email protected]

            Comment


            • #7
              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>
              Lance
              mailto:[email protected]

              Comment


              • #8
                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]
                Mike Luther
                [email protected]

                Comment

                Working...
                X