Below is a list of ProTop installation and configuration issues that we come across regularly. If your issue isn't here, please contact us at firstname.lastname@example.org for assistance.
Wrong ProTop Download
If you download a src-code version of ProTop then you need a license that can compile code, such as a "4GL Development" license. Use $DLC/bin/showcfg (or type showcfg from with a Proenv shell on Windows) to display the contents of the OpenEdge license file. If you only have an "Enterprise Database" license, or similar, than you need to download r-code (object code) for your version of OpenEdge.
ProTop is information dense and thus requires a minimum 160 column X 48 row terminal window. The larger screen allows you to see multiple panels of correlated information simultaneously, one of the biggest strengths of ProTop. If you try to run ProTop on an old VT100 80X25 screen, it simply is not going to work. Use putty or a similar xterm-type terminal emulator. You can get putty here.
By default, ProTop expects a light-colored background on which it will paint contrasting text. If your terminal has a dark background then try the Color Picker and select Dark Mode.
Keyboard and Function Key Mapping
This issue has plagues ChUI applications since the dawn of time! While most ProTop screens don't require any special function keys, occasionally you will need to save or confirm an action through a GO, typically the F1 key. If that doesn't work, try Ctrl-X. Similarly, END-ERROR is usually mapped to the F4 key, but you can try Ctrl-E if F4 doesn't work.
On UNIX/Linux, the Progress character client needs to know what kind of terminal you are using to correctly paint the screen, but some terminal emulators use custom values for the TERM variable. Example:
Unable to use your terminal. Check your PROTERMCAP file. (443)
** Could not find terminal type xterm-256colour in file /opt/protop/etc/protermcap.protop.Linux. (146)
Try plain xterm instead:
or download putty here.
On both Windows and UNIX, the user running ProTop must have adequate permissions to open database files and shared memory segments.
On Windows, this often comes as a result of running the OpenEdge AdminService using the SYSTEM account, whereas the user running ProTop is a regular user. You can try running ProTop as administrator or otherwise giving the user the appropriate permissions.
On UNIX, you'll likely see an "errno=13" message: that is your clear indication that there is a permissions issue somewhere. The OpenEdge client executable $DLC/bin/_progres is supposed to be owned by root and have the setuid bit set, but that is not always the case. Check by running the following command:
[/opt/protop] $ ls -al $DLC/bin/_progres
-rwsr-xr-x 1 root root 13811949 Oct 10 2018 /usr/dlc117/bin/_progres
The "s" in "-rwsr-xr-x" is the setuid bit, meaning that the executable runs as the owner, in this case root. Don't worry - this is not a security flaw. The process runs as root only during the initialization phase, after which it downgrades its permissions to those of the user running the process.
The ProTop agent connects to your database in order to gather statistics and upload them to the web portal. This means that if you attempt to make a dictionary change without selecting "Add objects online", the pt3agent could block the change. Read the Dictionary Changes guide on how to prevent this.
ProTop Service Paused on Windows
When stopping and starting the ProTop service on Windows, occasionally a file access conflict occurs and the service pauses. In this case, first delete all flg files in %PROTOP%\tmp, wait 30 seconds, then stop the Windows Service. You can then immediately restart the service. It will start normally and you will see the dbmonitor.flg flag appear, then pt3agen.*.flg files appear as the pt3agent processes start.
No pt3agents Running
This one is a little tricky because there could be many reasons. Go through these steps to find and fix the root cause:
Start the ProTop Real-Time Monitor using the friendly name as defined in $PROTOP/etc/dblist.cfg. See Starting the Real-Time Monitor. Make sure the Real-Time Monitor works before trying to get the agent to work.
Are you sure the pt3agent is not running? Check "ps -ef | grep pt3agent" on UNIX or Task Manager on Windows to be certain.
Is the DBMonitor running? The DBMonitor reads $PROTOP/etc/dblist.cfg and starts pt3agents for any database that has Monitor=yes.
Check if Monitor = yes in $PROTOP/etc/dblist.cfg. For example:
Check if there is a flag file $PROTOP/tmp/pt3agent.friendlyName.flg. This file is created when the pt3agent starts and its removal will normally cause the pt3agent to exit gracefully.
Check the agent log file in $PROTOP/log/pt3agent.friendlyName.log for any errors.
Check the error and debug files in $PROTOP/tmp/pt3agent.friendlyName.
On Windows, compare the user that starts the ProTop service and the user that starts the OpenEdge AdminService. The ProTop user may not have the necessary permissions
No Data in the Web Portal
This is almost always a web proxy issue. From the prompt, execute the following curl command. It should immediately return "test passed". Note: substitute the correct web portal if you're not trying to connect to demo.wss.com in North America.
$ curl --connect-timeout 5 demo.wss.com/proxy.test
If instead, you see the following, then you cannot reach the web portal from your database server:
$ curl --connect-timeout 10 demo.wss.com/proxy.test
curl: (28) Connection timed out after 10000 milliseconds
Ask your network adminitrator if you need to use a proxy, then try again with the proxy information:
$ curl --connect-timeout 10 --proxy proxyhost:8888 demo.wss.com/proxy.test
NOTE": Curl is normally installed on all Linux servers. On Windows, you can find it in %PROTOP%\ubin. If you do not have curl execute the following OpenEdge program:
cd $PROTOP _progres -p util/webget.p
If this test fails when using the demo.wss.com url, try using its ip address: 188.8.131.52. If that works then add this line to your respective host file:
For Windows place this line in:
For Unix add it to:
Blank Userid Not Permitted
If you get the error message "DB connection with blank userid not permitted", add -U and -P to one of the PF files described in protopenv.
Is ProTop telling you that you have no more empty AI extents when you clearly do? Or is it incorrectly stating that you're running in no-integrity mode? Chances are that you upgraded OpenEdge versions without running Update VST. ProTop expects to find information in the VSTs, based on your version of OpenEdge, but that information isn't there. Fix it by running the following command, substituting your full DB path for "DB":
_proutil DB -C updatevst
Missing Table and/or Index Statistics
If your -basetable, -tablerangesize, -baseindex and/or -indexrangesize parameters are insufficient, there will be tables and/or indexes whose statistics will not be gathered by the associated data collector and therefore not display in the Real-Time Monitor nor uploaded to the web portal. You can check this by running the Real-Time Monitor and checking the (T)able and Index Range Info screen.
Bonus: if your values are insufficient, the (T) screen will appear automatically at startup, but you should check them anyways as the values may be sufficient but not optimal.
No DB Analysis
ProTop provides much more meaningful information if it has a recent DB Analysis avaiable to it. If you start the Real-Time Monitor and see the following warning, please run DB Analysis and copy the output file to $PROTOP/dbanalys/friendlyName.tba:
You can run DB Analysis from within ProTop by hitting the "!" key (see the Help Page). This can be quite disk intensive so you may not want to run DB Analysis while the system is busy:
If you see this error message in the Web Portal, ProTop does not have access to the curl command for downloading configuration updates. In this case, configure ProTop to use 4GL sockets instead of the curl command. To do this, set PTDLCMD=http in $PROTOP/bin/localenv or %PROTOP%\bin\localenv.bat. See the localenv configuration page for more information.