Multiple RMTPRTQ devices at a single remote location

[Scott Coffey]

I have one printer at a remote location configured as a remote outq
device. I've opened up port 515 in the remote location and the
printer works just fine. Now I want to add a 2nd printer. How do I
do that? The firewall will only allow me to associate port 515 to a
single device (which makes sense). Is there something I can configure
on the '400 side to make it use a different port?
--
Scott at Scott dash(-) Coffey dot net

[Jonathan Bailey]

I'm assuming you have a router at the remote site, otherwise I cant see it working at all.
I don't see a port number on crtoutq, however crtdevprt has one. The other alternative would be to chose to run a pc server at the remote location. We used to have this arrangement, I think using the remote system as the hostname & remote printer queue for the windows printer name. This was removed after either an outage or the whole local domain name change thingy which made a mess of a few things for a while. It worked OK, except the print logging system counted every page as full colour not b&w.
I think I have tried with a personal computer with Win7/XP and sharing the printers installed. Win7 I have now is enterprise edition so you might get that working with other versions?

Jonathan

[Scott Coffey]

I'm not seeing a "port" parm on the CRTDEVPRT command.. where is it?

And I don't understand your explanation of the PC server
configuration. Sorry.

[CRPence]

On 08-Sep-2016 15:27 -0600, Scott Coffey wrote:
> I have one printer at a remote location configured as a remote OUTQ
> device.

Remote Printer Queue (RMTPRTQ) parameter of the Create Output Queue
(CRTOUTQ) allows for an operating-system-dependent name that "can be
*either* the actual name of the device or the name of a printer queue.";
that quote from the help text for that command parameter.

Apparently however, with more recent versions of Windows, that
reference in the help has become somewhat outdated; i.e. should since,
probably imply something about a "Printer Share Name (case sensitive)"
and that "the Windows print queue must be shared" -- see doc links at
end of this post.

> I've opened up port 515 in the remote location and the printer works
> just fine.

The port 515 is the /well-known port/ for the Line Print Daemon (LPD)
feature that would run on the remote server\system.

So from the above quoted text, seems that spooling to the Output
Queue (OUTQ) from the IBM i effects an LPR that is being properly
received via LPD at the remote system; apparently using\listening-on the
port=515 at the remote system, and received\processed at the unstated
RMTPRTQ() by whatever is the [unstated] active LPD feature.

> Now I want to add a 2nd printer. How do I do that? The firewall will
> only allow me to associate port 515 to a single device (which makes
> sense).

I am no expert, but AIUI, an LP Daemon typically would allow for many
incoming TCP/IP Line Printer Requester (LPR) connections. FWiW: Seems
that a firewall allowing for the LPD to accept LPR spooling to just one
specific printer device, seems contrary to the general purpose of the
LPD service with the well-known port.?

> Is there something I can configure on the '400 side to make it use a
> different port?

With RmtOutQ support, not that I am aware of. If there were, then I
would expect there would be a PORT parameter on the Send TCP/IP Spooled
File (SNDTCPSPLF) [aka LPR] command [and on the CRTOUTQ command; there
is no such parameter name to be found on either].

Perhaps naming a /printer queue/ instead of a /device/ for the
RMTPRTQ parameter of the CRTOUTQ would be of help; though see my prior
mention of share-name on newer Win.?

Otherwise, a change to use Remote Printer Device capability via
Create Device Description For Printer (CRTDEVPRT) may be a better
option? AIUI there are fewer restrictions with that feature, than for
the use of Remote Output Queue (RMTOUTQ) capabilities via LPR. Yet,
although with specification of a Device class (DEVCLS) of *LAN, along
with LAN Attachment (LANATTACH) of *IP, plus the Remote Location Name
(RMTLOCNAME) specification of the remote system name or IP address, the
CRTDEVPRT command offers a Port Number (PORT) parameter, I understood
this feature *also* to be dependent upon the LPD feature; i.e. for which
the common\well-known port is 515, so I am unsure that this alternative
even could be fully helpful -- probably that might be a restriction only
for the use of the TSPLPRD LPR Print Driver Exit Program, per the use of
the User-Defined Driver Program (USRDRVPGM), whereas with a more typical
usage specifying a System Driver Program (SYSDRVPGM) for the standard
PJL, SNMP, and IPP for which the former might have hardware-specific
port preferences, the latter [Internet Printing Protocol (IPP)] has a
well-known port of 631.? Anyhow, some of the following links might be
of interest.?:


Configuring a Remote Output Queue (RMTOUTQ) to a Windows Print Queue
Technote Reference #: N1018931
[http://www.ibm.com/support/docview.wss?uid=nas8N1018931]

Recommended Remote Printer Queue (RMTPRTQ) Values for Remote Output
Queues (RMTOUTQs)
Technote: Reference #: N1010172
[http://www.ibm.com/support/docview.wss?uid=nas8N1010172]

Capabilities and Limitations of *LAN 3812 Printer Device Descriptions
Technote: Reference #: N1019003 Historical Number 412453666
[http://www.ibm.com/support/docview.wss?uid=nas8N1019003]

Configuring a *LAN 3812 Device Description that Uses the LPR Print
Driver (TSPLPRD) Exit Program
Technote: Reference #: N1019586 Historical Number 18762910
[http://www.ibm.com/support/docview.wss?uid=nas8N1019586]

--
Regards, Chuck

[Jonathan Bailey]

PORT is on the 1st page of the CRTDEVPRT command for me at V7.1 when I F4 then F9. RMTLOCNAME is 4 pages down. You will have to setup other details as Chuck mentions. F1 adds some info.

For a pc server if you already have that hardware at the remote site then sharing the printers allows you to connect to the pc with the printer name in the RMTPRTQ param of the CRTOUTQ command and the pc re-directs the prints if you're lucky.
I don't like printers. They are all 'semi' intelligent, so they print whats best for themselves not what you wanted. A bit like anti-WYSIWYG. Also people seem to expect that as an ex-RPG programmer I should also have great graphic artistic abilities.

You have some work to do. See if you can concoct what you require locally before trying to implement it remotely.
Windows often saves a lot of data in C:\Windows\System32\spool & if you hold the windows printer you can usually see the 'raw' data in there waiting to go out. You can then delete from the 'whats printing' window so save on some waste paper.

HTH
Jonathan

[Scott Coffey]

On Fri, 23 Sep 2016 05:16:19 -0700 (PDT), Jonathan Bailey

Ah... the "port" parm only shows up when you define the printer type
as *LCL.

I'll take a look at yours and Chuck's suggestions and see if I can
make some progress

Thanks guys.

[CRPence]

On 23-Sep-2016 09:29 -0600, Scott Coffey wrote:
> Ah... the "port" parm only shows up when you define the printer

> type as *LCL. […]

FWiW, not "only" then. The PORT() parameter is conditioned to appear
_eventually_ for other [than local] Printer Device Class (DEVCLS)
specifications as well. Notably, for a LAN Attachment (LANATTACH)
setting of *IP, the PORT() appears sooner than with the default setting
of *LEXLINK, and even sooner if also defining the Device Type (TYPE) of
3812. To see that effect:

On a command-line type [paste] separately, each of the following
lines of text [each beginning with a question mark], and press Enter.
Then see what occurs\appears after each additional Enter is pressed,
having pressed Enter again four more times for the first, and three more
times for the second, but only two more times for the third; after which
the PORT() parameter appears:

? CRTDEVPRT

? CRTDEVPRT LANATTACH(*IP)

? CRTDEVPRT LANATTACH(*IP) TYPE(3812)

Also FWiW: For any command, to determine if there is support for a
PORT() parameter, a similar request can be composed; e.g. see the effect
for the following three command prompting requests, for which, only the
third does not log a msg CPD0043 "Keyword PORT not valid for this command."

? CRTOUTQ ??PORT()

? LPR ??PORT()

? CRTDEVPRT ??PORT()

--
Regards, Chuck

[Scott Coffey]

On Fri, 23 Sep 2016 10:50:57 -0500, CRPence <CRP...@vnet.ibm.com>
wrote:

>On 23-Sep-2016 09:29 -0600, Scott Coffey wrote:
>> Ah... the "port" parm only shows up when you define the printer

>> type as *LCL. [匽

>
> FWiW, not "only" then. The PORT() parameter is conditioned to appear
>_eventually_ for other [than local] Printer Device Class (DEVCLS)
>specifications as well. Notably, for a LAN Attachment (LANATTACH)
>setting of *IP, the PORT() appears sooner than with the default setting
>of *LEXLINK, and even sooner if also defining the Device Type (TYPE) of
>3812. To see that effect:
>
> On a command-line type [paste] separately, each of the following
>lines of text [each beginning with a question mark], and press Enter.
>Then see what occurs\appears after each additional Enter is pressed,
>having pressed Enter again four more times for the first, and three more
>times for the second, but only two more times for the third; after which
>the PORT() parameter appears:
>
> ? CRTDEVPRT
>
> ? CRTDEVPRT LANATTACH(*IP)
>
> ? CRTDEVPRT LANATTACH(*IP) TYPE(3812)
>

Thanks.

> Also FWiW: For any command, to determine if there is support for a
>PORT() parameter, a similar request can be composed; e.g. see the effect
>for the following three command prompting requests, for which, only the
>third does not log a msg CPD0043 "Keyword PORT not valid for this command."
>
> ? CRTOUTQ ??PORT()
>
> ? LPR ??PORT()
>
> ? CRTDEVPRT ??PORT()

Ooooh. Didn't know you could do that. Cool. :)