02-10-2015 12:00 PM
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?
02-10-2015 12:47 PM
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.
file "C:\mytextfile.txt"; or Fileref to your file
put name $10 @15 Sex $1 @20 Age f2. @25 Height f4.1 @30 Weight f5.5;
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.
02-10-2015 02:07 PM
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:
... several put statements ...
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.
02-10-2015 02:42 PM
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?
02-12-2015 10:23 AM
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.
02-12-2015 03:36 PM
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
04-30-2018 06:44 AM
04-30-2018 01:33 PM - edited 04-30-2018 02:02 PM
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;