How to move a legacy system to client/server? 1

[jessicatx]

I posted this on the MicroFocus forum, but since I have had no nibbles, maybe this is where I should have posted it!

We have a fairly large legacy system (about 100+ pgms), consisting mostly of CICS programs + I/O modules, etc. There is a bit of batch programs, too. Mgmt. would like to move this to a server-based system with as little "handling" of the code as possible. Of course, we have BMS screens. I was reading someone else's reply to another question, where they gave the website for Relativity. Could we use this? Has anyone else moved a legacy COBOL system successfully, and how was that handled? We are using Oracle databases in a couple of other server-based software systems, so I am assuming that this will be the case with the legacy system, also. These programs are already coded with SQL statements, if that would make things easier. Any and all comments are welcomed.

I looked at the Liant website, and they have a product to produce GUI-type interfaces. Has anyone used this product?

Any and all comments are welcomed.

Thanks.

 

[TomKane]

Is there a business reason as to why they want to move to client/server? Maybe you could develop a client/server front-end which accesses your legacy systems - that is what we do. We have a legacy back end system and we have a windows based front end.

The nature of our system allows us to import data (via sql) into our windows system in the morning and then throughout the day we send flat file data feed files back to the legacy system to be imported by it. We also have a very neat windows enquiry system too.

We think it's a win/win becuase we have a nice front end that protects the users from the "big bad" legacy system and we also have the robustness/reliability of a tried and tested, well settled back end system.

The other benefit is that if we were to switch to a different back end system we would just send it another flat file - so we could do parallel running without the duplication of effort from the user.

I hope this is of some help to you......

 

[jessicatx]

Thanks, Tom. You made some good points, but, unfortunately, the die is cast. Mgmt. has already committed to ridding us of our perfectly good mainframe (which has a whole lot less downtime than the servers, but that's another story). So we are still trying to decide on the "how", not the "if".

 

[Dimandja]

Hi jessicatx,

Yes, you can migrate your CICS COBOL applications to the Windows environment, at least. You can further move them up to the web. There are several tools available to assist you in this. And, you should be able to do this with as minimal code retouching as you wish, or is possible.

Since I don't know which client/server model your management has decided on, I cannot begin to offer specific solutions.

In the meantime, I posted material that may be of interest to you in this thread:
thread209-393016

Let us know which type of client/server system you are planning to implement.

Dimandja

 

[k5tm]

Hi jessicatx,

Relativity is a middleware product that provides ODBC SQL access to COBOL files. It is a great product (ahem!) but probably not directly appropriate for this. Relativity would be useful for follow on work where you might want to do reporting on your COBOL data using Crystal Reports, MS Access, etc.

Relativity has a sibling product called InstantSQL that might be appropriate for the Oracle/COBOL interface.

There are lots of flavors for client-server these days. In particular, what will your client be? A terminal emulator (i.e. you stick with green screen look)? Or is the goal to get to a web-enabled user agent client (i.e. a browser)? Or do you want something that looks more like a "true Windows" application along the lines of Word, Excel, etc. Each of these three approaches would be considered client-server, yet each would require a different toolset.
Tom Morrison

 

[jessicatx]

Dimandja and Tom -

Well, I do know that the desire is NOT for a green-screen look (ugh!), and I believe that a GUI-look is desired. (We have NT servers and the users' pc's are at various levels of Windows.) We are evaluating a move to a company intranet, also (don't laugh - we are a small quasi-governmental agency, and you know that NOTHING gets decided in a hurry, in this type of organization).

I have looked at the Liant website and browsed through the info on VanGui. Is this an option that we could look into, at least?

Dimandja, I looked at the other posts that you mentioned. Although some of it was Greek to me, they were intriguing. I'm checking out some of the websites that you mentioned in these posts.

Jessica

 

[k5tm]

Jessica,

Probably the best fit for moving a CICS application with BMS screens is to a web browser interface, using HTML forms, as this translates well from the block mode terminal model. If green screen is out, then you should expect to modify the CICS screen handling code a bit.

Since you are 'jessicatx' perhaps you are in Texas? Look up our sales 800 number on our web site and call; ask for me. Tom Morrison

 

[Dimandja]

Hi jessicatx,

Here is how we managed to adapt a legacy system to the Web.

The decision was made to use Visual Basic, Internet, and the existing application code. (Today, VB is being replaced with ASP, or Java, or something other).

As often happens in these situations, the old system had to keep working while (and after) we build the new system.

The key to accomplishing all this, was to build an interface between the old system and VB/Internet. The expected result was that the old system continued to service the old clients, while 'unwittingly' also servicing the new clients (VB).

The interface essentially acted as a 'legacy client' to the old system, and as a server to the new VB clients.

The old code was essentially left alone (no changes), while most of the work went into the VB clients and the interface module.

This adaptation went well mostly because the old system had clearly defined client/server modules.

If, in the old system, you have user interface modules that directly access the database (i.e. a single COBOL program acting as a user interface and as a database interface), you may be in for a long haul. This is because in a 'clean' client/server model, only the server should access the database (think security); and the client is the user interface to the application, not the database.

Dimandja

 

[GoAS400]

Dear jessicatx,

There is an important question here.
You said you wanted to move your legacy COBOL code over to a client server environment to make it look pretty...probably using Oracle.

How are you going to re-create all the business logic in the Oracle environment without rewriting over 100 applications into SQL?
That is one solution, albeit not pretty.

The other is to run COBOL in an NT environment with a GUI interface. You could buy Fujitsu COBOL for Windows and transer the code over. Fujitsu supports ODBC SQL to SQL Server and Oracle databases so it wouldn't be a problem calling SQL statements.

It doesn't sound like you have anyone there to support your legacy applications. If you do, I would 'highly' recommend preserving your COBOL investment in the business logic and porting it over.

If it was up to me, I'd move the COBOL over to the AS/400 and build an intranet based application using WebSphere Application Server that could tap into the COBOL logic.

Best Regards,

John

 

[saginaw]

The following should provide you with additional information and examples of what is possible when migrating a mainframe application to a windows or UNIX platform and building an HTML/JSP frontend.

The following provides actual examples of COBOL programs downloaded and frontended with a Java/JSP frontend and using Micro Focus for the COBOL backend...

http://www.simotime.com/docsj001.htm

The follwing is a white paper discussion that talks about extending legacy application to the Internet but building a new frontend is similar to what is required for moving the entire application...

http://www.simotime.com/sim4l2n1.htm

The following company has some very interesting approaches to accessing CICS or creating new Java based applications based on CICS techniques but will run independent, it is worth taking a look...

http://www.bridgewater.com/

Good Luck.... Saginaw
helpdesk@simotime.com

http://www.simotime.com

 

[dallasdino]

First 100 programs is a very small legacy system. In many legacy systems this would not even qualify as a small subsystem. Many shops add that many new programs every year.

I would use MicroFocus COBOL with the CICS option to get it working as written on the platform of choice. This is a very proven way of proceding. After you do that you can add GUI to the subsystems as you want using their GUI tools.

There are a lot of things to think about when going from a mainframe CICS region to a client server system. Taking a multi-user transaction based system and making it perform the same on a PC is not too tough. This has been done many time for all COBOL systems. Making the CICS transaction processing, record locking, security, backups and other things to work in a multi-user environment can be a challenge.

I would refrain from buying too many 3rd party packages. You may find you spend more money than you did on the mainframe.

Some people code whatever display they want and call the same CICS COBOL program modified to send out a data string much like the common area in CICS.

 

[jessicatx]

Thanks to all of you who have offered helpful suggestions. I realize that 100 programs is not a LARGE legacy subsystems, but we have a very minimal staff who have NO expertise in doing this kind of conversion. So 'large' is a relative term, given all that. You are the only one who felt compelled to point out that this is not a large system. It isn't the size of the system that will be the problem, but the decision on the approach will be the quandry.

I was trying to be pro-active in this conversion, and most of you have been very, VERY forthcoming in suggestions. We do have Micro Focus and have used it when maintaining our mainframe programs. The staff has experience in SQL as these legacy programs are maintaining a relational database on the mainframe.

Sorry - I was a little steamed at the belittling.

 

[k5tm]

Deep breath, JessicaTX. You needed to use one of these:

I renew my invitation to give us a call at 1.800.RMCOBOL. Ask for me; I am not in sales. Tom Morrison

 

[dchristensen]

jessicatx

Micro Focus Net Express has a wizard that will generate a web page from the mainframe CICS program(s) along with changes to use that page in lieu of the CICS screen. I've experimented with the process and it seems to work fairly well. It wouldn't be the Windows GUI interface, but would still allow you to hit your desired platforms.

Dave Christensen

 

[jessicatx]

Thanks, Tom and Dave. (Sorry, Tom - this Dallas guy gave me a pain when he just HAD to gouge me. I didn't post my original response, which was very heated - I didn't want to step down to that same level.)

Tom, I didn't realize that you were not in sales, so I just may give you a call. I have absolutely NO authority in this decision process, but I am trying to see what is available and what others have done.

Dave, thanks for the info on Micro Focus. We have done some limited Net Express programs, but mostly just batch stuff.

Thanks again to you both.

Jessica

 

[jetspin]

Hi.

Good Luck. I have converted 3 Cobol systems only from one legacy system to another which is a lot easier but one thing to note is that the cobol source code is a file which can be read, converted and written out to anther flat file.
You can perform most of your proprietory changes in that manner.

 

[saginaw]

jessicatx,
If you have 3-5 BMS screens that you could send to me then I will convert them to HTML/JSP and build a small model for you as an example... this would give you a closer look at what is involved. For example, a screen that displays a customers name, address for inquiry and/or update would be a good example... BMS source members in an ASCII/Text file containing a single MAP or a MAPSET would be fine... and in case you are wondering, this is a freebee but allow me a couiple of days to do it. My direct e-maill address is saginaw@simotime.com Saginaw
helpdesk@simotime.com

http://www.simotime.com

 

[k5tm]

Jessica,

saginaw's SimoVIEW product looks like a good starting point for this type of conversion.

Once you have HTML forms built from your BMS screens, it is a fairly straightforward step to use Liant's recently released XML Toolkit to arrive at an 'internet' application which uses web browsers as the client. In the Liant RM/COBOL implementation, the result is almost pure COBOL (hooked directly to the web server without CGI). (You will not find this technology described on our web site.)

Still waiting for the call. Tom Morrison

 

[dchristensen]

Jessica,

Since you already own Micro Focus Net Express, all you need to do with the CICS programs is download them and run each program through the migrate wizard. That will build a default HTML page to match the BMS mappings in the linkage section. Once created, the HTML pages are fully modifiable through the forms editor integrated in the IDE.

The in-line SQL should work with the only need for change being a change to the CONNECT statement which will have to point to an ODBC data source that you will configure to point to the Oracle database where ever it will reside.

From the work that I've done so far, this looks like a pretty seamless way to handle your conversion with minimal re-write. The programs generated can/will be either CGI or ISAPI programs that perform well.

If you have more questions about this conversion, let me know.

Dave Christensen