random shared in XP

[Reise Jacobs]

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

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

[Michael Mattias]

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.

[Mike Luther]

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]