RE: Cannon ImageRunner 5000

["Leland, David" <dleland@xxxxxxxxxx>]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
Paul:

Well, I've tried everything.  I created the spool files as QSECOFR.  I added
authority to the QPSPLPRT printer file of *PUBLIC *ALL.  Nothing.

I don't find the JOBSEP parameter on the SNDTCPSPLF command and I see by
looking at the job log of the remote writers, that they're actually using
the SNDTCPSPLF command to print.  That makes me wonder if job separators are
even possible using the Remote Outq method.  I have yet to hear of anyone
else that is actually getting job separators to print using this method of
printing.

Dave

-----Original Message-----
From: Paul Tykodi [mailto:paul@intermate-us.com]
Sent: Monday, November 25, 2002 10:39 AM
To: midrange-l@midrange.com
Subject: RE: Cannon ImageRunner 5000


Hi David,

Some information from IBM OS/400 TCP/IP Manuals regarding the operation of a
remote output queue is as follows:

<Begin IBM Info>

11.4.6.4 Authority for Sending Spooled Files

To send a spooled file, you must have one of the following authorities to
the file or to the output queue that the file is on.

Be the owner of the spooled file.

Have spool control authority (*SPLCTL).

Have job control (*JOBCTL) special authority on an operator-controlled
(OPRCTL(*YES)) output queue.

Be the owner of the output queue.

Have add, delete, and read authority to an output queue created with
AUTCHK(*DTAAUT).

Have read authority to output queue created with DSPDTA(*YES).

If you are using LPR through the Remote Writer, then the Remote Writer
changes its job attributes to run under the user profile that created the
spooled file. The writer does not change its job attributes to those of a
system profile. Instead, it uses the default user profile of QSPLJOB. In any
case, the Remote Writer always passes the authority test.

<End IBM Info>

The printer file used by OS/400 to create a job separator page is QPSPLPRT.
I wonder if the authority of the jobs you are sending through the Remote
Output Queue in question is having a problem gaining access to the QPSPLPRT
printer file and the job banners are not being created.

Because I test from an AS/400 development machine, I always sign in as
QSECOFR just to miss any permissions related issues that might impede the
printing test that I want to execute. Maybe you could create a test file,
using the QSECOFR User ID on your system, to print a spool file through this
remote output queue. If it arrive with a job separator banner at the
printer, you would know that you were experiencing a permissions issue with
access to the QPSPLPRT printer file.

The other option that is different between our systems is that the default
for the SEPPAGE parameter is *YES on my system. I don't change the value to
*NO when testing job separator pages via a remote output queue.

I don't know whether either of these ideas might be helpful to your current
situation or not.

Best Regards,

/Paul

>From: "Leland, David" <dleland@Harter.com>
>To: "'midrange-l@midrange.com'" <midrange-l@midrange.com>
>Subject: RE: Cannon ImageRunner 5000
>Date: Fri, 22 Nov 2002 13:06:58 -0600
>Reply-To: midrange-l@midrange.com
>
>Paul:
>
>Yes, I have 4 entries in the remote outq.  They have all been produced by
>different jobs.  Two of them have their FILESEP parameter value set to 1
and
>the other two have it set to 0.  All 4 of them print without a separator
>page.  The JOBSEP parameter on the outq description is set to 1 and the
>SEPPAGE parameter is set to *NO also.
>
>Dave

(snip)

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.