That depends.

If you just migrate, and do not adjust -Mn, -Ma,, -Mi, -Mpb and so on to account for the new threaded servers then you will have the same number of processes but they will be multi-threaded. That is _probably_ going to act like it is "using more resources" because you are, basically, getting the worst of both worlds.

If you adjust the relevant parameters to reflect your desired configuration then the threaded approach _should_ use fewer resources. In particular less CPU cycles. Maybe a bit less memory.

But you really need to test it and understand what is going on.

Also - it is November of 2025. Why are you migrating to 12.2? 12.8 is a much more suitable migration target.

Hello @Tom Bascom (White Star Software LLC)​ Thanks for the response. Do we need to decrease -Mn and increase -Ma for getting the benefit of multithreading? could you share more information on the database startup parameters which need to be modified while migrating from 11.7 to 12.2. Do we have any Progress Documentation for that?

"Why are you migrating to 12.2? 12.8 is a much more suitable migration target."

we would like to go in a phased approach for migration

"Do we need to decrease -Mn and increase -Ma for getting the benefit of multithreading?"

No. Whether the ABL servers spawned by a 12.x broker with "-ServerType 4GL" will be multi-threaded is determined by the value of the -threadedServer parameter. The possible values are 1 (multi-threading on) or 0 (off), and it is set to 1 by default.

It is important to understand what these parameters do, what their scope is, and how they interact with each other. The approach I take when selecting these values, whether in 12.x or pre-12, is the following:

• Determine which client types will be connecting remotely: ABL, SQL, or both.
• Determine how many login brokers are required. If the answer above was "both", you should have a minimum of two login brokers, one with -ServerType 4GL and one with -ServerType SQL.
  • While it is technically possible in this scenario to have one broker with -ServerType BOTH, you should never use value "BOTH". It is a worst practice.
  • It is possible, and sometimes desirable, to have more than one login broker per client type. For example if you have different categories of ABL clients, e.g. interactive users vs. PASOE MS agents, or human users on a slow remote network versus human users on a fast local network, you might want to have separate 4GL brokers for each category with different client/server parameter values.
• For each broker, determine the desired upper limit of concurrent remote connections.
  • This value is equal to the product -Mpb * -Ma.
  • Note that -Mpb and -Ma (as well as many other C/S parameters like -S, -H, -Mi, -Mm, -minport, -maxport, etc.), are scoped to the login broker, not the entire database.
• For each broker, choose a value for -Ma: the maximum number of clients per server. Tom provided some guidance above.
  • For 4GL brokers, this choice will vary between 11.x or earlier (single-threaded servers) versus 12.x and later (multi-threaded servers. For multi-threaded servers you can choose higher values as each client connection gets its own server thread.
  • SQL servers are always multi-threaded.
• For each broker, your choice of -Ma thus determines your value for -Mpb: (desired upper limit of concurrent remote connections) / -Ma = -Mpb.
• For brokers with single-threaded servers, I set -Mi (minimum connections per server) to 1, to spread the client load across servers. For brokers with multi-threaded servers, the value of -Mi doesn't matter as much (in my opinion).
• For each broker, the value of -Mpb determines the size of the dynamic server port range (-maxport - -minport + 1).
  • Do not re-use -minport/-maxport ranges across brokers or databases on the same machine.
  • Do not use overlapping port ranges across brokers or databases on the same machine. Some people do this because it is easy, but it actually makes things much more difficult when it comes to troubleshooting connection issues.
  • Don't configure a huge -minport/-maxport range. It doesn't need to contain more ports than -Mpb.
  • Do not use port ranges that include the ports of TCP services already defined in the OS (/etc/services or %SystemRoot%\system32\drivers\etc\services). The 4GL broker will skip those ports and you will be unable to spawn the desired number of servers.
  • Keep the OS services file sorted by port number, and add a comment in the file for each port range assigned to a database login broker, so that future users/admins won't use those ports for other purposes and potentially cause connection issues.
  • For both your broker service port (-S) and your server port range (-minport/-maxport), choose port numbers that are below the ephemeral port range used by the OS for the local ports of outbound connections. This varies by OS. Again, this is to avoid port conflicts. To view the ephemeral range:
    • Windows: netsh int ipv4 show dynamicport tcp
    • Linux: sysctl net.ipv4.ip_local_port_range OR cat /proc/sys/net/ipv4/ip_local_port_range
    • AIX: /usr/sbin/no -a | fgrep ephemeral
• Once you know all of your broker -Mpb values, and how many secondary (-m3) login brokers you will have, you can now set the value of -Mn, which is scoped to the database. it is a primary broker parameter, not a login broker parameter.
  • -Mn = (count of secondary login brokers) + (sum of -Mpb values for all login brokers).
  • This ensures sufficient records in the _Servers VST to allow all brokers and servers to be spawned.
• Side note, as this confuses people sometimes: if the primary broker has a -S parameter then it is also a login broker (with all the same locally-scoped C/S parameters as other secondary login brokers), though it is not counted as a secondary login broker.

Added the "OpenEdge RDBMS" topic.