multi user printing

[mrc2048]

Hi

If more than one user on a network starts vdos from the same shared folder  how will printing handle the possibility of both users trying to print to the same device at the same time?

Thanks

[Jos]

If you refer to the #.asc and #.txt files; those are just created to accommodate third party DOS-to-Windows print processors.
Mostly theoretically, it would be possible one vDos instance is saving the print data, while another tries to do the same during that time.
Suppose saving that data takes 1 second, 100 users, each 100 print jobs per working day of 8 hours, you could have 1 or 2 collisions per week?
Although no such situation has been reported, the next version will retry saving the #.asc file for 30 seconds (the #.txt file was already eventually just skipped).
So it would then be 2 possible collisions per year? Where the user is notified the print job couldn't be saved, and has to print again.
If it is a practical problem, split the users in one or more groups with their dedicated vDos folder.

Jos

[mrc2048]

i see - i missed the # prepended to the LPTx/COMx in the docs.

that means it is safe to start vdos from a shared network drive for printing.

when i start vdos from the network shared drive it automatically maps the current directory to C: and does not allow "use" to change it which makes the local drive C: inaccessible unless I 'use' it as some other drive. would it be possible to override that behavior and allow the initial drive assignment to be specified in config or on the command line?

Thanks

[Jos]

The # is required, Windows will treat all LPTx/COMx.* files being a LPTx/COMx device. And I like the file name to reflect where it originated (in DOS) from.
The mentioned 1 second to store those files is of course far from realistic; it’s a single Create - Write - Close sequence.
Even with a 100 page printjob, totaling some 200KB, that takes only a fraction of a second.

As long the default vDos C: drive isn’t accessed, it should be possible to change it by the USE command.

Jos

[mrc2048]

I was thinking the # was replaced by a uniq number but I see it is literal. So you are saying the file is not opened until the print job is released to the printer? IF so where is the data accumulated while the program that generates the output is runnning?

And, I have found that if c: is mapped to a network drive it cannot be changed - i assume its because it has been accessed immediately since it is the current drive. Any way to override that behavior?

Thanks

[Jos]

Print data is collected in memory.
You can do a USE command for any DOS drive letter once.

Jos

[Jos]

Reconsidering that 30 second period vDos will try to create an .asc file, I made it more practical: A maximum of 10 attempts with a 0.5 second delay in between.
So the user will be informed after 5 seconds of some mishap, not 30.
1 second to create the .asc file is of course far from realistic, even with printjobs of over 100 pages. While we are also far beyond the capabilities of printers in the example; 100x100x100 pages per 8 hours would be more than 2,000 ppm of continuous printing.

Jos

[mrc2048]

the use c: problem was solved by use'ing a d: then entering 'd:' to switch to that drive THEN doing a use c:.

but now i have another printing problem with one of the PC's - I try to spool print using vdos.exe ver 12/31/18 and it errors with "cannot initialize printer" no matter which printer I try to use. Printing for word and outlook works fine. i reverted to the version 8/9/16 of vdos and it printed successfully. I need to be able to use the latest version because I use the spooling option to avoid getting form feeds in the middle of long running print jobs.

i know i am only communicating problems but I have to say vDos is an amazing accomplishment and my customer would be dead in the water without it. It is getting to the point where vDos is better than NTVDM

Thanks

[Jos]

For the USE C: you probably have to make sure it’s (initially) set to an UNC path, not a mapped Windows drive letter.

Could be there’s just some testing code left in the vDos.exe I sent you. Don’t know about a version 8/9/16, that would be 2016.06.01 or 2016.10.01. Both already had the SPOOL option, though you might also try the (global) TIMEOUT=OFF directive. If your program uses DOS functions to print, that should solve broken pages and even make the printer respond faster.

Jos