can't print from IBM mainframe to LJ Pro M452dn printer share

[JillJerome]

You have been very helpful and I am not exactly young myself.

I will take a look in the WIndows Event Log tomorrow morning, that is a good suggestion.

Before Windows 7, we used RPM which had its own very helpful logs.

With WIndows 7 and newer, it's all a mystery.

But I do think the ticket is successfully installing an older driver version.

I have similar problems with FTP software and have to go back to older versions, so that makes sense to me.

thanks,

Jill

[dansdaduk]

>> ... the virtual USB port disappeared.

>> ... So I had to port to use for the driver installation. 

>> ... Do you have nay suggestions on how to work aroudn that?

Sorry - i know little about USB-connectivity issues.

The three printers I currently use (which includes the M475dn, the MFP equivalent of the M451) are network-connected, and when I last worked (in 2009) the rather larger set of printers I had access to were also all network-connected.

[dansdaduk]

Jill

I'm also a bit unclear about some of the mechanisms used when printers are 'shared', and in particular the meaning of the option 'Render print jobs on client computer' which you have enabled.

My understanding (correct me if I'm wrong) is that the computer which the shared printer is attached to is the print server, and the computer which the print request originates on is the client.

And that option determines which of your two computers renders (processes) the print job - the client or the server.

With the option enabled, I think that this implies:

• Your IBM client system is doing the hard work of rendering the text (and other?) objects in the source document into the equivalent objects in the target Page Description Language.

• The Windows 10 server  receives the print job, but assumes that the received data is already printer-ready, and does no processing or reformatting of it - the Windows printer (share) instance is merely used to identify the transport (i.e the port - where to send the print-ready data), but the associated driver itself is not relevant (or used).

If the above is the case, then I'm not sure whether "PCL6" is relevant or not.

Does your IBM system actually generate PCL6 (PCL XL) data - I think that this is unlikely- but I'm also unfamiliar with IBM systems (current or otherwise). 

[A large part of my working life was using ICL mainframes (1900, then 2900 and Series 39 VME) which were IBM competitors - I think that VME is still used, but on Intel emulations, rather than on the original proprietary architecture].

Chris

[JillJerome]

In this case I guess you could say that the workstation is both the print server and the client, since the job originates from the same computer.

However, any client can send a print job to any configured print server, which is simply a shared printer connected to a computer.

THe mainframe sends PCL6 formatted text.

For example, I can request a print job and direct it to one of the other print queues (shared printers that are configured to receive mainframe jobs according th print queue or share name).

I can also connect a different printer to this particular computer, configure the share on it, and direct a mainframe job to it.

The problem definitely resides with this particular printer.

I was able to install the v3 driver this morning, but was still unable to successfully print a mainframe job.

So I don't know what else to do.

I will have to be very careful in the future when I order HP printers because of this issue.

Thanks for your help Chris.

Jill

[dansdaduk]

>> ... you could say that the workstation is both the print server and the client, since the job originates from the same computer ...

That is not my interpretation; the sending computer is the IBM mainframe, so the latter is the client.

>> ... mainframe sends PCL6 formatted text ...

Which means that you do not want a driver on the Windows workstation making any change to this (binary) data.

... and this is what the "Render print jobs on client computer" setting indicates, so the (binary) data should just "pass through".

It also means that the driver associated with the Windows printer instance is totally irrelevant.

The printer instance (selected by your IBM-generated lpr jobs, via the Windows printer 'share name' matching the lpr queue-name) is merely used to identify the target device, via its port information.

[JillJerome]

Okay, so maybe the driver is irrelevant, but it does have to be PCL6.

All I know is that this printer will not work.

If it's not the driver, then what is it?

Please don't say user error!

[dansdaduk]

So can we run a few more tests, to try to obtain a bit more diagnostic data?

If you are happy to do this, what I suggest is:

• On the Windows workstation, temporarily stop the target printer from printing: either set the Printer | Pause Printing option in the "See whats printing dialogue", or perhaps just switch the printer off, or remove the (USB?) cable.

• On the IBM system, generate a test print job: preferably a small one, with "sanitised" data, as I'd like to look at some of the data we (hopefully) capture.

•  The job should be received by the LPD responder on the Windows workstation, but will not be processed because the target printer is paused (or unavailable). 

• Look for the received LPD files - there should be a pair for each job: the control file (possibly with a .cfa extension), and the data file (possibly with a .dfa extension); I'm not sure where these will be placed - perhaps in the %WindDir%\system32\spool\PRINTERS folder?

• If you find these files, make copies of them for analysis.

Assuming that you find these files:

• The .cfa control file should just contain ASCII text, so you can examine it with NotePad.

• The .dfa data file, acccording to how you've described things, should contain the raw PCL XL print job; if you open it in NotePad, most of it will appear to be random symbols, but there should be some ASCII text near the beginning, showing "ENTER LANGUAGE = PCLXL"; if so, then you should be able to analyse the whole file using the PRN FIle Analyse tool in the PCL Paraphernalia application, available via https://www.pclparaphernalia.eu/

[dansdaduk]

>> ... Please don't say user error! ...

I'd only claim this if there was strong evidence that this was the case - I've not yet seen any such evidence.

[JillJerome]

OK I can do that, but it will have to wait until tomorrow. I have to concenrate on other things the rest of today.

I will let you know what I find out.

Thanks for keeping up with this.

Jill

[dansdaduk]

Jill

OK - but I will be out tomorrow afternoon (UK time-zone), so may not see any updates until Saturday.

Chris