Mainframe web client

A method includes receiving a message in a JavaScript object notation (JSON) format from a first processor, converting the message from the JSON format into a hypertext markup language (HTML) format, and presenting the content of the message in the HTML format to a user on a display.

The present invention relates to mainframe computing, and more specifically, to mainframe computing with a webclient servlet.

Mainframe computers typically interact with terminals that are communicatively connected to the mainframe. The terminals are operative to send and receive messages and data using time sharing option (TSO) messages and interactive system productivity facility (ISPF) messages. TSO allows a user to, for example, create, maintain, and compile programs and interactively test batch and on-line programs. ISPF provides a terminal interface having a set of panels. The panels often include means to run tools on TSO. ISPF often includes an application programming interface (API).

BRIEF SUMMARY

According to one embodiment of the present invention, a method includes receiving a message in a JavaScript object notation (JSON) format from a first processor, converting the message from the JSON format into a hypertext markup language (HTML) format, and presenting the content of the message in the HTML format to a user on a display.

According to another embodiment of the present invention, a system includes a display, and a first processor communicatively connected to the display, the first processor operative to receive a message in a JavaScript object notation (JSON) format from a second processor, convert the message from the JSON format into a hypertext markup language (HTML) format, and present the content of the message in the HTML format to a user on the display.

According to another embodiment of the present invention, a method includes receiving an input from a user on a first processor, converting the input from a hypertext markup language (HTML) format to a JavaScript object notation (JSON) format message, and sending the JSON message to a second processor.

According to yet another embodiment of the present invention, a system includes a display, and a first processor communicatively connected to the display, the first processor operative to receive an input from a user on a first processor, convert the input from a hypertext markup language (HTML) format to a JavaScript object notation (JSON) format message, and send the JSON message to a second processor.

DETAILED DESCRIPTION

FIG. 1illustrates a block diagram of an exemplary embodiment of a system100. The system100includes a processor (mainframe)101that includes, for example a processor such as a mainframe and associated memory, input, and output devices that are operative to perform, for example, processing tasks and applications, and a user processor103that may include, for example a processing terminal or computer that includes a processor, memory, input, output, and display devices that are operative to perform processing tasks and applications and may receive and present data to a user via a graphical user interface (GUI). The user processor103includes a web browser and/or web client (client)102that operates on a computer and is communicatively connected to the processor101via a communicative link105that may include, for example, an Internet or other type of network communicative connection. The client102is operative to send and receive data to and from the processor101and present the data to a user. In the illustrated embodiment, the client102acts as a terminal user interface. The processor101includes a number of entities that may include for example, applications or services that may be processed and performed by the processor101. The processor101includes a servlet portion104that is communicatively connected to the client102. The servlet104is operative to send and receive data from a time sharing option (TSO) launcher portion106and message queues108. Each message queue108is associated with a time sharing option (TSO) address space and an interactive system productivity facility (ISPF) session. Though the illustrated embodiment includes a single client102, alternate embodiments may include any number of similar clients102that may be communicatively connected to the servlet104. The processor101may perform or reserve address spaces for any number of message queues108and associated TSO110and ISPF112.

In this regard, the servlet104provides interfaces for the client102to request a TSO110address space. Once the TSO address space110is reserved, the servlet104may send and receive both TSO and ISPF messages to and from the TSO110and ISPF112. The servlet104communicates with the client102using a JavaScript Object Notation (JSON) message format and converts messages received from the client102into a Unicode Transformation Format-8-bit (UTF-8) format readable by the TSO110address space such as, for example,

{“TSO RESPONSE”: {“VERSION”:“0100”,“DATA”:“TIME”}}. The client102is operative to receive JSON messages from the servlet104and convert the JSON messages into a format that may be displayed to a user in a web browser interface using a communications protocol such as, for example hypertext transfer markup language (HTML) or another type of communications protocol. The servlet104provides a service to the client102to, for example, terminate the address space and provides “housekeeping duties” to properly maintain the address spaces in the processor101. In the illustrated embodiments the interactions with the message queues108, TSO launcher106and TSO110address spaces may be performed using user credentials provided by the client102. The servlet104maintains a hash map that maps the client102or user to the proper message queue108and maintains other pertinent data. The servlet104maintains a hash map entry for all of the active TSO address spaces that it has started. The hash map includes relevant information about the TSO address space and the associated web browser session, including a unique servlet key, timestamp, state information, and data returned by the TSO launcher such as the message queue identifier.

FIGS. 2A-Billustrate a block diagram of an exemplary embodiment of a method for starting a session between the client102(ofFIG. 1) and the mainframe processor101. Referring toFIG. 2A, in block202logon parameters such as, for example, a user name and logon procedure are received by the client102. In block204, the client102sends a connect call message that includes the logon parameters to the servlet104. The servlet104processes the logon parameters and sends a request to the TSO launcher106to initialize a TSO address space. In block206, the client102determines whether a callback message has been received from the servlet104. If yes, the client102determines whether the received message is an error message in block208. If the message is an error message, the client102displays the error message to the user on a display in block210. In block212, if the message is not an error message, the client determines whether the message is a TSO message as indicated by the headers in the JSON data structure that includes labels indicative of error messages, TSO messages, and ISPF messages. If the message is not a TSO message, the client102processes the message and displays the message in an ISPF panel window to the user on the display in block214. If the message is a TSO message (in block212), the client102determines whether the message includes a ready prompt. If no, the client presents the content of the message to the user and requests user input in block218. If yes (in block216), the client104sends a request to the mainframe processor101to start an ISPF112session in block220.

FIGS. 3A-Billustrate a block diagram of an exemplary method for receiving and processing messages sent by the mainframe processor101(ofFIG. 1) to the client102. The descriptions below include the sending of messages between the client102and the mainframe processor101. In this regard, the messages are sent between the client102and TSO110address space of the processor101via the servlet104application. For illustrative purposes, it will be understood that when referring to a message sent between the client102and the mainframe processor101the messages will pass through the servlet104. Referring toFIG. 3A, in block302, a message is received by the client102. In block304, the client102determines whether the message is an ISPF message in a similar manner as described above. If the message is not an ISPF message, the client102converts the TSO message from a JSON format into a HTML format in block306. In block308, the client102displays the TSO message in a display window such as, for example a popup window or other similar graphical user interface (GUI) representation space and may block user ISPF interactions. The ISPF interactions are blocked by, for example, preventing the user from entering inputs into ISPF windows that may be displayed by the client102. In block310, the client102determines whether an input by the user is requested by the TSO message. If yes, in block316, the client102prompts the user for input, by for example, presenting an instruction to the user or providing an input means such as, for example, a user input field or button to the user. The client receives the input from the user, and sends the input that may include or imply a request for a processing step by the mainframe processor101to the mainframe processor101in block318. If no input is requested for a response to the received message (in block310), the client102may receive an input from the user such as, a key stroke, or selection of a button such as, for example, an “OK” button in block312. The client102receives the user input, and sends the input in a message to the mainframe processor101in block314. If the message is an ISPF message (in block304), the client102determines whether the message includes a screen ID that is associated with a window or tab that is being displayed (or is available for selection) by the user in block320(ofFIG. 3B). A screen ID includes a unique identifier of a window or tab and is used to direct received messages to be displayed on a proper window or tab to the user on the client102. If yes, in block322, the client converts the message from JSON format into HTML format. In block324, the content of the tab/window is replaced with the content of the received message in HTML format. If no (in block320), the client102generates a new tab/window and associates the new tab/window with the received screen ID in block326. In block328, the client102converts the JSON content of the message into HTML format. In block330, the client102presents the content of the message in HTML format to the user in the new tab/window.

FIG. 4illustrates a block diagram of an exemplary method for sending input from a user to the mainframe processor101(ofFIG. 1). In block402, the client102receives an input from a user in a tab/window or other input means presented to the user in an HTML interface. In block404, the client102converts the HTML content into a JSON message format that may include, for example, a unique key that identifies the TSO address space that will receive the message, and a screen ID that identifies the tab/window that is being used by the user to input the data or instruction. In block406, the client102sends the JSON formatted message to the TSO110address space or other entity on the mainframe processor101via the servlet104.

FIG. 5illustrates examples of JSON snippets502and corresponding graphical representations504of the corresponding HTML snippets. In this regard, the client102is operative to receive a JSON snippet502and convert the JSON snippet502into a HTML snippet that may be displayed to the user on the client102display. For example, the JSON snippet502for a menu includes “MNU”:[“PUL”:“Log/List”,“CHS”:[{“N”:“Log Data set defaults”,“I”:“I”}, and a corresponding HTML snippet includes <div dojoType=‘dijit.PopupMenuBarItem’ label=‘Log/List’ id=‘1’><div dojoType=‘dijit.PopupMenuItem’ label=‘Log Data set defaults’ id=‘1-1’ onclick=‘wi.MenuBarRenderer. fireClick(‘1-1’)></div></div>. The corresponding HTML snippet may be presented to the user on a display as shown inFIG. 5. Other conversions for JSON to HTML snippets may be performed in a similar manner.

The client102is also operative to receive data or other inputs input by the user in the HTML format and convert the inputs into a JSON message format that may be sent to the mainframe processor101via the servlet104. As discussed above, the servlet104is operative to receive JSON formatted messages and convert the messages, if desired, into a format that may be processed by the address space of the mainframe processor101.

FIGS. 6A-Billustrate a block diagram of an exemplary method for converting JSON snippets502(ofFIG. 5) to HTML snippets. In this regard, a JSON message may include any number of JSON snippets502that include key words and corresponding data for elements within the JSON snippets502. The client102may process the JSON snippets502in any appropriate order by, for example, scanning the JSON message to identify and process the key words and associated data, creating an HTML element that is associated with the key word, and filling the HTML element with corresponding data from the JSON format. Referring to block602, the JSON snippet502from a JSON message is processed by identifying key words in the JSON snippet502that indicate a corresponding HTML element. Examples of key words include field array key words (e.g., “output,” “checkbox,” and “input”); menu (e.g., “MNU”); cursor position (e.g., “cursor”); and key list (e.g., “key”). Alternate embodiments may include different or additional key words that may be used in a similar manner. For each key word in the JSON message, the client102(ofFIG. 1) determines whether the key word indicates a field array entry in block604. If yes, in block606, the type of field (e.g., “output,” “checkbox,” or “input”) is identified. An HTML element that corresponds to the type of identified field is created in block608. In block610, the HTML element is populated or filled with the corresponding field data from the JSON element in the JSON message. In no, (in block604), in block612, the client102determines whether the key word indicates cursor position. If yes, the client102determines whether the cursor position corresponds to an input field in block614. If no, in block618, an HTML element for cursor position is created and a default position is inserted into the HTML element. If yes (in block614), an HTML element for cursor position is created, and the cursor position data from the JSON element is inserted into the corresponding HTML element in block616. If no (in block612), the client102determines whether the key word indicates a menu bar in block620(ofFIG. 6B). If yes, an HTML element corresponding to a menu bar is created in block622. In block624, the HTML element is filled with corresponding data from the JSON element. In no (in block620), the client102determines whether the key word indicates a key list in block626. If no, the key word is ignored in block628. If yes, an HTML element corresponding to a key list is created in block630. In block632, the HTML element is filled with corresponding key list data from the JSON element.

FIGS. 7A-Billustrate a block diagram of an exemplary method for converting HTML snippets to JSON snippets. Referring to block702, a screen identifier (screen ID) and panel name are added to the JSON message that correspond to the screen ID and panel name that is, or was displayed on the client102(ofFIG. 1). In block704, the type of HTML response is identified. In block706, if the HTML snippet indicates a menu bar selection, a corresponding JSON element is created and populated with the corresponding associated HTML data in block708. If no (in block706, in block710, the client102determines whether the HTML snippet indicates a key or key link selection. If yes (in block710), a JSON element corresponding to the key is created and populated with the HTML key or key link data in block712. If no (in block710), a JSON input link element is created and populated with corresponding input link data in block714. In block716, a JSON element cursor position is added to the JSON message. In block718(ofFIG. 7B) the client102determines whether any field array input fields have changed by comparing the current values in the HTML elements to the original values passed in for display in the JSON field array. If yes, in block720field array elements for the changed fields are added. If no (in block718), an empty field array JSON element is added in block722. In block724, the JSON data structure is completed and the message is sent to the servlet104, which will send the JSON data to the message queue108for processing by the TSO110address space. For example, if the menu selection inFIG. 5was chosen, the following corresponding JSON snippet may be sent: {“PANEL”:{“SCREENID”:“1”,“NAME”:“SETTINGS”,“RESPONSE”:{“TYPE”:“CHOI CE”,“ID”:“1-1”},“CURSOR”: {“ROW”:24,“COLUMN”:14},“FIELDS”: [ ]}}.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon. Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.