We're trying to upgrade from RHEL 7 to 8 (and upgrading UniVerse to the supported versions from 12.1 to 12.2.1)

Upgrading our test system to RHEL 8 (using the LEAPP in-place upgrade method) and then updating UniVerse to 12.2.1 worked as expected, and critically printing continued to work as normal.

However performing this on our production system, results in printing not functioning after the RHEL upgrade. I posted about this issue when we attempted this initially last year and as suggested we've taken a clone of the production system so we can experiment with it freely.

So far we've tried:

RHEL Upgrade only > printing fails > then Universe update > printing still fails

Universe update > printing ok > then RHEL > printing fails

Printing direct from the OS level e.g. # cat testfile.txt | lpr -P PRINTERNAME - this results in printer output.

So it seems performing the upgrade to RHEL 8 changes "something" in UniVerse which prevents UniVerse from spooling to the printer itself. 

Can anyone suggest some troubleshooting steps we could try? Red Hat support attempted some analysis their findings just pointed the finger back at UniVerse predictably.

Thanks.

------------------------------
Matthew Wright
Analyst
Tomago Aluminium Co PTY Ltd.
Tomago NSW AU
------------------------------

Hi Matthew,

What actually happens when something is printed? Does the print job show up in a SPOOL -LIST output? If so, what is the status? Is the spool file found in the /usr/spool/uv folder or wherever you have defined the spool location. Are you using driver scripts or sending output directly to printer devices? Do the print jobs just disappear? 

Thanks,

Neil

Thanks Neil - no the print job doesn't seem to appear in SPOOL -LIST output.

We're using the driver files like: /usr/ptr/PRINT1.drv

$cat PRINT1.drv
cat - | lpr -P PRINT1 -h

It doens't look like the job gets created at all.. the spooler is running though.

Thanks Neil - no the print job doesn't seem to appear in SPOOL -LIST output.

We're using the driver files like: /usr/ptr/PRINT1.drv

$cat PRINT1.drv
cat - | lpr -P PRINT1 -h

It doens't look like the job gets created at all.. the spooler is running though.

What does usa look like when you run it directly as the user triggering the print, this will make sure there are no print_group issues.

Another thing to make sure is it's getting as far as the driver, you can have the output go to two places using tee or you can write out to a file instead of sending to a printer:

```

cat - | tee output.txt |lpr -P PRINT1 -h

```

The below will write out the data to a file.

```

cat - > output.txt

```

If it gets to the driver, presumably its going to be some issue between Linux and the printer.

If it fails to get to the driver then its completely in UniVerse.

Hopefully this helps narrow things down.

What does usa look like when you run it directly as the user triggering the print, this will make sure there are no print_group issues.

Another thing to make sure is it's getting as far as the driver, you can have the output go to two places using tee or you can write out to a file instead of sending to a printer:

```

cat - | tee output.txt |lpr -P PRINT1 -h

```

The below will write out the data to a file.

```

cat - > output.txt

```

If it gets to the driver, presumably its going to be some issue between Linux and the printer.

If it fails to get to the driver then its completely in UniVerse.

Hopefully this helps narrow things down.

I was also going to ask what happens if you just do something as simple as "LIST VOC SAMPLE 10 LPTR". Are any errors produced? If the job doesn't show up in a SPOOL -LIST, did any file get created in the spool directory? 

If you do the same "LIST VOC SAMPLE 10 LPTR" command after setting a FORM name which doesn't exist, does the job show up in the queue? If so, that would indicate UV is creating the job correctly and they must be getting lost at the driver level? 

>SETPTR ,,,,,,FORM DUMMY,BRIEF
>LIST VOC SAMPLE 10 LPTR
>SPOOL -LIST
Printer: lp                 Q: on    P: error   Form: <EmptyForm>
Job  # Job description  User name        Pri Forms       Size  Cps Status  Delay
000005 UniVerse         root:1            30 DUMMY         747   1 wait

What does usa look like when you run it directly as the user triggering the print, this will make sure there are no print_group issues.

Another thing to make sure is it's getting as far as the driver, you can have the output go to two places using tee or you can write out to a file instead of sending to a printer:

```

cat - | tee output.txt |lpr -P PRINT1 -h

```

The below will write out the data to a file.

```

cat - > output.txt

```

If it gets to the driver, presumably its going to be some issue between Linux and the printer.

If it fails to get to the driver then its completely in UniVerse.

Hopefully this helps narrow things down.

Thanks Neil - this is what I got when trying to set a dummy form, interestingly it's tried to send it to the first printer in my list, is that what you'd expect?

Printer: BC01               Q: on    P: on    Form: DEFAULT
Job  # Job description  User name        Pri Forms       Size  Cps Status  Delay
029083 UniVerse         uvadm:1           30 DUMMY         620   1 wait

Hi Matthew. The SPOOL -LIST output does show the job is being created. And I would expect the job to go to the first printer in the list. If there is no matching FORM name for the job or the job wasn't specified to go a specific printer, it will end up in the first print queue.

Since UV appears to be creating the print jobs, the issue would seem to be at the driver level. That is, getting the spooled output directed to the printer. Based on another update I saw this morning, redirecting the output to a file appeared to  work as well.

Do any of the error related files in the /usr/spool/uv directory contain any information which might help?

We're trying to upgrade from RHEL 7 to 8 (and upgrading UniVerse to the supported versions from 12.1 to 12.2.1)

Upgrading our test system to RHEL 8 (using the LEAPP in-place upgrade method) and then updating UniVerse to 12.2.1 worked as expected, and critically printing continued to work as normal.

However performing this on our production system, results in printing not functioning after the RHEL upgrade. I posted about this issue when we attempted this initially last year and as suggested we've taken a clone of the production system so we can experiment with it freely.

So far we've tried:

RHEL Upgrade only > printing fails > then Universe update > printing still fails

Universe update > printing ok > then RHEL > printing fails

Printing direct from the OS level e.g. # cat testfile.txt | lpr -P PRINTERNAME - this results in printer output.

So it seems performing the upgrade to RHEL 8 changes "something" in UniVerse which prevents UniVerse from spooling to the printer itself. 

Can anyone suggest some troubleshooting steps we could try? Red Hat support attempted some analysis their findings just pointed the finger back at UniVerse predictably.

Thanks.

------------------------------
Matthew Wright
Analyst
Tomago Aluminium Co PTY Ltd.
Tomago NSW AU
------------------------------

Ok I've got a solution for this - it seems that after the upgrade our /usr/ptr .drv files required an extra options flag.

previous: cat - | lpr -P PRINTER -h

new: cat - | lpr -P PRINTER -h -o page-ranges=1-

Thanks for everyones responses, the relief is real! :D

That is very interesting. 

Do you know why the simple tests at the OS prompt worked without that option? Size of the print jobs?