Users can access IBM i through any browser on a variety of desktop operating systems or even through mobile devices.

System i Access for Web is the Web-based solution that enables users to connect to their IBM i systems through their browsers. This option requires no additional software to be installed on the desktop other than the browser. It provides many features for browser users to work with IBM i resources: for example, the ability to upload PC data to DB2 for i, query and download database information, convert printer output to PDF format, and more. It also allows users to start 5250 sessions from which they can run host applications or IBM i commands.

The January 2009 MC Press article "System i Access for Web: The Fast Path to Configuration and Managing End User Access" covered software requirements as well as tips on configuration and on restricting access to functions. In this article, we will compare Access for Web's 5250 interface with emulators like PC5250, which is the most popular component in the System i Access for Windows product (which many of us still call "Client Access"). In addition we'll take a closer look at System i Access for Web's 5250 functions and capabilities.

Getting Started

One way to start a 5250 session is by pointing your browser to the main System i Access for Web URL; then, on the left navigation bar, select 5250 > Start Session. Figure 1 is the result.

Figure 1: Start your 5250 session. (Click images to enlarge.) 

In the System field, the value filled in as default will be the IBM i system you are authenticated to. You can specify any IBM i in your network here, and there are several other fields to specify for the session. We'll take a look at some of these settings in more detail later. If you press the Start Session button and have not selected the Bypass Signon checkbox, the result will be Figure 2, the IBM i signon screen. The 5250 uses a TN5250 session; therefore it runs as an interactive job.

Figure 2: If you didn't bypass signon, you'll get the IBM i signon screen.

Comparison with the Windows Client's PC5250

There are many differences with the 5250 function in System i Access for Web when compared to full-function emulators like PC5250 in System i Access for Windows or IBM Personal Communications. The differences have to do with Access for Web's implementation in the Web application serving environment.

The first step in understanding the differences is to look at the different nature of the two environments. With the full-function emulators, like PC5250, all of the code needed to keep track of each keystroke, interact with the 5250 session, and update the display is running in the Windows operating system on the PC. Refer to the System i Access for Windows portion of Figure 3.

Figure 3: Note how the different environments work.

You are interacting with an application that, as you type, takes each keystroke, directly interacts with a 5250 session, and updates the display with the result. For System i Access for Web, the user input and display portions of the scenario are separate from the 5250 session interaction. Refer to the Web portion of Figure 3. The user input and display update occur in a Web browser using an HTML form. The 5250 session interaction occurs in a Web application server on the IBM i. The connection between the browser and the application server is via HTTP. HTTP is a request-driven interface: the browser makes a request, and the application server provides a response. When entering data on Access for Web's 5250 screen, you are interacting with an HTML form in your browser. The 5250 session is not aware that anything has occurred until you take an action to submit the form, such as clicking the Enter button on the form or pressing the Enter key on the keyboard. When the form is submitted, all of the entered data is sent to System i Access for Web. The data does not record an exact sequence of keystrokes but is the collection of data from the fields on the form. With PC5250, the data is received as a sequence of keystrokes in the order they are typed. With Access for Web, the data is received as a collection of strings from input fields rather than as a sequence of keystrokes. In addition, the order in which the fields are received is not necessarily the same as the order in which the data was entered on the screen. Access for Web gives the data to the 5250 session, which processes the data and updates the session. When the update is complete, Access for Web takes a picture of the screen, renders it in HTML, and sends it back to the browser to display.

This separation between user interaction and session interaction results in a number of differences between Access for Web's 5250 interface and full-function emulators like PC5250. The most notable differences are these:

Cursor-Sensitive Actions

Since the data that Access for Web receives is a collection of strings rather than a sequence of keystrokes, the interactions in an input field that are sensitive to the cursor position, like erase EOF and field exit, will not work the same as in PC5250.  

Here are examples of functions that are sensitive to cursor positioning within a field that are not going to give the results you'd see with PC5250:

• Backspace
• Beginning of Field
• Cursor Down
• Cursor Left
• Cursor Right
• Cursor Up
• Delete Character
• End of Field
• Erase EOF
• Field Exit
• New Line

What will occur with Access for Web's 5250 depends on your application, the cursor-sensitive function you are trying to perform, and the order in which Access for Web received the data from the form. Therefore, these functions that are dependent on cursor positioning within an input field are not supported.

Will prompting with F4 work? F4 would work, since this prompt function is not dependent on the exact position within the field. Also, F1 will give you Help.

Data Entry in Fields

On the traditional green-screen, users are accustomed to input fields being in overwrite mode, which allows you to type over the data in the field. Input fields in a browser are in insert mode. So if the browser entry fields contain data, you change the data by deleting the existing data and entering the new data.

Break-Message Handling and Other Unsolicited Writes to the Display

Because HTTP is a request-driven interface, for 5250 applications that perform unsolicited writes to the display, the user will not see the updated display unless the user takes an action to submit the 5250 form. For example, you're at your browser, and the operator sends you a break message. The message will not break to the display until you do something to submit the 5250 form, like press the Enter key or press the Refresh Screen button on the keypad.

There are other similar scenarios where the screen is not going to give immediate feedback: for example, when the screen updates after you do a system request or use the Attention key or when you use Qshell, Telnet, or FTP. On a traditional green-screen, those would break dynamically, not related to whether input inhibited is on or off. Those interactions are going to be different on Access for Web's 5250, where you may need to use the Refresh Screen on the keypad in order to see the updates on your screen.

Keyboard Mapping

System i Access for Web does not support keyboard mapping, although it does provide limited support for the keyboard. The Enter, Page Up, Page Down, and function keys are support if enhanced JavaScript is enabled when the session is started. The enhanced JavaScript function is enabled by default when you use Start Session. If you configure a session (we'll cover configured sessions later), be sure that the setting "Enable advanced JavaScript functions" is checked, which is the default, shown in Figure 4.

Figure 4: "Enable advanced JavaScript functions" is the default.

Because of these differences, the 5250 function in System i Access for Web is not meant to replace full-function emulators like PC5250 or IBM Personal Communications for some users, such as data entry personnel who require cursor-sensitive actions within fields or keyboard mapping or those users who would lose productivity by using the mouse.

An additional difference: Emulator High Level Language API (EHLLAPI) is not supported. EHLLAPI is for screen-scraping applications or for interacting with other Windows desktop applications.

Macros

The 5250 function in System i Access for Web provides the ability to record and play back macros. Figure 5 shows the Start Recording button on a 5250 screen.

Figure 5: Use the Start Recording button on a 5250 screen to record macros.

To record a macro, click the Start Recording button, take your actions, and then press the Stop Recording button. You'll be presented with a dialog to give the macro a name. The macros you have recorded or that you have been given access to are available to play in your session from a macro drop-down list. You can see this on Figure 5 in the Macros field. In addition to playing the macros during the session, you can specify the initial macro to play when you start a session or configure a session. Figure 6 shows the Initial Macro drop-down on the Configure New Session screen.

Figure 6: The Initial Macro drop-down appears on the Configure New Session screen.

The recorded macro represents the interaction between System i Access for Web and the 5250 session. The interactions are recorded in the order they were processed. When a macro is played, you do not see all of the interactions with the 5250 session. Instead, you'll see the result after the macro has completed. This is different from playing back PC5250 macros, where the user sees all keystrokes.

You can view the macros you've recorded by scrolling down on the 5250 screen and taking the My Macros link. From the macros list, you can copy, delete, rename, create a shortcut to, or edit the macro.

As stated earlier, the cursor-sensitive actions will not work as you expect when interacting with the 5250 form in the browser. However, those actions will work in the macro playback if you edit the macro and arrange the data and functions in the proper order. For example, suppose you need to perform a repeated set of steps: go to a field, change it, field exit, go to the next field, change it, field exit, and so on. If you put these steps in the macro in the precise sequence, the execution occurs in that sequence. This works during macro playback because, at the time the macro is played, it is played in direct interaction with the 5250 session in the Web application server. Furthermore, the order of the interactions in the 5250 session in the Web application server is dictated by the order they occur in the macro.

Workstation ID

You can specify the workstation ID, also called session ID, when using the 5250 emulator in System i Access for Web. This is the device name that is used for the TN5250 session when connecting to IBM i. Here is how the workstation ID can be configured.  

Back on Figure 1, which shows the Start Session display in System i Access for Web, you can see the section to specify Workstation ID. There are two Workstation ID options:

• Use user ID--The System i Access for Web authenticated user ID is used for the workstation ID. It allows up to 10 characters.
• Specify workstation ID--Enter a workstation ID of your choice, up to 10 characters. If you select the radio button and leave the text field blank, the server generates a value. The default device name starts with QPADEV.

There are two configuration options for avoiding conflicts:

• Avoid duplicates for this user--When this option is enabled, a wild card character is added to the device name to make it unique for the current user.
• Avoid duplicates with other users--When this option is enabled, the IBM i adds a wild card character to the device name to make it unique for all users on the IBM i.

When using these "Avoid" options, if the specified device name already contains 10 characters, the name will be truncated before adding the wild card characters to make a maximum of 10.

Some System i Access for Windows PC5250 users are accustomed to configuring the workstation ID by inserting keywords and special characters in the workstation ID field. Here is how the keywords and special characters are handled in System i Access for Web:

• Computer name or User name (&COMPN or &USERN)--These keywords are accepted if entered for workstation ID. However, they will not resolve to the PC name and the Windows login user ID like they do in PC5250. The reason for this is that System i Access for Web runs entirely on the System i. There is no code running on the PC. Therefore, the Computer name will get resolved to the IBM i host name, and the User name will get resolved to the user profile name of the Web application server job. Also note that using the &COMPN and &USERN keywords could result in workstation IDs that are longer than 10 characters, which would then be truncated.
• Session Type ID (%)--This will add an "S" to workstation ID, indicating that this is a display session. With PC5250, a "P" would replace the percent symbol (%) if a printer session was started. However, System i Access for Web has only display sessions, not printer sessions.
• Short session ID (*)--Adding this character will make the ID unique for this user. The System i Access for Web option "Avoid duplicates for this user" also causes the asterisk character (*)  to be added at the end of the ID. Therefore, if you use both the asterisk and "Avoid duplicates for this user," then two special characters will be added to the workstation ID.
• Collision Avoidance ID (=)--Adding this character will make the session ID unique. The System i Access for Web option "Avoid duplicates with other users" also causes the equals character (=) to be added at the end of the string. Therefore, if you use both the  equals character and "Avoid Duplicates With Other Users," then the equals character will be added to the string twice.

For example, suppose you have users connecting from locations around the country, and you want to identify their location by the workstation ID when you look in the interactive subsystem. For your North Carolina users, configure a new 5250 session. Select the Specify Workstation ID radio button, enter %NC in the text field, and leave the default checked for "Avoid duplicates with other users." Create a shortcut to this configured session and set policies so that your North Carolina users can only start a session using this configured session. Now, user NCSALESMAN signs onto System i Access for Web using the shortcut and is the first to start a 5250 session in his group. The resulting device name would show as "Display: SNC0."

Printer Emulation

Many of our customers use System i Access for Windows PC5250 printer emulation for remote printing. PC5250 printer emulation allows you to use a printer connected to your PC as if it were connected to the IBM i. This is done by configuring a 5250 printer emulation session for the printer attached to your PC, creating an output queue on the IBM i, and assigning it to your remote 5250 printer emulation session. The printer output directed to this queue is routed to the PC printer and prints automatically.

Using System i Access for Web, you can print to your PC printer with a few extra steps; however, it is not automatic as it is with PC5250 printer emulation. Here are some options.

The printer output gets spooled in SCS or AFP with overlays and so forth and is put on the output queue. Using System i Access for Web, you have options to convert the IBM i printer output to several different formats: for example, PCL, PNG, TIFF, or AFP Viewer formats. You do this by opening the Print tab, expanding the Printer Output list, and then selecting View As in the action column. Another format System i Access for Web supports that is the most popular is PDF. From the Printer Output list, select View PDF, and you'll see a dialog as shown in Figure 7, where you can select the destination. Display the PDF document in your browser, email it as an attachment, place it in one or more of System i Access for Web personal folders, or place it on an output queue. Of course, with any option you choose, you'll need to prototype your output to ensure that your document layout is preserved.

Figure 7: System i Access for Web supports PDF format.

System i Access for Web has additional functions for facilitating the PDF conversion process called PDF Printers and PDF Printer Output. Using Access for Web, you can create a PDF printer, which automatically transforms SCS or AFP printer output into PDF documents. This transformation occurs at the time the file is spooled so that the PDF documents are readily available, as opposed to the Printer Output list's View PDF option previously described, where the transformation occurs manually at the time the action is selected. The PDF Printer Output function lets you display the list of documents transformed by PDF printers. You can view and print the PDF documents on the local PC printer or print the documents on an IBM i-defined printer from the output queue. The PDF Printer and PDF Printer Output functions require that the customer has purchased and installed the IBM Infoprint Server for iSeries (5722-IP1). Using the View PDF option of Printer Output does not require Infoprint Server; however, Infoprint Server is used for the transformation if it is installed.

To print IBM i output on PC printers that are not attached to the network, your System i Access options are to use either System i Access for Windows PC5250 printer emulation or one of the conversion functions available in System i Access for Web and then print the converted document from the viewing application on your printer. If you have a printer that is attached to the network and can be defined on the IBM i as a printer, several remote printing options are available with IBM i. Using the Internet Printing Protocol (IPP) function is one option. For example, you could have an IPP-enabled remote printer (most new printers are IPP-enabled) and associate an IBM i printer device description, writer, and output queue with this IPP-enabled printer. Then all output directed to that output queue will be printed on the IPP printer. To find out more about IPP printing, refer to the IBM i Information Center; once you've selected your release, search for "Internet Printing."

Bypass Signon

Starting in V5R4, System i Access for Web supports bypass signon with a checkbox on the 5250 Start Session function, as seen in the Start Session screen in Figure 1. One requirement for bypass signon is that the QRMTSIGN system value is set to *VERIFY. Another requirement is that System i Access for Web is configured for one of the following authentication type and method combinations available on the Configure command (CFGACCWEB2):

• Application authentication, AUTHTYPE(*APP)--This is the default type of authentication. This means that System i Access for Web handles the authentication using HTTP basic authentication. You do not need an Authentication Method parameter (AUTHMETHOD) with AUTHTYPE(*APP).
• Application Server authentication, AUTHTYPE(*APPSVR), coupled with Authentication Method of Kerberos, AUTHMETHOD(*KERBEROS)--With this method, a Kerberos principal name is used to authenticate a user. This requires the use of V6R1 System i Access for Web configured with WAS 6.1 or later.

Note that there are other AUTHMETHOD choices for application server authentication: form-based authentication, AUTHMETHOD(*FORM), and HTTP basic authentication, AUTHMETHOD(*BASIC). Bypass signon is not supported with *FORM and *BASIC methods. The reason the *KERBEROS method is supported for bypass signon is that the Telnet server, used by 5250, supports using Kerberos authentication. On the other hand, with the *FORM and *BASIC authentication methods, a user is authenticated with the WebSphere user registry and then Enterprise Identity Mapping (EIM) is used to generate an identity token, which is used to authenticate with IBM i. This method is not supported by the Telnet server.

As a comparison, the PC5250 emulator in System i Access for Windows supports single signon by using a Kerberos principal name to authenticate a user. .

The bypass signon function is available for both System i Access for Web servlets and portlets. The authentication methods described here are for the System i Access for Web servlets. For portlet info, refer to the iSeries Information Center. Search for "single sign-on considerations."

Test Drive 5250 Yourself

How will you know if this interface will work for you or the users in your business? You will want to try the 5250 function yourself. One option available is a demo system. A demo environment is established on an IBM i system where you can connect from your browser via the Internet and see the functions in System i Access for Web. If you'd like to see the demo site, send Linda an email at This email address is being protected from spambots. You need JavaScript enabled to view it. for the URL and the user profile and password.

Another option for trying the product is to configure it on your system. Follow the steps in the January article "System i Access for Web: The Fast Path to Configuration and Managing End User Access." The article lists the Web application environments supported and promotes the integrated Web application server, which is delivered as part of your HTTP Server for i, as a fast way to get up and running yourself.

Summary

While the 5250 emulator is not meant for your data entry personnel or other personnel who depend on specific keyboard interactions, it could be very useful for some i users in your business. An attractive characteristic is being able to configure the product once on your IBM i without having any desktop requirements other than a browser and therefore getting away from desktop administration. Your remote users can use any browser on a variety of desktop operating systems or even on mobile devices. They point their browser to the URL for System i Access for Web and then use the IBM i command line or run their applications without needing a desktop emulator like PC5250 installed. Check it out yourself by looking at the demo or by configuring System i Access for Web on your system.  

Linda Hirsch and Jason Hansen are advisory software engineers in System i Access Development in IBM Rochester, Minnesota. Contact Linda at This email address is being protected from spambots. You need JavaScript enabled to view it. or Jason at This email address is being protected from spambots. You need JavaScript enabled to view it..

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Also Read

Practical Middleware: Starting the Journey

IBM i 7.2: The Carrot Versus the Stick

A Renaissance for Domino