I manage several development teams, and we have a couple of large applications utilizing Natural. One of the challenges we face (like everyone else) is providing a better interface (versus 3270) for our customers. We have some experience with EntireX, and have looked at utilizing that as a mechanism to leverage our existing skill sets while being able to put a ‘modern’ (browser-based) inteface on the front-end. We are also looking at the other end of the spectrum like moving towards a BPMS solution.
One suggestion was to do something like the following. Inject a call to COBOL/CICS in between Natural and a Java-based front-end. This solution seems similarly (but less advanced than EntireX). If I understand the proposed solution, it is something like:
Natural calls a COBOL/CICS object. To ‘kill’ the map, one has to use SET CONTROL ‘QO’ and possibly do some type of DUMMY input (i.e. this will cause the map to not be displayed, but allow an INPUT to occur so that data could be transferred in the process). I think it looks something like this:
Java Web Page <-----> CICS <-------> COBOL <----------> Natural
Forgive my lack of understanding, as I don’t really understand what is being proposed. I was provided something like the following:
NATURAL provides a mechanism to allow a CICS connection. This is a “DUMMY INPUT” that will replace the existing INPUT and allows a call to CICS directly. For example:
CALL ‘COBOL-SEND’ USING MAPDATA
SET CONTROL ‘QO’
INPUT ‘DUMMY’
CALL ‘COBOL-RECEIVE’ USING MAPDATA
If you are going to ProcessWorld later this year, I will be giving a three hour session, mainly on ways to add “bling” to existing Natural code.
It will include using DY=, %N, Windows (via the %W commands), Control Variables, and much more (e.g. Calendars that look just like web calendars for date entry).
I’d look at Natural for Ajax, this gives you a Rich GUI frontend and allows for a smooth
transition path, you can intermix maps and “pages” (that’s what Natural for Ajax calls the
GUI) and thus change them one by one.
Plus map based Natural will render in a web browser as well.
Answering your original question:
when you talk ECI to CICS you might be able to just call into Natural
without an intermediate COBOL program.
We did take a look at the Ajax solution a while back. If we were to go with a solution along these lines, I think the Ajax stuff would make sense. Realistically, I would like to move more towards an incremental improvement through a more fundamental strategy shift like the BPMS solution. That seems to make more sense from a long-term perspective.
Since I am a manager, I am incompetent (technically; at least I think that’s how it supposed to work). I am familiar with Natural applications. I am not that familiar with the system side (CICS, ECI, etc.).
More or less what I think I really wanted to know was whether or not people were really trying to modernize Natural screens in any such manner as I have tried to describe. Just seems like a convoluted solution.
A BPMS just defines the rules, it’s got nothing to do with what the actual processes are written in.
The flow you have drawn seems to go “Web page talks to CICS, CICS invokes COBOL program, COBOL calls Natural”
but then you say “Natural calls a COBOL/CICS object” so I’m a bit confused, can I assume the COBOL program is
just a layer in between to pass data back and forth between the Java page and Natural ?
This is possible, and probably about what I had in mind when I said “use ECI to call into Natural”, you will have to
create a “stub” called via ECI (the External CICS Interface) which then constructs the parameters to call Natural
as an async application, so to say, but of course it’ll all be easier when using EntireX, as far as error handling is
concerned etc. etc.
Ajax otoh is the least intrusive way and lets you, as I said, run “the old and the new” side by side while you
shift more and more stuff towards the new.
Understood, and yes I believe the proposal is to simply have a COBOL layer that passes data back and forth. It just seems like a way to ‘get around’ using or paying for something like EntireX.
I was hoping someone (more than one person) here had experience with some type of model like that (using ECI, COBOL as a layer, etc., but not using Ajax nor EntireX), and could comment on the success or difficulties.
When I say BPMS, I am referencing something more than just rules. I am talking about a fundamental shift away from our current architecture. The shift could include an ESB, some type of rich interface development, rules management, etc. At least that is the way my SAG Sales Rep positions it: The utopia of IT is just around the corner.
If you are looking at just “web enabling” your 3270 applications, you could see if ApplinX would provide the solution you are looking for - you can use it to take the existing screens and expose them as web services or you can use the Application Framework to render the screens as web application pages. Basic customization allows you to replace PF-keys with buttons, menus with drop downs, apply colors and other style effects. From there you can combine multiple 3270 screens into a single web page and update multiple 3270 screens from a single web page, completely hiding the original 3270 look and feel.
Generally, if your 3270 applications are stable and provide the functionality and data that your web application needs, ApplinX is a great way to go, providing a quicker path to modernization. If you need to extend and modify the functionality and/or data to support the goals of the web application, I would recommend the EntireX approach instead or in conjunction with ApplinX. EntireX works on a service level, wrapping your business logic in an object (Java, XML/SOAP, .Net), so it is less constrained by the 24x80 bounds of the 3270 screen, but typically requires some coding in the mainframe to provide the service routines (subprograms in Natural), where ApplinX works directly with the 3270 screens and does not require changes to the mainframe code (“non-invasive”).
