×
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.
Nathan,
2,500 * 8 = 20,000 routing steps
That's probably an overshoot. While many of our DSPFs do have multiple record formats, many have only one record format--and those that have more than one record format almost never have 8 (more like 2-5).
But your point is well-taken.
I think there are some ways to break things up using the methods in the original post of this thread. The fact that our developer teams are organized along lines of business may help us in this regard. Each team is responsible for end-to-end software development for the lines of business they support. So we can divide apps along lines of business, then along meaningful divides within lines of business. For example:
1. We could use multiple web servers to reverse proxy. Our development teams are organized by lines of business. Different lines of business could have their own web servers to serve as reverse proxies for the node apps they use.
2. Some of our green screens contain options to run a set of related interactive programs. For example, we have a green screen that lets employees take options to run six interactive programs for managing prepayments on orders. We could turn these six interactive programs into sub-apps or modules of a single "prepayment" app. The "prepayment" app would only have one port number and one reverse proxy route. The rest would be handled by routing inside the "prepayment" app.
3. Some of our green screens are only used to enter parameters to run reports. Sets of these green screens could be set up as single web pages inside a single "run reports" app. The "run reports" app would only have one port number and one reverse proxy route. The rest would be handled by routing inside the "run reports" app.
My concern is how to make the best use out of such ideas. Is one of the ideas mentioned above going to be a pain point or major limitation as we accumulate more apps? When we want to scale up an app? When we try to implement fail-over and load balancing? Is there a combination of the above ideas that would be better? Or worse? Am I missing any major strategies for hosting large numbers of node apps?
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
1.217.773.4486 ext. 12676
kcookson@xxxxxxxxxxxx
midrange.com
