A major insurance company, a major government agency, and a major oil company all switched from SDSF to (E)JES without looking back. Why? Because (E)JES has superior
functionality and uses resources more efficiently. Companies not making the switch are not realizing the potential of some of their most significant expenses—people, hardware
and software.
In this summary, we will focus on just four areas where (E)JES excels when compared to SDSF: productivity, performance, security, and modernization – all areas in which (E)JES
excels when compared to SDSF. Productivity: (E)JES is more compliant with standard ISPF behaviors than SDSF. The user experience is smooth and consistent—free of idiosyncrasies. It requires fewer keystrokes to operate, provides answers more quickly, can be used to send reports via email or FTP, integrates with IBM Knowledge Center for message lookup, and teaches end users about z/OS as they use the product via adaptive pop-up help. (E)JES end-user documentation is thorough, easy to understand, and accessible through IBM Knowledge Center. SDSF does not even provide an end user manual.
Performance: One of the reasons (E)JES provides answers more quickly than SDSF is because it runs faster; much faster. It’s zHPF-enabled I/O driver delivers measurably superior SPOOL access performance and (E)JES typically requires only a fraction of the CPU time needed by SDSF to perform common query functions, such as displaying output on the JES2 Hold or Output queues. And, nearly 100% of the CPU time required for such queries can be offloaded to zIIP processors, a ubiquitous technology in modern
environments.
The test below was run on an idle 2965-D03. The Output display was refreshed 50 times in five-second intervals. The test was run without the benefit of zIIP offload. Security: Many SDSF customers still use ISFPARMS – an arcane security paradigm that relies primarily upon strict adherence to job naming conventions rather than modern SAF resource ownership concepts. This makes transitioning to SAF-based SPOOL security difficult. With SDSF, you cannot use SAF and ISFPARMS security at the same time. The
need for an all-or-nothing, overnight conversion is one reason so many SDSF customers are “stuck” using ISFPARMS.
(E)JES provides non-SAF internal security constructs that are similar to ISFPARMS in principle, but they are designed with SAF security concepts in mind. In typical customer
configurations, (E)JES internal security enforces SAF ownership rules – even when SAF calls are not actually made. Best of all, there is no all-or-nothing approach. (E)JES
internal security is intended to be used in conjunction with SAF-based SPOOL security.
ISFPARMS are easily converted to (E)JES internal security and one reason customers switch to (E)JES from SDSF is to simplify their SAF-based SPOOL migration path.
Modernization: Today’s customer wants modern browser-based access to z/OS resources. Unfortunately, many purveyors of products in this space offer “dumbed down” solutions and SDSF is no exception. Its web-based solution, which is accessed under z/OSMF, is extremely limited in function, performs quite poorly, and is difficult to use.
By contrast, (E)JES Web supports nearly all functions available to (E)JES 3270 users as well as many unique features of its own, such as PDF creation from the browsed
system out.
(E)JES Web performance is nearly indistinguishable from 3270 performance and even “power users” are finding significant value with it.
Phoenix Software International invests countless development man-hours implementing the latest cost-saving technologies and features into (E)JES. Our willingness to
consistently take this leadership role on behalf of our customers should be an important factor when deciding which company really has its customers’ best interests in mind.