Hi Richard,
Thanks for the responses.
I think our shop is pretty much set on moving to .NET Core. Asking if we should wait until the release of .NET Core 3 is a good question.
DB2 Connect would work. That's on the table for discussion by our team evaluating options.
I would love for us to be a .NET / Node / COBOL shop.
Our .NET developers are currently standing up a Node.JS web service on the IBM i. We need a web service for an app going into production relatively soon. The web service is running in Node.JS on the IBM i and uses the Node Toolkit (XMLSERVICE). However, our .NET developers have already said they don't want to be setting these up in the future. So a team is evaluating our options going forward. If our COBOL developers are expected to develop web services for the IBM i, then node might not be their preferred option. CGI using COBOL might make more sense.
I guess maybe I should ask the question more broadly. We have many hundreds (at least) of interactive COBOL programs. Many of these interactive COBOL programs have multiple green screens associated with them. Is there a way to replace all of these green screens with web pages and not create a need for multiple web servers (ports) and/or a lot of routes within those web servers?
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<
http://www.dotfoods.com>
From: OpenSource [mailto:opensource-bounces@xxxxxxxxxxxx] On Behalf Of Richard Schoen
Sent: Monday, June 04, 2018 8:25 AM
To: opensource@xxxxxxxxxxxx
Subject: [EXTERNAL] Re: [IBMiOSS] Ports and routes needed to replace very large numbers of green screens
Perhaps you could ask why they feel they have to jump right in to .Net Core when they don't have DB2 connectivity sussed out yet.
There's no reason the web service API can't be done in .Net 4 and maybe the rest of the layer in .Net Core.
Then they can swap the service layer pretty easily once MS releases .net Core 3 which will have many of the desktop things (such as ODBC/OLEDB, etc I'm guessing) available for Windows environments. That probably means the current connectivity will work again.
Or you guys can purchase DB2 Connect which I think will work now. That would also be a smart move to preserve existing coding instead of re-plumbing everything prematurely.
.Net Core is cool but still a growing child so putting all your eggs in this basket at once seems a bit premature. But then again I'm not your Senior .Net Architect.
Node might be cool but it's also another technology your team has to master.
And then you're a .Net / Node / Cobol shop.
Whatever works but just throwing out the questions.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx<mailto:richard.schoen@xxxxxxxxxxxxxxx>
p. 952.486.6802
w. helpsystems.com
-----Original Message-----
Hi Richard,
Our .NET developers are the ones wanting to find ways of developing web services on the IBM i. The .NET developers recommended using Node.JS on the IBM i, and there are several .NET developers on the same team as me looking at other technologies (Java, PHP, CGI, etc.) on the IBM i to develop web services. This team is actually being led by a senior .NET developer.
What's driving this is a desire to switch from .NET 4 to .NET Core. I have been told by senior .NET developers that .NET Core does not support some of the technologies they previously used to connect to the DB2400 database. (This is not a theoretical concern. They tried migrating to .NET Core and ran into problems.)
I did ask about using .NET 4 to create web services that interface with the IBM I the same way as always, then having .NET Core apps call the .NET 4 web services. They said it would work. But this was not the approach they wanted to take.
So, I'm not sure what more, exactly, I should ask our .NET developers. I'm open to suggestions.
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<
http://www.dotfoods.com><
http://www.dotfoods.com<
http://www.dotfoods.com>>
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx<mailto:OpenSource@xxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/opensource<
https://lists.midrange.com/mailman/listinfo/opensource>
or email: OpenSource-request@xxxxxxxxxxxx<mailto:OpenSource-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/opensource<
https://archive.midrange.com/opensource>.
midrange.com
