Re: Single Page Applications

Vernon,

The ASP.NET applications do not use CGI. The ASP.NET applications run inside an IIS web server on a windows machine. When ASP.NET applications need to access the IBM I, it uses the .NET Provider (http://www-03.ibm.com/systems/power/software/i/access/windows/dotnet.html). The .NET Provider uses ADO technology, which is Microsoft technology that replaces ODBC and OLE DB. It's a database interface. So the .NET Provider allows ASP.NET applications to run SQL against DB2 files and to call COBOL programs using DB2 stored procedures. There is no web server on the IBM I, and there are no COBOL programs using CGICBLDEV2 or the CGI APIs.

Thanks,
Kelly


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

Kelly

I'm going to throw in a concept that may already have been raised, but OK -

All that ASP.net and CGIDEV2 do is write text out through a web server that gets delivered to a browser. The "program" you write with ASP.net runs in IIS and generates the appropriate CGI stuff. CGIDEV2 generates CGI stuff through procedures you call -

So I guess I don't know the need for your COBOL people to learn ASP.net
- except maybe for something you mentioned - server-side stuff?

Which makes me think of another thing - what you create with CGIDEV2 probably won't be delivered using IIS, right? It'd be the Apache server on i.

But seems to me you can create end-to-end apps using COBOL and CGIDEV2 procedures - that's all that's needed.

With CGIDEV2 you are going to put together the HTML in templates and fill in variables, basically - you have to have built the HTML - and that's not an ASP.net thing, that's HTML[5?] and CSS and all that.

That is probably over-simplifying things, but at the bottom of it all, you are just creating text to distribute across a network - whether you use ASP.net as a front end or you use CGIDEV2 procedures, matters little to the end user. ASP.net will likely have better widgets and structures than raw CGIDEV2, but that's what some of the CGIDEV2-based frameworks are about.

OK, enough for now - this has been interesting to watch!!

HTH
Vern

On 5/28/2015 1:30 PM, Kelly Cookson wrote:

Buck,

Our development teams are organized along lines of business. We have two main developer pools, IBM I COBOL and ASP.NET. But the developers in those pools are distributed across teams that support particular lines of business (i.e., particular departments for the most part). Each team has to develop end-to-end applications for the lines of business it supports.

Thanks,
Kelly


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Buck
Calabro
Sent: Thursday, May 28, 2015 11:50 AM
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Single Page Applications

On 5/28/2015 11:41 AM, Kelly Cookson wrote:

The question I'm being asked is why would we want to have two ways of developing web and mobile applications? That means we will have to maintain two sets of legacy applications and maintain sufficient staff with the right skills. Add that to the demonstrated success over more than a decade at using the ASP.NET approach. So why in the world would we want to add COBOL CGI to the mix? That's the obstacle I have to overcome to sell a CGI COBOL approach, or an IBM i Integrated Web Services approach, or any approach other than ASP.NET.

I fight that here. The problem is that management is hung up on the
TCP/IP protocol rather than the user. The actual situation is that
there are already two development staffs; one for the external
customers
(web) and one for the internal customers (5250). Does it really make sense that the same over-stretched outside group be tasked to handle inside chores too, just because the end result will appear in a browser?
Or is the plan to add to the web team to support the additional workload? That's a real cost to the business for enforcing a 'one web team to rule them all' strategy.

--
--buck

--
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.

--
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.