Kelly,

Why do your COBOL programmers need to learn .Net?

Let the .Net guys do their job, and let the COBOL programmers create the
stored procedures or whatever is needed on their end (the IBM i end).

The .Net guys know .Net. The COBOL programmers know the database and the
business logic and rules. Keep it that way. :) Let each person do what
they're best at.

Now, I'm all for the COBOL programmers learning new things, but... if .Net
is what is said will be used, not much you can do except ask if it's
possible to put together a COBOL CGI proof of concept.

I did this once any my prior job. We had customer service web applications
that ran on Windows (Cold Fusion I think it was). We mirrored our data
from the IBM i (AS/400) to their servers using mirroring software.

The CF web pages worked fine... until the data was more than 1000 records.
Then it chugged to a halt. It was brutally slow. Timeouts everywhere.
Don't even think about adding any complex sorting or searching.

I asked if I could do a POC using the IBM i as the web server and RPG (this
was before CGIDEV2 or anything was even out there except a few API
wrappers). They said sure and gave me a month to put something together.
I had it done in a week or 2 and they bought into it and liked it so much
they bought a dedicated IBM i just for this application (this was a
mutli-location company with servers all over the US, a few overseas too).
The rest is history. (It's still running to this day on the IBM i from
what I hear from the "old trenches").

Just a thought.

Brad
www.bvstools.com

On Thu, May 28, 2015 at 12:22 PM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

Brad,

You have the gist of things. But there not asking how to get IBM I data to
their ASP.NET applications. They already know what they want. They want
to get the data using the .NET Data Provider to run SQL against DB2 files
and/or called stored procedures to kick off COBOL programs.

I was hoping to find some way our COBOL developers could avoid having to
learn ASP.NET in order to become web and mobile developers. I was hoping
to make an argument that CGI COBOL lets them leverage their COBOL skills,
or the IBM i Integrated Web Services is so simple that COBOL developers
would essentially be leveraging their COBOL skills. The main benefits (that
I see) would be: (a) we can more quickly leverage COBOL developers for web
and mobile development if they don't have to learn ASP.NET, and (b) we
would be positioning the IBM i as a web server and not just a back-end
database server.

I'm still going to make the case, but I'm less and less optimistic about
selling it to managers. I think the counter-argument is, "We can use
ASP.NET as we've already been doing for years. And we can split
responsibilities between developers, with some COBOL developers on a team
learning the browser UI and SPA side and other COBOL developers on the same
team learning ASP.NET for traditional web applications and services for
SPAs."

Thanks,
Kelly


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Bradley
Stone
Sent: Thursday, May 28, 2015 12:10 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Single Page Applications

Kelly,

Let me know if I'm oversimplifying.. but... it sounds like they're set on
.Net. Lets say they are.

Then it sounds like the IBM i side of things just needs to get the data to
the .Net applications (via web services, data mirroring, stored procedures,
etc.. etc..)

Maybe you should be asking them "how do you want us to get the data to
your .Net applications?" And then work out if it's viable on your end with
COBOL.

If they want to send data selection parameters to a web service app on the
IBM i that returns JSON (or XML, or something else) that should be work
fine.

Brad
www.bvstools.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.