Printing from vDos has suddently stopped

[efty]

Hello there,

I have a very strange problem with printing on all the network printers in an office network where I installed vDOS about 5 weeks ago:

I installed vDos on 3 windows10 64bit PCs, and I configured them to access a program directory on a network share. I used chcp=737 in \vdos\autoexec as the programs are in Greek, and that works fine as the greek characters display fine on the screen. 
I setup \vdos\config to use an OKI ML3320 dot-matrix printer by default (LPT1=SEL: "ML3320" RAW) and that worked perfectly up until last week. The #LPT1.asc and #LPT1.txt files were generated correctly until last week, but now, even though nothing has changed in the environment, printing has stopped and the generated #LPT1 files are both empty!
I tried printing to other printers on the network, but had no success whatsoever.
I have checked the printer queues, they seem to be receiving a job every time I try to to print, but nothing is printed. All printers work fine when I send a test page from windows to be printed. It seems the printing problem is within vDos. If I try to print from the vDos command line, I seem to be getting the whole page printout on a single line (seems like CARRIAGE RETURN is not happening).

Is this a licensing problem? Do I need to purchase a network license in order to fix this?

Many thanks,
Efty . . .

[Jos]

Both #LPT files being empty is puzzling. You didn’t tell if the vDos directory is local or on the network share. If the latter, create a local vDos directory on one PC, copy autoexec.txt and config.txt to there, and set the “Start in” property of the vDos shortcut to that directory. Then start vDos by the shortcut.
If that solves the problem, it should a issue with (access rights of?) the share. Though vDos should warn you if it has a problem with updating the #LPT1 files.

You can’t just replace SEL: "ML3320" by something else: With the RAW option the OKI interprets the ASCII datastream with Epson printcodes. Most other printers can’t.

More stranger that printing from the command line works (partially). Could you submit the file you printed (copied to LPT1?), and the generated #LPT1 files. Then also start vDos.exe with the log option (“…vDos.exe” /log) and submit the generated vDos.log file.

Licensing won’t help: It only removes the nag and the occasional “www.vdos.info” notice when printing w/o the RAW option.

Jos

[efty]

Hi Jos,

Many thanks for the prompt reply!

The vDOS directory is local, each PC has its own vDOS installation on its own hard drive. All versions are the same. It is only the accounting software/data that resides on the network drive (I added "USE C: I:\ACC" in autoexec).

I use LPT1=SEL: "ML3320" RAW in the config file because that's the only option that worked with GREEK characters. I REMarked it to test with other printers,  I got the usual popup window to select the printer I wanted (so I selected another laser printer, just to see if it works) but still, no success. Have it in mind that the laser printer also worked fine in the past. 

I will enable logging this afternoon when I revisit my client and send you the logs along with the #LPT1 files.

Cheers,
Efty ...

 

 

[Jos]

The plot thickens; the #LPT1 files are merely a byproduct. If for instance #LPT1.asc has 0 bytes, it would indicate there’s no vDos’ internal cached printer data the moment the DOS LPT1 times out. Though vDos would then certainly not present a printer selection dialog.

Another option would be to add SPOOL to the printer setting: Nothing will be printed until you press Ctrl+S, but the title bar of the vDos window will show how many bytes are ‘spooled’ and will be send to the printer.

Since by default the same font is used for display and printing: If GREEK is correctly displayed, it should also print correctly. However a matrix printer has a low resolution, so it could be better to let the printer do the rendering.

Jos

[efty]

Hi there Jos,
OK, got some files here for you:

LPT1.asc (2 B)
LPT1.txt (2 B)
these 2 files actually show up as 1KB each in windows explorer 


REPORT.TXT (2.2 KB)
This is actually the report that is generated from the program (it is the output from executing the "sagerep command" as seen in the vdos.log ....

[efty]

...and this is the log file:

vDos.log (10.99 KB)

The actual printing happens on the "sagerep ../glst121 ........ > prn" command. If I run this command without the ">PRN" i get the report.txt in the previous post displayed on the screen, so the program is working ok. It is when i redirect to the printer that nothing happens. If I run the sagerep command on the vdos command line wit the redirect to he printer, it simply prints everything on a single line. If I run the whole thing from the screen program, nothing is printed, as the #LPT1 files indicate...

What i don't understand is the "openfile failed" errors in the log. it is trying to open a VDU file and at another time a _SCTRANS.log file on the actual server rather than the PC - These are SCULPTOR files (SCULPTOR is the 4th Gen Language used by the programs, by the way, and yes, i am than ancient ...) but i do not think that they are the cause of the printing problem...

So yes, I am still baffled after day 2 with this problem...

[Jos]

If I do “COPY REPORT.TXT PRN”, or even “TYPE REPORT.TXT >PRN”, I just get a printout (PDF) that seems to look ok (though Greek).

Still strange that this all happened out-of-the blue the last week. It’s not some oversight like “../glst121” that should be “../glst101”?

Since you also have a problem with sagerep at the command line, could you send me that program and the file that it processes.

Printing seems a rather roundabout in your program, can’t you just print to LPT1?

If you break down for instance “OpenFile failed: ACC\VDU(2) => \\Srv01\Data\ACC\VDU”:
The program opens “ACC\VDU” w/o a drive letter or leading “\”. So “ACC\VDU” to that directory in the current DOS drive and directory.
(2) mains DOS error code 2: File not found.
The current DOS drive and directory resolves to Windows “\\Srv01\Data\ACC\VDU” path/directory.
If these should be opened at the local PC, I guess there would have some switch in the program be set, or DOS environment variable.

Jos

Attachments:

vDos.pdf (11.35 KB)