Mainframe Vs. Multi-Tier Programming. What's the Dif?

[BoulderBum]

I looked a little into what mainframe programming is, and the definitions I saw were "Programming coordinated tasks across multiple processors". How is coding for a mainframe in Cobol different than multi-tier programming in .NET, for example?

How is it all different than modern programming paradigms?

 

[Truusvlugindewind]

A traditional (cics) mainframe program contains code to
- read & write the screen
- read & write the data(base)
- perform business-logic

This kind of program is difficult to use together with other kinds of application on other platforms.

When you split the program logic into separate modules you can still process the progam the old way, but you can also:

write a java module doing (graphical) screen-io calling java on the mainfram calling you COBOL business-logic.

Then it is called multi-tier and then people say: "Ah, you are tackling your legacy problem", and you think "I did not know I had a problem.... ".

About .NET: Next month Micro Focus introduces the next version of Net Express and that should intergrate seamlessly into the .NET thingies of MS. See if can attend the introduction session at you local Micro Focus store.

 

[ceh4702]

Since a web page is just text it is easy to make webpages on a mainframe. All that is left is to script the data out to the web page. This usually requires a webserver to be attached to a mainframe.

We use a product called decision ananlyzer and it has a 32 bit VB client for the PC and uses EHALLAPI Extended High Level Language API to send data to the PC. IBM uses this to make their Personal Communications Software with is a software Emulator used to connect to the mainframe over ethernet.

If you do not like my post feel free to point out your opinion or my errors.

 

[BoulderBum]

So if I'm reading you guys correctly, a mainframe program is, in essence, a multi-tier program where the presentation layer is still handled by a web server, but all other logic (database AND business logic) are handled in a single location or "mainframe" (instead of seperate servers).

Is this correct? Is there more to it? It almost sounds like a mainframe also goes into client-server interaction. I guess I'm still a little unclear.

 

[Dimandja]

Not "a little unclear", try "very murky".

I think the over-abused "multi-tier" terminology has successfully muddied the waters.

Simply put, a multi-tiered application runs on more than one computer.

In the old days, mainfarme applications were entirely written on the mainframe: screen displays were sent to "dumb" terminals.

Today, you can still write on mainframes, but also design and code the display module to actually execute on your PC while exchanging data with the mainframe application. Two-tier.

In this age of global communication, an application can execute on several computers to satisfy a single transaction. Multi-tier.

A mainframe can be one of those "tiers"... or not.

Dimandja

 

[etom]

We have a case where the PC communicates with a application server that in turn communicates with mainframe A (application a) which communicates with a second mainframe B (application b). Tiers can come in many forms.

etom

 

[BoulderBum]

Dimandja, I know what how a multi-tier app operates, I was trying (and failing, I guess) to relate what the previous posters were saying about the differences between mainframe/ modern multi-tiered architecture.

To reiterate the question, is it correct to say a mainframe traditionally perform the operation of the equivalent of many "tiers"? Am I understanding that it also traditionally sends data to the client as straight text?

Additionally, would I be correct in saying tradition is starting to crumble a bit, such that the lines between old mainframe programming and multi-tiered apps are sometimes blurring (because workload is getting distributed between servers and sometimes the client)?

If so, why is there still a "mainframe" distinction? Is it simply because the workload is, at least, more centralized?

 

[Dimandja]

1. To reiterate the question, is it correct to say a mainframe traditionally perform the operation of the equivalent of many "tiers"? Am I understanding that it also traditionally sends data to the client as straight text?

The problem here is there is nothing "traAditional" about multi-tier applications, and nothing "traditional" about sending data to any client as text.

2. Additionally, would I be correct in saying tradition is starting to crumble a bit, such that the lines between old mainframe programming and multi-tiered apps are sometimes blurring (because workload is getting distributed between servers and sometimes the client)?

No. As matter of fact, client/server models originated from mainframe applications. I learned the fine techniques of client/server models by programming entirely on a mainframe, over 20 years ago (an eternity).

3. If so, why is there still a "mainframe" distinction? Is it simply because the workload is, at least, more centralized?

Perhaps. But, to me, mainframe means too big for my desk top. Especialy when many "desk top compatible" computers can outperform some "mainframes".

The real tradition in all of this is insisting on calling IBM behemoths "mainframes".

Dimandja