HostBridge Technology

A HostBridge White Paper


Content > White Papers

Blast from the Past

A FEPI Retrospective with IBM Developer Robert Harris


Recently, while working out a FEPI requirement with a customer, I had the very good fortune of reconnecting with Robert Harris, one of the IBMers responsible for the design and development of FEPI. I talked with Robert hoping to fill in gaps about FEPI’s roots. The interview follows – after a brief note.

The company, in business for more than a century, implemented its first CICS®-based account management application in the late 1970s; it continues to perform and provide critical functionality. As years passed, the company also implemented mainframe databases, more CICS applications, other enterprise applications on distributed platforms, productivity suites, office programs, and so on.

I’m not trying to spark a FEPI revival (my company supports FEPI, but the CICS 3270 Bridge interface will always be our interface of choice). But if you need to integrate one of the following categories of applications, then FEPI is “good as gold”:

The Interview

Russ Teubner: What was the first version of CICS that included FEPI?

Robert Harris: FEPI first came out in CICS/ESA 3.3. This was the first thing that used the newly restructured CICS kernel with the ability to use non-QR TCBs. So the SZ TCB was the first one that was introduced for “foreign” usage within CICS. I called it the SZ TCB (although I wanted to call it the Remote Handler TCB!) because it was simulating VTAM. Since CICS’s terminal control modules used TC for BTAM and ZC for VTAM, SZ made sense.

FEPI was originally going to be called Terminal Simulation Facility – but that failed due to some naming issues. Hence, Front-End Programming Interface. (I still remember spending a very tedious two weeks renaming all the FEPI modules to SZ and correcting the comments.)

Russ: Sounds like you guys were the pioneers of the whole “open TCB” concept. What drove the development of the FEPI API (clearly, it’s a bit unique)?

Robert: Because the restructured kernel was so new, and we wanted FEPI to service many more things than the CICS Dispatcher could cope with, we decided upon an architecture that isolated QR from SZ activity as much as possible. So we evolved into a request/scheduling mechanism with XCF (EXEC CICS FEPI) activity turning into a request block, which then got queued to the SZ TCB for processing. This had an implication on the FEPI application coding style which I think was beneficial.

The SZ TCB was needed anyway because all the VTAM inbound activity on the SLU ACB/RPLs was asynchronous driven by VTAM exits. You can see in the SZ trace this effect – lots of requests suddenly appearing due to VTAM exits pinging away for RECEIVE(ANY) function. The QR (or CO) TCB would not have been able to cope with all that interference whilst doing useful work.

Russ: So that explains all the events that are generated when tracing is active for the SZ domain. Why are FEPI resources defined differently from other “normal” CICS resources?

Robert: Because FEPI was seen as “alien” to CICS (after all, it had its own TCB), I was not able to persuade anyone that FEPI resources should be RDOed. This is what gave rise to the dynamic resource management scheme. In the long run, this was a good thing because support the CLSDST(PASS) operation required some sort of dynamic action/response. It was also good because the ordering of TARGETs/NODEs into a pool gave different (and needed) operational properties which at that time would have been difficult to get into SZ domain initialization (this would be easier now as the Java domains required some of this function).

We decided on TDQs for things because that removed the need for the SZ TCB to schedule operations on the QR TCB which would affect existing operation. Still, usage of the TDQs required QR – but that was a quicker and more isolated operation that doing transaction starts. Tracing for the SZ TCB required all the usual region-wide locks. But that was business as usual, so no problem.

Russ: Over what CICS versions (or time) did FEPI primarily evolve?

Robert: Nothing really evolved with FEPI. Its LU2 and SLUP support was all there from the start. The only thing that was added was the ability to generate a PASSTICKET for a Connection so that automatic password signon could be accomplished. What we wrote for CICS/ESA 3.3 is still pretty much in place.

Because FEPI was not really a part of CICS, the doc was never up to the standard I wanted. So I wrote my book The CICS Programmer's Guide to FEPI which was published in 1994. It was my attempt at rectifying things. It was a bit of a struggle within Hursley to get it approved – but eventually it contained all the usability and hints/tips that I wanted, but failed, to put in the official pubs.

Russ: What was the original vision or need that FEPI was meant to meet?

Robert: I’ve described how FEPI was seen as an intruder into the CICS nucleus. That implied that FEPI was not really developed as part of the CICS organization. Well, ’tis true. FEPI was funded by MQ, and was actually developed alongside the first release of MQ (our offices were in an un-waterproofed temporary building in a parking lot at Hursley).

The idea was that MQ would provide asynchronous messaging (with that famously small API) – but that would not be interesting unless the messages actually got somewhere useful. That meant reusing existing applications – which in the 1990s meant mainly CICS (and a bit of IMS). It's taken from then to now for CICS Development to take over the CICS/MQ Adapter and put MQCONN definitions into RDO!

Russ: So MQ was the driving force behind FEPI. And it was all about integration.

Robert: Yes, some way of getting into CICS applications, via MQ, was needed – and those applications were 3270-based. Thus, the need for a 3270 terminal emulator within CICS.

The idea was this: MQ would send a request into CICS (one of the reasons that TRUEs were developed); this would start a transaction which would screen-scrape an existing application; the results would be sent back via an MQ Response message. Thus the need for XCF FREE HOLDS (to keep the virtual terminal needed for the screen scraping) and the XCF FREE PASS (to transfer the virtual terminal to another part of the MQ interaction).

Russ: OK… it’s all starting to make sense. Anything else?

Robert: There was also another sneaky use of FEPI. Under MRO you could not route anything back into a CICS region that was involved with the routing. So one cannot use DPL to go in a long loop and end up back in the region you actually issued the XC LINK PROGRAM() SYSID() command. FEPI did not have that restriction, and so some clever sysprogs used FEPI to remove this restriction (which is still around).

The SLUP emulation (a particular subset of LU0) was the one that IMS/DC used – and so that gave MQ the ability to get into IMS applications as well. LU0, being very basic, exposed all those cunning VTAM flags and protocol interactions.

The MQ requirement was only for XCF FORMATTed operation – but the SLUP operation required XCF DATASTREAM. Thus, we coded up the datastream layer first, and put the formatted presentation layer on top. All those VTAM indicators naturally arose from the datastream operation.

Russ: How big was the original team, and who was on it?

From CICS application to new front end, the levels are as follows:

Figure 1

Robert: There were only four people who did the development work (plus a few contractors to do the testing). I mainly looked after the CICS side and stayed with CICS development for another 15 years or so until I left due to “early retirement” (since then, I have transformed myself into “dfhexpert”). I had the VTAM and CICS experience after doing a lot of work on terminal control and LU6.2 in CICS/XA 2.1 (added the STATE parameter on the Distributed Transaction Programming APIs, rewrote most of the then Intercommunications documentation, and caused the split into the Reference and Guide books).

Alan Webb majored on the VTAM side after joining IBM as an operator, turning into a CICS developer via SNA development, and afterwards doing a lot of the early Java work at Hurlsey (Alan then went to the USA as part of IBM Research and is now involved in grid computation).

Keith Andrews drew up the internal request protocol between an XCF command and the SZ TCB (Keith then went to MQ Development). There was another person who was lent from IMS who gave us input on LU0 programming.

Russ: During your tenure on the CICS team, what other roles did you play?

Robert: Well, first and foremost, I usually looked after FEPI even though I had moved on to other areas. Whilst I was in the CICS strategy and marketing team, I occasionally looked at the code while helping customers out with FEPI design and coding issues. Then I had a bit of a stay in CICS test and had fun coding up some regression tests for FEPI in PL/I. After that, I got involved with IBM Beijing Labs and mentored a load of bright Chinese doing CICS testing on what turned out to be the CPIC (I still persist in calling this MRO/IP) extensions for function shipping in all its variants. I also started learning Mandarin as a result. The very last thing I did at Hursley before my early retirement was to do a bit of design work on a project involving FEPI and CTG for a European customer. So I guess you can say that FEPI is alive and well, and still being used for new applications.

Russ: Given all the new communication components that have been added to CICS TS over the last decade, what do you think the role of FEPI is now?

Robert: Notwithstanding the fact that CICS has a full Web services/XML stack, FEPI is still very unique. It’s a full-function 3270 terminal emulator running inside of CICS. That’s what differentiates FEPI from the 3270 Bridge interface. Sometimes the 3270 Bridge interface is the best approach. But sometimes FEPI is the only approach. The thing I like about your product, HostBridge, is that it normalizes the underlying technical differences between FEPI and the Bridge interface and allows customers to focus on what they really care about: transforming existing 3270 applications into business services that create new business value today.

Copyright Notice

Copyright © 2011-2015 by HostBridge Technology. All rights reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, optical, chemical, manual, or otherwise, without prior written permission. You have limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry this copyright notice. No other rights under copyright are granted without prior written permission. The document is not intended for production and is furnished “as is” without warranty of any kind. All warranties on this document are hereby disclaimed including the warranties of merchantability and fitness for a particular purpose.

Revision date: 1/10/2011

Trademarks

HostBridge and the HostBridge logo are trademarked by HostBridge Technology. All other trademarks mentioned are property of their respective owners.