Janus Web Legacy Support

Janus Web Legacy Support is a facility that is part of Janus Web Server that makes it possible to access existing User Language 3270 applications from a browser with little or no coding. Because of the lack of a coding requirement, it might be tempting to use this facility as an exclusive or, at the very least, strategic solution to the problem of providing browser access to Model 204 data and applications. This, however, would be a mistake.

Mapping 3270 screens to HTML does not take advantage of most of the powerful features of web technology (hypertext links, redirects, local caching of data, local scrolling, standard intuitive interface, etc.) and carries all the limitations of the 3270 interface. Furthermore, because of the stateless nature of browsers and because of a few 3270 features that do not map naturally to browser features, a 3270-to-HTML mapping facility provides an end-user interface inferior to that provided by a true 3270 emulator. When 3270 emulation access to existing applications (whether it's Janus Web Legacy Support or a non-Model 204 specific product) is used for all browser access to Model 204 data, it is browser access in name only, with most of the benefits of such access unavailable to the end-user.

All this said, Janus Web Legacy Support can be very useful in many situations. It can make it possible to mix and match true web-style access to Janus Web Server applications with access to 3270-based applications without forcing end-users to constantly switch between a browser and a terminal emulator. This allows the gradual migration of applications to true web applications and it makes it possible to leave unconverted applications that are unimportant and/or infrequently accessed. A good way of thinking about a Janus Web Server implementation is to plan on converting as many of the most important and frequently used applications into true web applications and to provide access to all the others through Janus Web Legacy Support.

Getting started

Getting started with Janus Web Legacy Support is simple. When a web thread issues a READ SCREEN, Janus automatically converts that screen to HTML and starts up a Janus Web Legacy 3270 session (if one hasn't already been started) for the end-user. For example, given the following web rule:

JANUS WEB portname ON /SUBSYSMGMT CMD SUBSYSMGMT

A request for URL "/subsysmgmt" would cause the SUBSYSMGMT command to be issued to Model 204, which would cause (probably) the SUBSYSMGMT subsystem to be run. SUBSYSMGMT is a standard 3270-based application, so when SUBSYSMGMT issued its first READ SCREEN statement, Janus Web Legacy Support would automatically be invoked, start a pseudo-3270 session, and convert any 3270 screens to HTML.

Note that this example will generally not work correctly, however, because SUBSYSMGMT is (hopefully) a private subsystem and should not be accessible by the default public web userid. A request for url "/subsysmgmt" might result in a page that simply says

SHR000 Access to SUBSYSMGMT facility is not authorized End of SUBSYSMGMT session

For subsystems like SUBSYSMGMT where security is a concern, a web rule that forces a login before invoking the subsystem must be in place. In the previous example, web rules like the following would force a login before issuing the SUBSYSMGMT command:

JANUS WEB portname DISALLOW /SUBSYSMGMT JANUS WEB portname ALLOW /SUBSYSMGMT USER * JANUS WEB portname ON /SUBSYSMGMT CMD SUBSYSMGMT

If the user logs in as a userid that is a SUBSYSMGMT user, SUBSYSMGMT enters its normal 3270 processing, with which the end-user can interact from the browser.

Thread utilization

When Janus Web Server receives a request from a browser, it assigns a connection block from the pool of unused connection blocks assigned to the web-server port. The number of connection blocks per port is limited to the maximum number of simultaneous connections allowed by a site's license, and it is set by the fourth parameter after the DEFINE in the JANUS DEFINE command for the port.

Once a connection block is assigned to a web request, the request is then associated with an Sdaemon thread. The number of sdaemon threads is limited only by Model 204's internal thread limit (32768) and by the practical limits of available virtual storage and server swapping bandwidth.

For a "normal" web request, Janus Web Server parses the request and returns an error page, static page, or a binary, or issues a Model 204 command that initiates a User Language web application. That application then returns a static page or binary to the browser. In any case, once the page is returned to the browser, both the sdaemon thread and the connection block are made available for other requests. The connection block is freed, because the TCP/IP connection with the browser is closed after the response is sent.

Janus Web Legacy requests work much the same way, except that when the HTML page that represents the 3270 screen is returned to the browser, only the connection block is made available for other requests. The sdaemon remains in-use, holding all the information associated with the 3270 application. When the browser submits the form associated with the 3270 screen, Janus Web Server associates a connection block and a different sdaemon thread with the request. Once it is determined that the request is actually associated with a Janus Web Legacy 3270 session that is associated with the original sdaemon, the request is passed to the original sdaemon, and the second sdaemon is made available for other requests. The connection block is freed when the next 3270 screen is returned (in HTML format). When the 3270 application is terminated, both the connection block and the sdaemon thread are freed.

An important conclusion from the preceding description is that a Janus Web Legacy 3270 session will tie up an sdaemon thread for a considerable length of time (exactly as other full screen threads might be tied up for long periods of time). Therefore, if a site expects to be using the Janus Web Legacy Support heavily, considerably more sdaemon threads should be allocated than the connection limit on the web server port.

Because of the ease with which Janus Web Legacy 3270 sessions could be created and forgotten, session timeouts are in important tool in preventing these sessions from proliferating in an Online. Session timeouts are controlled with the STIMEOUT parameter on both the JANUS DEFINE command. (also described in JANUS WEB SCREEN).

Navigation

While it is possible to move around a web application or application suite by manually typing URLs into a browser, this can be cumbersome and difficult to learn for most users. A more common way to navigate through applications is to follow hypertext links and submit forms where appropriate. A hypertext link makes it possible to move to a URL with a simple mouse click, even if that URL has dozens or even hundreds of characters in its name.

Providing end-user friendly navigation to a Janus Web Legacy application is not very difficult. Since these applications will ordinarily be accessed by a specific URL, it is easy to build a static or dynamic HTML page that contains a link to the 3270 application. For example, if the URL /legacy/shipping takes the end-user into a 3270 application subsystem called SHIPPING, an HTML statement like the following provides a hypertext link on an HTML page, so an end-user can enter the SHIPPING subsystem by simply clicking on the phrase Enter shipping application.

<a href="/legacy/shipping"> Enter shipping application</a>

Once inside a Janus Web Legacy 3270 application, navigation is essentially linear. That is, the 3270 screens are converted to forms with no hypertext links, and all submit buttons submit to the same URL. This is because of the essentially linear (or stateful) nature of 3270 applications: Whenever a 3270 screen is received by a browser, a single READ SCREEN statement is being executed by Model 204, and there is no way for a browser to arbitrarily force the User Language application to a different READ SCREEN statement.

If an end-user manually moves backwards in the browser cache and re-submits a now obsolete form, attempting to bypass the Janus Web Server controls that ensure linear processing of 3270 applications, Janus Web Server responds to such a request by re-sending the current screen. This ensures that no matter what an end-user does, he or she is brought back to the current 3270 screen for a session.

If an end-user leaves a 3270 application session by moving to a bookmark, moving back in the browser cache, manually typing in a URL, or simply exiting the browser, the Janus Web Legacy session is "orphaned." While this can happen quite easily and is difficult to prevent, the adverse impact of the orphaned sessions can be minimized with the use of session timeouts. Session timeouts are controlled with the STIMEOUT parameter on both the JANUS DEFINE command the JANUS WEB SCREEN command.

If, on the other hand, the 3270 application terminates and returns to Model 204 command mode, Janus Web Server sends an empty page to the end-user and terminates the Janus Web Legacy session. This leaves the end-user in the position of being forced to work back through the browser cache, switch to a bookmarked URL, or manually type a new URL. A far more user-friendly approach would be to have the browser go back to some standard "home" page when a 3270 application is terminated, so the user may then select a new application. The simplest way to accomplish this is with the EXITURL parameter on a JANUS WEB SCREEN rule.

The EXITURL parameter indicates the URL to which the browser is re-directed after a 3270 session associated with a URL is terminated by an application's return to command level. For example, a rule like the following causes all Janus Web Legacy clients to be returned to the site's home page if the 3270 applications terminate:

JANUS WEB portname SCREEN * EXITURL /

The STIMEOUTURL parameter provides a similar function for sessions that are terminated as a result of a timeout, BUMP, or cycling of an Online.

Hybrid applications

From an end-user perspective, the best application interface is provided by an application that is completely converted into a web application. From a programmer perspective, the simplest way to convert an existing 3270 application to a web application is to use Janus Web Legacy Support. The Sirius Software position is that the best approach is to convert all heavily used applications (or as many as possible) into true web applications and to use Janus Web Legacy Support for the "leftovers."

There is, however, a middle ground: Applications can be partially converted into true web applications and partially left as 3270 applications that are made web-accessible by Janus Web Legacy Support. This option, incidentally, is the great strength of Janus Web Legacy Support over external web-based 3270 emulator solutions.

The two basic ways you can "hybridize" an application are specified below and described in the subsections that follow:

• Use hypertext links to replace a front-end hierarchical menu structure by either static or dynamically generated HTML pages, and leave the complex back-end code as a 3270 application.
• Leave complex front-end data input screens as a 3270 application, and convert into a web page the back-end data display screens that have support for scrolling and searching, so the scrolling and searching can be performed locally on browsers.

Note: A caution about hybrid applications: It might be tempting to convert an application from a 3270 application to a web application piecemeal, running for a period of time as a hybrid application. While in certain cases this might work well, in other cases this could result in the ultimate web application inheriting characteristics from the 3270 application that don't make sense in a web context.

Before embarking on a piecemeal conversion, it is worth thinking through how the ultimate web application should work, so you can better evaluate the efficacy of a piecemeal approach.

HTML front end, 3270 back end

One way to convert a 3270 application to make use of the web is to replace its 3270-screen front end menu but leave its 3270 back end screens.

The design of the HTML pages that are to replace a 3270 menu structure is fairly straightforward and intuitive. Because the text in an HTML page can provide a direct link to another page, there is no need for function key or command processing code. So with little effort, thousands of lines of 3270 navigation code can become a handful of static HTML pages. In a hybrid application, however, the end-user ultimately receives a 3270 screen.

If the menus and back-end screens are all part of a single APSY subsystem, there may be no way to get to the back-end screens without going through the menus. In this situation, hybridizing an application requires going into the subsystem's User Language to provide a mechanism to bypass the menu structure. There are several ways this can be done, one of which is to use the web "isindex" structure.

Isindex data is data that appears in a URL after a question mark. For example, in the URL /apsy/accounts?balances, "balances" is isindex data. For JANUS WEB rules processing, isindex data is not considered part of the URL, and it can be retrieved via the $Web_Hdr_Parm function. To use this structure to produce a hybrid application, consider a subsystem called CLIENTS with eight different back end sub-applications that are reached via a menu structure:

1. You could create a JANUS WEB rule to present a static page with hypertext links to the eight sub-applications as follows:

   JANUS WEB portname ON /CLIENTMENU.HTML OPEN FILE CLIENTS SEND MENU.HTML

   The links on the page could have this form:

   <a href="/clients?1">Background</a> <a href="/clients?2">Balances</a> . . . . . . .

   Another rule could be specified to cause the CLIENTS subsystem to be invoked when an end-user clicks one of the above hypertext links:

   JANUS WEB portname ON /CLIENTS CMD CLIENTS

   Since the question mark and the data after the question mark are ignored in rules processing, the above rule would cause a request for URL /clients?1 to result in the invocation of the CLIENTS subsystem.

2. To complete the hybrid application, you add code to the subsystem to prevent the menu screens from coming up when the subsystem is invoked as a result of one of the above rules. This requires some User Language coding, but the coding is quite simple. At some appropriate place before the READ SCREEN for the first menu is issued (anywhere from the subsystem's start procedure to immediately before the READ SCREEN statement), insert a test to bypass the display of the menus and to transfer to the appropriate part of the code. This can be done inside a simple If clause:

   If $web_hdr_parm('ISINDEX') Ne '' Then . . . . . . End If

   The $Web_Hdr_Parm function in this example returns the isindex data, namely the number after the question mark in the URL. When the subsystem is run from a non-web port, the $Web_Hdr_Parm call always returns a null, so the code inside the If is bypassed.

   One thing to be aware of, however, is that after the first 3270 screen is displayed at the browser, the original URL as well as the isindex data is lost. This should not be an issue in this type of hybrid application, and it can easily be worked around by moving the isindex data to a global variable:

   %rc = $setg('ISINDEX', $web_hdr_parm('ISINDEX'))

3270 front end, HTML back end

Another way to convert a 3270 application to make use of the web is to leave the front-end 3270 screens in place, and to replace back-end scrolling and searching screens with an HTML page. To create this kind of application:

1. Define a web rule that causes the front-end 3270 application to be invoked.
2. At the point where the scrolling would ordinarily be performed, insert User Language code that downloads the scrolled data to the browser. Since it is bad form to send a page to a browser that is a dead-end (has no hypertext links, for example), it is advisable on this downloaded page to include at least a link to a home page:

   If $web_ipaddr Ne Then Print '<HTML>' Print '<head>' Print '<title>Search result</title>' Print '</head>' Print '<body>' Print '<center>' Print '<a href="/">Back to home page</a>' Print ''

     Print '<table>'
     For each Record
          .    .    .    .    .    .
     End for
   

   Print ''

     Print '</body></HTML>'
     %rc = $web_done
     %rc = $setg('NEXTPROC', 'EXIT')
     Stop
   

   End if

   In the above example, the $Web_Ipaddr function is used to determine if the application is being run on a web thread. Whether or not 3270 screens have been presented via Janus Web Legacy Support, $Web_Ipaddr returns a null if the code is not running on a Janus Web Server thread, and it returns the IP address of the browser, otherwise.

Customization

The defaults for Janus Web Legacy Support try to make a legacy page look as much like a 3270 screen as possible: a black background and no borders for input areas, the standard 3270 colors, plain browser submit buttons on the bottom of the screen for function keys, and so on. While this is probably sufficient for getting a basic idea of what Janus Web Legacy Support can do, it is likely to be deemed inadequate should the support be used in a real production application.

JANUS WEB SCREEN rules make it possible to customize many aspects of Janus Web Legacy's conversion of 3270 screens to HTML pages: color mappings, submit button placement, and so on. As flexible as these rules are, they are somewhat limited in what they allow to be configured, and heavy use of them can produce very large HTML pages associated with each screen. A more flexible approach, which also reduces the size of pages associated with 3270 screens, is to use an external style sheet.

To use an external style sheet, you specify the CSS parameter in either a JANUS WEB SCREEN rule or via $Web_Set. For example, the following command indicates that an external style sheet is to be used from URL /MYCSS/FANCY.CSS for any Janus Web Legacy screens presented for URLs that begin with /FANCY/:

JANUS WEB WEBPORT SCREEN /FANCY/* CSS /MYCSS/FANCY.CSS

To use an external style sheet with Janus Web Legacy support, you should understand Cascading Style Sheets in general, and you should be aware of what tags and classes are used by Janus Web Legacy support in particular. For the former, there are many good books about Cascading Style Sheets, or you can simply read the specifications for them at http://www.w3.org.

Janus Web Legacy Support mainly uses four HTML tags in its generated HTML:

<span>	For protected colored or hilighted text.
<div>	For the title line, if CSSTITLEDIV is set.
<input>	For input fields, that is, unprotected areas.
<a>	For hypertext links generated by AUTOPF LINK processing.

Submit buttons are always given class="key" to facilitate the specification of different formatting characteristics for submit buttons from other input areas.

Any input or text area that has a color attribute or is set to BRIGHT is also given a class:

B	BLUE
R	RED
P	PINK
G	GREEN
T	TURQUOISE
Y	YELLOW
W	WHITE
H	BRIGHT (H for "Hilighted")

DIM protected fields have no span tags associated with them, so no class. Similarly, DIM input fields are not given a class; they use the default input attributes.

The Janus Web Legacy classes can be combined with a B, U, or R if a field is set to BLINK, UNDERSCORE, or REVERSE, and if LEGBL, LEGUS, and/or LEGREV is set. That is, a field set to RED and BLINK would have class RB, and a BRIGHT UNDERSCORE field would have class BU.

While the class D would never be used alone for DIM fields, a DIM BLINK field would have class DB, and a DIM REVERSE field would have class DR. Unless BLINK, REVERSE, or UNDERSCORE fields are heavily used in applications and are necessary to understand the application, it is probably best to avoid the complexity of all the extra classes potentially created by such fields.

To set the attributes of DIM fields, the styles for a <body> or <pre> tag should be set — Janus Web Legacy screens are always inside a <pre> tag, which is inside a <body> tag. The main difference between setting the style for <pre> versus setting it for <body> is that the <pre> style will not affect text or other elements generated by a PREJS or POSTJS URL, so it is usually best to set styles via the <body> tag.

The TITLE line in a 3270 screen always gets mapped to a special class that defaults to title, but the mapping can be set to any class with the CSSTITLECLASS parameter in JANUS WEB SCREEN rules or with $Web_Screen. This allows the title line appearance to be changed inside an application without changing style sheets within the application.

The following is an example of a style sheet that sets some basic color mappings:

body {background: #FFDAB9; color: #404040;} a {background: #FFFF00; color: #0000FF; cursor: pointer;} span.H {color: #C000FF;} span.B {color: #0000FF;} span.R {color: #CD0000;} span.P {color: #FF1493;} span.Y {color: #EE7600;} span.T {color: #009ACD;} span.G {color: #228B22;} span.W {color: #000000;} input {color:#404040; background-color: transparent; font-family: courier, monospace; border-width: 0px; padding: 0px; margin: 0px; padding: 0px; vertical-align: text-bottom; line-height=120%; cursor: hand;} input:hover, input:focus {background: #FFEEEE;} input.key {color:#404040; background-color: #FFDAB9; font-family: helvetica, sans-serif border-width: 2px; padding: 0px; margin: 0px; padding: 0px; vertical-align: text-bottom; line-height=120%; cursor: hand;} input.key:hover, input.key:focus {background: #FFEEEE;} input.H {color: #000080;} input.B {color: #0000FF;} input.R {color: #CD0000;} input.P {color: #FF1493;} input.Y {color: #EE7600;} input.T {color: #009ACD;} input.G {color: #228B22;} input.W {color: #000000;} span.title {color: #FF00FF; text-align: center; font-family: helvetica, sans-serif; font-style: bold; font-size: 130%}

Of course, you can set styles for tags and classes generated by PREJS and POSTJS processing, and you can harmlessly define styles that never appear in Janus Web Legacy screens. This may make sense if a style sheet is shared among Janus Web Legacy applications and other applications that use different tags and classes.
Note: There is some empirical evidence that Microsoft's Internet Explorer™. does not cache style sheets whose names are in mixed case.

While Cascading Style Sheets is a standard, there are some browser specific differences in support, interpretation, and implementation of this standard. If a site wants to support multiple browsers with external style sheets, the style sheets may have to vary from browser to browser. One way of accomplishing this variation is by using the BROWSER parameter in JANUS WEB SCREEN rules to specify a different style sheet for each browser type:

JANUS WEB WEBPORT SCREEN * CSS /MYCSS/GENERIC.CSS JANUS WEB WEBPORT SCREEN * BROWSER IE CSS /MYCSS/IE.CSS JANUS WEB WEBPORT SCREEN * BROWSER NS CSS /MYCSS/NS.CSS JANUS WEB WEBPORT SCREEN * BROWSER NS POST 6 CSS /MYCSS/NSNEW.CSS JANUS WEB WEBPORT SCREEN * BROWSER OPERA CSS /MYCSS/OPERA.CSS

The reality is, though, that most style sheet settings will be the same for all browsers, so it may be easier to begin with a single generic style sheet rule like:

JANUS WEB WEBPORT SCREEN * CSS /MYCSS/GENERIC.CSS

Then have the ON rule for the above URL dynamically generate a CSS specific to the browser, as in the following:

JANUS WEB WEBPORT ON /MYCSS/GENERIC.CSS OPEN FILE CSSPROC CMD 'I GENERIC.CSS'

Though in "real life," the rule would probably invoke a subsystem. In any case, the procedure GENERIC.CSS should first set the mime type to text/css:

%rc = $web_type('text/css')

The mime type can also be set with a type rule, which would work even if the style sheet were static and were sent via a SEND rather than a CMD:

JANUS WEB WEBPORT TYPE *.CSS TEXT/CSS

With the mime type established, the procedure GENERIC.CSS can set some values based on the browser type:

%valign = 'text-bottom'; %pointer = 'pointer'; if $web_browser('NS') then %valign = 'top' end if if $web_browser('IE') then %pointer = 'hand' end if

In this example, the vertical alignment is set to top for Netscape Navigator™ input fields because, oddly, this is what is required to get them to align properly with protected text fields. The pointer type is set to hand rather than the CSS standard pointer for Internet Explorer, though pointer works also.

In the style sheet section of the procedure, the following would be within a User Language HTML statement block:

HTML EXPRS \ EXPRE \ ... input {color:#404040; background-color: transparent; font-family: courier, monospace; border-width: 0px; padding: 0px; margin: 0px; padding: 0px; line-height=120%; vertical-align: \%valign\; cursor: \%pointer\;} ... End Html

Note that the standard expression start and end brace character defaults ({}) in the HTML statement above are overridden because they have special meaning in the Cascading Style Sheet grammar.

Using Cascading Style Sheets one can control almost every aspect of formatting and display of a Janus Web Legacy screen. In fact, the level of control is so great that it is quite easy to destroy the alignment and general appearance of a Janus Web Legacy page. For example, one can easily set the font of text elements to a proportional font, which would almost certainly ruin the text alignment on a mapped 3270 screen. Still, within the constraints imposed by automatic mapping of 3270 screens, there is considerable flexibility in customizing page layout using JANUS WEB SCREEN rules and external styles sheets.

Cascading Style Sheets is not sufficient, however, if you want to add extra information to a page. To accomplish this, the PREJS and POSTJS parameters on JANUS WEB SCREEN rules are required. The URLs that these parameters specify are placed literally in <script src="..."> tags immediately preceding and following

the <pre> and tags in the generated HTML.

The URLs pointed to by the PREJS and POSTJS parameters can then contain any JavaScript that you might want placed in the HTML at that point.

More likely than not, rather than dynamic JavaScript, you are likely to want relatively static HTML placed in these positions. Fortunately, it is not difficult to produce HTML from JavaScript statements. For example, the following JavaScript sent from a URL specified after the POSTJS parameter displays some explanatory text on legacy pages at the bottom of the page:

document.write("<br><hr><br>") document.write("References to PF1-PF12 in help") document.write("refer to the buttons at the") document.write("bottom of the screen. These") document.write("can also be accessed by holding") document.write("the \"Alt\" key down and hitting") document.write("\"1\" for PF1, \"2\" for PF2 up") document.write(to "\"-\" for PF11 and") document.write(to "\"=\" for PF12.<br>")

Obviously, for large quantities of HTML, especially dynamically generated HTML, this can be quite tedious and difficult to produce and read.

Fortunately, in the JANUS WEB ON rule for the URL serving the JavaScript, you can specify the WRAPJS parameter, which tells Janus Web Server to convert HTML to JavaScript document.write methods, "escaping" double quotes in the HTML by preceding them with backslashes (\). The WRAPJS parameter can also be set with $Web_Set, as in the following:

%rc = %web_set(, 'WRAPJS') Html <br><hr><br> References to PF1-PF12 in help refer to the buttons at the bottom of the screen. These can also be accessed by holding the "Alt" key down and hitting "1" for PF1, "2" for PF2 up to ""-" for PF11 and to ""=" for PF12.<br> End Html

This WRAPJS technique can be useful outside of Janus Web Legacy Support for embedding large blocks of relatively static HTML that is shared among many pages. You only need to ensure that the pages embedding these large blocks contain <script src="..."> tags that specify the URL of the static HTML block, and that that URL sends its HTML with WRAPJS set.

In addition to sending explanatory text, PREJS and POSTJS URLs can be used for embedding graphics, such as a corporate logo, on a legacy page. For example, if referenced by a PREJS parameter and automatically converted to JavaScript, the following HTML places a logo on a legacy page:

<table> <tr> <td valign="top"> <img src="/images/logo.gif"> </td> <td valign="top">

The HTML above places the legacy data inside a table cell, causing the logo to appear to the left of the legacy page. To terminate the table cell, table row, and table, the following HTML must be pointed to by the POSTJS parameter for the same URLs:

</td> </tr> </table>

It is also possible to manipulate the HTML sent by Janus Web Legacy Support to the browser. Although specifying how this can be done is beyond the scope of this reference (a browser JavaScript reference would have the required information), it can be broadly outlined:

1. Such HTML page manipulation can usually only be done after the page has been received but before it is rendered by the browser. This is typically accomplished with the onload attribute in the <body> tag. The JavaScript statements to be executed after a page has been received from the network can be indicated with the ONLOAD parameter in a JANUS WEB SCREEN rule.
2. While any JavaScript statements can be specified in the ONLOAD parameter (multiple statements separated by semicolons), it is much simpler and more flexible to simply invoke a method defined elsewhere. The most convenient place to define a method invoked in an onload attribute is inside the <head> tag of an HTML document. Janus Web Legacy Support provides a HEADJS parameter for JANUS WEB SCREEN rules that indicates a URL that contains JavaScript that will be requested with a <script> tag in the Janus Web Legacy pages.

In addition to simple static HTML, it is possible to send images that map to the 3270 PF keys (or a single image with an image map). For this to work, the buttons or image map must somehow set a value for a form field called "KEYH" that is sent as a hidden form field. The KEYH values would be PF1 through PF24, as needed, or Enter, for the Enter key.

For browsers that fully support the standard <button> functionality, the following would suffice to provide a PF1-key image:

<button accesskey="1" name="KEYH" value="PF1" type="button"> <img height=45 width=85 border=0 src="/img/pf1.gif"> </button>

The accesskey attribute allows the PF1 key to be accessed by holding the "Alt" key down and pressing "1". For browsers that don't fully support the <button> functionality (Internet Explorer, for example), the <button> tags must be coded as follows:

<button accesskey="1" onclick="document.F.KEYH.value='PF1'; document.F.submit();" type="button"> <img height=45 width=85 border=0 src="/img/pf1.gif"> </button>

PREJS and POSTJS can even include active JavaScript code that performs a task like one of the following, for example:

• Puts up alerts such as: "Warning: entering 3270 legacy mode, your browser might not work exactly the way it does for most other things."
• Does field validation (though given Janus Web Legacy Support's meaningless field names, this could be extremely difficult to code).

Limitations

While most 3270 capabilities map fairly naturally to web browser capabilities, some things do not map well and can be potential impediments to using an existing 3270 application from a web browser via Janus Web Legacy Support. Following is a list of limitations of Janus Web Legacy Support:

• There is no general purpose cursor in browsers; that is, there is no cursor that can be positioned over non-input fields.

  This means that any application that depends on cursor-position sensing for non-input fields will not work with Janus Web Legacy Support.

• There is no application access to workstation function keys from most browsers.

  This means that function keys used by an application must be displayed as form buttons, which takes screen space and can be more awkward and inconvenient to use. With Sirius Mods version 6.2 and later, the key combinations Alt+1 through Alt+= are available as PF keys, as long as corresponding submit buttons appear on the page. This is helpful, though not as convenient as F1 through F12.

• Many browsers do not support blinking fields.

  Blinking fields are displayed as non-blinking text on most browsers, though with Sirius Mods version 6.2, blinking fields can be mapped to some other display effect using external style sheets.

• There is no support for inverse video fields in browsers.

  Inverse video fields are displayed as un-inverted text, though with Sirius Mods version 6.2, blinking fields can be mapped to some other display effect using external style sheets.

• Most browsers ignore font, color, and blinking attributes for input fields.

  This can affect the visual impact of screens where input field attributes are set. This is especially a problem in applications that highlight invalid input data.

  Furthermore, since input fields always use a proportional font, there is no way to force alignment of input field data. With Sirius Mods version 6.2, the use of Cascading Style Sheets means that the attributes of input fields are generally controlled

  as well as text fields, and alignment of input fields on a page is completely accurate.

• Input fields look very different from display-only data on browsers.

  While this might be a benefit for some applications, it does change the visual impact of the screen, and it slightly alters the alignment of the text. With Sirius Mods version 6.2, the use of Cascading Style Sheets makes input fields look exactly like text fields by default, improving alignment but making it more difficult for end users to determine where input fields are.

• The entire 3270 screen might not fit in the browser window, especially on low resolution monitors.

  While the whole screen is accessible with scrolling, this can be annoying and cumbersome to end users. With Sirius Mods version 6.2, the use of external style sheets makes it possible to control fonts more precisely, though it is not likely that even this level of control will ensure that all 3270 screens will fit in all browser windows, especially since browsers allow end users to override font settings or to size the display windows arbitrarily small.

• Janus Web Legacy Support does not currently support access to the Model 204 editor.