Quote

They changed the printer to RAW.

I tried to print from the new system and it did not compress. The programs have a control character set that if > 80 characters is put in compression code 1st for 16.5 cpi and end of report it puts back to 10 cpi. That works on all amos and ashell (windows) systems.

To test that they are setup correctly, I saved a file from the old system (c22.txt attached) then I printed from old system to that printer and it worked. I ftped that file to the new system and tried from a dot, print umedp1=c22.txt and it worked perfectly. So then I created the same report on the new system but it did not compress.

I saved that file c2222.new to the disk and tried to print umedp1=c222.new but it did not work. The only difference is the c22.txt (created on the amos box) is it says DOS or AMOS format when I vue the file on the linux box. The c222.new and the c22.txt have the same control codes to compress the printer at the beginning and end of file. I already look at that.
Although it's not clear to me what code module (printer driver? subroutine?) is responsible for processing the control code and turning it into the printer instruction for compressed print, the fact it works when using PRINT.LIT to print a file created under AMOS and FTP'd to A-Shell/Linux proves that the mechanism is working there as well.

The issue is what's the difference between the print file created under AMOS (or A-Shell/Windows) and the one created by the same application under A-Shell/Linux? The VUE message about DOS/AMOS format provides the clue: the line terminators are different. Under AMOS and Windows, you'd have CRLF terminators. Under A-Shell/Linux, by default you'd have only LF terminators in the print file. (This conforms with the normal UNIX/Linux standard.)

I don't know why that is interfering with the mechanism that is setting up compressed print for you, but you can easily have A-Shell use CRLF terminators instead: just add the following line to the miame.ini file:

OPTIONS=CRLF

Admittedly it's buried in the documentation, but here are a couple of links ...

MIAME.INI OPTIONS
OPTIONS=CRLF

A few related comments:

1) For better or worse, this is a global setting (affecting all sequential files created by A-Shell). However, if necessary, you could turn the option on and off at the program level using the MX_GETOPTIONS and MX_SETOPTIONS routines. (The option flag is GOP_CRNL)

2) In most cases, A-Shell will handle either type of line terminator when inputting text files. This applies to all variations of INPUT, COMPIL, and VUE. (As you noted, VUE will display an advisory message when the terminators in the file don't match the expectation for the environment. VUE also has a command mode option - CRLF ON or CRLF OFF, allowing you to convert the terminators when saving the file.

3) One way to check the terminators is to first use SET HEX and then PAGE DUMP which will allow you to see whether there is a 0D 0A at the end of each line, or just 0A. (Or something messed up, like OD OD 0A, or just OD, which can sometimes happen when conversions go awry.)

4) FTP ASCII mode transfers may (depending on the configuration) convert the line terminators during transfers. This doesn't happen with BINARY mode transfers, and may be disabled by most Linux implementations of FTP due to security concerns.

5) Yet another solution would be to shell out to the Linux commands dos2unix and/or unix2dos to convert the terminators on just one file. For example, leaving everything the way it is now (presumably with LF terminators) you could insert this call just before your XCALL SPOOL ...

Code
xcall HOSTEX, "unix2dos report.prt"
6) Given the same terminators, I can see no reason why the print file created under A-Shell/Linux should differ from the one created under A-Shell/Windows or AMOS. If they have different hashes but you can't otherwise see what the difference is, I would first check the sizes in bytes (to see if they are only off by 1 byte, or maybe one per line). And you can use the Linux command cmp -l file1 file2 to display byte-level differences between them.