Re: Running COBOL under z/os.e
- From: timothy.sipples@xxxxxxxxxxxx (Timothy Sipples)
- Date: 29 Nov 2005 06:02:23 -0800
>I was thinking of CGIs. I was also thinking of the HTTPD server. We
>don't have Websphere. Perhaps Websphere has things in it to make
>developing CGI-like applications in COBOL easier. When we tried to do
>CGI in COBOL a few years ago, it was very difficult due to not being
>able to use "stdin" and "stdout" directly from COBOL code, using COBOL
>verbs. I haven't looked at this since installing Enterprise COBOL, so
>maybe it is easier now.
Ah. Well, J2EE is a complete replacement for CGI (and then some). There's
something called JNI if you absolutely positively must make a native
platform-specific call, but there are vanishingly few reasons to do that.
CGI has fallen out of fashion (industry wide) for a variety of reasons.
Aside: WebSphere Application Server for z/OS is unique in being able to
run COBOL as EJBs (Enterprise Java Beans -- don't take the "Java" too
literally here). The COBOL code appears as "Java" objects within the
WebSphere runtime, interacting with ordinary EJBs. None of that is CGI,
though, and it wouldn't require a C compiler.
>Plus, I'm trying to get my C compiler back <grin>. Not likely as I'm the
>only C literate person here on the z/OS side. The Windows side might
>have some C people. Although from what I know of them, they are all
>VB.Net people now.
OK. Well, in that case, you should probably go into the z/OS Web Services
business. Make everything (or at least almost everything) accessible as
VB.Net-friendly Web Services. "Update account" a Web Service. "Query
account(s)" a Web Service. Everything you possibly can, starting with the
important ones (from an application perspective). Then you're relevant --
you have a directory (yes, directory) of oh-so-easy to use services that
VB.Net developers can just grab-and-go. (It's also pretty easy to do in
many different ways.)
VB.Net really doesn't know much about anything else -- including core
business function -- unless it looks like a database (ODBC) or a Web
Service (SOAP/WSDL). (Yes, it's that stupid. :-)) If all the valuable
stuff (i.e. your mainframe apps) doesn't look like either one (especially
SOAP/WSDL) then, of course, that mainframe stuff will be everything you
mentioned. It'll be like an interstate highway with no on-ramps.
Now I can't think of anything more proprietary than VB.Net, and even
Microsoft isn't sure what to do with legacy VB. (Q: How do you bring
classic VB to the Web? A: With major difficulty.) But the beauty of Web
Services is that when your company changes its mind about its primary
development environment you're still in very good shape because you've
abstracted your core business functions into reusable, language-neutral
Web Services. In fact, the more rewriting of existing code you do in
VB.Net -- without abstracting as services -- the worse off your company
will be in the future.
Another aside: I'll let you in on a little secret. IBM treasures its ~300
MIPS customers -- a brand new z890 starts at 26 MIPS, after all -- but,
just as with its ~30,000 MIPS customers, it doesn't work if everything is
frozen at circa 1976. It's a mixed workload platform with significant
economies of scale, and that means it should run code you wrote 30 years
ago alongside code you wrote 5 minutes ago. What IBM is saying is pretty
simple, actually: put something "new," anything "new," on your mainframe
and you will enjoy the best cost-of-ownership (and qualities of service)
any IT money can buy. Making your VB.Net programmers more productive (and
more architecturally sensible) could be your "new."
Probably no surprise (or secret), actually, come to think of it. But hope
it helps someone.
What you're probably not going to win is the argument about "primary"
development platform. Sounds like it's VB.Net in your shop. A VB.Net
developer is going to take a dim view of someone arguing that *their* next
line of code ought to be written in COBOL or C on z/OS. It's like asking
someone to change their brand of cola. But Web Services -- well, that's a
different story. Now you're actually making their job easier and simpler
because they don't have to figure out how to write thousands of lines of
code to recreate that accounting system you already have (for example). If
they could only plagarize that business function from the comfort and
convenience of the only development environment they know in the ways
they're used to working....
Oh, one more thing. Ask for help. Go to your friendly IBM rep and say,
"Let's find out more about a zIAW." (That stands for zSeries Integration
Architecture Workshop, also known as a SOA Workshop.) Your friendly IBM
rep will go to w3.ibm.com/search and figure out what you mean, then
they'll understand. See if it makes sense to have a workshop at your
company. As it happens the workshop doesn't cost anything except a couple
days' time.
Good luck! (Or is it "Lose a bit"? :-))
- - - - -
Timothy F. Sipples
Consulting Enterprise Software Architect
IBM Americas zSeries/z9 Software
Phone: +1 312 529 1612
E-Mail: Timothy.Sipples@xxxxxxxxxx
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Prev by Date: Re: Submitting JCL via FTP
- Next by Date: RE: Submitting JCL via FTP
- Previous by thread: RE: Running COBOL under z/os.e
- Next by thread: RE: Running COBOL under z/os.e
- Index(es):
Relevant Pages
|
