IBM Mainframe Forum

Hello,

I have an AFP output, which goes thru POSY (a software which sorts and bundles output e.g. for zip code).
But I'm printing on a paper roll, so the last page is the first on the roll and it's bottom up.

I can tell by AFP to turn every page by 180°, but how can I tell the printer, that it should print the AFP data in reverse order?
Is there a JCL parameter to handle this?

best regards
Mike

You would have to change the application generating the print file to do this. As far as I know, there is no system function or utility to print in reverse. Since a print file could be millions of lines, systems don't usually need to reverse print them.

If your printer is roll-fed, there is hardware available to "rewind" the roll. I guess you don't have that. As a parallel track to looking for a software solution, you could get someone to call printshops (sorry, I don't know what you call them over there, but businesses which do lots of printing for other people) and see if they may be able to flip it for you. Call the printer manufacturer, see if they have a solution, or know some friendly person with a rewinder.

I've just looked at the OUTPUT statement. I don't think you'll get any help from JCL.

Is there only one sheet per envelope? Is your print run is driven by a file? How about adding three extra steps into your process? Firstly, add a sequence number to the front of each record on your driver file. Secondly, sort the file on the sequence number. Thirdly, strip off the sequence number. Then proceed as before.

The sequence numbers can be ascending or descending, as long as you sort in the "opposite direction". You'll need you 180 degree flip as well.

If it is not single sheet, tell us as much as you can (it should be in the spec ) about the print.

Can your collating machine take a roll? Why, if you don't mind me asking, choose a roll for your stationery before you know how it is going to work with your hardware?

Hi BillyBoyo

thanks for your answer!

I'm working on already existing jobs, which do the reverse and bottom up by an exit controlled by special content of CHARS and MODIFY=<modulename>.
This works today, but now I want to use BPXWDYN to define the DD and OUTPUT statements dynamically, because a lot of parameters are decided at runtime.
Today the jobs are submitted by internal reader and I want to have them under control of OPC/TWS.

The problem is, that BPXWDYN does not support MODIFY=<modulename>.
Therefore I'm looking for an other way.

BillyBoyo wrote:Is there only one sheet per envelope?

no, it differs from letter to letter, also attachments may be added or not and the postal charge is calculated and added to the address window.

BillyBoyo wrote:Is your print run is driven by a file? How about adding three extra steps into your process? Firstly, add a sequence number to the front of each record on your driver file. Secondly, sort the file on the sequence number. Thirdly, strip off the sequence number. Then proceed as before.

The sequence numbers can be ascending or descending, as long as you sort in the "opposite direction". You'll need you 180 degree flip as well.?

The print file is not line mode, but AFP!
I think sorting this record by record does not make sense.
A solution could be an AFP command "reverse printing" on top of the file:
The sort order of the file keeps as it is and the printing is done in reverse order.
=> But I cann't find a command like this in AFP.

BillyBoyo wrote:If it is not single sheet, tell us as much as you can (it should be in the spec ) about the print.

See above

BillyBoyo wrote:Can your collating machine take a roll? Why, if you don't mind me asking, choose a roll for your stationery before you know how it is going to work with your hardware?

I'm changing already existing jobs

best regards
Mike

Robert Sample wrote:You would have to change the application generating the print file to do this. As far as I know, there is no system function or utility to print in reverse. Since a print file could be millions of lines, systems don't usually need to reverse print them.

Hi Robert,

thanks for your answer!

Between the application and the printing is a step with the 3rd party software POSY.
This is sorting the output by zip codes.
So, the application have no control over the sort order.

I check in parallel, if POSY can sort in reverse order...

best regards
Mike

Hi Mike,

Isn't your requirement a leetle bit different from what you originally said?

Then:

Mike1304 wrote:I have an AFP output, which goes thru POSY (a software which sorts and bundles output e.g. for zip code).
But I'm printing on a paper roll, so the last page is the first on the roll and it's bottom up.

I can tell by AFP to turn every page by 180°, but how can I tell the printer, that it should print the AFP data in reverse order?
Is there a JCL parameter to handle this?

Now:

Mike1304 wrote:I'm working on already existing jobs, which do the reverse and bottom up by an exit controlled by special content of CHARS and MODIFY=<modulename>.
This works today, but now I want to use BPXWDYN to define the DD and OUTPUT statements dynamically, because a lot of parameters are decided at runtime.
Today the jobs are submitted by internal reader and I want to have them under control of OPC/TWS.

The problem is, that BPXWDYN does not support MODIFY=<modulename>.
Therefore I'm looking for an other way.

There is lots of discussion of BPXWDYN around here, do a search and see if any of that helps or ask, I'd guess in the forum for whatever language you are using.

Mike1304 wrote:The print file is not line mode, but AFP!

To me, AFP is a News Agency. With the new requirement we can read in that it is more than one lot of output you want to process in this way. So you need something generic, not to fix-up an idea gone bad. You have a solution already, but you want to change it to make it more flexible?

ok, I did not tell the whole story on my first posting, because I did not know, what details are necessary for a solution.

I think I'm enough familiar with BPXWDYN, that I can see, there is no solution for me.
Of course I can switch from Cobol to Assembler and use the OUTADD function, but the guy who has to maintain the solution after my retirement may not understand Assembler.

AFP is the abbreviation for IBMs Advanced Function Printing, sorry I'm not aware, that this is not known in the IBM mainframe forum.

Can you break it down a bit?

A)

You have your data (with all the information which may cause a letter to be printed).

You have Agence France Presse, which is able to rotate 180 degrees. I have no idea what else it does.

You have POSY (another product I don't know, don't know how I can possibly be in these fora) which is, I assume, putting collating marks for what goes in which envelope, does it need an insert, here's the end of a packet for the post office.

And you have a couple of SORTs at least, I guess.

B)

You have a solution at the moment. Takes the spool file, reads it backwards "page by page" and prints it. That plus the rotating gives you your result, but you have parameters to sort out at run-time, which means manual intervention.


----

If you can correct/expand on the above we can do some more thinking.

I'm still wondering whether an extra sort would help. What I'd be unclear about, is how you are doing the envelope stuffing for multiple sheets? If you are taking your roll at the moment and putting it through the collating machine, how are you avoiding getting the letter in the wrong order in the envelope if you are effectively putting the print in backwards with the pages 180'd? If you've got that working, the add-a-key, sort, strip-a-key might work if inserted at the correct place. Possibly, as you suggest, even the sort before POSY can be reversed instead.

A)
I have Advanced Function Printing data stream, which is a binary file, that contains information, what is to print, also informations like FORMDEF and PAGEDEF provides for line mode data stream.

I have POSY, which does what you wrote above and does the sort yb zip code.

I have no additional sorts.

B)
I have a solution at the moment, which takes the spool file, reads it backwards logically "page by page" and rotate each page and prints it.
This is done by a 3rd party software in an exit. The exit is activated by a special content of the CHARS and MODIFY parameters of the OUTPUT card.

In the step after POSY I have variable JCL parameters for FORMS, ADDRESS, TITLE, DEPT..., so I can't use a fix job.
The solution at the moment creates the JCL in the program and submits it by internal reader.
I do not like this, I want to have the job under control of OPC/TWS, restartable by batch control room maybe in the night and traceable for audit department.
For all parameters except MODIFY, I can use BPXWDYN, but without the MODIFY I can not activate the exit.

Therefore I ask, if there is a possibility to print reverse and rotate without the exit.
The rotation could be done by a AFP command, but I did not found a solution for the reverse printing in AFP manual.

An additional sort has to understad AFP - it could be no "normal" sort like ICEMAN.

Printing on a role in reverse order and rotated will result in a role with the first page is the original first page with the top upside.

The handling of the envelopes is done by the machine, reading codes on the paper written additionally by POSY (last page of envelope, add attachment...).
A sort before POSY have no effect, because POSY sorts regarding the zip code.
A sort after POSY must be a "functional sort", not an ICETOOL. It has to interpret each record of the AFP datastream, file headers, page headers, overlays, content ....

I think, that if there is no JCL parameter to tell the printer, that it should print the output in reverse order, there is no solution for the problem at this point.

=> I have to check if POSY can write the output in reverse order (I don't believe)
=> I have to check it the exit can be activated in an other way
=> I have to use OUTADD instead of BPXWDYN (I do not want)

Thanks for the time you spent - even if I get no solution, I know now, what to do!

Just because your job is submitted from another job via the internal reader does not mean that it cannot be tracked by OPC or equivalent. OPC will track jobs that are submitted remotely - not from itself and it will submit jobs when a remote dataset is received. Just a case of getting your OPC guys to set it up.