The -Mm parameter is used to specify the standard message buffer size in bytes. OpenEdge uses message buffers to move records between servers and remote clients. The number of records that get packed into a message buffer depends on they type of query run and the size of the records.
When running a query using the NO-LOCK
qualifier, the first record is packed into a message buffer and sent to the client. For the remaining records, a message buffer will be packed with as many records as it can fit. The number of records that will fit in the message buffer depends on the size of the records and the value of -Mm.
However at the IP level, packet sizes are limited to the MTU for the connection which is determined by the Ethernet frame size the network interface can handle. Larger TCP message must be split into several Ethernet frames not larger than the MTU. TCP will break it up into the MTU size packets and send them out using TCP windowing. There are some theories that -Mm should equal the MTU network setting to be as efficient as possible.
$ netsh interface show interface | find "Connected"
$ netsh interface ipv4 show subinterface
Running a query that utilizes any other type of lock other than NO-LOCK, will result in only one record per message buffer sent to the client, regardless of the -Mm startup parameter value. This is done by design, so as to minimize the number of records locked at any one time. If multiple locked records were allowed in a message this would destroy performance since everyone else would have to wait on the unnecessarily
locked records in the message, until the user gets around to them on the client side where the lock releases would need to go back individually defeating the purpose of the multiple-record message. This would also potentially cause deadlocks and other problems due to locking logic.
To this end, consider upgrading to OpenEdge 12, which introduced the multi-threaded database model: (-threadedServer -threadedServerStack ) to handle client/server requests concurrently and server-side joins (-ssj) to further improve reducing the result set over the network for final client-side processing. Improvements for dynamic queries were added in later.