Under either the starter system or MVS 3.8, printed output is "spooled" by the JES2 component of MVS. Print and punch output is not available until the processing of the job has completed; the exception to that is on SYSOUT DD statements where FREE=CLOSE is coded, in which case the output is available as soon as the program issues a CLOSE for the output DCB. Once the job completes (or when the file is closed and FREE=CLOSE is coded on the DD statement), unless the output class to which the output is written is HELD, a writer task is started to move the output from the queue (on the spool DASD volume) to the emulated output device. Under Hercules, the output of emulated print and punch devices is directed into a file on the host operating system (Linux, Windows, Mac, etc). This file remains open to Hercules until a devinit command is used to change the file name, at which time the existing file is closed and the new file opened. Note: if you specify the same file name in the devinit as is currently in use, any existing output in the file will be lost.
As long as the file is open to Hercules, you must make sure that whatever method you use to view the contents of the file does not attempt to write back to the file. When I was running Windows I used an old version of Vernon Buerg's LIST program in a Windows console to view output. I am running under Linux, so I usually use Leafpad. It bears repeating that if you use any text editor to view these files do not modify the file because Hercules and/or the host OS will probably take grave offence. Other Linux users have said that tail works well. I prefer to use a method that will allow me to search both forward and backward for string arguments, as it facilitates checking CONDition CODEs in the MVS JOBLOG.
Other Hercules' users have stated a preferred technique of using the devinit Hercules' command prior to submitting a job to MVS to name specific host OS files to contain the output of a specific MVS job. My preference is to never modify the host OS file specification connected to the printer and punch devices in Hercules (and I specify them in the configuration file). I utilize whatever utility I have available (depending upon which OS I am running Hercules under) to view the file and search for the beginning of a job, using "//jobname" as a search string. I usually start at the bottom of the file, search backward for the beginning of the job, and then search forward looking for specific "marker" strings, such as IEF142I to check CONDition CODEs in the MVS JOBLOG. If I want the output from a specific job saved, I mark the block of lines containing that output and copy it over to another host OS file, leaving the file Hercules is writing to intact.
[July 2020] The preceding paragraph was relevant back in the first decade I was running MVS under Hercules. Now there are several fine programs available, both for Windows and Linux, that will process the output from Hercules emulated devices as it is produced and filter the output by job into output files, ready for viewing. Two of those are Hercprt from Software Development Labs and vpw from Enrico Sorichetti. Hercprt is a Windows program, but I have seen posts from people saying it will run under Wine on Linux. Virtual Paper Writer (vpw) is available for both Windows and Linux and is what I use on my Linux system. Enrico has posted vpw at various times in the Hercules discussion groups, but it is currently not available in the files sections of any of the groups I am aware of on io.groups, which has replaced Yahoo groups, following the demise of the Yahoo groups forums. I am going to make vpw available from my site, since Enrico has placed a comment in the archive that the software is placed in the public domain. It may be downloaded from vpwpc-v2 [1.4 kb MD5: 8397101e626e24561b94f37af25acc40].
In May 2020 there was a discussion on the Hercules MVS group regarding the control file for Hercprt. Apparently the file distributed with Hercprt does not exactly match the output produced by MVS JES2. I do not currently use Hercprt, so I cannot confirm that, but a different control file was shared by Marco Verpelli that I will make available here for anyone wishing to use Hercprt with MVS JES2 output: ../downloads/JobSepPDF.ini.
Under the starter system, there is no necessity to "start" the printer or punch tasks before output is written to the host OS file. However, under MVS 3.8, you will receive a message on the MVS console when the first output is ready for processing by a print or punch task:
*$HASP190 INIT SETUP -- PRINTER1 -- F = STD. -- C = 6 -- T = 0
A response of:
$s printer1
or:
$s punch1
is required to begin processing the print or punch output, respectively. This is a SETUP message, and occurs because this is the first time a job with this particular form - STD. - has been directed to the emulated printer. Another start command - $s - will not be required as long as the form designation remains the same.
Unless you have placed JES2 commands in the JES2PARM member to automatically start the printer tasks, you will have to issue these commands manually on the MVS console each time you IPL. They do not persist from IPL to IPL.
If you are using an MVS system built using my installation/tutorial, start commands for both printers are included in the JES2 startup section of the JES2 parameters.
Unless you have circumvented spooling (which is not a trivial sequence of steps), all printed and punched output from batch jobs, started tasks, and time sharing users is captured by JES2 to the spool volume until the completion of the job (or started task, or until the time sharing user logs off), or until the output file is closed and FREE=CLOSE is coded on the SYSOUT DD statement. Provided that a writer task has been started for the class to which you directed the output, the output should be selected for writing to the device attached to the writer task.
To display the printer tasks, use the command:
$d u,prts
which will list all of the JES2 printer tasks. Those with a status of INACTIVE are waiting for work. If all of the tasks have a status of DRAINED, you need to use the command:
$s prtn
where n is the number of the printer task to start and should correspond to an actual device for which you have specified an emulated printer (such as 00e or 00f). If there is already an INACTIVE task listed, check the class(es) of output for which the writer task will function. They are listed as the last parameter from the display command:
Q=abc
where abc is one or more SYSOUT class designations.
If you have output waiting, but the task is not set to print the matching class, you can alter the printer task to include the class by using the command:
$t prtn,q=abc
where n is the number identifying the printer task and abc are the classes of output you want the printer task to print. After changing a printer task, you will have to respond to a setup message on the console.
If the printer task is attempting to print the first output of a particular form and class to a printer, a SETUP message will appear on the MVS console and require an operator response:
$HASP190 jjjjjjjj SETUP -- PRINTER1 -- F = STD. -- C = 6 -- T = 0
where jjjjjjjj is the job identification. The response required is:
$sprtn
where n is the number of the printer task.
[July 2020] If you have the QUEUE command installed (which will be the case if you are running the Turnkey system or an MVS built using my instructions/tutorial), you can use QUEUE to view, release, and purge output from the JES2 spool.
When the emulated printer processes a request to advance to the next page, a form feed character is written to the host OS file, followed immediately by the text on the line that would logically occur on the top of the new page. This causes the first line of each page to appear "stacked" with the last line on the preceding page. If you print the file to a physical printer, the form feed is interpreted correctly and everything is fine. However, if like me, you prefer to keep these files on disk for viewing on screen, this can be less than perfect. I wrote a short awk script that will process an emulated printer file, "breaking" these lines at the form feed character and inserting a line of equal symbols (=) to indicate the page breaks. You may download the script from here - formfeed.awk - and use it as is or modify it for your own needs. If you are running under Windows/?? + Cygwin, you will need the gawk.exe from Cygwin. See the comment at the top of the script for usage.
[July 2020] This is a very old answer, but as far as I can research personally and from feedback I have received from otheres, it does still occur at times. This only occurs when the printed output is processed by JES2 to move it from the spool to an emulated printer device, from where it is written to a file on the host Operating System. I believe that most people are viewing printed output as it resides on the spool, using the QUEUE command. This problem does not occur in that case; only when the output is transferred to the host Operating System file.
Previously I had made a brief reference to this artifact in the discussion of the previous question (above), but had devoted little time to researching the problem. A couple of months ago I exchanged several lengthy emails with Robert Hodge about this and I believe we have pretty well concluded why this happens. My previous comment on how I had fixed the problem on my system was cavalier and my solution just didn't work.
The reason this situation occurs is the combination of how JES2 handles print buffers and how Hercules subsequently interprets the Channel Command Words that are built by JES2 as it transfers the print records from its spool to the emulated printer file on the host Operating System. JES2 attempts to generate print before advancing commands because IBM in its design thought that was more efficient. Everything works splendidly until the situation where JES2 gets to the last line of a block. The data for the print line has already been sent to the hardware (Hercules, in our case). JES2 sends a CCW of x'01', write without advancing, which Hercules interprets by sending a single carriage return character to the print file (x'0d'). When JES2 begins processing the next block, it sends a CCW of x'0b', space once immediately, which Hercules interprets by sending a carriage return/line feed pair to the print file (x'0d'x'0a'). So the print file contains the sequence x'0d'x'0d'x'0a', which when viewed with a viewing program (such as Vernon Buerg's LIST) or printed to a physical printer on the host computer, you will see an extraneous blank line. (The preceding explanation may be a bit fuzzy, but it is my attempt to condense down several moderately complex technical email exchanges.) If you turn on device tracing for a printer and release printed output by JES2 that will produce a page or two, you will see the sequence of CCW operation codes that correspond to the blank line in the physical print file.
So, what can be done about it? At the moment, it appears the best remedy is to correct the problem after it occurs. Robert has written to Vernon Buerg (he and I both use Vernon's LIST utility to view and/or ultimately print our Hercules emulated printer files) to see if Vernon would be willing to write a specific fix into LIST. You can also easily use the tr command to correct the final print file by removing the spurious carriage return character:
tr -s \015 < your.print.file.name.goes.here > corrected.print.file.name.goes.here
The \015 in the command represents the carriage return character in Octal.
[At the time I wrote this] I used SPF/PC to submit many of my jobstreams to Hercules via the socket reader interface (you can read about my technique and, if it will benefit you in your environment, download a JCL preprocessor and SUBMIT shell script I wrote at socketreader.htm). I also wrote a script (well, OK, a batch file since I was running under Windows/2000 then) to utilize LIST to view the output from my Hercules emulated printers. So I simply inserted a line to execute the tr command above into the script before invoking LIST. I redirect the output of tr into a temporary file, execute LIST to view the temporary file, and, when LIST terminates, I delete the temporary file before control is returned to SPF/PC.
A particular class may be set up to be automatically held in the JES2 parameters by coding:
substituting the desired class designator for X (X has traditionally been a held print class in every installation where I have been employed). If you have built your system using the instructions/jobstreams from my site, class X is set up this way on your system.
Also, you can cause the output produced for any particular job/dataset to be held, regardless of the settings for the output class in the JES2 parameters, by coding HOLD=YES on the DD statement:
You may do this by setting up an automatic command in the JES2 parameters to create a recurring automatic command to purge output. Typically automatic operator commands are placed near the end of the JES2 parameters, so you need to edit the member of SYS1.PARMLIB that is read by your JES2 procedure on startup and scroll to the end of the member. The format of the command to set up a recurring, time triggered JES2 command is:
$T nn,t=hh.mm,'$command'
where nn is a unique identifier for each command; hh.mm is the time of day that the command is to be activated, and $command is the text of the JES2 command to be issued automatically.
There are three types of output maintained on the JES2 queue: output from batch jobs, output from started tasks, and output from time sharing sessions. For each of these types of output you wish to clear, you will need to set up an automatic task. Using arbitrary identifiers of 10, 11, and 12, the entries in to the JES2 parameters to set up the three commands to purge all three types of output from the queue at midnight of each day would be:
Note that these purge commands will remove all output from the queue, so you should take precautions to avoid losing any desired output by releasing to print the output from any job, started task, or time sharing session you wish to save prior to the time these automatic commands will be executed.
Once the JES2 parameters have been updated, each time JES2 is started, the automatic commands will be scheduled and will continue to be issued automatically at the specified time of day.
This question, which I never asked or researched myself, was recently answered in a post to the H390-MVS forum by Greg Price, the maintainer of the QUEUE command. I have often found myself switching to RPF in order to use the 3.6 option to change the output class of a print job to allow it to spool to the emulated printer, even though I exclusively use QUEUE to view held output. It turns out that there is a primary command available in QUEUE to perform this function. The format of the command is:
REq [<jobname> | <jobnumber>] <new class>
The command may be entered as either REQ or the abbreviation RE. Either the jobname or job number may be specified to identify the job. If there are multiple jobs with the same name on the queue matching the jobname you entered, the first job listed will be the job selected for processing. QUEUE presents a confirmation screen displaying the selected jobname/job number where the command may be confirmed for execution or aborted.
This is another question I received in a email:
When I submit jobs from TSO using a MSGCLASS=T, the output is queued but I can't get it. If I status the job, it shows that it's on the queue. If I try to "Output" the job, it says it can't find it. What might I be missing.
The quickest and easiest way to accomplish this is to add the class in which the output is queued to the classes currently being processed by your JES2 output writer, using the command:
$tprt1,q=at
In the command above, the writer is prt1 and after this command the writer will select and print output queued for both class a and t.
Other ways that you can view held print output are by using the OUTPUT TSO command and option 3.6 in RPF.
[July 2020] If you are using an MVS system built following my instructions/tutorial, there is an added JES2 command that may be used to change the class of print output held on the spool:
$u'<jobname>',o=v,c=z Change output for <jobname> from class v to class z $ujnnn,o=v,c=z Change output for job number nnn from class v to class z $utnn-nn,o=v,c=z Change output for jobs in number range nn through nn from class v to class z
The 'from' class may be multiple class designations, as in: $ut15-16,o=ab5,c=x, or may be specified as an asterisk to match all class designations: $uj101,o=*,c=a.
There are several ways to accomplish this:
$ps1-9999 purge all started task output $pt1-9999 purge all TSO output $pj1-9999 purge all batch job output
$pjes2 stop JES2 $sjes2,parm='COLD,NOREQ' start JES2 with empty output queue
r nn,COLD,NOREQ
Obviously the first two will be used when the MVS system is up and running and the third is from a non-running system. Also, in order to input the response during IPL, JES2 must be set up to prompt the operator for the startup options.
Also check out setting up automatic time interval triggered JES2 commands to empty the queue: How do I set up JES2 to automatically purge output from the queue?
I hope that you have found my instructions useful. If you have questions that I can answer to help expand upon my explanations and examples shown here, please don't hesitate to send them to me:
This page was last updated on July 15, 2020 .