|
Post by Jorge Zaldívar on Jul 7, 2018 0:31:04 GMT 1
Re: Precision errors and rounding.
OK, I'll wait for next version.
Re: Opening and file locking in 123
Retrieving a file in Lotus 123 may seem OK, but it's not! The sequence that you mention:
Open > Lock > Read > Unlock > Close
shouldn't be that way. Once you retrieve a file it should remain locked until you manually close it (I provided examples in a previous post - quitting 123, opening another file, etc.). Otherwise, as I also mentioned, potential for data loss is present (you can read the examples on one of my previous posts).
Again, I have no idea how it's implemented by the OS but the sequence (by the observed "macroscopic" behaviour) looks something like:
Place reservation > Open > Read > [User works with the file for as long as they like] > Close > Release reservation
I'm using Lotus 123 wording (for example Retrieve is synonym to Open). I don't know if a reservation is the same as a file lock.
You mention that something may be wrong with Lotus locking logic. I concur. Lotus should place a reservation whether the file is local or remote... but one has to keep in mind that (back on the day) on a non-multitasking system there was no way to locally open the same file (there was no way to have two instances of a program running at the same time on the same machine). That may be the reason why the Lotus programmers decided to focus the file locking logic on remote files. How they detected if a file was local or remote, I don't know. How does vDos detect if a file is local or remote, I also don't know. But I think is something worth taking a look at.
If for nothing else (real business reasons like data loss), because the behavior under vDos is different as under a real machine.
Regards,
|
|
|
Post by Jos on Jul 7, 2018 9:53:49 GMT 1
As a file is opened, 123 requests a lock starting at the begin of the file, (65536x65356)-1 bytes long, the file is read in, the locked region unlocked, and the file closed. Even if 123 wouldn’t explicitly unlock the locked region, locks are unlocked by the OS when the file is closed. Leaving the lock intact isn’t even an option: Only the instance owning the lock would be able to access the locked region.
Retrieve in my understanding is still reading in a file (between open and close). If 123 doesn’t know/care about multitasking, what is the lock then meant for? You PC could share folders/files, so it shouldn’t matter if a file is local or remote. The moment you assign a DOS drive letter by the USE command, vDos determines if that DOS drive letter is local or remote using Windows API calls. The first time a DOS program accesses a file on a remote drive, vDos will eventually display his nag. You could also start vDos with the /log option (“…vDos.exe” /log), the generated vDos.log file will list the assigned drive letters and whether they are local or remote. DOS API supports checking if a drive or an open file is local or remote. 123 uses the first method, cycling through all possible 26 drive letters.
I already checked what two 123 instances did in a VirtualBox Windows XP retrieving the same remote file. As with vDos, no warning, nothing.
Jos
|
|
|
Post by Jorge Zaldívar on Jul 12, 2018 1:58:17 GMT 1
Hi, Jos. From your response I gather that I may not be explaining myself correctly. You mention the technical details of the file lock, how 123 handles detection of remote drives, incorrectly state that in a single-tasking environment there's no need for a file lock (the usefulness of the file lock in this scenario arises not from multitasking but from file sharing), and so on. I only mentioned the difference between local and remote files because I thought that may be the cause of the problem. Let's put that aside for the moment. I'll try and organize my thoughts: 1) Fact: On a real machine, if a remote Lotus 123 file is opened, any attempt to open it again (on another machine or another Lotus 123 instance on the same machine) results on a "Retrieve the file without a reservation" warning. This way, the second user attempting to open the file will be conscious that s/he will not be able to any changes s/he makes to the file (retrieving the file without a reservation is then equivalent to opening it read-only: you can view, you can change, you can't save). 2) Problem: vDos fails to replicate this behavior. You can open the same file in different instances of Lotus 123 without receiving any warning. I think the boldface text is the essence. The rest are comments, clarifications, perspectives, ... You mention that you failed to observe this behavior testing under VirtualBox XP VM. Well, something must be wrong with VirtualBox emulation. I observe the behavior described in (1) on a real XP machine and in a VMWare VM. I recorded such a test so you can view what I'm talking about. I used the session recording capabilities of TeamViewer, just because that's what I had on hand. I uploaded the recording as an MP4 file (1.53 MB). I didn't attach it here because of its size. Note: The controlled (recorded) machine is a real Windows XP machine. Again, I used TeamViewer just because that's what I had that could record the screen. Regards,
|
|
|
Post by Jos on Jul 12, 2018 9:22:20 GMT 1
Two more hints:
When I use a real machine (Windows 7-32 bits, don’t have a XP PC), do NET USE F: <shared drive>, start F:\123\123.exe, I get the same results as with vDos or Windows XP-VirtualBox. File – Admin – Reservation – Get produces “File is not shared” in all three situations.
Jos
|
|
|
Post by Jorge Zaldívar on Jul 12, 2018 17:42:43 GMT 1
Well, that's a different scenario.
There I think you're trying to get a reservation on a file you already have one - the automatic one that's placed when you open the file. However, the error message I get when I try to get a reservation on a file I already have reserved is different, it reads: "You have a reservation for this file", and not: "File is not shared".
But... in my case, Lotus 123 is on a local drive (C:) and the data file is on a network drive (I:). You're starting 123 from a network drive and you're not telling where your data file is located, I presume it to be on the same drive.
So, I made another test. If I try to get a reservation (File > Admin > Reservation > Get) on a file I just opened (File > Retrieve) on the same drive (different folder) as 123, I do get the same message as you: "File is not shared". And if I try to release the reservation (File > Admin > Reservation > Release), I get an error message: "You have no reservation for this file".
Upon this evidence, I change my hypothesis regarding Lotus 123 reservation logic to:
"If the data file (WK1) sits on a different drive as Lotus 123 itself (123.EXE) , a reservation on it is placed upon opening."
My previous hypothesis was: "If the data file (WK1) is on a network drive, a reservation is placed upon opening it."
I'll get my hands on a real machine with two local drives to test this later.
Regards,
|
|
|
Post by Jos on Jul 12, 2018 18:24:42 GMT 1
One last hint:
I don’t have a network license for 123, you will have one, but…
My best guess since I never used 123. Only this makes sense.
Jos
|
|
|
Post by Jorge Zaldívar on Jul 12, 2018 19:30:39 GMT 1
Neither do I. I really don't remember there being a separate network licence... at least not for v. 2.2.
|
|
|
Post by Jos on Jul 12, 2018 20:05:01 GMT 1
I get the same results for vDos, Windows XP-VirtualBox and Windows 7 32-bit. So 123 licensing is the obvious suspect. You could search the Internet for that. Eventually start vDos with the log option (“…vDos.exe” /log) and look in the vDos.log file for failed open or find file operations.
Jos
|
|