Printing from datastep on mainframe

[S_Burggraaff]

We're migrating a SAS AF application from 9.1 to 9.3 on mainframe, so we are dealing with some pretty old code. A couple of programs use proc printto to direct output to a certain printer and then create output by using file print in a datastep. This all worked fine in the past. But now with 9.3 there is a problem. The print output is buffered until a proc print is used or if the SAS session is closed. This is not workable for the people who have to use this several times a day.

A solution might be to redesign the programs using ODS but that's not desirable because of the amount of work and the fact that the application is nearing it's end of life. Does anyone know a quick simple solution?

[ballardw]

Is the hang-up the PROC PRINTTO or the FILE PRINT?

If the problem is with PROC PRINTTO and getting the results into a dataset then the ODS SELECT might be what you're looking for but some more description of the procedures involved and the output might be helpful.

Or instead of FILE PRINT which goes to the default output  file reference would work if you have a dataset.

Data _null_;

     file "C:\mytextfile.txt";  or Fileref to your file

     set sashelp.class;

     put name $10 @15 Sex $1 @20 Age f2. @25 Height f4.1 @30 Weight f5.5;

run;

for example to create a fixed width file.

You can create a lot of control with this approach and by passes any boundaries as it is written when the data step executes.

[S_Burggraaff]

We simply don't know which one causes the hang up because we can't separate the two. As I said before, it worked without problems under 9.1. The code is basically something like:

data _nulll_;

set SomeData;

file print;

  ... several put statements ...

run;

What we suspect is that the print file is not closed when the datastep ends and the output stays in a buffer. Only exiting SAS or using a proc with printer output seems to release that buffer.

[sbb]

Help clarify here please (best to reveal more of your SAS code, including the PROC PRINTTO statement(s) please) - you have a z/OS MVS TSO user running interactive SAS and when the SAS session is immediately started, a PROC PRINTTO PRINT FILE=xxxxx (where "xxxxx" is a pre-allocated SYSOUT= destination?)  is issued, followed by a DATA step that issues some PUT references against FILE PRINT, and eventually a RUN;  and a PROC PRINTTO to reset the output re-direct -- is that the case here? 

Consider helping us help you will the encapsulated SAS program to start, along with some confirmation about observations / presumptions above?

[S_Burggraaff]

Unfortunately my contract doesn't allow me to copy code and place it on a forum. I've sent part of the code to SAS support though. We also seem to have gotten closer to the problem.

Users run SAS interactive on z/OS and enter data in an AF application. That application then executes code by using several SUBMIT blocks with the option CONTINUE. Within those SUBMIT blocks a filename statement is used to route the output to a printer. At the end of a SUBMIT block that filename is cleared but it looks like it doesn’t really release it. It seems that it is only released if that filename is reinitiated in another SUBMIT block.

SAS mentioned that default settings for listing output have been changed in 9.3. We have a work around for now but I do wonder what causes this.

[ballardw]

Have you run into this?(my emphasis added)

Any time you use PROC PRINTTO to route output, you must close the output device

before PROC PRINTTO will release the output or log and send it to the

destination that you have specified. To close the output device, issue PROC

PRINTTO without any parameters:

proc printto; run;

Issuing PROC PRINTTO without any parameters closes the output device,

generates output, and reroutes the log and procedure output to their default

destinations.

[S_Burggraaff]

Yes, PROC PRINTTO without parameters was already in the code, but thanks for the tip.

[mnjtrana]

We also had this kind of requirement in one of my project which resided in mainframe and we neede dto convert it to windows sas9.4 code.
so the printer output had to be removed, all of this printer code was luckily inside a macro, so they used to call the printer macro in the program.

So we just removed the printer code from there and changed it to ODS PDF, so now we had all the printer output in the pdf which was emailed to user based on the printer name earlier.

macro call
%print_main(<dataset name>, <printer name>);

now based on the printer name an email is triggerd to user id mentioned in one permanent dataset with the ods pdf report.

Hope this may help you!

[Tom]

Is the printer waiting for a new page?

Did you try sending something to start a new page?  Like a FormFeed character? Or a '1' in the carriage control position if you are using old FORTRAN style controls?

How does the PROC PRINT cause it to print? What if you just add an extra data step instead?

proc printto print=fileref ; run;
data _null_;
  file print;
  ....
run;
data _null_;
  file print;
run;

What about an extra PROC PRINTTO step? Either back to the same  device?  

proc printto print=fileref ; run;
data _null_;
  file print;
  ....
run;
proc printto print=fileref new ; run;

Or back to normal PRINT location?

proc printto print=print; run;