Can we print a range from an MVS Download file?
ITEM: RTA000155015
Q:
Topic thread:
Printer Systems (PRINT - NA/ATS)
PSF/AIX
My user will need to support a print room with five duplex systems.
Some jobs are created on their RS/6000 and printed via PSF/AIX and PSM
today. When they need to print only a range of pages, they know how to
go into the PSM menus and indicate the range they want. This works
fine. The remainder of their print output are MODCA/P files which come
from an MVS host via MVS Download. They have found that they are not as
successful printing a range of pages from the host. Their technical
person suspects it has to do with the fact that the AFP created at the
RS/6000 is ASCII and the AFP created at the host is EBCDIC. I have
research without success. No ViewBlue entries I could find, nor
anything in PSF/AIX, PSM, or MVS Download manuals.
1. Is my user's theory valid?
2. If so, how do other PSC users solve this requirement, as most surely
they have the same situations as mine does?
3. If ASCII vs. EBCDIC is not our issue here, how do we go about
nailing down the real cause?
Thanks for your help.
Q:
Please disregard this item. I will re-ask if necessary.
Thanks any-hoo.
A:
Okay, I'll close and you can reopen as necessary. However, I will
say that AFP structured fields are identical no matter where created.
That's why you can create an AFP file on the RS/6000 and either
manually upload/reblock it or use AFP Upload to print it to a PSF/MVS
printer. So no, your user's theory is not valid.
Reopen if you want us to pursue.
Q:
Okay, we think we have a better understanding now. It appears that the
problem is this:
There is an MVS Download option to precede each record being sent to
the RS/6000 with a record length. The MVS Download manual suggests
coding as YES for print jobs and NO for On Demand. My user codes YES,
so they get the length prefix. Then when they try to run AFPSPLIT or
use the Range capability, they get an error because AFPSPLIT does not
recognize that it is looking at a MODCA/P record with a prefix on it.
Similarly, AFP Viewer can't handle it. Clearly, for MODCA/P jobs, this
external length is extra anyhow. I have suggested that they set up
multiple Download pipes and have separate ones for MODCA/P and line mode
jobs.
My user just wants to check to make sure this is the recommended
alternative. (They'd like to see AFPSPLIT and Viewer made smart enough
to recognize that a MODCA/P record has a length field in from of it.)
How are other users solving this?
I think what this question boils down to is: If we follow the
admonition in the MVS Download book, page 50, to use SEND_REC_LENGTH
set to YES, then it appears to us that AFP WorkBench for Windows,
AFPSPLIT, and the print range capability of PSM-PSF/AIX (and InfoPrint)
no longer function. Our suspicion is that this is because there is now
a length count in front of each MODCA/P record. I am trying to figure
out if we are doing something wrong or how other users have solved this.
Thanks.
Thanks for your help.
A:
I checked with the afpsplit developer, and neither he nor I have heard
this issue from other customers.
In reviewing the customer PMR, there was some mention of running ACIF to
eliminate the two-byte length introducers, namely that the customer was
doing that, but the L2 rep thought that might be unnecessary. And it
*is* unnecessary for printing with InfoPrint Manager or PSF/AIX, since
both will process the downloaded file with fileformat=record. However,
that doesn't help you with viewing or afpsplit.
Thus, the only two current options are the one you describe or
possibly ACIFing the downloaded data as your customer may have already
been doing. I don't have any way to test the latter here; I was able to
ACIF a standalone AFPDS job by specifying a pagedef (a required field
for the ACIF command), formdef (ditto), cc=yes, and cctype=A.
As far as requesting enhancements, your best bet is to submit a formal
request either through NEWREQ or by sending a note to Randy Larsen,
the product manager. Note that it's unlikely that PSF/AIX will be
enhanced since it's w/d from marketing; however, they might consider it
for InfoPrint Manager V3.1 or a later release.
Sorry I don't have a better solution for you.
S e a r c h - k e y w o r d s:
psf/6000 psf/aix psf aix infoprint ipmgr mvs download afpsplit viewer
workbench range pages selected two-byte length introducer fileformat
record
WWQA: ITEM: RTA000155015 ITEM: RTA000155015
Dated: 02/1999 Category: XPSF6000
This HTML file was generated 99/06/24~12:43:42
Comments or suggestions?
Contact us