No announcement yet.

random shared in XP

  • Filter
  • Time
  • Show
Clear All
new posts

  • random shared in XP

    When I open files with "random shared" and access the file at the same time from two applications it works fine in Windows 98 , however in XP I get random failures with error code 75 (path access error)
    Any ideas?? thanks


  • #2
    Show exact OPEN syntax used. "random shared" does not appear as a valid mode in my PB/DOS help file.

     Syntax:   OPEN filespec [FOR mode] [ACCESS access] [lock] AS [#]filenum
                           [LEN = recordsize]
    You may have to check/adjust the ACCESS and LOCK options of the OPEN as Win/98 and XP may understand the defaults differently.

    Also, if you are working on a network, and 'filename' was created new by application 1, I know there is some kind of difference between Win/9x and Win/NT-class vis-a-vis the availability of such a file to another process.

    So check if you are ever creating new, and if that's the case when application 2 has a problem, change your application so that both program instances are always opening an existing file.

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


    • #3
      Boy what you said when you reported the word RANDOM in your post!


      Multiple PB applications on the same box at the same time or is
      this a network issue where more than one box is accessing the file
      across a network?

      Does the error occur when the same record is accessed by more than
      one application or even if completely different records are accessed
      when it occurs?

      Is this a read-only issue, or is one or more of the applications
      writing to the file, even though the other use of the file is merely
      reading records from the file?

      If writing is also involved, is it possible that record-level access
      is part of this where one record is being altered .. and you are
      using record lock, but another application doesn't have provision
      to delay action for a read for that record until after the writing
      application has cleared the lock on that record? Timing does make
      a difference between how WIN-98 can('t) handle this and WIN-XP does
      things, in the far different way the WIN-XP world can sequence things.

      More specific, is one of the applications using file lock during
      writes instead of record lock?

      Is it possible that write cache contamination in XP may be involved?
      Operating systems with true multi-tasking and multi-threading sometimes
      have problems with synchronizing file operations on the same file
      for DOS applications where DOS is always a 'guest', if you will. I
      pose this comment in the light of OS/2's long history of DOS-VDM
      applications work in heavily networked both multiple PB applications
      on the same box as well as simultaneous multiple PB application on
      other boxes across OS/2 networks.

      During the long history of OS/2's Fix Pack, kernel and operating
      system support by IBM, at times, both native OS/2 and DOS-VDM
      networking has had a few very strange conflict errors like this
      show up that would not only produce these sort of traps, but also
      produce difficult to find and fix operating system timing related
      errors. Errors would show, for example, only on certain CPU's; not
      others! You may find your's are CPU related as well. They may
      show only on certain hard disk kinds; IDE and not SCSI or SCSI and
      not IDE - as from driver related errors. For example, are these
      files stored on a hard disk, USB attached hard disk, USB memory
      stick? Are all the boxes, if this is across a LAN, the exact same
      hardware and device driver mix? Are they all the exact same Fix
      Pack level of the operating system and device driver level status?

      Yes, it really can make a difference as the complexity of things
      gets greater and greater .. that in support of WIN-98 vs. XP and
      so on.

      In that I've not had XP experience at this, but over a decade of
      this in OS/2 DOS-VDM's, the following are only thoughts. But they
      should be helpful, as concepts, for what you might face, OK?

      Sometimes, the isolation and 'proof' of an operating system's part
      in causing this can be isolated, in OS/2 .. by turning off the
      operating system's hard disk write cache with an OS/2 command line
      instance of "cache /lazy ff". That has proved in the past to stop
      strange random error 75 issues in PB here. Tracing that for the
      minute time details so that IBM (Or Novell!) could fix it, has, in
      the past, required even assembly language level debugging with in
      my code with PB's ability to report on the assembly language level
      what is going on at even the interrupt 21 level to get that fixed.

      In OS/2 it wasn't PB's fault either, but problems in the threading
      and I/O related to DOSCALL1.DLL and other processes in the OS/2
      on-going and perfectly normal and expected move upward as it
      continues to support everything from the mid 1970's onward into
      today's operations. Years ago, in Novell, it finally was traced
      to their technique of examining multiple calls for exactly the
      same small file record size in a massive scanning operation on the
      file. As we did call after call after call, the operating system
      began to think it should slush more and more of the file for read
      ahead purposes to expedite the process! And over time, the entire
      LAN became slower and slower as the server read-cache got bigger and
      bigger, finally bringing both Error 75's to us .. and worse,
      taking the whole LAN down as a result of this PB 3.5 data mining
      and searching operation! I watched this in Novelle, take a whole
      hospital down at one time years ago until they fixed it.

      One would hope that WIN-XP would make the same sort of effort to
      support heritage applications for things like this and so on. You
      may really need Microsoft's help to get it fixed, if my experience
      at OS/2 and Novell holds for you. Only time will tell for you.

      One very curious other operating system issue that has produced
      similar random file I/O issues over the years with OS/2 might give
      you a further clue. Not only file I/O must be considered in what
      is happening in multi-threaded and multi-tasking operations, but
      write/read cache issues also can be affected for operating system
      errors in relation to communications port I/O at the same time
      as well! You may not have thought about it this way.

      Consider taking in data from a comm channel where you really can't
      control received flow of data as precisely as you might like. You
      can't shut up the sender but have to slush incoming data during CPU
      time slicing while you also have to plan for CPU actions surrounding
      disk I/O and data caching as well! This is what multi-tasking and
      thread vs. process orchestration for CPU action is all about. It is
      the prime reason why I've never, to date, been able to handle any
      of what we do on Windows boxes, especially WIN-98 stuff.

      Yes, WIN-XP is FAR more capable here. But at what price for heritage
      applications? I sure don't know that. Others will have to help
      you here as to specifics, but the concept is the same.

      Too, WIN-98, to my feeble awareness of it, is only process-able to
      handle multiple instances of PB and file I/O. It doesn't split the
      I/O into smaller threads of operation so that thread-line-of-activity
      is coordinated for support in the single cycle operations of whatever
      single CPU you are using. When you tell us you are capable of use
      of WIN-98 for your applications, that may be just because, at this
      point, you have been lucky as to what it does in sequence! Now
      that you have advanced to XP, what worked before just as to the lack
      of time slicing and sharing and so on; blows up on XP.

      You haven't also told us yet whether one or more of these boxes, if
      there are more than one across a network, are single CPU or multiple
      CPU motherboards as well! And whether you are trying to run WIN-98
      or XP on multiple CPU boards or not. See how complex this can get
      when you add that word RANDOM to your error report?

      Are simultaneous comm port and/or TCP/IP actions going on at the
      same time as you see these irregular Error 75 PB traps?

      Looking back over networked shared file operations in DOS/VDM's
      with OS/2 and also in a limited way with Novell, I personally
      believe the toughest of the problems to find and get fixed like
      this, are those which also occur as a result of simultaneous
      commumications port I/O issues which are not properly handled at
      the same time as disk I/O. And no, it doesn't have to be anything
      wrong with what you are coding in your PB application.

      It has taken me months, at times, even hundreds of hours of my
      life to isolate and furnish data for these type errors to get things
      like this fixed with IBM - which they *HAVE* addressed and taken
      care of. When it could finally be shown where the error might be.

      And, I just spent almost a week learning yet another way this very
      random Error 75 can hit in PB on an OS/2 PEERLAN that has NOTHING
      to do with PB and is no fault of PB. Take note. I'm almost sure
      you could hit this in WIN-XP even though I don't use it.

      The random PB Error 75 in this case was being produced by a failing
      NIC card in a workstation! It was releasing white noise across the
      CAT5 OS/2 PEERLAN network on a random basis. In this case the noise
      pulses produced by the faulty NIC card were producing the time-line
      conflict issues for the PB file I/O operations in an otherwise
      completely clean programming operation! In this case it also took
      IBM's IPTRACE program to actually examine the data packet transfer
      across the LAN to figure out part of this. But most of the time,
      operating system failures alone have been the cause of the RANDOM
      failures like you pose.

      I don't have the funds, training, or time to run my PB development
      work in what I'll call an ICE machine environment. One where each
      and every part of the CPU and operating system's work can be studied
      in detail to find where these random errors as you describe hit. So
      I have to do the best I can to furnish IBM and others with proof of
      where the error most LIKELY is being caused. That's where the hours
      and hours pile up assembling the best-efforts external proof of
      failure data needed.

      You can't fix what you can't find and see.

      This gets particularly nasty when communications program and port
      I/O issues are involved which my be running on a box at the same
      time your PB applications are doing something totally unrelated
      which throw the error actually caused by something external you
      aren't even aware of.

      To do this, for years now, I've had to, at times, both write a trace
      log file from within a PB application which records the file I/O
      exact sequence and timing for each of the uses in an external log
      that can be used to verify exactly under what I/O circumstances
      and at what exact time the trap pops. Then, I must sychronize that
      with the same sort of trace log file which is written as other third
      party applications roll through batch files with communications
      port work. We can then compare the time line across multiple
      applications for all this.

      It helps, in OS/2, to be able to have a completely different form
      of AUTOEXEC.BAT file for every single general batch file under
      which you run a BBS operation, a collection of PB program operations,
      even two or more different PB program applications on the same
      box at the same time. That lets me, for debugging these third-
      party program/op system complex errors, to be able to write a
      log file to the disk for every step and time of step, for each
      time we chance functionality in the batch file. That so as to
      compare the time line with what is internally happening in a
      given PB program where these random errors pop. See where the
      hundreds of hours go flying by for this mess?

      I have no idea if you can do this in WIN-XP. Yes, I understand
      that separate .DIP or whatever it is called, files are produced
      for different 'programs.' But from what I've seen so far of XP
      and the NT-CONFIG file game, this is still totally beyond what
      we have in OS/2 in separate AUTOEXEC.BAT files with the host of
      SESSION COMMAND instance changes that can be instanced for every
      operation you do in a DOS-VDM in OS/2. It's probably my lack of
      understanding of WIN-XP, but I have no idea of where, in a DOS box
      operation, you could grant or restrict hardware access to it,
      control thread priority levels, keyboard repeat time rate holds,
      complete control over hardware EMS/XMS memory area excludes and
      includes, all of this stuff we take so much for granted in how to
      set up DOS for PB in a more 'modern' multi-tasking world in OS/2.

      Pure conjecture here. But are Int21 file operations in XP provided
      for with complete hackwards compatibility with DOS of old and then
      completely and safely sequenced between more than one DOS session
      in WIN-XP now?

      For example, I may be running three or four different PB 3.5 programs
      on a given box, and on say a dozen other boxes just like that, all
      across an OS/2 PEERLAN which have common file access from one box.
      I will take a random PB 3.5 Error 75 on one box like you report. But
      knowing what I already know from long years of this, I have to examine
      not only my programs as the execute, in time, but OTHER applications
      as well! And that includes examining the environment of every other
      application which is running as well as that of the PB application
      in the box as well, just to isolate what causes this.

      For example, that same OS/2 workstation may be running a BBS,
      TCP/IP FTP server/client work, or even hardware-level comm port
      UART state level line-state hardware control applications out all
      four communications ports on the same box at the same time. These
      may be a mix of OS/2 (WIN-XP in your case!), DOS-VDM, even WIN
      3.1 or actually some WIN-95 upward native programs in OS/2 under
      the ODIN project here. I have to consider every single process
      which is running at the time these start showing up as random
      errors to trace this stuff!

      Which one causes the conflict? Why? You have to generate a
      'common' time-line log that can be related to the whole process
      on that box - and all the others - to find the glitch.

      It takes all this access with the other generated time line logging
      to prove that the conflict takes place when a third party program
      communications port I/O operation has tripped this.

      To do this, in the past, has also required the use, in OS/2 DOS-VDM
      work, of Ray Gwinn's SIO communications port tool set and a utility
      he provides which logs the complete comm port I/O to a disk file!
      The tool is called PMLM, short for "Poor Man's Line Monitor." To
      get stuff fixed in the real world of multi-tasking and multi-threading
      for PB to work smoothly over the years has even required, at times,
      I can prove what's in the comm port I/O process and time line ..
      is right there at the same point in the time line where the file I/O
      trap hits in PB. But whomever does the 'fixin' for this kind of
      stuff has to be able to run what you are running, on the whole
      operating system level you are running, and with the same hardware
      you are running .. sometimes .. to fix it. Sigh.

      Of course after write cache has been disabled, grin. And where PB
      has nothing to do with comm port I/O that pops the Error 75 in my
      PB program. To trace and coordinate these requires that you write
      everything needed to coordinate the time-line and user-data to a
      file on the disk as well. You record the machine, time, and other
      needed error information on a file for your PB program so that you
      can actually go back and compare it with all the other progress
      file trace data on the box. Step by step you narrow the random error
      over time, down to where it begins to focus on where somebody else,
      not necessarily PB at all, has caused the problem.

      And .. grin .. if PB *IS* doing communications port I/O as well in
      one or more of the applications simultaneously, you can guess how
      much more difficult this gets. When you can focus the error here in
      the time-line schema of things, that's when you have to get out the
      port logging tools and see just where the I/O and port buffering
      issues come together to cause this. I really mean the hours mount
      up as this goes down. It's crushing.

      And it really does take serious help from a lot of others, to find
      these sort of errors, per my experience over years. WIN-98 is a
      far cry from WIN-XP at multi-tasking and multi-threading. While
      I don't use XP, I hope you have the kind help of a lot of tools
      will be needed for the research, and from Microsoft as to operating
      system fixes, if you need it, to get this one fixed, if what I've
      seen of similar random Error 75 and other file I/O errors in PB
      over years of this, is involved.

      But .. at least to make you feel a bit better, I've never yet had
      the issue EVER come back to a fault in PB 3.5 over this. If I have
      provided record lock level code for my applications and a similar
      record lock hold and bailout for an application which could same-
      time try to access that particular record in PB, I've never had
      a single issue with PB's file I/O that I've ever found which was PB's
      'fault'. It has always been an external issue either with the
      operating system, hardware driver problems .. or .. for the first
      time as noted in my life, the just seen LAN noise contamination
      issue from defective network hardware!

      I wish you luck. It can be a long, long journey down a very dark
      road full of very big holes and ruts.

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