This topic contains solutions to common problems that you might experience with BARR/NJE.
Microsoft SNA Client failed to establish a sponsor connection to SNA Server
LU is not "Available" when connection becomes active in SNA Server
Error occurs after modifying the Routing Table path under NJE Configuration
SNA manager says connection is active, but NJE is not connected
MVS operator console shows errors when operator starts NJE node program
Report has box character () or the @ character when printed
BARR/NJE print jobs received from the mainframe are not being printed as a group
JCL sent to host, but not the data file with the embedded command
Cause: Sufficient buffers were not available when downloading files.
Solution: Have the mainframe system programmer configure additional output buffers or purge the job. If additional output buffers cannot be configured, you can download the PDS members in sections by specifying specific subsets of the PDS members in the JCL. See the following example of how to specify specific subsets in the resource.obj. (In the example, the PDS member name is TEST.)
|
##resource.obj/b80 |
Cause: Both the Microsoft SNA Client and the Barr software request a user account for their services during installation. In a Windows Workgroup environment, however, it is not possible to get a service to access another computer in the workgroup using a user account, because users are defined separately on each computer. If the services are attempting to use a user account, this account access problem prevents the SnaBase service (the heart of the Microsoft SNA Client) from connecting to SNA Server. It also prevents the BARR NJE service from connecting to SNA Server, even if the SnaBase service is connected.
Solution: Configure both the SnaBase service and the BARR NJE service to log on as System Accounts, and then restart the services.
See also: Choosing the correct account type
Cause: When Microsoft SNA Server connects to VTAM, VTAM issues a request to activate each LU that is defined for the PU. If the LU is not defined in VTAM, VTAM will not activate it.
Cause: LU 0 and LU 1 are used by SNA Server for APPC Acronym for Advanced Program-to-Program Communication. A specification developed as part of IBM's SNA model and designed to enable applications programs running on different computers to communicate and exchange data directly. applications, which is why the LU number begins with LU 2 when you add a 3270 LU. Do not use LU 0 or LU 1 for the NJE application LU.
Solution: Verify with the host VTAM programmer that the LU you are assigning as the NJE LU number in SNA Server is configured in the PU definition for the SNA Server connection. There is a one-to-one correlation between the LUs defined in SNA Server and the LUs defined in VTAM. If the PU definition has LOCADDR = 100 then you must choose LU number 100 when you add the 3270 LUA to the connection in SNA Server.
Solution: Verify with the host VTAM programmer that the LOCADDR number assigned as your NJE LU is greater than 01.
Cause: The data file referenced by the embedded ## command in the JCL, cannot be opened because of invalid spaces in path.
Solution: When using long directory names that contain spaces in the embedded ## command, the path must be enclosed in quotation marks (for example, ##"C:\PROGRAM FILES\BARR\UPLOAD DATA\TODAYS FILE.DAT"/B80). Do not include the file send mode inside the quotation marks.
See also: Sending JCL files with an embedded command
Cause: The appropriate securities may not have been granted for the Barr node.
Solution: Check the securities by issuing the following command at the host:
$DNODE(xx)
where:
|
xx |
Replace xx with your node number. |
You will receive a display for that node. Verify that the following values are set.
AUTH=(DEVICE=YES,JOB=YES,NET=YES,SYSTEM=YES)
If any of the host settings deviate from the above, you will need to change the settings to match. Use one or more of the following commands to change the AUTH settings. Remember, xx is your node number.
$T NODE(xx),AUTH=DEVICE=YES
$T NODE(xx),AUTH=JOB=YES
$T NODE(xx),AUTH=NET=YES
$T NODE(xx),AUTH=SYSTEM=YES
You can then issue a $DNODE(xx) command to verify that the changes took effect. This will give the Barr node the appropriate permissions to execute commands on the remote node.
Cause: The JES2 definition may not have PATHMGR=NO defined.
Solution: Add PATHMGR=NO to the node definition in SYS1.PARMLIB(JES2PARM) so that it resembles the following:
NODE(i) NAME=nodename,PATHMGR=NO
where:
|
i |
Replace i
with the node number. |
If you are using a customized line definition, your NODE definition may resemble the following:
NODE(o) NAME=nodename,PATHMGR=NO,LINE=i
where:
|
o |
Replace o
with the node number. |
The PATHMGR=NO can also be performed dynamically, ($TNODE(xx),PATHMGR=NO), but keep in mind that the change is only in effect until the next warm start of JES Acronym for Job Entry Subsystems of the IBM MVS operating system. These subsystems are used for entering jobs into the MVS operating system and dispensing the output from the jobs.
See also: Configuring JES2
Cause: Modifying the routing table path in NJE Configuration modifies the "pointers" to the routing table itself, and requires that the routing table information be reentered (for example, after modifying the routing table path, the routing table field will revert to a blank field). The information entered in the routing table path is stored as a text string in the following Windows registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Barr Systems\Network Job Entry\Routing\Path.
Solution: Verify that the routing table path selected is correct, and that it ends with a trailing backslash. Check that the routing table field is not set to a blank field. Correct entries as necessary. The registry key mentioned above can be verified with the REGEDIT utility.
These steps require you to use the Windows Registry
Editor. The system registry contains information about how your computer
runs, and your computer might not work if there is an error in your registry.
If you are unfamiliar with the Registry Editor, we do not recommend that
you perform this procedure. Please contact
Barr Systems Technical Support and reference this topic to be walked through
this procedure.
See also: Working with NJE routing tables
Cause: The job card must be coded as: //RESOURCE JOB ...............
If it is changed to something other than //RESOURCE, Barr Enterprise Print Server does not recognize the file as a resource and sends it to the print spool instead of to the printer.
Solution: Make sure the //RESOURCE portion of the job card has not been modified. For security purposes, most mainframe systems use parameters in the job card for user information. It is common to customize the job name on the job card to reflect the submitting users identification. This would cause problems for the FCB download process.
See also: Downloading host resources using NJE
Cause: The Microsoft Client for SNA Server updates some environment variables in Windows (such as the path to the necessary DLLs). However, the update does not complete until the computer is restarted. As a result, the BARR/NJE software does not find the DLLs it needs to connect to Microsoft SNA Server.
Solution: Restart the computer after installing Microsoft Client for SNA Server.
Cause: An extra copy of the WINRUI32.DLL or SNAMOD.DLL binary file is interfering with the BARR/NJE Application Programming Interface call to the Microsoft SNA Server service.
Solution:
Open Windows Explorer and select drive C.
Right-click and select Find.
In the Named box, enter WINRUI32.DLL.
Make sure the Include subfolders box is selected.
Click Find Now.
If you find this file in any folder other than <drive>\SNA\SYSTEM, rename it to WINRUI32DLL.SAV, restart your workstation, and test your NJE connection. If you have more than one local drive, search each drive.
Follow the steps above searching for SNAMOD.DLL. If the file is found, rename it to SNAMODDLL.SAV.
Renaming these extra versions of WINRUI32.DLL and SNAMOD.DLL,
can cause problems for any program that might have installed them. If
this is the case, you might not be able to run that program on the same
workstation as the Barr Enterprise Print Server.
Cause: The pacing value is set to zero.
Solution: Have the host VTAM programmer create a logmode entry on the LU used for the NJE session. A sample logmode table entry can be found in the Configuring VTAM topic. Once this entry has been created, the LU in VTAM will be changed to the following:
<luname> Locaddr 02,USSTAB=,DLOGMOD=BARRMOD
Cause: The MAXBTU parameter might be incorrect. The value of the MAXBTU parameter is based on your connection type:
For SDLC Acronym for Synchronous Data Link Control. A low-level communications protocol for synchronous communications. connections, the MAXBTU length on SNA Server or Workstation must be equal to the MAXDATA parameter in the VTAM PU definition.
For channel connections, the MAXBTU parameter must be less than the VTAM definition for IOBUF multiplied by the MAXBFRU parameter in the VTAM PU definition.
Solution: For SDLC connections, match the MAXBTU length defined on the SNA Server Connection (on the SDLC tab) to the MAXDATA definition on the Host VTAM PU to which you are connected.
If you are using BARR/CHANNEL for SNA Server as the link service for your NJE Connection LU, the value of the connection's MAXBTU parameter must be less than the VTAM definition for IOBUF multiplied by the MAXBFRU parameter in the VTAM PU definition.
See the following example of what to do with these parameter settings in a channel connection to help guide you with your particular settings.
MAXBTU (SNA Server connection definition) = 4105 (default)
MAXBFRU (VTAM PU definition) = 6
IOBUF (VTAM startup definition) = (200,508,19,,1,20)
By applying the formula mentioned above, you will find the MAXBTU is too large:
MAXBFRU (6) * IOBUF (508) = 3048 < MAXBTU (4105).
You can correct the problem by choosing one of these methods:
Reduce MAXBTU from 4105 to 2540.
Increase MAXBFRU from 6 to 9 (or greater).
See also: Optimizing Microsoft SNA gateway with BARR/CHANNEL link service
Cause: The jobs are discarded by the host's security system because they do not contain a valid origin node and user.
Solution: Assign a valid origin node The NJE node where data originates. See node. and user to the print job.
Use the Print Utility to add the ORGNODE and ORGUSER attributes to the print job.
Add the file to the spool again.
Resubmit the file to the host by starting the spool printer.
Cause: The connection to the mainframe is up, but the connection from BARR/NJE to the Microsoft SNA Workstation is not. This can happen when all of the appropriate settings do not match. Remember that the settings are case sensitive.
Solution: Check the NJE Configuration to make sure that the following parameters match.
BARR LU name = SNA Workstation LU name = JES2 LU name
BARR LU number = SNA Workstation LU number
If NJE is still not connecting after correcting the parameters, then check the NJE Configuration to make sure the parameters match.
BARR host node name = JES2 host node name
BARR node name = JES2 node name
If the parameters match, then make sure you have entered this command at the host: $sn,a=luname.
Cause: The NJE service is not started.
Solution: Start the BARR NJE service on the Barr computer.
Cause: Invalid DLOGMODE on PU definition in VTAM.
Solution: Verify that the DLOGMODE entry defined on the VTAM PU definition exists and is valid. If the entry is incorrect, correct the entry, re-activate the PU, and then start the node.
For documentation of VTAM sense errors, see the IBM
manual ISTM3102 "VTAM Codes".
Cause: For the Barr auto-start feature to function properly, the XID Type used by the connection must be set to Format 3. Using Format 0 does not allow the Barr software to effectively communicate with APPC on the host.
Solution: From SNA Server, change the XID Type on the System Identification tab to Format 3.
Cause: The host canceled the job being sent to it. The NJE protocol does not provide any information explaining why the stream was canceled.
Solution: Examine the host's console log to see why the job was canceled. Possible reasons are:
The data is corrupt. This might mean an incorrect data conversion choice was made when using Print Utility to import data to the Barr spooler. On the Format tab, make sure you select SYSIN data (JCL) as the file type.
The NJE host and Barr stream configurations are mismatched. The host may not support the stream in use.
Sending files to the NJE host requires correct values in the Destination Node (NDHGNODE), Execution Node (NJHGXEQN), Execution User (NJHGXEQU), and Originating Node (NJHGORGN) fields.
Cause: The NJE default destination node was not found. Either the destination or path node was not defined in a routing table.
Solution: Verify that the routing table is configured correctly. Then make sure that all relevant header fields in Print Utility are properly completed so that the job contains the information that mainframe operators expect to see when it reaches the host. See the Sending files (JCL SYSIN) to the host topic for more information.
Cause: The host node name to which the job is being routed is not in the routing table of the currently active communications profile.
Solution: Assign the correct host node name in the routing table of the currently active communications profile. See the Working with NJE routing tables topic for more information.
Cause: The BARR/RJE DOS product has the TRANS=YES option, which translates any non-printable characters to a space. BARR/NJE, however, does not have this option. BARR/NJE sends the data to the remote without any translation occurring. The print file has low values (hexadecimal '00'), and the printer character for hexadecimal '00' is a box graphic character or an @ character, depending on the printer.
Solution: Complete the steps in the following sections.
Modify the code page
Open the EBCDIC code page you are using (for example, 3000).
Change the field next to 00 to 0020. (This will cause the 00 to print a space.)
Save the code page.
Modify the override table
Open the Configuration Utility.
Select Override
Table tab. 
If you have an active override table, modify the table. If you don't have an active override table, create one.
From the Rules box in the Rules Editor dialog box, select Data Set Header Overrides, and then click Add.
Under Actions, select <None>,
and then click Modify. The Rule Actions dialog box displays.
Because this will apply to all jobs, you do not need to add a condition.
Under Step 2: Choose the Header field to override, click the plus sign (+) next to Data Set Header to expand the list.
Click the plus sign (+) next to Internal Custom Section. Select NDHBCPAG - Code translation page field from the list.
Under Value, enter the EBCDIC code page number (for example, 3000). Use the Action box to verify the NDHBCPAG field is equal to your code page number (for example, NDHBCPAG=3000).
Click OK three times to exit the Configuration Utility.
Click Yes to restart the BARR SpoolCore service.
Receive jobs and print
If you need to reprint jobs that have already been received, change the NDHBCPAG value on existing jobs by modifying the Spool Window. Add NDHBCPAG (located in the Data Set Header Internal Custom Section) as a visible column, then modify the value to equal the EBCDIC code page number (for example, 3000).
Cause: The Print jobs while receiving data option is enabled.
Solution: Complete the following steps to disable the Print jobs while receiving data option.
Open the Configuration Utility.
Select the Spool Printers tab.
Clear the Print jobs while receiving data check box to disable this option.
Cause: The information packets being sent to the final destination (BARR/NJE node) are larger than what can be received through VTAM.
Solution: As a general rule, the MAXBFRU times the IOBUF bufsize needs to be greater than or equal to the largest possible packet of information that might be received from this device. For Ethernet One of the LAN physical standards. It allows multiple stations to access the transmission medium. connections, the largest information packet size must be kept under 1493 bytes, unless segmentation is acceptable to all PUs in the system.
See also: Optimizing Microsoft SNA gateway with BARR/CHANNEL link service
Cause: These symptoms might occur in a system that has a channel-attached 3174 and a downstream PU over Ethernet.
The information packets being sent to the final destination (BARR/NJE node) are larger than what can be received through 3174. Because a 3174 does not segment data frames or packets, it truncates the data being received from the application (POWER). Built-in error checking on the mainframe identifies that data is not being completely received and terminates the connection.
Solution: Do not use the 32K BUFSIZE for the PNODE recommended in the Help when there is a 3174 involved. 2048 or 4096 are acceptable values. Set the MAXBTU to 1033 if Ethernet is the connection type on the downstream side.
See also: Optimizing Microsoft SNA gateway with BARR/CHANNEL link service
Cause: The incorrect host node name is being used; therefore, the host will not authenticate the connection. Sometimes, the APPLID In SNA, VTAM communicates with many applications. The APPLID is the identifying name of a VTAM application. name for JES2 is entered for the NJE Host Node Name in the BARR/NJE settings.
Solution: Enter the correct node name for the host JES2 OWNNODE. To determine the correct value, the host operator can enter the $DNODE command on the host operator console to view a similar display:
|
$HASP826 NODE(1) |
In this example, the node that is identified as STATUS=(OWNNODE) has the node name BAR1JES2. The node name must be used in these three locations:
In the NJE Configuration dialog box, under Host node, in the Name box. This dialog box displays when you configure BARR/NJE.
On the Routing tab, in the Route to host node table so that Barr Enterprise Print Server can send SYSIN files to the host.
In the NJHGXEQN (Exe. node) header field when jobs are sent from Barr Enterprise Print Server to the mainframe.
Cause: When Print Utility is used to read files with an embedded command, first the JCL and then the called data file appear in the Spool Window. They are then sent to the host in the correct order (JCL first) when the host printer in the Spool Window is set to Ready status. If the JCL appears in the Spool Window, but the data files do not, it is likely that Print Utility does not have rights to access the data file directory. Because Print Utility is reading both the JCL and the data file, the service must have rights to both directories.
Solution: The Print Utility service must be configured as a user account, not a system account, and the service must have rights to the server and directory where the data file is stored. Follow the steps below to check the account type.
Open the Services utility.
Select the BARR Print Utility service, and on the menu bar select Action | Properties.
Select the Log On tab. If a system account is selected, we recommend you uninstall and then reinstall the software selecting the user account type. If you are unable to uninstall and reinstall the software, you can configure the service to log on as a user account.
See also: Sending JCL files with an embedded command
Cause: The host node name entered in the Barr software does not match the host OWNNODE parameter.
Solution: Verify that the host node name in the Barr software matches the OWNNODE parameter set on the host. The host node name can be found in the following locations in the Barr software.
In the Name field, under Host Node on the NJE Configuration dialog box, which is used when you configure BARR/NJE.
In the Route to Host Node list on the Routing tab so that Barr Enterprise Print Server can send SYSIN files to the host
In the NJHGXEQN (Exe. node) header field when jobs are sent from Barr Enterprise Print Server to the mainframe.
Cause: Because of network problems, the SYSOUT transmitter is canceled when a Data Send Failure error occurs. When the host encounters the error, it cancels the job and will not reconnect.
Solution: To recover the connection to the host, you may need to stop and restart the Barr NJE Service.