It wasn’t long ago that IT staff needed to repeatedly logon and logoff a single non-programmable terminal to access different applications. It wasn’t unusual, either, to find two or more terminals in a developer’s office, each with the ubiquitous “Far Side” cartoon attached. By the early ’80s, a software solution emerged to address that inconvenience. Homegrown “session switchers” did little more than permit toggling between active host applications. Typically, there was no interface and no ability to communicate between applications; nonetheless, the switchers measurably improved productivity.
The second generation of host session managers was more overt. Users logged on or were otherwise connected to an interface that presented an application list. From there, applications could be launched and logons could be navigated using basic session management scripts. Second-generation session managers had primitive menu displays with hard-coded session values, cryptic PF-key sequence controls, and took little advantage of available host graphical capability.
As more organizations adopted session managers as their host “portals,” these tools took on mission-critical status. What was originally developed as a productivity tool for programmers was now the enterprise interface—the point through which users accessed all applications. Increased dependency and workload drove much of the innovation still used today.
With today’s stable third-generation session managers, green-screen background application sessions can be navigated to transparently perform routine functions or to interact with each other while a user interacts with a new interface. New applications can be easily developed, too. Aesthetically pleasing use of color and Graphical User Interface (GUI) functions were introduced with these session managers; they exploited the APL character set and subscribed to IBM’s Systems Application Architecture Common User Access (SAA/CUA) guidelines (see Figure 1). Animation was even possible.
A decade had passed and, while session manager technology grew more reliably stable, interesting things occurred elsewhere in the industry: The mainframe had died, was reborn, and according to a landmark Datamation cover depicting Tony Bennett singing alongside an S/390, the mainframe was deemed “cool.”
Through it all, a commitment to the “Big Iron” has persisted. Most recently, IBM’s Mainframe Charter, “a framework for planned future investment with the goal of delivering ongoing value to mainframe customers,” provides clarity to those organizations that may have otherwise held a cautious position.
Today, if an enterprise has zSeries hardware, they’re probably using a session manager to manage access to their host applications. But whether these venerable tools are used solely for centralized access or are more creatively exploited, they’re still critical to an organization’s success.
Traditional Session Manager Functionality
A session manager’s most fundamental attribute is its ability to permit users to connect from it to multiple applications, toggling between them as necessary. Many sites either LOGAPPL all devices to their host session manager’s entry point APPLID or name that APPLID as the DEFAULTAPPL in their TELNETPARMS. In that way, the mere act of either powering on a non-programmable terminal or launching a TN3270 emulator presents the user with a list of available host applications; a portal to the host, so to speak. Full-function session managers provide more comprehensive portal operation such as first querying the host security system or group-level profile to present only those sessions for which the user has interest or authorization.
Other functions typical session managers provide that are particularly beneficial to organizations include: