Passing -o flags to print server with rembak remote client
Various machines types
I have a queue setup on machine garfield. This queue has
a custom backend program which is an executable, not a
script. The permissions on the script are 6555 root:printq.
I can send jobs to this queue fine, and my backend works
as desired. I have a remote queue setup to this queue from
another AIX client machine socrates. When socrates sends a
job to this queue I have two problems:
1) Flags sent with the -o option are not passed to the backend
on the server garfield.
2) I see the message 0781-312 on the client's console, or in
the user's mail if I don't have writesrc daemon running.
Tested this out by recreating as closely as possible here.
On server fozzy I added this to the /etc/qconfig file:
device = lpzd
file = FALSE
backend = /tmp/echoflags
Then ran enq -d to redigest qconfig.
the script /tmp/echoflags contains these two lines:
echo $* > /tmp/flags
Then, on client machine e3017 I created a remote queue to
this queue named rlpz (remote lpz).
enq -Prlpz -o option1 -o option2 /etc/motd
option1 option2 /var/spool/lpd/asdf23456
You modified your backend slightly and got similar results -
we know that flags will be passed to your backend program.
Next, what generates the message 0781-312 to appear on the
client's console when the job runs on the server?
To recreate this, do a chmod 000 /tmp/flags on the server
or just change your backend /tmp/echoflags script to this:
When you submit a job from the client, it now gets back the
0781-312 Request /etc/motd removed from queue lpz:dlpz.
Could not open or stat file(s)
From the queue and queue device name, we know the message is
being sent back from the server and it is sent back whenever
the backend program tries to write anything to stderr. It
does NOT send this message back when the backend writes to
stdout, though stdout is set to /dev/null.
Closing with Customer Approval
Support Line: Passing -o flags to print server with rembak remote client ITEM: BE9535L
Dated: February 1996 Category: N/A
This HTML file was generated 99/06/24~13:30:22
Comments or suggestions?