Advertisements
After more than two decades of experimentation with client/server computing, centralized mainframes continue to host nearly 80 percent of mission-critical business applications. In many companies that have deployed client/server applications, mainframes coexist with distributed server platforms. These companies often face challenges as they seek to develop stable printing and file transfer mechanisms that integrate the processing power of mainframes and their subsystems with the resources of the distributed computing environment. In this type of environment, the use of IBM-originated facilities such as Remote Job Entry (RJE) and Network Job Entry (NJE) can be an extremely effective tool.
Information Technology (IT) professionals may find it difficult to determine the appropriate application for either of these facilities due to limited available comparisons of these technologies in the trade press and elsewhere.
The Evolving Technology of NJE
RJE allows desktop computer users to leverage the processing power of the mainframe host while maintaining local data and applications. It provides extensive file input and printer control as well as support for multiple form types and consoles.
For example, RJE permits a remote workstation, running a 3770 communications emulation, to transmit jobs to the mainframe Job Entry Subsystem (JES) or to receive output from JES for local storage, printing or other use. Systems managers must configure a unique RJE workstation identifier for each RJE workstation within JES prior to use.
IBM's NJE facility, an extension of JES, supplements and extends the functionality of RJE. Basically, NJE is a JES-to-JES communications system, enabling two JES subsystems on different host systems, or in different logical partitions (LPARS) of a single host, to communicate with one another. In this way, NJE provides peer-to-peer access to computing resources on IBM host systems, including S/390 and AS/400 hosts. Therefore, a user can submit a job on CPU "A" and can define, through the use of control statements, where (CPU "A", CPU "B", etc.) the job is to execute and/or where output is to be directed.
In order to operate, NJE establishes a network among peer hosts or nodes. A simple control statement such as /*ROUTE XEQ (NJE Node Name) is required to direct a job to execute on an NJE node, whether local or remote. Similarly, using the control statement /*ROUTE PRINT (NXRY), where X is the node number defined in JES and y is the printer location identifier, a user can direct output to any device or RJE location defined in JES.
NJE is specifically designed for transmitting jobs and operator commands and messages from one computing system to another in a network. It enables users to transfer work and data throughout a distributed network of mainframe-class and appropriately configured AS/400 minicomputer-class computing facilities, as well as, to RJE workstations. Peer-coupled systems in an NJE network may be interconnected by a variety of physical links. A link may be a teleprocessing line, channel-to-channel adapter, or channel-attached communications controller. SNA and TCP/IP networks can also provide host interconnections. Any member of an NJE network can send jobs, job output (SYSOUT), commands, and messages to any other member of the network where they have authority to do so.
Installations should always use the DESTID JES2 initialization statement to assign meaningful names for both RJE and NJE output destinations. Use of this statement allows the end user to route print to names like "BOSTON", "SHIPPING", "BDLG325" or "3RDFLOOR" rather than explicit destination names like R1 or N3. These names are easy for a user to understand, remember, and insulate them from future changes in the network configuration. If these symbolic destination identifiers are used ubiquitously, the installation can switch from RJE to NJE without changing any JCL.
Strengths of NJE
Due to its long history and widespread use, many IT professionals are more familiar with RJE than with NJE even though the latter is an established technology. While NJE has been available for mainframe-to-mainframe JES communications for nearly 20 years, it is rarely mentioned in computing. Only recently, has technical support for NJE been added to IBM's AS/400 midrange operating system. For these reasons, some systems professionals consider NJE a new technology and, as a consequence, are reluctant to use it for mainframe-to-distributed systems applications.
Although NJE is simple to implement, mainframe administrators sometimes express concerns that it may add unwanted complexity to their environment. However, as these IT professionals become familiar with NJE's networking strategy, they will be more likely to use it in companies with mixed mainframe and distributed computing platforms. When compared to RJE, NJE has at least five distinct strengths.
1. Advantage NJE: Peer-to-Peer Communications
RJE was developed in the days when computers used 80 column punched cards to receive input programs and data and output was directed to 132 column printers or 80 column card punches. RJE workstations were fixed function devices designed only for sending cards to the mainframe and receiving print lines and cards back. At the time no one imagined personal computers, local area networks, or high-speed laser printers and there was no pressing need for exchanging with mainframes the complex data streams these new technologies would require.
NJE was developed as companies began deploying multiple mainframes at multiple locations. NJE allows for the exchange of jobs and print between peer hosts. Work can be submitted at one location in an enterprise, processed at another location and printed at a third location.
In an NJE network, hosts and remote stations function as peers with non-transformed information moving bi-directionally between them. NJE also enables users to transmit files without the need for programming, and receive output from the host. In addition, these users can send and receive print data sets and batch jobs. Users can also receive notification of job completion.
In a modern computing environment with desktop computers interconnected with Local Area Networks (LAN) the potential exists to exploit NJE for communication between workstations and mainframes. Data generated on a LAN that may require further processing on the mainframe can be directed to the mainframe platform via NJE. Conversely, LAN-based desktop computers in an NJE network can be used to access data sets on networked mainframes, perform work with them and/or direct output to any location (host, workstation, or printer) in the NJE network.
2. Advantage NJE: Job Routing and Control
In NJE communications, mainframes attach headers to jobs and data sets. These message headers contain a rich set of user and job information that is preserved when the job is routed from node to node. Routing headers provide the ability to add intelligence to NJE-based processing. Header information, including information about a job's originator, is always generated by the mainframe. However, the mainframe does not include these headers in the case of an RJE transmission.
In addition to originator information, an NJE job header also contains information that can be used to customize and automate processes in other ways. For example, a job header may contain information pertaining to form name, department number, job class, number of records, and so forth. Each of these header components can be used as a basis for automating the printing of files or their transfer to selected destinations.
3. Advantage NJE: Security
The ability to set authorization levels and password protection provides additional security for the connection between two NJE nodes. These settings are configured on the Host NJE node and grant a level of control to the remote NJE node via JES or RACF configuration. The typical JES authority levels are as follows:
*
Job - remote node has the authority to issue job-related commands
*
Device - remote node has the authority to issue device related commands
*
System - remote node has the authority to issue certain system commands
*
Network - remote node has the same authority as local consoles
Security features, other than password protection, were not emphasized in RJE design. NJE provides authorization levels and password security along with the added capability to control routing using job header information.
4. Advantage NJE: Ease of Configuration
NJE is straightforward and relatively simple to configure. First, for NJE over SNA a communications link is established in VTAM, the same as configuring an RJE connection. Next, the NJE node is defined in the Job Entry Subsystem by setting up the name for the NJE node in NJEDEF, the subsection of JES initialization parameters where NJE definitions are stored. If desired, additional parameters can be specified to automate or otherwise enhance NJE communications.
Compared to an NJE setup, configuring an RJE workstation is a much more laborious task. A typical RJE definition consists of defining RJE workstation facilities, teleprocessing lines, and logical lines for SNA terminals (such as, an IBM 3770, 3790, or a System/32 workstation). The remote configuration can range from one remote terminal (such as, a 2770 or 3780) to an RJE workstation consisting of a system operating many devices. Support of multiple logical units permits the concurrent use of more than one device at an RJE workstation. With NJE you can have multiple SYSOUT Transmitters active with only one logical unit. RJE only allows one console per device and NJE allows virtually an unlimited number of consoles and the consoles require no host configuration.
Devices for an RJE workstation are defined through the RMT(nnnn) statement and the $ADD RMT(nnnn) command. The RMTNUM= parameter on the TPDEF initialization statement is used to specify the highest number of devices that can be defined at a given installation. Up to a maximum of 15 devices can be defined on each RJE definition, and up to eight of these device definitions can consist of a combination of printers, punches, and an optional SNA console. These device definitions may include:
*
One SNA console
*
Up to seven printers (or six if an SNA console is defined)
*
Up to seven punches
*
Up to seven devices that consist of readers only
Specifying SETUP=PDIR on the RMT(nnnn) allows data sets to be spooled and multiple copies of output (from a single, transmitted copy) to be created.
An RJE workstation configuration involves the detailed specification of each device that is hard wired together to form an RJE subsystem. NJE configuration, aside from optional parameters, involves only the specification of an NJE node name representing a remote JES spooler that is to receive output data.
5. Advantage NJE: Compatibility with Industry-Standard Clients and Server
NJE enjoys widespread third-party software support, enhancing its compatibility with industry-standard desktop and server systems such as Microsoft Windows NT. Products like BARR/NJE, developed by Barr Systems, Inc., enable support for NJE command and control using widely installed Microsoft desktops.
Operating RJE and NJE with Barr Systems Support
IBM's NJE provides a substantive set of capabilities for supporting peer-to-peer networking and modern distributed computing. To exploit these capabilities on non-IBM platforms requires either custom programming or the use of third-party NJE software and spooler products. Of the latter, Barr Systems' NJE solution is among the leaders of Windows NT based software packages.
By configuring as an NJE node, a Windows NT server hosting the BARR/NJE and BARR/SPOOL software, companies can realize the benefits of sharing centralized mainframe and distributed processing resources in a seamless, enterprise-computing platform. Barr Systems products support a broad range of physical and logical connectivity options to provide stable connections between mainframe and Windows NT hosts. The balance of the BARR/NJE solution consists of a rich NJE console that is fully integrated with the Windows environment, and a robust spooler that serves as a native repository of mainframe JES output. In addition, Barr Systems' BARR/NJE software provides a graphical user interface to facilitate customized routing and disposition of NJE jobs based on selected header information elements.
NJE can also be used to send output jobs and datasets to user directories, archive directories, Line Printer Daemon (LPD) servers, and NJE-connected mainframes. The BARR/NJE software also can be harnessed to leverage the header information in order to automate file transfers.
To facilitate a better understanding of the BARR/NJE solution, and the advantages of NJE versus RJE in addressing common corporate IT requirements, the following implementation examples are useful.
Case Study #1: Recovering From a Disaster
Disasters or unplanned interruptions of normal system processing can range from irritating-but simply resolved component malfunctions, to far-reaching and costly losses of data.
In one company, a disaster occurred when time-sensitive, mission-critical output from a mainframe-based application was directed to a printer that was defined as part of an RJE workstation. Unfortunately, the destination device had broken down and the job had to wait in the RJE workstation print spooler until the peripheral could be repaired or replaced.
Because the output was being handled through an RJE workstation, rather than through an NJE peer-to-peer connection, the company had no easy way to redirect the spooled output to an alternative host destination. Fortunately, the printer was repaired expeditiously by the printer vendor. The job was printed late-but still in time to be useful.
Due to this unforeseen event, the IT manager of this company sought an alternative. He selected Barr Systems' BARR/NJE and BARR/SPOOL and established an NJE peer-to-peer network. He tested the resulting network to develop a disaster recovery procedure that would work around a failed printing device in the future.
With BARR/NJE and BARR/SPOOL, he discovered, once a print job was received, it could be routed to any identified device in the NJE network. If an intended printer was unavailable, the job could be routed back to the host for redirection or it could be directed to other NJE nodes that he might deploy in the future. The data comprising the job is not changed in any way, so the job remains intact for re-processing and printing on another device.
Users of the BARR/NJE software, for example, can use NJE header information to determine automatically where a job should be printed or archived. If a company wants to have each TSO user's print data routed automatically to his or her local LAN printer, this can be accomplished readily using information about the job originator, which is stored in the NJE job header.
Header information, including information about a job's originator, is always generated by the mainframe. However, the information is ignored in the case of an RJE transmission since the destination is "hard wired" in the RJE configuration. With the Barr Systems' NJE software, originator information is received and can be routed to a user's printer automatically via a configurable printer spooler.
BARR/NJE also provides direct access to Barr's own Windows NT-based print spooler, BARR/SPOOL. This product may be used to send and receive print and job data sets, and fully supports job routing and other header-based job automation possibilities. BARR/SPOOL also supports common mainframe spool queue attributes such as JOBNAME, FORMNAME, FCBNAME, UCSNAME, Priority and Class. This capability enables NJE data to be received and stored on the BARR/SPOOL spooler in the same format as in the JES spool, eliminating the need to "pad records" after data is transferred.
Case Study #2: Long Print Records
Modern printers offer a wealth of capabilities designed to enhance the readability and graphics support capabilities lacking in older line printers. Capitalizing on these capabilities, however, proved an impediment for one IT manager who was handling JES remote printing using RJE.
Investigating a problem involving partially printed pages, she discovered that JES imposes a limit of 255 bytes on the length of a print record directed to a remote RJE printer. However, BARR/NJE provided a solution. With BARR/NJE, records can be up to 32,767 bytes in length. Through the deployment of a Barr Systems' BARR/NJE solution, this IT manager was able to drive printers at their rated speed and capability. She found that smaller fonts allowed more data to print on a line, shortening print runs, while users praised the graphical perspective that mainframe reports now offered. These print capabilities were impossible with RJE because of record length restrictions. With the Barr Systems' NJE solution, print became an asset rather than a liability for the IT shop.
The remote mainframe, in this distributed computing paradigm, is a true network peer of the BARR/NJE-enhanced workstation. Mainframe-connected peripherals appear as networked printers on the Windows NT desktop, with all device drivers and printer port definitions provided by the Barr product.
Conclusion
As these case studies illustrate, implementing an NJE solution can provide significant advantages for the IT organization by bringing the mainframe into the distributed computing environment, leveraging its unique capabilities and extensive resources to augment enterprise computing investments.
RJE continues to play a role in mainframe computing, and NJE does not preclude the effective use of RJE in specific applications. In fact, RJE workstations may be valid target destinations for local and remote NJE jobs.
However, BARR/NJE brings the mainframe into the modern, distributed, enterprise-computing environment. It offers a valuable and readily implemented set of capabilities to utilize the resources of the mainframe across a broader range of corporate computing requirements.
Contact Barr Systems to learn more about the many ways that NJE can be used to enhance the utility of your distributed computing environment. Barr Systems provides comprehensive solution sets to support the broadest possible range of remote printing and file transfer requirements for both NJE and RJE on IBM and non-IBM platforms.
