PSF/AIX:Defining AFP resources
ITEM: RTA000100250
Q:
ABSTRACT: PSF/AIX: Defining AFP resources in a PSF for AIX
environment using the LPR command from the host (MVS).
SEARCH ARG: psf aix 3160 afp pagedef
TOPIC THREAD: PRINT
PSF/AIX
..
My customer has an MVS system without PSF installed. He also has an
RS/6000 with PSF for AIX connected to a 3160 laser printer using a
token ring connection. He is using the LPR command from MVS or any
other IWS (ie: OS/2) specifying the AIX PSF/AIX Queue and server name.
He is able to print files in portrait. When we change the default
formdef F1A10111 in the Processing Options smit panel to F1C10111
to print in landscape the printer goes into initing status for more
than 20 minute and hangs.
1. Does an LPR command send an ASCII file to PSF/AIX? If yes, is this
an option on the LPR command or does it do it transparent to us?
2. Why, when we specify formdef F1C10111, does it not print landscape?
3. When we use the PSF for AIX SMIT Processing Options panel, we did
not see an option for PAGEDEF. How do I specify one if I have to?
4. We do not use ACIF. Should we use it for the simple requirement of
printing landscape that the customer has? What is the advantage of
using ACIF since I can specify AFP resources in the Processing
Options panel.
5. The plan currently is to create multiple PSF/AIX queues for each
application set. Is there a better way to dynamically define AFP
resources?
Any help will be appreciated.
A:
R1) By default, the MVS LPR command will convert EBCDIC to ASCII
according to a translation table before sending the file down to the
AIX system; you can explicitly specify the BINARY option if you do
not want the conversion to occur.
R2) F1C1011x formdefs, also known as the compatibility formdefs, were
designed for use on continuous forms printers; the SMO commands
within them do not take effect on cutsheet printers such as the
3160. The tables in Print Submission try to make this clear, but I
see that page 476 in Print Administration says that F1C10111 can be
used on either cutsheet or continuous printers--that is wrong, and I
will work with the technical writers to get that corrected.
I'm not sure why specifying F1C10111 hangs the 3160; you may wish
to open a PMH if this continues to be an issue.
To get landscape on a cutsheet printer, you can use a pagedef with a
landscape orientation. Or, since your printer supports n-up, you can
code a formdef with n_up 1, present portrait, direction down.
R3) Since pagedefs are only supported through the line2afp/acif
transform, there is not an entry on the standard PSF processing
option panel. Please ASKQ item RTA000042170 for a description
of how to set up a default pagedef for a queue.
R4) I prefer using line2afp/acif with a pagedef rather than just
submitting flat (a.k.a. Proprinter ASCII) because:
a) You have more control over the fonts with the pagedef or CHARS.
If you submit ASCII without a pagedef, your fonts are determined
by the values in the ASCII Font Mapping Options table.
b) You have more control over the formatting with the pagedef.
If you submit ASCII without a pagedef, your formatting is
limited to what is in the datastream; some modification is
possible through the ASCII Transform Options, Printer ESCAPE
CODES, but it is limited and will affect all jobs sent to
that queue.
c) You have access to Production Print enhancements (which ones
will depend on how the job is submitted). If you submit the
job without invoking acif/line2afp, you do not have access to
these enhancements. In Print Administration, Table 1 (page 5
of S544-3817-03) lists the production print enhancements; in
particular, see footnote #2 that lists the limitations for
Proprinter ASCII.
R5) The method you describe (multiple queues with different defaults)
will work no matter which platform the customer is submitting jobs
from--it's the least common denominator. There are some platforms
which have other alternatives. For example, for TCP/IP for MVS,
there is an undocumented -o flag on the LPR command that will allow
you to pass parameters (formdef, datatype, pagedef, etc.) down to
PSF/AIX. Or, with TCP/IP for MVS V3, the optional free NPF feature
might be a possibility if their jobs are relatively small; NPF with
the PSF/AIX input record exit (see the appendix of Print Admin) will
pick up and pass some JCL OUTPUT parameters like pagedef, formdef.
(Note that with the announcement of TCP/IP for MVS 3.2 and IP
PrintWay, NPF is no longer considered strategic. So you may not
want to recommend that as an option.) Neither of those solutions
require PSF/MVS.
If they are willing to consider PSF/MVS, then MVS Download is an
excellent solution--a better performer than NPF and strategic. And
it does pass JCL OUTPUT parms down to PSF/AIX; the new IP PrintWay
does not. It too is TCP/IP based.
If the customer has any UNIX workstations, then consider the
lprafp sample code we ship with PSF/AIX; it can be compiled on
various UNIX platforms, and it allows you to pass parameters to
PSF for AIX.
For OS/2, I don't believe its LPR will allow you to pass any
parameters, so in this case you are probably limited to the
multiple queue approach.
Some customers have done some creative programming on AIX to
parse incoming jobs and on the basis of the data, decide what
pagedef or formdef to invoke (for example, based on line length,
to use a portrait or a landscape pagedef). I have a contact in
the AIX Support Center who has done this for a customer on a
contract basis, and I'd be glad to put you in touch if you think
that's something your customer is interested in.
I hope that helps.
Q:
Thanks for your response. I have a couple more questions:
A. Do I have to specify Binary in the LPR command from MVS if I will
use line2afp/acif?
B. The same if I use NPF.
C. Where can I find which options can I use with -o in the LPR command.
A:
A) You do not have to specify binary to use line2afp/acif. If the host
file is fixed length, it would be easier to send it down binary; to
acif, you'd specify the parameter "fileformat=record,nnn", where nnn is
the LRECL. If the host file is variable length, it's generally easier to
send it down ascii; to acif you'd specify fileformat=stream. You'd also
most likely need to specify the parameter
"inpexit=/usr/lpp/psf/bin/apka2e" so that the data would be converted
back to EBCDIC in order to print with the majority of our fonts.
See Section E in informational APAR II07646 for some useful information.
B) To use NPF with PSF/AIX, you set up the options table so that the
data is sent down in binary format. The input record exit supplied
with PSF/AIX, when dealing with linedata, takes care of specifying
the correct fileformat and datatype parameters to PSF/AIX. For a
complete explanation, please see Print Administration, page 388
(S544-3817-03).
C) Since the MVS LPR -o flag is an undocumented one, there is no list of
formally supported parameters that can be passed in this manner.
Since the -o flag on the MVS lpr command merely passes the attached
parameter onto the receiving application (in this case, PSF/AIX), I
would think you should be able to pass most of the PSF/AIX parameters
down (see the Print Submission book for the various parms). I may be
able to test if you have specific parameters you're concerned about.
The exposure is that since this is undocumented, there is no commitment
of continued support from TCP/IP for MVS.
Thanks for using WWQ&A. Please let me know if you have additional
questions. (Reviewed 17 Sep 1998)
S e a r c h - k e y w o r d s:
CROSS PSF/AIX IP PRINTWAY DOWNLOAD PSF/6000 NPF LPR MVS LANDSCAPE
infoprint ipm ipmgr pod psf aix tcp/ip rotate orientation formdef nup
WWQA: ITEM: RTA000100250 ITEM: RTA000100250
Dated: 09/1998 Category: XPSF6000
This HTML file was generated 99/06/24~12:43:33
Comments or suggestions?
Contact us