× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi James,

Here is a slightly different method for accomplishing
the steps outlined by Scott, which was posted to
comp.sys.ibm.as400.misc a few months ago. 

In terms of the dilemma resolved, it was to print a
pdf file from the IFS but the code should work for a
PostScript file as well. The print file QSYSPDF was a
copy of QSYSPRT with the device type set to *USERASCII
and the replace unprintable character action changed
from *YES to *NO.

On 15 Dec 2004 08:35:35 -0800, in
comp.sys.ibm.as400.misc you wrote:

>Hi Paul...
>I have found the solution:
>
>
>#include <stdio.h>
>#include <string.h>
>#include <stdlib.h>
>#include <recio.h>
>
>#define LEN_BUF 132
>
>int main(int argc, char *argv[]) {
>  FILE *infile;
>  _RFILE  *prtf;
>  char buffer[LEN_BUF+1],FileList[11];
>  int len=LEN_BUF;
>
>  infile = fopen(argv[1],"rb");
>  sprintf(FileList,"QSYSPDF");
>  prtf = _Ropen(FileList, "wr lrecl=132 ");
>
>  while( len>0 ) {
>    memset(buffer,0x00,sizeof(buffer));
>    len=fread(buffer,sizeof(char),LEN_BUF,infile);
>    _Rwrite(prtf,buffer,LEN_BUF);
>  }
>  fclose(infile);
>  _Rclose(prtf);
>  return 0;
>}
>
>
>in this way I can send a pdf file into the correct
>OS/400 OUTQ.

Because the files stored in the IFS are in stream file
format, you need to set the lrecl=132 to get the
buffering correct when the file is passed into an
OS/400 OUTQ for delivery.

One other thing I normally do in the printer file is
to change the parameter 

Unprintable character action:
Replace character  . . . . . . from its default of
*YES to *NO. 

This is just additional safety suggesting to the
operating system that it should not change anything.

HTH

Best Regards,

/Paul
--
Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC
E-mail: ptykodi@xxxxxxxxxx

>date: Wed, 9 Mar 2005 13:20:30 -0600 (CST)
>from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
>subject: Re: outputting postscript to a printer
>
>
>> I have an RPG program that creates postscript.  I 
>> need to send it unchanged to a printer.  I can't
use >> a print file because that will then send an SCS

>> print job and that won't work.  Any ideas on how to
>> do this?

> When you create a print file, it has a device type 
> parameter.  For example CRTPRTF FILE(MYPRTF) 
> DEVTYPE(*SCS).
>
> You're correct that if you specify DEVTYPE(*SCS) the
> system will send an SCS print job to the printer.
But > if you specify DEVTYPE(*USERASCII) the data will
be 
> sent to the printer without any changes.
>
> The way I like to do it is generate the PostScript 
> file as a stream file in the IFS. The IFS APIs will 
> automagically do the ASCII to EBCDIC translatation 
> for me. Then, if I want to debug things, I can
easily 
> NFS/SMB mount my IFS and open the stream file with
my > favorite text editor, or even use ghostview to
see 
> what it looks like.
>
> When I'm ready to print it, I re-open the stream
file > in my RPG program, this time in binary mode (so
no 
> translation takes place) and read fixed-length
chunks > of data (the length matches that of my print
file) 
> and write the results to the *USERASCII print file.
>
> On the final record that I write to the print file, 
> the data size will be smaller than the record size 
> (most of the time).  I wasn't exactly sure what to
do > with this -- I ended up padding the data with
ASCII 
> blanks at the end and that seems to work okay. I 
> think the blanks are considered whitespace in 
> PostScript and are therefore ignored.
>
>Make sense?



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.