× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Kelly

I think we are talking on 2 different levels. So far as I know and remember, ASP.net and PHP and all that are layers on layers on layers over communicating HTML between a web server and a browser.- CGI programs do that at a lower level, one might say - that is what I mean.

I don't mean CGIDEV2 - the set of procedures in a service program - when I use CGI by itself.

I've done a fair amount of VB development (VB6 the latest, for the most part) and dabbled in classic ASP for a web site I maintain - yeah, very different from ASP.net, but in a way, not - still an abstraction layer. In any case, requests are rec'd from a browser and processed by a script or program - with CGI programs (not necessarily CGIDEV2) these requests are closer to your code - with ASP and all, they are kind of pre-processed, as it looks to me.

From what the thread has been saying, and with this description - it seems there is no need for CGIDEV2 in COBOL - that is, IF the web pages are being delivered only by IIS. I mean, I suppose you CAN generate pages (the HTML text for them) that somehow are handed off to IIS to deliver further.

Anyhow, I've muddied the waters enough. Back to my regular job!

Good luck!
Vern

On 5/28/2015 3:14 PM, Kelly Cookson wrote:
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.