so what is a session? a broker? does a session use the broker? please help me understand, the docs say a broker is required to connect to the databases.
Part of the challenge of learning about the Progress database is navigating the sea of confusing terminology, and inconsistent usage thereof. You might hear people say that they are "starting the database", "starting the database broker", or "opening the database". While one might argue the degrees of correctness, they all mean the same thing. Over time you pick up the lingo and figure out what people mean from context if they speak ambiguously.
An offline database can be opened in one of two modes: single-user or multi-user. Single-user is self-explanatory: a client opens the database and has exclusive access to it. Therefore it has no need of brokers, servers, or shared memory. A database is opened in multi-user mode by a broker, which performs a variety of functions that you can read about in the docs (Database Essentials and Database Administration). One of these is to spawn servers which remote clients can connect to. The broker that opens the database is referred to as the primary broker. Other (secondary) brokers may also be started, for various reasons. Often brokers are assigned a particular server type (via the -ServerType startup parameter), meaning they will only spawn servers of the specified type; this is recommended. For example, a database that will server both 4GL and SQL clients may have a primary broker started with "-ServerType 4GL" and a secondary broker started with "-m3 -ServerType SQL". The -m3 parameter identifies the broker as a secondary broker. Every broker is assigned a unique TCP port number on which it listens for incoming connections from clients. This is specified with the -S parameter. Brokers are started with the "proserve" shell script/batch file.
Clients come in two types: 4GL (aka ABL; native Progress clients) and SQL. SQL clients always connect to a SQL server (not to be confused with Microsoft SQL Server!), and they always connect via TCP. They use a protocol like ODBC, JDBC, or eSQL. 4GL clients on a remote machine (i.e. not the database server) always connect to a 4GL server and always connect via TCP. 4GL clients run on the database server machine may connect in one of two ways: via TCP to a 4GL server, or they may attach to directly to "shared memory", the segment(s) of application memory allocated by the primary broker when it first opened the database in multi-user mode. In the latter case, the client does not connect to a broker or a server. It maps the shared memory segments into its own process virtual memory address space and acts as its own server to process database requests (queries, updates, etc.). If a 4GL client running on the database server has a "-S <port number>" startup parameter then it is connecting via TCP; if it does not, it is connecting via shared memory. This will also be reflected by its entry in the user list in promon screen 1 | 1 (user list); shared-memory (aka "self-service") clients are shown with user type "SELF" and remote (TCP) clients are shown with user type "REMC".
Remote clients (4GL or SQL) connect to the appropriate broker by specifying that broker's port number with the -S parameter. So if your database has a 4GL and a SQL broker, and the 4GL broker was started with -S 5001 and the SQL broker was started with -S 5002, then a connecting 4GL client would specify -S 5001 in its command line, whereas a SQL client would specify -S 5002. Service names can also be used in place of port numbers, if you defined them in your server and client machines' services files. When the client connects to the broker it is given the port number of a server. It then disconnects from the broker and connects to the server on that port and remains connected until it shuts down, chooses to disconnect, or loses its network connection (and shuts down). The client process is also referred to, at the application level, as a client "session".
OpenEdge brokers, servers, and clients can have their runtime characteristics altered with startup parameters. A full list of them is in the Startup Command and Parameter Reference manual. They are broken down into categories, as some apply only to specific processes such as clients, servers, brokers, etc. Some apply to only a subset of these such as 4GL clients, SQL clients, primary brokers, etc. Some startup parameters are particular to one category and some apply more than one. Parameters can be specified directly in the command line of a process or they can be grouped together into a parameter file (somename.pf) which is referenced in the command line with the -pf parameter, e.g. proserve
<dbname> -pf
<params.pf>. A few parameters cannot be put into a .pf.
I have a 4gl broker and manually start a SQL broker. can the second broker be automatically started? if so what scripts are needed.
Yes. You just need a script that does something like the following:
Code:
# conceptual example only
proserve mydb -pf my4glparams.pf # 4GL broker
proserve mydb -pf mysqlparams.pf # SQL broker
where "my4glparams.pf" contains the parameters you want to use for your 4GL broker (e.g. -S, -ServerType, etc.), and "mysqlparams.pf" contains your SQL broker params (e.g. -S, -ServerType, -m3, etc.). Your primary broker's .pf may contain params that pertain to the DB as a whole (e.g. -n, -Mn, -B, -bibufs, -aibufs, etc.) that will not be in your secondary broker's .pf.
does this start the database?:
/usr/dlc/bin/proserve -pf /databases/tst/db/esop.pf
this is what is in our start-up script.
It does, although you have a mix of database and client parameters in your .pf file; the client params will be ignored. Move those to a separate .pf that you invoke in your client shell script/shortcut.
)
