Hi,

this question might sound a bit stupid, but if I need to write an
application in C that will print under AIX, how would I approach this?
Are there any special files in /dev/... that I could open to submit
something to a print queue.

I know how to submit jobs into a queue with commands on the command
line, but I don't think the way to do it would be to have my
application call the command line tool?

I have searched a lot for any little piece of sample code, but couldn't
find any. Sorry if I overlooked the obvious.

Regards,
Torsten

In article <1124277958.744291.283520@o13g2000cwo.googlegroups .com>, "Torsten
Schlabach" <tschlabach@gmx.net> writes:
> Hi,
>
> this question might sound a bit stupid, but if I need to write an
> application in C that will print under AIX, how would I approach this?
> Are there any special files in /dev/... that I could open to submit
> something to a print queue.
>
> I know how to submit jobs into a queue with commands on the command
> line, but I don't think the way to do it would be to have my
> application call the command line tool?
>
> I have searched a lot for any little piece of sample code, but couldn't
> find any. Sorry if I overlooked the obvious.
>
> Regards,
> Torsten
>

how about using

system("lpr -Pprinter filename");

?

I wrote:

> but *I don't think* the way to do it would be to have my
> application call the command line tool?

Are you really telling me that the only way to print out something from
an application is to write it to a temporary file and then issue a
shell command through system?

I have a hard time believing this.

check on www.redbooks.ibm.com the book
"Printing for Fun and Profit under AIX 5L"

Vlad,

> check on www.redbooks.ibm.com the book
> "Printing for Fun and Profit under AIX 5L"

Certainly and interesting reading and much better than the original AIX
"Guide to Printers and Printing", but it still did not answer my
question.

To what (special) file do I have to write in order to submit a print
job into a queue. If the queue name was "foo", what how would my
fopen() statement look like?

In article <1124282422.684856.248280@g47g2000cwa.googlegroups .com>, "Torsten
Schlabach" <tschlabach@gmx.net> writes:
>
> Are you really telling me that the only way to print out something from
> an application is to write it to a temporary file and then issue a
> shell command through system?

Well, I'm not sure if it's the only way,
but it appeared to me as a pragmatic one.
When it comes to printing, it's mostly
about sending a PostScript file to a network printer.
And for that the shell command solution should be sufficient.

> I have a hard time believing this.
>

It's certainly not the most elegant one,
but the alternative would be to deal with the
intrinsics of AIX's queueing system, and I somehow
doubt that this would be less work than creating
a tmpfile and then dumping it to the printer.

I have a related problem: how to (quietly and portable) determine if
a given identifier is truely the name of an existing print queue,
and not just some plain file name or X $display.
"lpstat" wouldn't help I guess, since it's unclear if a
queue exists, but is down, or if it doesn't exist at all.

If all you want to do is write straight ASCII text to a printer, then
locally defined printers will normally have a device file such as
/dev/lp0 listed on the system.

Remote printers and network printers don't have this ability...you need
to send the data to a remote host so it needs to be able to send
something tangible (such as a text file) and won't allow you to have
direct access to its printer pipes in /dev.

Also, most printers nowadays make use of a printer queue so you can
define the default font, print width, lines per page, etc...this is why
you probably want to have the data you send out go to a printer
back-end such as piobe or rembak and let it do the printing for you.

As MikeK demonstrated, the most efficient way (although not always the
best to hear for a programmer) is to write the report or form you want
to print to a file and then direct that file to the printer using a
system call.

Unless you are willing to write a device driver and include that logic
in your code, you will probably want to send data to printers in that
fashion, so that the software can worry about generating its report and
not concern itself with printing (for example) in Courier 17 because
the 132 column report is actually being printed on an Hp Laserjet that
is only 80 columns wide.

Is there a reason you are dead-set against creating a flat file to
print from? Security issue such as check printing? Special graphics
printing that needs to talk to the device? Don't want to have to build
in the code for creating the file and cleaning it up afterward?

steven_nospam at Yahoo! Canada wrote:
> If all you want to do is write straight ASCII text to a printer, then
> locally defined printers will normally have a device file such as
> /dev/lp0 listed on the system.
>
> Remote printers and network printers don't have this ability...you need
> to send the data to a remote host so it needs to be able to send
> something tangible (such as a text file) and won't allow you to have
> direct access to its printer pipes in /dev.
>
> Also, most printers nowadays make use of a printer queue so you can
> define the default font, print width, lines per page, etc...this is why
> you probably want to have the data you send out go to a printer
> back-end such as piobe or rembak and let it do the printing for you.
>
> As MikeK demonstrated, the most efficient way (although not always the
> best to hear for a programmer) is to write the report or form you want
> to print to a file and then direct that file to the printer using a
> system call.
>
> Unless you are willing to write a device driver and include that logic
> in your code, you will probably want to send data to printers in that
> fashion, so that the software can worry about generating its report and
> not concern itself with printing (for example) in Courier 17 because
> the 132 column report is actually being printed on an Hp Laserjet that
> is only 80 columns wide.
>
> Is there a reason you are dead-set against creating a flat file to
> print from? Security issue such as check printing? Special graphics
> printing that needs to talk to the device? Don't want to have to build
> in the code for creating the file and cleaning it up afterward?
>
I think the original poster is used to an environment where
you didn't have to explicitely create a file before sending it
to a printer and may not realize that this is the reality.

Whether you print from MSWindows, VMS, MVS, AS/400, a file is created,
somewhere, and that file is sent directly to the printer. Output to
a printer device is never done (except in some realtime applications).
The printing resource is to valuable to be kept idle waiting for use
by a single program.

AIX/unix doesn't automatically save output to a file and then send it
out for printing. You have to save the output to a file and then
send it for printing, taking into accoutn that your output may need
final processing so that it prints in PCL, Postscrip, or whatever.

sol gongola

> this question might sound a bit stupid, but if I need to write an
> application in C that will print under AIX, how would I approach this?
> Are there any special files in /dev/... that I could open to submit
> something to a print queue.
>
> I know how to submit jobs into a queue with commands on the command
> line, but I don't think the way to do it would be to have my
> application call the command line tool?

I think it would be preferable to use a queue instead of opening and writing
to /dev/lp## file for several reasons:
1) /dev/lp## only exists for local (serial/parallel) printers - what if you
have a network printer?
2) Let the queue do any formatting without changing your code for various
types of printers.

The easiest way I can think of is to just:
fp = popen("/usr/bin/enq -Pqname");
write your print data to fp
close(fp);

By using the queue instead of just writing to /dev/lp, you'll have the
flexibility to use print queues that are local, network, etc.

Best regards,
Paul