Seems to me you're definitely overthinking this.

Have you sat down with your .Net development team to talk architecture yet ? I believe I asked this question before.

If I were your .Net development team lead I would be most likely creating .Net web services that call the various IBMi services behind the scenes.

There's really no reason to do most of this outside of .Net.

For exposing services from .Net/IIS or IBMi/Apache, multiple apps/services or a single app/service with URL routes should work fine over a single HTTP/HTTPS port. Preferable port 443 or something else SSL enabled.

I don't know enough about your apps, but you might have a separate data service to replace each menu option and the services could be in any of the things you mentioned including .Net itself.

Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802


message: 3
date: Sat, 2 Jun 2018 19:41:57 +0000
from: Kelly Cookson <KCookson@xxxxxxxxxxxx>
subject: [IBMiOSS] Ports and routes needed to replace very large
numbers of green screens.


Our shop has been using .NET web pages to replace IBM i green screens. We now want our .NET web pages to use RESTful web services to connect with the IBM i, rather than using DB2 drivers and stored procedures like we have in the past. We are looking at various technologies for creating the RESTful web services on the IBM i: Node.JS, Java, PHP, COBOL CGI, and a few others. I am on a team currently evaluating our options.

My concern is with the ports and routes that will be needed to replace our green screens. Our business departments typically have 1 main green screen menu with, say, 50-150 options. A few of the menu options call up sub-menus with 5-20 options each. Each menu option calls up one or more green screens. So we have a lot of green screens in production.

If we develop web pages to replace most or all of these green screens, then I am concerned about the number of ports and routes involved. Here is how I imagine two extremes:

* One extreme is to use a unique port for every set of web pages that replaces a green screen menu option. This would result in many hundreds or even several thousand unique ports being open. This seems like a nightmare to maintain. I know too little about ports to know whether or not this would have a negative impact on system performance or security.

* Another extreme is to set up a single web server on a single port, then set up many hundreds or several thousands of routes within that single web server. This, too, seems like a nightmare to maintain. It also seems like a performance hit to have so many routes to resolve.


1. Does it make sense for each department to have its own web server running on a unique port, then deal with the dozens or hundreds of routes needed for replacing that department's green screen menu options? Maybe we could keep the number of routes needed down by using single page web apps.

2. Is there a way to set up hierarchies of routes so that resolution of a particular route is quicker?

3. Could we reduce the number of ports and routes needed by running the client front-ends from web servers on the IBM i instead of using .NET? For example, if we serve web pages from an Apache web server or a Node.JS web server running on the IBM i, is there some way to reduce the number of ports and routes needed to replace so many green screens? (I don't see how, but I'm no expert so I'm asking.)

4. Does anyone have other ideas for reducing the number of ports and routes needed? And if the ports or routes can't be reduced, any ideas on how to efficiently maintain large numbers of ports and/or routes?

We will not be replacing all of our green screens all at once. It will be a gradual process of replacement. But I don't want to end up in a bad place down the road because we weren't thinking about how we use ports and routes.


Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676<>

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by 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].