Foxplus printing using ? in SCO Unix - page ejects after each line

[mduddytel]

We have some print programs that have suddenly stopped working after many years of being just fine. Might be related to newer printers.

The Foxplus programs us ? to output each line, including a font code in the output line to change for titles, subtotals, etc. Recently some (but certainly not all) of these programs have started ejecting the page after each line is printed. Fonts seem to print fine, nothing garbled and output is correct.

But each new line is printed on a new page, on the line it would have been at on the original page. Changing the fonts doesn't seem to make a difference. We can use report in Foxplus but lose some functionality that way.

Any ideas? TIA for your help.

 

[TamarGranor]

You might try some alternate printer drivers, but this is likely a problem of using 30-year-old code techniques on modern technology.

Tamar

 

[mduddytel]

I would think that was true, but there are over 50 "reports" in the system that still use this methodology, same network, same printer and they work fine.
Just to think through a possible driver problem out loud:
The report is running in SCO Unix - it is very rare that we encounter a problem where a printer driver makes any difference since the SCO printer scripts do not use them. Yes, I understand that the driver makes a difference for the printer itself, but this is not a specific printer issue, and the same problem occurs on old printers and new, network wide. I would think that a driver issue would have a more global impact.


Margaret

 

[dbMark]

So what had just changed when you started getting the ejects before or after each line? Did the SCO Unix workstations get hardware or software upgrades or updates? Any changes made to the FoxPlus apps or settings? Are ALL of the reports doing this on these affected workstations or just some of them? Do ALL the SCO Unix workstations have this problem or just some of them?

The reports used to work and now some or all don't. If you can narrow the issue down and determine what changed and triggered this failure then you can better determine the fix.

I believe FoxPlus is an old DOS app, even before FoxPro for DOS as I recall.

 

[Olaf Doschke]

All I can contribute is, legacy printing code using ? and SET PRINTER ON still will need a correct printer driver behavior for AT to work and not pageeject with any output. So it's still very likely the reason you fail on this. You might output to ascii text file via SET ALTERNATE, this still understands AT positioning, but won't work with fonts and foreget about picture options.

Using ??? would enable you to send escape sequences or other printer command code directly.

Anyway, it looks like new printers don't work with this old dog anymore.

Bye, Olaf.

 

[mduddytel]

We have not yet identified any change anywhere that has caused the problem to occur. The problem is not restricted to a workstation or a printer. There were no changes to the network, printers, workstations (Windows or Unix) or to Foxplus. The behavior of the programs that exhibit the problem is the same across the entire network.

There are dozens of other reports using the ? and "set printer on" methodology that have no problems, all printing from the same workstations, on the same network to the same printers, using the same fonts and the same source data as the output with the problem. Out of 50+ reports we have two that exhibit this behavior, but only two.

Olaf - there are lots of printers - all modern HP printers, some brand spanking new Enterprise level machines - that work fine with that old dog.

Foxplus is old - the precursor to FoxPro. It is running in SCO Unix environment, not DOS. There was a DOS version that was it's contemporary.

Escape codes are being sent to the printers directly.

There is no page eject in the commands being sent to the printer, but on some lines there is a command that changes the font before it prints the line (sends the escape code sequence to the printer at the start of the output line. What is puzzling is that the problem is not occurring on the lines where the font code is sent with the output, but rather when the "details" line of the output is printing - when there are no escape codes being sent.

I appreciate the responses here.

 

[Olaf Doschke]

Escape codes are being sent to the printers directly.

There is no page eject in the commands being sent to the printer, but on some lines there is a command that changes the font before it prints the line (sends the escape code sequence to the printer at the start of the output line. What is puzzling is that the problem is not occurring on the lines where the font code is sent with the output, but rather when the "details" line of the output is printing - when there are no escape codes being sent.

With ? you're using features like FONT clause and PICTURE clause causing VFP or the printer driver (not sure) causing the right escape sequences for the printer. If you want to control a printer directly you use the ??? command, not ? command.

Bye, Olaf.

 

[mduddytel]

1) This is not a VFP application - it is Foxplus. It is sometimes surprising the features that are available in Foxplus but you cannot assume VFP functionality is available.

2) Defining a "font" as a character string with the escape code sequence works just fine when sending it as part of a ? or ?? line.

 

[Olaf Doschke]

FoxPlus vs VFP lessen taken. OK, so to clarify if you say you use ? with FONT, you don't mean the FONT clause but output the necessary escape sequence + fontname?

When you make use of the FONT clause in VFP, eg ? "Hello, World" FONT "Broadway" you don't output escape sequneces, and VFP doesn't know all escape sequences of all printers in the world, surely not whatever printers will be coming in the future, so the support of the FONT clause has to be done by a printer driver, that's my line of thinking, why a printer driver can be in your way. How do you thinkg VFP (and if you use the FONT clause also Foxplus) does set the font itself without printer driver? Do you think there is a generic code working with any printer?

You only print without using any printer driver and control the printer yourself, if you don't make use of such clauses. In VFP and on Windows you have to set up the printer to use the "Generic/Text" printer driver, which really is just a stub of a printer driver forwarding whatever you send to it. I don't know if there is something similar in SCO Unix, but you never talk to the printer directly anyway, at least in VFP/Windows. On Windows setting up a printer you define it acting on a hardware port (serial or usb) and through a driver, there is no way to setup a printer driverless and just knowing the port the printer is connected to, directly sending though this port is not done by the ?-command, you SET PRINTER TO printername and of course SET PRINTER ON to let VFP ?-command send it's output to the printer driver associated with the printername in Windows. To print directly the only other way would be low level opening a COM port and send to it, but that has much more overhead.

Bye, Olaf.

 

[Dan Freeman]

Olaf, in FoxPlus there was no FONT clause on ?. It was standard practice to create variables for the necessary font/formatting requirements and prepend them to the string to output.

lcEsc = Chr(27)
lcBoldOn = lcEsc + && Printer escape code for turning on bold
lcBoldOff = lcEsc + && Printer escape code for turning off bold

?lcBoldOn + "String for output." + lcBoldOff

The FONT clause on ? was new in VFP (and relies heavily on the graphical environment's printer drivers). Foxplus was character-mode only and predated printer drivers pretty much.

The Unix version of Foxplus was the one version that I never had any experience with. I'm also unfamiliar with SCO-UNIX. Is it still character-based? If it's GUI these days, it will have a printer driver sitting in the ooze. On Windows, we often resort to using the "Generic/Text" printer driver to get manually created output to work.

 

[mduddytel]

SCO Unix is character based, no GUI, no mouse support, no printer drivers. Printers are typically configured to default to a "line printer" font. The reports that are having the printing problem, and many that are not having problems, use the methodology that Dan Freeman describes.

 

[Dan Freeman]

The usual question asked when something that used to work suddenly stops working is "what changed?"

Did someone install a maintenance release of the OS?

 

[mduddytel]

That's the rub - there's nothing we can identify that has changed. Clearly something triggered the problem, but since the problem is so isolated it is proving very difficult to diagnose.

There have certainly been no OS changes, and no changes to the programs themselves, the programs do not reference particular table or data source. We have had printer changes but nothing that coincides with the "break" in the program output. One day the program works fine, the next it does not. And there are are only two reports out of 50 that have the problem.

I tend to believe it is not printer related since the same results occur regardless which printer the report is sent to - any one of 20 different laser printers have the same result.

The problem started "out of the blue" a little over a year ago for one report we run every day, sometimes twice a day. The report uses a lot of fonts, manipulating them for headings, etc. and output is generated one line at a time. Then, about two months later the second report had the same type of problem - also a report that manipulates fonts, but different data and printed elsewhere on the network.

We implemented work arounds for both reports and the problem has not shown up anywhere else (we have added a bunch of new printers in the mien time). I circled back to one of these reports late last month to see if the problem still existed and it does, but still only for these two reports.

 

[Olaf Doschke]

We have had printer changes but nothing that coincides with the "break" in the program output. One day the program works fine, the next it does not. And there are are only two reports out of 50 that have the problem.

Well, then only use the reports on the one day.

Funny. Well, you have to find out what difference was introduced. There is not much involved from Fox to a printer in direct print mode, but there still are settings of ports and I don't know abou Unix, but most probably even there you have spooler hard and/or software. The output is piped from Fox to some printer at some port. All I know is CUPS is not a very user friendly thing, I know someone cursing on it, though that has nothing to do with Foxpro at all.

And on the topic of spooling I can contribute the experience of a Windows based case, where VFP reports were blamed to print slow (not wrong, but very slow), whereas that was caused by wrong spooling. It may be a good thing to ask a net/sys admin with some Unix knowledge about CUPS and spooling or whatever similar mechanisms are in between Foxpro and the printers. It clearly isn't code, because either somethings works reproducable or doesn't work reproducable, even when it only works sometimes, it's a sure sign the code osn't broken, at least not fully. Obviously, it may depend on some pattern of data printed, length of reports, whatever feature you discover is the fault, but things not working sometimes, even often, but also working sometimes, even when seldom, show there is an infrastructural problem, not a code problem.

Bye, Olaf.

 

[TamarGranor]

I think the question I'd be asking is what's different about these two reports than all the others. What do they do that the others don't? Or conversely, what don't they do that the others do?

Tamar

 

[mduddytel]

At this point I am pursuing a possible data problem - not sure that makes sense but it cannot hurt to look.

Both of these reports use a mechanism where a table structure is copied to a temp table that is then used to load data for the output (temp file is discarded at the end of the report). The structure file that each report uses is unique to each report - perhaps there's something in that structure that took a hit and is the cause of the problem (????). The temp file works fine for creating an export file, and there's no problem viewing the data. Seems a little far fetched but we will see.

 

[Dan Freeman]

The structure of the temp file won't have anything to do with it because the printer never sees that.

Control characters embedded in the data is where I'd look as the next step. An embedded page eject would likely not be visible on screen. Likewise Chr(0), which might be interpreted as end of print job.

 

[mduddytel]

There do not appear to be any control characters in the data. The same data is used to support multiple reports, but only one report exhibits the problem.

There is, however, a unique work table that is used to hold data for the report with the problem. That table is zapped and reloaded each time the report is run.

 

[dbMark]

Do the affected workstations generate some good reports as well as the bad ones? If so, are the successful reports going to one print spooler and the bad reports going to a different one? Then look to see what is different or has changed between the print spoolers.

 

[mduddytel]

Well I'm happy to say we found the problem.

Long story short - there is a program (written a very long time ago) that is called to lock the current record with some additional functionality. It also saves the current screen, then tries to lock the record, writing a notation to the bottom of the screen if there's a problem doing that. After the record is locked or the user aborts the lock, the program restores the screen and returns.

When this routine is called in the middle of a print sequence where
a) device is set to print, and
b) output is generated using "@ x,y say blah"
the result is that the report ejects the the page every time the "screen" is restored. The next block is then printed (several lines of output for each record), then the routine to lock the record is called and another page break occurs.

The fix was to not call this routine, but rather to simply lock the record that needed to be updated using rlock(). The report now prints fine. It seems that the screen restore was impacting the output.