Together, -n and -Mn determine how many concurrent connections to the database are possible; the maximum number is (-n) + (-Mn) + 2. This includes not just "users" but all processes that connect to the database: brokers, servers, ABL clients, SQL clients, helper processes (AIW/BIW/APW/WDOG), database utilities, backup, etc.
Connections, users (human or batch), and licensed users (i.e. users counted for the purposes of Progress licensing) are three different things. And "licensed users" may mean different things (i.e. have different definitions and counting methodologies) based on the model and terms of the RDBMS license.
Regardless of your licensing specifics, if your RDBMS license is for 50 users then your -n should be set higher than 50, as helper processes, utilities, secondary brokers, etc. each take a connection slot even though they don't count against your license count as they are never licensed users. You can set -n as high as you want; it doesn't affect licensing compliance as tamhas said. What matters in terms of licensing compliance is how many licensable users there are, though to get more specific than that I would have to know your RDBMS license model.
If you don't increase -n above 50 then you won't be able to get 50 users connected, assuming you have database connections other than a primary broker and remote servers. The primary broker and remote servers don't count against -n; there are -Mn number of connection slots reserved for them.
but there are users more than 50
If you only have a 50-user RDBMS license then why are you trying to connect more than 50 users?
If I were you I wouldn't worry about trying to programmatically handle (748) errors. I'd concern myself with configuring the database properly, given the anticipated (and allowed) connection count, such that (748) errors don't happen if the application is being used properly. And if it isn't being used properly, i.e. if too many users are attempting to connect, then a (748) is exactly what you should see. Making the error comprehensible to users is, to me, not very important as they have no way to resolve it anyway. All they need to do is report it to the appropriate party. Anyone who is responsible for the back end should know what a (748) is, what can cause it, and how to address it.