If you are using COBOL Kelly you might want to take a look at Icebreak as a vehicle for making the transformation. It is modelled on .Net/aspx and is the only tool out there that I know that offers direct COBOL support.

They have a Community Edition you can try for free. Although the Community edition does not support web services, the Server and Enterprise editions do. Check the feature list here: http://www.system-method.com/en/page/icebreak-features <http://www.system-method.com/en/page/icebreak-features>

It is a great tool and I have been very impressed by its capabilities over the years. One of its objectives is to make it easier for .Net literate developers to integrate with IBM i apps.

Well worth a look and it might be the kind of .Net integration software you need.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jun 4, 2018, at 9:56 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx> wrote:

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>.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/opensource.


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.