The Immortal Mainframe in the Java World

1. The Immortal Mainframein the Java World JavaZone 2005 Tron Hvaring Software developer Gallagher & Robertson AS Oslo, Norway tron@gar.no

2. Agenda • Gallagher & Robertson AS • The J2EE Connector Architecture • The Glink for Java terminal emulator • Creating a J2EE Connector from Glink for Java • Mainframe comms: principles, caveats and challenges • Using the Connector: screen mode, line mode • Demo • Q&A

3. Gallagher & Robertson AS • Norwegian software house, est. 1982 • Specializing in mainframe communications products: • Terminal emulators • Mainframe access gateways • Mainframe web-enabling solutions • Java and J2EE mainframe access solutions • Expertise in • IBM, Bull, Unix and other mainframe protocols • Multi-platform products, most products run on • Windows • Linux • UNIX (Solaris, HP-UX, AIX …) • Java (all 1.4+ enabled platforms)

4. The J2EE Connector Architecture JSR016: J2EE Connector Architecture Specification 1.0 - connection management - security contract - transaction management - common client interface- outbound connections only - no lifecycle management JSR112: J2EE Connector Architecture Specification 1.5- EIS-initiated communications activating message-driven beans - transactional inflow from EIS systems - improved thread management- lifecycle management - multiple connection factories in a single deployment

5. System Contracts • Connection Management and pooling • Container manages pool of reusable connections on behalf of Connector • Most containers allow precise control of pool dimensioning, idle time management and automatic growing/shrinking of pools • Security contract • Credentials and logon management • Transaction contract • None, local or XA transaction management depending on the capabilities of the underlying EIS

6. Container-Component Contract • Component (typically an EJB, can also be a Servlet/JSP) uses JNDI lookup to acquire a ConnectionFactory handle • The ConnectionFactory handle is used by the component to request a Connection handle • The Connectionobject exposes its (proprietary) client API to the component • In addition, the Architecture specifies an optional Common Client Interface (CCI) that can be implemented by Connectors for uniform access independently of the underlying EIS

7. Connector-EIS interface • Not specified by the Arhitecture • Proprietary interface between resource adapter and EIS, different for each EIS type • Will typically include logic for establishing physical connections, and protocol drivers to transport data on these connections in an EIS-specific way

8. The Glink for Java terminal emulator - DOS version early 80’s- Windows version 1992- 600 000+ users world wide- First Java port in 1998- Client API added in 2001- First Connector version in 2001- J2CA 1.5 version ready in 4Q05

9. Glink for Java features • Emulations: • Bull VIP, Bull DKU • IBM 3270, IBM 5250 • ANSI/VT100/200/300 • Minitel/Prestel • Communications: • Telnet • TN3270(E), TN5250(E) • TNVIP • G&R Ggate (DSA mainframe access gateway) • DSA native to Bull mainframes • Minitel/Prestel • Editions: • Standard, desktop emulator and Web applet/Webstart app • Professional, adding Java API • Enterprise, with API and without GUI, optimized for server operation

10. Creating a J2EE Connector • Basic requirements: • Get rid of the GUI, no AWT thread allowed in Connector • Add an API that allows a client component to perform all operations that a human operator can perform (within reason!) • For responsive and multi-client operation, API should post asynchronous events to clients • Challenge: handle the case of blocking event handlers • Connector requirements: • Provide implementation classes for all J2CA required interfaces • Decide which parameters go into the deployment descriptor, figure out how to handle configuration settings • Provide classes that allow unmanaged operation • Additional requirements • Provide a Line mode of operation, i.e. bypassing the emulation. Some (newer) mainframe applications are written to communicate with other programs, so there’s no need for a terminal/emulation layer. Basically this means exchange of binary buffers (e.g. binary COBOL records).

11. Screen mode & line mode • Screen mode: • mainframe and user application exchange formatted screens with embedded control information defining fixed and variable fields, attributes, fixed texts and variable field values • syntax of control data defined by the terminal type • API allows access to form fields, values and attributes • API allows emulation of keystrokes from a human user • Line mode: • emulation layer is bypassed • only application data is transported, without terminal specific control information • syntax of data stream is defined by mainframe application • user application must be able to encode and decode the data stream, there’s no emulation layer that helps to extract/encode fields and attributes

12. Config & deployment 1 • Because of the range of different emulations and mainframe applications supported, Glink for Java has more than 100 parameters that can be used to define a complete session profile • Glink for Java reads the profile from a configuration database, either via a Glink for Java server or from the file system • A Java GUI application is used to maintain the database • It’s not practical to keep all these parameters in the deployment descriptor! • Besides, the configuration code would have to be completely re-written. • Solution: point to the configuration database from the deployment descriptor.

13. Config & deployment 2 <config-property-name>GlinkDirectory</config-property-name> <config-property-value> </config-property-value> <config-property-name> ConfigName </config-property-name> <config-property-value> </config-property-value> Configuration profile Host profile Emulation profile Printer profile Screen profile not used byconnector Keyboard profile Toolbar profile Config database

14. Glink for Java thread model GUI (Swing) thread data flow sync flow Emulation layer The Comms thread loops on the socket, continuously reading input and pumping the data into the emulator. The emulator receives data both from the comms thread and the main (Swing) thread where the user lives. Synchronization is required at several levels in order to avoid sync problems between Glink’s view of the virtual screen, the user and the mainframe application. Obviously the comms thread can’t be allowed to block except very briefly during synchronization. Semaphores Comms output Comms inputthread Socket layer

15. Connector threads – naive solution Client thread(EJB, Servlet) Eventlistener API calls running in client thread Data flow Asynchronous events,running in comms thread API Problem: what happens if the client event handler blocks?Clearly this can’t be allowed as it will freeze the comms thread, i.e. no more host data can be received until the event handlerunblocks the thread.Solution: de-couple the comms thread from the event handling. Emulation layer Comms inputthread Comms output Socket layer

16. Connector threads – real solution Client thread(EJB, Servlet) Eventlistener When the API needs to post an event back to the client event handler it will start a separate one-shot thread for the event. This thread will call the client’s event handler. Thus the comms thread will never be blocked by client code. This relaxes the requirement for non-blocking event handlers. However, event handlers now need to be either synchronized or re-entrant since events could occur at any time and in any order, as the JVM decides when the event threads will run. Eventthread 1 Eventthread 2 . . . Eventthread N API Emulation layer Comms inputthread Comms output Socket layer

17. Emulator TCP/IP TCP/IP Mainframe comms: basic principles User Mainframe Application protocol (data) Glink Host application CICS Presentation protocol (screen headers) Presentation Presentation 3270 Session protocol (session ID, tokens) Session Session Telnet 3270 Transport protocol (TCP headers) Transport Transport Network protocol (IP headers) Network Network Link protocol (link headers) Link Link Physical protocol (modem, frame headers) Physical Physical

18. Whose turn is it? • Transport connection is full-duplex (two-way simultaneous) • Session connection is normally half-duplex (two-way alternate) • At any point in time, one or the other side has the “turn”, i.e. the right to send • On a real terminal, Busy or Keyboard Locked would appear on the status line when it’s not your turn • Both sides maintain the state of a “turn token” which is passed along with data to indicate a change of direction • Sending against the turn is considered a protocol error • Some mainframes sometimes don’t care (e.g. IBM) and send against the turn anyway • So, an emulator must be prepared to handle nonsense in an intelligent way! • In an API scenario, the turn token is the main synchronization tool between a client API application component and the mainframe application • A “smart” emulator will delay turn signalling to the API client component until the entire form has been processed, regardless of the position of the turn token in the data stream

19. Form synchronization – listener static private final int NUM_RETRIES = 3; static private final int DELAY_TIME = 200; // milliseconds public void onGlinkEvent(GlinkEvent e) { switch (e.getEventCode()) { case GlinkEvent.TURN_RECEIVED: screenID = identifyScreen(e.getSource()); synchronized(formSemaphore) { formSemaphore.notify(); } break; . . . } } private int identifyScreen(GlinkApi api) { for (int i = 0; i < NUM_RETRIES; i++) { for (int j = 0; j < NUM_AREAS; j++) if (api.isScreenAreaMatch(area[j])) return j; try { Thread.sleep(DELAY_TIME); } catch (InterruptedException ex) { } } return –1; }

20. Form synchronization – client // Acquire a Connection handle and add listener Connection cnx = connectionFactory.getConnection(); Object formSemaphore = new Object(); Listener myLsn = new Listener(formSemaphore); cnx.addGlinkEventListener(myLsn); cnx.sendKeys(”Donald Duck”); // Set contents of current field cnx.sendCommandKey(GlinkKey.TRANSMIT); // Send form with Turn to mainframe // Wait for result, i.e. for Turn to come back try { synchronized(formSemaphore) { formSemaphore.wait(20000); } } catch (InterruptedException ex) {} // Handle result depending on what form we received switch (myLsn.getScreenID()) { case –1: oops(); break; case FORM_1: handleForm1(); break; . . . }

21. Programming in screen mode • Tedious and repetitive if the number of forms is large: • Write code to identify each single screen • Write listeners and handle the same events all the time • EJB framework pretty much the same from app to app • Thus, screen mode programming lends itself to automation! • The Connector is accompanied by Gargen, a Javabean/EJB generator tool • Gargen is visual and template-based, thus can be adapted to a wide variety of applications.

22. Gargen, the component generator User Mainframe Sequence File Javabean component EJB component Templates

23. Line mode Mainframe application encodes and sends a record as a binary buffer. The contents is usually defined by a COBOL record declaration .The Connector receives the buffer as a byte[].It is very tedious indeed to decode such buffers ”by hand” in Java. And to encode buffers to be sent to mainframe! 01 S000-CSS307R. 02 S000-CSS307. 05 S000-C1ENTSRV. 07 S000-SRV1-LGSERV PIC X(5). 07 S000-SRV1-PISRVC PIC X(12). 07 S000-SRV1-CRTSRV PIC X(2). 07 S000-SRV1-PINTRV PIC X(1). 07 S000-SRV1-LGPFIX PIC S9(9) COMP-3. 07 S000-SRV1-LOCCUR PIC X(4). 07 S000-SRV1-NOCUTI PIC X(3). 07 S000-SRV1-NTTOCU PIC X(3). 07 S000-SRV1-IDORGA PIC X(5). 07 S000-SRV1-APPLEXT PIC X(1). 07 S000-SRV1-PVRSER PIC X(3). . . . . . . 5 12 2 1 . . . 3 To Java client – now what??

24. Data conversion challenges • Character sets • Pre-historic (7-bits) encoding of national-language characters • Historic (8-bits) encoding of national-language characters • EBCDIC vs. ASCII encodings • EBCDIC has always used 8-bits characters, but that didn’t stop IBM from defining a couple of hundred different 8-bit code pages to confuse the enemy … • … the enemy being the end user  • Challenge: offering transparent bidirectional conversion between the Java Unicode world and the old mainframe 7/8 bits world • Line mode challenges • In screen mode all fields are human readable, i.e. represented as String objects • In line mode the binary contents of actual COBOL records may flow on the connection, i.e. alpha, alphanumeric, decimal, packed decimal and COMP-X computational fields • In addition there’s the same character set and character conversion issues as with screen mode • Challenge: offering transparent and bidirectional conversion between COBOL binary fields and suitable Java types (e.g. String, BigDecimal)

25. Greg to the rescue! Java record EJB(optional) Template files COBOL input record COBOL output record

26. Greg details • UNICODE/EBCDIC conversion is automatic and transparent when the EBCDIC host option is selected • Greg records expose execute() methods that use the Connector to carry out the transaction with the mainframe • Optionally, Greg can generate an EJB that uses the record to carry out the transaction • Wrapping the record and EJB together in a deployable EJB-JAR file allows remote access • Typically one uses Greg once per input/output record pair, thus building a library of “black box” components, each carrying out one specific mainframe transaction • Greg is template based. Templates are tagged text files and can be modified at will and adapted for special needs.

27. Demo • Using Gargen to create a simple application towards a real TP8 application running under GCOS8 in Phoenix, AZ • Deploying the application on an application server • Running the application’s Servlet from a browser

28. G&R and Java – other products • GlinkWeb: exposing and facelifting mainframe applications to Java outside J2EE environments (e.g. Tomcat) • Glu62: IBM LU 6.2 J2EE Connector for peer-to-peer processing with IBM CICS and other LU 6.2 mainframe applications • GCPM: connection pool management for Glink for Java in non-J2EE servers (e.g. Tomcat)

29. Thank you for your attention! Q&A Contacting G&R: gar@gar.no http://www.gar.no