Yes, we allocate the maximum at startup and allow changing the parameter to control the number of _Checkpoint records in the VST.
> But the increasing (from 1 to 1024) the -numCheckpointStats through _DbParams increases the used shared memory by 160 bytes. It's a bit strange, isn't it?
Yes, that would be a bit strange. I don't believe the 160 bytes are from changing the parameter. Instead, those bytes are from the first assignment of the in memory user structure.
With a DB started with the defaults, the "Status: Shared Memory Segments" screen in promon shows X bytes in the used column. When I connect a self-service client, I see X+160 bytes in the used column for the only segment. When the client logs out, the used portion is still X+160. Login a new client that would take the same user number and the used column doesn't change. When I then change the -numCheckpointStats through _DbParams, the used column doesn't change. Do you see this behavior as well or are you also seeing the value change as a direct result of changing the parameter?
A bug has been entered to fix the typo.
> Do you see this behavior as well or are you also seeing the value change as a direct result of changing the parameter?
Kyle, you are correct. The used shared memory is increasing by 160 bytes every time when HWM of db connections is increasing by one. Changing the -numCheckpointStats through _DbParams does not change the used size of shared memory. I used the wrong sequence during the test: update _DbParams, then start promon to check the shared memory. New promon session has increased HWM of db connections. So _DbParams works as expected.
George Potemkin Thank you for maintaining this list.
We found another effect of the -zn parameter, maybe it's worth adding to the list.
-zn affects which data gets recorded by the profiler. Without -zn _procedures are not shown in the profiler data. With -zn those procedures do appear.
In 12.1 we found a bug that profiling recorded with -zn . see also community.progress.com/.../the_profiler_should_not_hide__procedures
> -zn affects which data gets recorded by the profiler. Without -zn _procedures are not shown in the profiler data. With -zn those procedures do appear.
It's true not only with profiler. For example, with a procedure trace reported by session:debug-lert = true. Without the -zp parameter the underscope sign ("_") has the special meaning at the begining of the table's and procedure's names. In some cases Progress excludes the procedures with the special names from listing. With -zn Progress will treat the _procedures as the ones with the ordinary names. It's an intentional behaviour me think.