Brad,
Because our development teams are organized by lines of business. The development team that I'm does all custom software development for Human Resources, Payroll, Accounting, Accounts Payable and Accounts Receivable. My team is responsible for creating end-to-end applications for these departments.
Our ASP.NET developers are on other teams that support the corporate website, a few warehouse web applications, and one custom web application to supplement our CRM. Sometimes we've hired ASP.NET developers to these positions. Sometimes a COBOL developer has become an ASP.NET developer. But when a COBOL developer becomes an ASP.NET developer, they do little or no COBOL development going forward.
The organization of our teams along lines of business is not going to change in the foreseeable future. So, if my team is going to start making web and mobile applications using ASP.NET instead of 5250 green screens, it might make sense to have some COBOL developers on my team learn browser UIs and SPAs and other COBOL developers learn ASP.NET for the back ends of server-side web applications and RESTful services. It would reduce the amount of initial learning for each individual COBOL developer, which means my team could get up and running more quickly. (The developers on my team could then learn the whole skill set for end-to-end applications at a slower pace.)
Thanks,
Kelly
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Bradley Stone
Sent: Thursday, May 28, 2015 12:45 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Single Page Applications
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
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
midrange.com
