Printing ASCII data in an AS400 PF
ken....@mhcm.com
produced by a Windows application. Basically, we printed to a file on
the PC, copied the file to the IFS, then CPYFRMSTMF'd the file to a
physical file.
How can we now print this data? We can't quite get CPYF to a printer
file to work. Even if I create a printfile called ASCIIPCL as DEVTYPE
(*USERASCII) RPLUNPRT(*NO), it doesn't come out right. We can see
some of the PCL data in the printout, and the PF does contain the
original untranslated ASCII data. The ASCIIPCL printfile is a modified
copy of qpnpsprtf. Is a parm wrong, or should I use an API? I also
changed ASCIIPCL to PAGESIZE(66 200 *ROWCOL), because the PF has 200-
byte records and the CPYF complained when ASCIIPCL was 132 columns.
The CPYF is
CPYF FROMFILE(pf_name) TOFILE(ASCIIPCL)
Also, the resulting splf has the attribute
PC printer emulation . . . . . . . . : N
while splfs actually produced from PCs have this as Y. Our printers
are *LAN-attached HP-compatible laser printers. We're not doing
anything fancy (APF, IPDS, PSF, etc.) so far as I know. We normally
just print PC documents, and AS400 splfs using HPT.
TIA,
Ken
Sent via Deja.com http://www.deja.com/
Before you buy.
Larry W Loen
>
> We have an AS400 physical file into which we've copied a PCL datastream
> produced by a Windows application. Basically, we printed to a file on
> the PC, copied the file to the IFS, then CPYFRMSTMF'd the file to a
> physical file.
>
> How can we now print this data? We can't quite get CPYF to a printer
> file to work. Even if I create a printfile called ASCIIPCL as DEVTYPE
> (*USERASCII) RPLUNPRT(*NO), it doesn't come out right. We can see
> some of the PCL data in the printout, and the PF does contain the
> original untranslated ASCII data.
This reminds me of the old joke. "Doctor, when I do this,
it hurts" and the doctor responds "don't do that."
Short answer: Print if from IFS.
You have, essentially, "fibbed" to the system about the character
set of the data. AS/400 DB has no understanding of anyone who
manages to stuff ASCII data into an AS/400 DB. It has no
ASCII code pages in its supported code pages. If you look under
DSPFD, you'll probably see a code page listed (like 037) that is
some EBCDIC code page or other. DSPFFD will reveal any field
specific code pages you have set that are not the general
one applying to the DB as a default. That's probably not an
issue here, but it may be worth looking at to be sure.
Regardless, it will either be EBCDIC
or 65536, the latter of which is
"no comment" which, for this discussion,
may as well be EBCDIC.
The system generally assumes that if a DB is marked with a code
page, that's the right way to interpret the data. By managing
to turn off translation somewhere along the
way, you've effectively faked out the system
and now are complaining because the system is, in fact, thoroughly
fooled. Whether it says "EBCDIC" or "Unknown", the printer
support doesn't know what the data "really" is. Whatever it thinks,
it is _not_ thinking the data is ASCII, because you've
told it is something else.
Larry Loen speaking on his own. . .
Rodney Johnson
printer file to work."
When you create a printer file (or change/override one) to a device type
of *USERASCII, the data is taken AS IS and placed into the spooled file
UNCHANGED. The DB members used to store the spooled data are created with
a CCSID of 65535. Most of the printer file attributes do NOT apply to
USERASCII spooled files. Page size, margins, fonts, record length all
really don't mean much. If you are using the AnyImage support, then the
some of the attributes start to play a part (read about the Convert Image
API or the Any Image section of the Printer Device Programming book for
more details). Since you are going to a HP printer, I doubt you are using
the AnyImage support to transform PCL to PS Level 1.
At the time the spooled file is PRINTED, NO translation is done with the
exception of HPT when transforming EBCDIC to ASCII. In this case,
HPT won't do ANYTHING with the spooled file (because it is *USERASCII).
The spooled data will be passed STRAIGHT through to the printer. That
means that when you placed your PCL data stream into the DB file, you must
have put all of the necessary file formatting and printer setup in there
as well.
When you place the PCL data into the DB file, you need to make sure that
the DB file is created with a CCSID of 65535. I'm not sure what the CPYF
code will do if you have a different CCSID. All I know is the print side
will NOT modify the data stream.
ken....@mhcm.com wrote:
> We have an AS400 physical file into which we've copied a PCL datastream
> produced by a Windows application. Basically, we printed to a file on
> the PC, copied the file to the IFS, then CPYFRMSTMF'd the file to a
> physical file.
>
> How can we now print this data? We can't quite get CPYF to a printer
> file to work. Even if I create a printfile called ASCIIPCL as DEVTYPE
> (*USERASCII) RPLUNPRT(*NO), it doesn't come out right. We can see
> some of the PCL data in the printout, and the PF does contain the
> original untranslated ASCII data. The ASCIIPCL printfile is a modified
> copy of qpnpsprtf. Is a parm wrong, or should I use an API? I also
> changed ASCIIPCL to PAGESIZE(66 200 *ROWCOL), because the PF has 200-
> byte records and the CPYF complained when ASCIIPCL was 132 columns.
> The CPYF is
> CPYF FROMFILE(pf_name) TOFILE(ASCIIPCL)
>
> Also, the resulting splf has the attribute
> PC printer emulation . . . . . . . . : N
> while splfs actually produced from PCs have this as Y. Our printers
> are *LAN-attached HP-compatible laser printers. We're not doing
> anything fancy (APF, IPDS, PSF, etc.) so far as I know. We normally
> just print PC documents, and AS400 splfs using HPT.
>
> TIA,
>
> Ken
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
Rodney A Johnson
Technical Team Lead for AS/400 Spool
Dept GJC
IBM Rochester, Minnesota
The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, IBM. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
ken....@mhcm.com
response). So, how do we print from the IFS? This isn't an area we're
familiar with.
Larry Loen
Looks like the CPY and CPYFRMSTMF commands expect the target to
be a DB, as I tried using the '/qsys.lib/qgpl.lib/qprint.file' syntax
to specify a print file. So, no simple command unless some OVR trick
works, which is doubtful here.
Alternative: Write a simple C program to do it, with an
OVRPRTF of QPRINT to the *USRASCII kind of printfile Mr. Johnson was
talking about.
Something like this:
#include <stdio.h>
int main() {
FILE *infile;
char buffer[10240]; /* not critical except make big */
int len=10240;
infile = fopen("/yourifsdir/youroriginalifsfile",
"rb"); /* The "rb" is probably critical */
/* or is it buffer len1 len2 filename on fread and fwrite? */
while( (len=fread(infile,1,10240,buffer)>0)) {
fwrite(stdout,1,len,buffer); /* puts out to QPRINT */
}
return 0;
}
This would be compiled with *IFSIO.
If the write to stdout doesn't work, put the
fwrite in a separate module _not_ compiled with
*IFSIO and then do something like this:
FILE outfile = fopen("QUSRASCII","wb");
where "QUSRASCII" is the name of your
print file with *USRASCII and then you
put outfile instead of stdout.
Then, you link them together for the
completed program.
There's probably something simpler
I'm overlooking, but on the other hand,
something along these lines gets the
job done quickly enough if you have
ILE C handy.