Rails to replace old 3270 terminal system

Hi.

We have a large setup of 2000 apps running on AIX using DB2, CICS, MQ,
TWS and SFS.

The programs that currently run on the system are.

  • HP3000 Cobol converted to VAG
  • Ksh and Perl scripts (mostly converted from HP:MPE)

As you might imagine the system does not perform very well. This
mostly due to the program not using DB2 as intended, the large
overhead produced by COBOL conversion and then VAG compilation to C++

I’m dreaming of replacing a this large setup serving 4000 users with
ruby running both batch and online (Rails).

I hope it would be possible rewrite the system part by part, and have
Ruby communicate with the old programs through ksh, perl, mq and of
course db2. Perhaps it would be possible for the users to access the
old 3270 terminal programs inside the new Rails system - so they do
not have problem finding there programs when they are rewritten in
Rails.

The system is only accessible in-house - beautiful web design and
novice ease-of-use is not rated as high as rapid input…

  • Do you know it this doable and a wise path to go?
  • Do you know of other setup with this many apps and users?
  • Enterprises tend to go IBM, Java or .Net way in hope of “great”
    support and cheep developers… any thoughts on this?
  • Possible for old school programmers to make nice programs in Ruby
    when given the right framework and guidelines?

Any thoughts, suggestions and references…

Regards
Rasmus

Rasmus Bergholdt wrote:

Hi.

We have a large setup of 2000 apps running on AIX using DB2, CICS, MQ,
TWS and SFS.

The programs that currently run on the system are.

  • HP3000 Cobol converted to VAG
  • Ksh and Perl scripts (mostly converted from HP:MPE)

As you might imagine the system does not perform very well. This
mostly due to the program not using DB2 as intended, the large
overhead produced by COBOL conversion and then VAG compilation to C++

I’m dreaming of replacing a this large setup serving 4000 users with
ruby running both batch and online (Rails).

I hope it would be possible rewrite the system part by part, and have
Ruby communicate with the old programs through ksh, perl, mq and of
course db2.

That sounds feasible.

Perhaps it would be possible for the users to access the
old 3270 terminal programs inside the new Rails system - so they do
not have problem finding there programs when they are rewritten in
Rails.

Perhaps, but then why replace the 3270s at all?

The system is only accessible in-house - beautiful web design and
novice ease-of-use is not rated as high as rapid input…

  • Do you know it this doable and a wise path to go?

Looks good to me. Another idea you might want to consider: use a
service-oriented architecture. Write the Rails frontend to communicate
with the legacy system using ActiveResource. Then swap out the legacy
backend for a Rails backend at your own pace. (We’re doing something
like this at my current job.)

  • Do you know of other setup with this many apps and users?

The number of apps is kind of meaningless. I seriously doubt that an
equivalent Rails system will need 2000 Rails applications to duplicate
the functionality.

There are plenty of high-traffic multiuser applications written with
Rails – Hulu and Ravelry are good examples.

  • Enterprises tend to go IBM, Java or .Net way in hope of “great”
    support and cheep developers… any thoughts on this?

“No one ever got fired for using Java.” It’s the conservative choice,
with all the advantages and disadvantages that implies. You’ll be able
to get a decent application working a lot faster in Ruby, and your
developers will be happier.

As for Windows and .NET, don’t bother. Windows is not a good server OS
(actually, it’s not a good OS at all…). I’ve heard good enough things
about MS developer tools that I’ve occasionally considered using Mono on
*nix, but so far as I can tell, Ruby beats the pants off C# as a
language.

  • Possible for old school programmers to make nice programs in Ruby
    when given the right framework and guidelines?

Well, of course – provided they’re willing to learn!

Any thoughts, suggestions and references…

Regards
Rasmus

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]