Progress DB 4GL/SQL start/stop

javadevloper

New Member
I have a question regarding progress database using 4GL and SQL connections.

-We are wanting to have a progress database running that allows 4GL and SQL connections.
-Occasionally, we want to stop the service listening for 4GL connections (to kick off and prevent users that use a GUI that connects thru 4GL from connecting)...BUT, keep the SQL up and running.
- then have the capability to start 4GL connections again.


Does this make sense? Is this possible?
 

javadevloper

New Member
Ok so would it be something like this:
proserve dbname -S prod4GL -H myhost -Mn 10 -Mpb 4 -ServerType 4GL​
proserve dbname -S prodSQL -H myhost -Mpb 4 -m3 -ServerType SQL

And then to shut down 4GL:
proshut dbname -S prod4GL -H myhost -by

1) This seem correct?
2) And SQL will still be running smoothly?
3) To start 4GL back up, would we re-issue command:
proserve dbname -S prod4GL -H myhost -Mn 10 -Mpb 4 -ServerType 4GL

4) My work is currently using Progress Explorer to manage these similar settings. And, they are using batch files to call the commands: proshut, dbman -stop, dbman -start...etc
Would the above still work the same in Progress Explorer with these commands?​

 

gerie

Member
It's actually rather simple if you use the explorer. You can make two connections, the first for 4GL and the second for SQL and you can stop and start them independit from each other.
 

javadevloper

New Member
In Progress Explorer, we have a database 'PROD' with 2 connections (1 for 4GL and 1 for SQL).

What would the command-line command be to stop the 4GL service only (leave SQL running)?
call dbman -stop -db prod (closes both 4GL and SQL)
 

RealHeavyDude

Well-Known Member
You have set two distinct server groups in the Progress Exploder. From the database point of view these are called login brokers. There is always one primary login broker (that is the first one started) and all others are secondary login brokers. The primary login broker manages the shared memory resources and if you stop that broker all secondary login brokers are stopped too. In other words you can start secondary login brokers individually but you cannot stop the primary login broker and having the secondary login brokers running. Plus you can't stop a secondary login broker individually - you shut down the database and all login brokers will be stopped.

Heavy Regards, RealHeavyDude.
 

javadevloper

New Member
We have two server groups:
[configuration.prod.defaultconfiguration]
database=prod
displayname=defaultConfiguration
servergroups=prod.defaultconfiguration.prodsql, prod.defaultconfiguration.prod4gl]

So, you are saying that we can't stop/start 4GL without affecting the SQL?
 

RealHeavyDude

Well-Known Member
Exactly. You can't stop individual login brokers.

What is the reason why you want to start/stop login brokers individually?

Heavy Regards, RealHeavyDude.
 

javadevloper

New Member
Most users connect using 4GL clients. And we have some programs that connect using SQL (that we want to be highly available with no downtime). But, occasionally we want to prevent typical users from connecting thru 4GL. (but, everytime we stop that broker, it also kills SQL connections).

I would think since you have startup parameters for 4GL and SQL, that you could start/stop them independently without affecting each other.

Have any suggestions on any form of a solution?
 

tamhas

ProgressTalk.com Sponsor
If all you are trying to do is prevent ABL users from logging in, there are a bunch of different ways without bringing down the broker. Years and years ago I used to use what I called a maintenance lock, which was just a file in the file system which could be created from a menu option in the scripts we used to manage the database. The user scripts checked for the existence of this file. If it was present and the user was a "regular" one, it told them about the lock and exited. If the user was one of a short list of "special" users, then it would advise and ask if one wanted to continue. This allowed us to lock out regular users and yet allow "super" users to do maintenance work. It helps to have some kind of broadcast system and one may have to run around getting the workaholics out of the database who have been in there all day ... but then one doesn't really want to rip the broker out from under people either. One could easily build this into the application too, but we didn't because we wanted it to work at times when there was no server running, e.g., around backups and such. Piece of cake, really.
 
Top