FEPI: My Favorite Four-Letter CICS Word
NOTE: This Letter from the Trenches (LFT) is a short version of a technical white paper by the same name. For the story in all its technical detail, plus an interview with Robert Harris, one of the original designers of FEPI, get the white paper PDF here .
January 6, 2011
Every now and then a customer has a “special” requirement. At HostBridge we love these situations: they’re usually time-critical and have clear business value. Such was the case when a customer recently asked us if they could use HostBridge to integrate with a non-CICS application. The request went like this: “We have applications that run under Model 204. Can we use HostBridge to XML-enable them?”
Wow! Model 204! What a blast from the past. Most Model 204 apps were written in their own proprietary language, styled as a terminal-oriented (end-user) apps, and accessed via their own communications monitor (not CICS, etc.). So for us, the key questions were: what are the operational characteristics of the Model 204 apps, and what are their specific integration requirements? Conference calls ensued.
We learned that, true to form, the customer’s apps were written in the Model 204 language, styled as terminal-oriented apps, and accessed via the Model 204 communications monitor. The customer’s requirement was to interact with these apps from a .NET application via HostBridge in order to optimize a business process.
Our answer was, “Yes, HostBridge could support access to these apps, but we’d need to use our ‘generic interface’ to non-CICS terminal-oriented transactions.” But what did that mean? It meant I got to throw around my favorite four-letter word in the CICS lexicon – FEPI, or Front-End Programming Interface.
Or as I’ve been heard to say – F#*%!
FEPI: A Four-Letter Word?
I’ll admit right off the bat that I’ve had a love/hate relationship with FEPI over the years. I love it because it’s inside CICS, and when used appropriately, it can help meet some targeted CICS integration requirements. On the other hand, I’ve hated it at times because FEPI has been used to create some rather “brittle” CICS integration solutions.
Over the last decade, HostBridge has replaced more than a few customer-written FEPI apps and vendor-created FEPI-based solutions that were inflexible or performed poorly. But I must give a nod to those customers who exploited FEPI. Why? Because they didn’t really have many alternatives! At least not until CICS TS 1.3, when the 3270 Bridge interface became formalized and available. But to this day, the Bridge interface doesn’t do what FEPI does.
FEPI is a full-fledged 3270 terminal emulator running under the covers of CICS; it creates the appearance of a SNA Type 2 Logical Unit (LU2) to VTAM. The 3270 Bridge interface, as the name says, is an interface to run 3270-based CICS transactions without a real 3270 terminal. The Bridge interface was game-changing because it was the first time that CICS included a supported interface that allowed a program (like HostBridge) to interact with a CICS terminal-oriented application DIRECTLY – that is, NOT via FEPI. And if the target CICS app uses BMS, the 3270 Bridge allows you to circumvent the entire process of 3270 data stream generation and interpretation. Indeed, FEPI and the 3270 Bridge are very different.
Bottom Line: FEPI was revolutionary for its time. However, with the advent of CICS TS 1.3, FEPI’s optimum role became more targeted. Using FEPI for programmatic access to CICS terminal-oriented apps became at best passé, and at worst a bad idea. However, for programmatic access to non-CICS terminal-oriented apps, FEPI was still the only game in town.
HostBridge and FEPI
HostBridge began life as a product whose sole means of interacting with CICS apps was the 3270 Bridge interface. We were undisputed early-adopters and advocates of this technology – still are. These are our roots and it’s why our customers probably represent the largest users of the 3270 Bridge interface. But it’s funny how the changes keep coming. As HostBridge was adopted more widely, customers wanted to use it to integrate with non-CICS apps! And what did this imply? FEPI! We describe HostBridge support for FEPI as providing access to “special” types of applications:
- CICS applications that cannot be executed under a bridge facility, usually because they circumvent the CICS terminal control interface
- Non-CICS applications, such as those that run under IMS or other subsystems
- Applications provided by an external service provider, and that can be accessed as a VTAM application from within the customers SNA network.
Well Behaved – or Not
When you use FEPI to interact with a terminal-oriented VTAM application, it’s important that you understand how the app interacts with the terminal. Inevitably, this draws you back into the cruel reality that all VTAM apps communicate with terminals according to SNA LU2 protocols. The LU2 protocols allow for significant freedom in how an application chooses to interact with a terminal. Depending on the choices, the application may be “well behaved” (i.e., easy to use with FEPI) or not! here are two aspects of being “well behaved” that are relevant vis-a-vis FEPI. Posed as questions, they are:
- Does the VTAM app send any “asynchronous” messages, i.e., does the app violate a mannerly “your-turn-my-turn” view of the world and send messages out of turn?
- Is the VTAM application id (applid) to which you initially connect different from the VTAM applid that you ultimately end up connected to and communicate with? Stated differently, does the VTAM app “pass” your terminal LU to a “secondary” or “third party” application LU?
By the above standard, CICS apps are well behaved because (1) asynchronous messages are rare and usually limited to applications that exploit ATI (Automatic Transaction Initiation), and (2) CICS does not pass the terminal from a primary applid to a secondary applid. IMS apps are a mixed bag because (1) they have a penchant for sending asynchronous messages, but (2) they don’t use secondary applids. The poster child for a VTAM app that is NOT well-behaved is TSO because the answer to both questions is “yes.” (To be fair, TSO exploits the SNA LU2 protocols as designed, and squeezes every ounce of functionality out of them.) Model 204 behaves mostly like TSO because it DOES pass control of the terminal session to a third-party VTAM applid (e.g., from “M204” to “M204xxxx”). Thankfully, it doesn’t send too many asynchronous messages past the initial logon process. But for our purposes, Model 204 had to be deemed NOT “well behaved.”
PASSing LU-LU Sessions
The most challenging aspect of achieving access to VTAM apps like TSO or Model 204 via FEPI is this: the VTAM applid that you initially connect to is different from the ultimate applid that you end up communicating with. For example, when you logon to TSO, it accepts the session but immediately passes it to a secondary applid: “TSOnnnn.” The programming macro that VTAM applications use to achieve this transfer of control is CLSDST, with the PASS option. Thus, the most important two pages of the FEPI doc are appropriately labeled “Handling CLSDST(PASS).” Read this information carefully; commit it to memory; every word has meaning.
PASSing Etiquette: How
The first commercial software product I wrote was called A-NET (great code; strange name). It was my opus magnum as far as VTAM applications were concerned. Under the covers it did many of the things FEPI does, but for a different reason. I certainly knew that a CLSDST(PASS) macro caused an SNA “Unbind, Bind forthcoming” Request Unit (RU) to flow. Wait.... That was 25 years ago!
Somewhere during the past decade (while I had my head buried inside of CICS), IBM decided that the traditional mechanism used by VTAM to implement CLSDST(PASS) was inefficient. True enough. In order to improve this process IBM implemented a mechanism called “FASTPASS.” FASTPASS is clearly more efficient, but it is completely different from the traditional Bind-Unbind-Bind mechanism (the RU flow is much different). However, not all VTAM applications are compatible with FASTPASS. The use of the FASTPASS mechanism is controlled by a parameter on a VTAM application program major node definition. Here’s the bottom line: FASTPASS=YES is the default on a VTAM APPL definition, and FEPI doesn’t support FASTPASS. Thus, the application major nodes used by FEPI to connect to an application that uses CLSDST(PASS) had better specify FASTPASS=NO or you will not get to square one. Period.
PASSing Etiquette: When
TSO does its CLSDST(PASS) immediately; that is, before TSO ever interacts with the terminal. Model 204, however, prompts for the userid/password using the session established under the primary VTAM applid. Once the credentials are validated, it then passes the session to the secondary applid. This may seem like a small matter, but it all plays out very differently under the covers of FEPI. Furthermore, the FEPI application (i.e., HostBridge) must also be aware of what’s going on. This brings us back to the two most important pages in the FEPI doc: “Handling CLSDST(PASS).”
Under the heading “Third-party PLU name not known and unsolicited bind expected,” you will see two minor sections: “Conversation in progress” and “Conversation not in progress.” In this context, “conversation” needs to be understood in the FEPI sense. Model 204 is an example of a VTAM app that performs a CLSDST(PASS) while a conversation is in progress. That is, FEPI has already returned a conversation id (convid) in response to a FEPI ALLOCATE request. To FEPI, TSO performs CLSDST(PASS) at a point when the conversation is not in progress because it perceives it as happening during the FEPI ALLOCATE process (not after it).
Confusing? Perhaps. Just know this: FEPI works very hard to maintain the conversation id over a CLSDST(PASS) operation when it happens inside a conversation. However, your unexpected event handler, and the FEPI app, must work hand-in-glove with FEPI (and it needs to fit nice and tight). If you get it right, it’s a thing of beauty.
If not, it’s an F#*%! moment for sure.
PASSing Etiquette: Where
When you login to TSO, your terminal enters into an LU-LU session with a primary VTAM applid – usually “TSO.” All terminals enter into a session with this same applid. TSO then immediately passes the session to a secondary VTAM applid which is unique for the life of your session (usually “TSOnnnn”). So where does TSO pass your session to? To a unique VTAM applid id. Remember that.
When you login to Model 204, your terminal also enters into an LU-LU session with a primary VTAM applid; assume it’s “M204.” All terminals enter into a session with this same VTAM applid. After you enter valid credentials, M204 passes the session to a secondary VTAM applid. However, the secondary VTAM applid is not unique. All terminal sessions are passed to the same secondary VTAM applid (i.e., each Model 204 address space has one primary and one secondary VTAM applid). That’s important.
This project started out innocently enough: a special request from a customer. As it progressed, it started to feel like one of those long cross-country family car trips where your kids keep asking “are we there yet?” Along the way, I was reminded that the how, when, and where of VTAM session passing must be precisely accounted for in your FEPI event handling exits and even your FEPI applications.
Once you’ve dug into the bowels of FEPI, you can see that the designers worked hard to mask many of the nasty details of SNA LU-LU sessions from users of the FEPI API. But they couldn’t mask them all. If you are using FEPI to interact with a well-behaved VTAM app like CICS, ignorance can be your friend. However, in a CICS TS world, there are better ways to programmatically integrate with CICS terminal-oriented transactions. Thus, the well behaved cases are often irrelevant, and understanding how FEPI maps its concepts/actions to the underlying SNA protocols is very important in dealing with the difficult cases.
I’m not trying to create a modern day FEPI revival (or in any way champion the cause of screen-scraping), but I suppose now is the time to make a little announcement: You can use HostBridge to XML-enable, web-enable, or service-enable TSO, Model 204, or any other “badly behaved” VTAM application.
Is that the lid of Pandora’s Box I hear opening?