Unless you have a valid use case you should avoid a share-lock like hell. It might have been "okay" in the late 1980s of the last century where you had a max. of 1 user connecting to the database ....
But, I have one valid use case:
I have processes running against our database which must only run once. If you use some flag - could be anything from a file touched in the OS to a logical in a database table - which is set by the process to detect that it is already running you are fine in most cases. Except when the process crashes and does not reset the flag. In such a case you need some other means to detect that the process is not running anymore and reset that flag manually.
For that I use a share-lock. When the process starts, it starts a transaction and attempts to grab a certain database record with an exclusive-lock. If it doesn't get it, it knows that an instance is already running and exits gracefully. If it does get it it immediately re-finds the record with a share-lock and leaves the transaction block. That means that there is no active transaction open which might cause all sorts of other issues, but - no other process can grab the record. And, if for some reason, the process crashes the database engine takes care about the share-lock in that it releases it automatically when the process that held the lock disappeared. So nobody needs to manually take care about a certain "flag".
To be honest, that's about the only valid uses case I've come up in all the years I've been working with Progress since 1991.