Troubleshooting using RJE

This topic contains solutions to common problems that you might experience when using RJE.

Receiving files from the host

Sending files to the host

Printing

Error messages

See also:

Extra page breaks in data coming from the host after line 61

Cause: The JES2 page length is shorter than the page length required for the job. JES2 will then insert a page break on any page that exceeds its logical page length. For example, the JES2 default is 61 lines on a page. If a page has 80 lines, JES2 will break it into two pages. The first page will contain 61 lines, the second page will contain the remaining 19 lines, leaving the original page break intact after the 80th line.

Solution: For specific jobs, you can override the global default page overflow length by using the LINECT parameter in the JCL for that job. Ask the host programmer to use the LINECT parameter in the JCL JOBPARM statement:

Setting LINECT to 0 will completely prevent JES2 from inserting page breaks for that job. Only the original page breaks from the application will be in the data.

The default JES2 setting for the page length is controlled by the LINECT variable in the global PRINTDEF statement. LINECT=61 is the IBM default. LINECT=0 causes the automatic page overflow of JES2 to be suppressed. The LINECT setting is global and affects all JES2 remote printers, so it is not commonly changed.

Reports received from the host are split into three separate jobs

Solution 1

Cause: Different PDIRs Acronym for Peripheral Data Information Record. are being received during the same print job. PDIRs within a single print job will contain the same information. Any changes in the content of the PDIR constitutes a new job and is used by RJE and other SNA remotes as a method of job separation.

Solution: Ask the host programmer to use the Diagnostics Utility and RJE Diagnostics utility to show the content of the PDIR to confirm this condition. The host programmer will then need to adjust the JES Exit that creates the PDIR to conform to IBM standards, in order to correct this problem.

Solution 2

Cause: The Create separator files option is selected on the Device Properties dialog box. The Create separator files option is used to divide an output file into multiple files by using a PDIR Acronym for Peripheral Data Information Record. as file boundaries. By default, this option is not selected. The following is a simplified structure of data as it is received from the mainframe.

Begin frame (This is how RJE knows that a file has started)
PDIR
Banner page
PDIR
Data
PDIR
Trailer page (This is how RJE knows that a file has ended)

As you can see from the example, you would actually have three distinct files if the Create separator files option was enabled, because there are three PDIR records.

Solution: On the RJE Configuration Utility's Device Control tab, select the printer or punch and click Configure. From the Device Properties dialog box, clear the Create separator files check box.

If you are receiving files to the Spool Window, and the PDIR copies value changes within the file, the file will be divided into separate files to allow the Spool Window to handle the different copy counts. This is an automatic feature of the print spool that is not affected by the Create separator files option.

Solution 3

Cause: A VPS VTAM Print Services by Levi Ray and Shoup parameter is configured incorrectly. VPS has various switches that control how the data is sent to the remote. The FMHCLASS and FMHJOB parameters act as switches to control how the data is bracketed when sent to the remote. If the FMHCLASS option is used, VPS will bracket the file by wrapping FM headers around the beginning banner, data, and trailing banner. Because the Barr software uses the beginning and ending brackets to determine when the reception of a file is complete, it will create separate files for the beginning banner, data, and trailing banner.

VPS is a functional subsystem of JES that permits the host to send jobs to a VTAM-attached printer. VPS enables JES2 to interpret a VTAM-attached printer as a local printer.

Solution: Ask the host programmer to use the FMHJOB parameter instead of the FMHCLASS parameter. When VPS is coded with FMHJOB, the system brackets the beginning banner, data, and trailing banner as one transmission.

Mainframe can not send files to the computer

Cause: A VPS A main frame subsystem that takes print jobs that are in the JES2 output queue and re-routes them using different methods, such as TCP/IP or 3270 printer sessions. parameter is incorrect.

Solution: Ask the host programmer to set the VPS parameter to RJE=N. For jobs to be correctly received, VPS has to code the FMHJOB option. If the VPS remote printer statement is set to RJE=Y, then the mainframe will not be able to send files to the remote computer. The sense error (SNS=10082004) indicates there is a problem with the format of the Function Management Header (FMH).

Records received by a punch device are padded to an incorrect length

Cause: Jobs sent to the remote by a punch device are truncated at, or padded to, the length defined in the punch's LRECL parameter in the JES PARMLIB. On other devices, this default length can easily be overridden by issuing commands to dynamically change the device's LRECL parameter, or by adding the LRECL parameter into the DCB section of the JCL's SYSOUT statement. On a punch device, however, these changes are ignored by JES and the value in the PARMLIB is always used. This occurs, even though the LRECL might appear to have changed when displaying the punch's status.

Solution: Ask the host programmer to change the PARMLIB punch's LRECL setting on the host to the desired length, perform the IPL Acronym for initial program load The process of copying an operating system into memory when a system is booted., and resend the job.

Host does not send complete separator pages

Cause: To receive a full separator page from the host, JES Exit 1 needs to be enabled.

Solution: Ask the host programmer to enable JES Exit 1 so that the host will send complete separator pages to the RJE remote.

Form name criteria on host changing to the form name of the last job received

Cause: The Mount forms by option on the Device Control tab is set to RJE Console.

Solution: On the RJE Configuration Utility's Device Control tab, from the Mount forms by drop-down list, select SETUP=PDIR FORMNAME.

Output not received on correct PR stream from host

Cause: Additional print streams were added on the host. Often, the host JES remote definition is copied from a previous print stream and not updated. The output, then, is still released on the previously defined PR stream. This problem can also occur when punch PU streams are added to the host.

Solution: Ask the host programmer to verify that the SELECT statement has the correct print stream defined (for example, for RMT999.PR3 use SELECT=PRINT3).

Cannot receive jobs from host

Solution 1

Solution: Ask the host programmer for the number of LUs defined for your remote. In addition, ask the host programmer to verify that there are at least as many LUs defined in the node as there are for printers, readers, punches, and keyboard and console in the JES2 remote definition. To compare the number of LUs defined in the RJE software with the number of LUs defined in the host, on the RJE Configuration Utility's Communication Link tab, click NCP. In the NCP definition, view either the MAXLU number or the number of Lunames, depending on your selected link type. The number will be equal to or less than the number defined in the JES2 remote definition. For more information, see the LU macro formula.

Solution 2

Solution: Ask the host programmer to reset the remote. Reconnect the RJE software. Files should now be received from host.

Solution 3

Cause: The remote's PRi definition has the work selection specified to require a match for the FORMNAME, FCBNAME or class.

Solution: If the remote printer has the work selection defined (WS= ) in the JES2 definition, verify that the printer has been set to pull the forms specified. If it is not, you will need to correct the WS definition. To find out what the WS is defined as, and to change the WS accordingly, complete the following steps. For more information, see the Operator commands topic.

Solution 5

Cause: The host programmer changed JES or VTAM settings that affected the RJE remote definitions.

Solution: Ask the host programmer to verify and correct any changes made to JES or VTAM settings during the IPL Acronym for initial program load The process of copying an operating system into memory when a system is booted. that affect the RJE remote definitions.

BARR/TRAN transfer fails from the computer to the mainframe

Solution 1

Cause: This symptom is usually a result of setting the reader Maximum line length to a value greater than 80. The data is sent correctly, but a signal is sent with a maximum length that BARR/TRAN thinks is too high.

Solution: On the RJE Configuration Utility's Device Control tab, set the reader Maximum line length to 80.

Solution 2

Cannot transfer files to host using RD1

Cause: If the host's receive pacing value (SSNDPAC) is set to zero, the Barr software will send frame after frame of data without checking with the host to see if it has received the previous frames. This can flood the host with too much data, forcing it to drop the reader connection.

Solution: Ask the host programmer to set the receive pacing value (SSNDPAC) to a non-zero value in the logmode table entry. We recommend setting the receive pacing value to 7.

Cannot send commands to host

Solution: Ask the host programmer to allocate more LUs by modifying the VTAM definition for the remote. Use the LU macro formula to calculate the number of LUs you need. For more information, see the Communication link parameters topic.

Cannot send packed data to host

Cause: RJE does not support the translation of packed decimal data (compressed data) from ASCII to EBCDIC, or vice versa. Packed decimal data that needs to be translated and transmitted using RJE must be unpacked on both ends before transmission.

Solution: To send packed decimal data to the host, the data on your computer must be in EBCDIC and you must use the /B binary send mode in the JCL.

Computer stops responding when attempting to send files to the host

Cause: The JES BUFSIZE does not correspond with the VTAM PU definition. The BUFSIZE must be nine less than the value for MAXDATA. For more information, see the Remote definition topic.

Solution: Ask the host programmer to set the JES BUFSIZE to a value appropriate for the VTAM PU definition. For example, if VTAM's MAXDATA=521, ask the host programmer to set the BUFSIZE to 512.

JES3 commands containing a ? prompt for user replacement

Cause: When sending commands to the host, the Barr software interprets a ? as a prompt for character replacement.

Solution: JES3 commands that contain a ? as a standard character must be entered as double question marks (??). Double question marks will be ignored during the Barr prompt replacement and will be sent to the host as single question marks. The software can then distinguish between the Barr ? prompt and the JES3 ? command character.

Unable to print 255 characters per line

Solution 1

Solution 2

Cause: JES2 allows a maximum reader line length of 254 characters, but some mainframe programs cannot accept lines longer than 80 characters.

Solution: On the Device Control tab, set the appropriate Maximum line length.

Files are not named correctly

Cause: The PDIR Acronym for Peripheral Data Information Record. is not received in the proper order, so information is not extracted until a new file is created in the spool folder.

Solution: Ask the host programmer to either modify the JES Exit, or the application generating the job, to conform to the following standard IBM sequence. The host programmer might also want to use the Diagnostics Utility and RJE Diagnostics utility to illustrate how the host is sending data on the SNA line. The proper IBM sequence for receiving files and PDIRs is as follows.

PDIR
Header/Banner page/Initial DJDE statement
PDIR
Data set/Report text
PDIR
Trailer page

Printer prints in uppercase characters only

Cause: The JES2 host TRANS parameter is set to TRANS=YES. The JES2 TRANS parameter controls data translation, setting this parameter to YES causes non-printable characters, such as binary data, to be converted to blanks. When printing mainframe data, laser printers will work better if data translation is disabled at the mainframe. Data translation is not necessary because laser printers can print uppercase, lowercase, and special characters.

Solution: Ask the host programmer to set the TRANS parameter to TRANS=NO in the JES2 remote definition statement. If the TRANS parameter is not specified, the mainframe will default to TRANS=YES. For older versions of JES, the TRANS parameter is set only on the PRINTDEF statement. For newer versions of JES, this parameter can be set on the remote printer statement.

Printer does not print correctly

Solution 1

Cause: The JES2 host TRANS parameter is set to TRANS=YES. This causes non-printable characters, such as binary data, to be converted to blanks.

Solution: Ask the host programmer to set the TRANS parameter to TRANS=NO in the JES2 remote definition statement.

Solution 2

Cause: IBM no longer offers JES2 support for JES Exit 15, where some translation parameters were customized system wide for JES2.

Solution: Ask the host programmer to set the TRANS parameter to TRANS=NO in the JES2 remote definition statement.

Form settings are not being applied to jobs

Solution 1

Cause: The form associated with the job has not been defined in the Barr software.

Solution 2

Cause: You are upgrading from the BARR/RJE DOS product and the form has been defined, but it is not being applied correctly to the job.

Solution: If you are upgrading from the BARR/RJE DOS product and Mount forms by is SETUP=PDIR FORMNAME or $HASP190 FORMNAME, then you will need to create an override table. We recommend creating a rule action of NDHGFCB=NDHGFORM.

Jobs from the mainframe print endlessly

Cause: The SRCVPAC (Secondary Receive Pacing) value does not match on the remote and host. After a recent upgrade to OS/390 v 2.6, if these settings do not match, the jobs may print endlessly. For more information, see the Communication link parameters topic.

Solution: Verify the host settings for pacing. Ask the host programmer to modify the SRCVPAC value in the host's logmode table to match the MAXOUT value on the Barr remote.

Slow print performance while RJE waits for data from host

Cause: Slow performance or printer clutching can be caused by incorrect settings in JES2 on the host for the PACING, VPACING, PASSLIM, MAXOUT, CKPTLINE and CKPTPAGE parameters. These parameters govern flow control and job recovery if communications are lost with the host. For more information, see the Communication link parameters topic.

Solution: Ask the host programmer to set the parameters to the following optimal values.

Recommended Setting	Description
CKPTLINE=66	The number of lines to backspace when resuming transfer.
CKPTPAGE=10	The number of pages to backspace when resuming transfer.
PACING=7, VPACING=7, PASSLIM=7, and MAXOUT=7	The data frame pacing parameters; they must all be the same value.

Non-printable characters are replaced with spaces

Solution 1

Cause: When a non-printable character is replaced with a hexadecimal 40 (a space), translation is probably occurring on the host. Translation is usually controlled by the TRANS parameter.

Solution 2

Cause: When testing the Barr product, the host programmer copied the JES spool files (test files) onto the host multiple times. Copying the spool files allows multiple host-to-Barr transmissions without having to run the host job again that creates the output file. The JES2 COPY feature, however, examines the data file being copied and replaces all non-printable characters with 40h (spaces), even if the TRANS parameter is set to TRANS=NO in the remote printer statement.

Solution: Run the job again on the host or prevent deletion of the output data set on the JES2 spool. If the job is not deleted on the JES2 spool, transmission of the output may continue until the printer is drained.

$HASP190 message is printing

Cause: The host can be configured to send job information using either a $HASP190 message or using PDIR information. If the $HASP190 message is used, it will be sent each time something in that message changes. For example, if the form or FCB name changes between the current and previous print job, the host will send this message. Because the $HASP190 message is automatically received on the remote as print data, there is no way to stop it from printing. Typically, the $HASP190 message is used in conjunction with FCBLOAD. FCBLOAD, however, is not recommended with RJE.

Solution: Ask the host programmer to send PDIR information instead of the $HASP190 message. This will prevent the production of the $HASP190 message and make the form name and FCB name more reliable.

When the host is changed to send PDIRs, FCB data will no longer be sent to the printer by the host. You will need to update RJE's Mount forms by option. On the RJE Configuration Utility's Device Control tab, make sure Use FCBLOAD is not selected. From the Mount forms by drop-down list, select SETUP=PDIR FORMNAME or SETUP=PDIR FCBNAME.

Jobs with a record length of 133 characters are truncated to a 120-character width

Cause: The host JES2 remote definition has the print stream defined to a 120 character maximum record width.

Solution: Ask the host programmer to redefine the LRECL parameter and PRWIDTH settings for the print stream to a 133 character width. These parameters are found in the JES remote definition.

The last line of the job log is overprinted

Cause: Two files, the report and job log (SYSPRINT), are being produced with the same output class. The job log usually goes to a non-printed class, but in this case the report and job log are both sent to the same printer destination. If the job log prints first, the report will force a new page and print correctly. If the report prints first, however, the job log will not issue a page break and will start printing immediately after the report.

Solution: Ask the host programmer to send the job log to a different non-printed class or a hold queue at the host. This will eliminate the risk of it printing after the report without a page break.

FCBLOAD is causing jobs to print incorrectly

Cause: The FCB definition that is coded on the host might not be the same FCB definition sent to the printer using FCBLOAD. FCBLOAD is not recommended with RJE.

Solution: Ask the host programmer to send PDIR records instead of using FCBLOAD. You will need to update RJE's Mount forms by option. On the RJE Configuration Utility's Device Control tab, make sure Use FCBLOAD is not selected. From the Mount forms by drop-down list, select SETUP=PDIR FORMNAME or SETUP=PDIR FCBNAME.

$HASP094 I/O

Solution 1

Cause: Both the host and the remote are attempting to start a device (printer, reader, console) on the same LU.

Solution: This is normal behavior. This will occur occasionally because the LUs are shared. No data will be lost.

Solution 2

$HASP649

Cause: An invalid host command has been sent from one of the following locations.

Solution: You will need to reenter the command, or correct the invalid command on the RJE Configuration Utility's Commands tab or Connection Control tab.

Page format error, page will not be printed

Cause: The host programmer performed the IPL Acronym for initial program load. The process of copying an operating system into memory when a system is booted. without saving job routing configuration changes. This causes jobs to be received incorrectly and to be assigned the wrong class in the Spool Window. The jobs are then routed to a printer that cannot accept the job format commands. For example, a Xerox Metacode job is sent to an HP Laserjet PCL printer that prints incorrectly and causes printer errors.

Solution: Ask the host programmer to save job routing configuration changes and then perform the IPL.

RJE device not defined. Check JES remote definition

Cause: This is caused by a request to begin printing on PR2. The following line from the Diagnostics Utility trace file shows print data starting on PR2 (indicated by 31 in the following example).

The RJE description indicates 1 JES printer, so PR2 is not defined. In this case only PR1 is valid. This could occur with other printer numbers. For example, 3 printers are defined in the Barr software, but the print is coming down PR4.

Solution: On the RJE Description tab, select 2 from the Printers drop-down list. Alternatively, you can modify the host JES remote definition to eliminate PR2, causing the data to be routed to PR1. This is much more difficult than changing the Barr software settings, but may be appropriate depending on the intended operation.