Using different CPF files

During startup a Caché/Ensemble/HealthShare instance must consult a parameter file to get some information it needs at the early stages of startup. By default it uses the file called cache.cpf, but by adding an extra argument to the ccontrol start command you can make it use an alternative file.

One scenario where this might be useful is if you need to start an ECP data server in a mode that prevents application servers from connecting to it.  Copy your cache.cpf file into one called, say, noecp.cpf and edit that file with any text editor, changing the MaxServerConn value in the [config] section to 0. Then stop your Cache instance (named CACHE in this example) and restart it so it uses the alternative CPF file: ccontrol start CACHE /full/path/to/noecp.cpf

More documentation about CPFs is available here.

If you make use of alternative CPFs please add a comment below to describe your use-case.

  • + 1
  • 0
  • 272
  • 2

Comments

Starting containers with a different configuration... say you're moving a container from within your CI/CD provisioning process and finally you deploy it in production you'll want to tune your system differently (more buffers etc.).

It's the same artefact you use across your software factory; you just tune it accordingly to its needs and environment and in so doing adhere to the 12-factor app principles... :)

HTH

if you need to start an ECP data server in a mode that prevents application servers from connecting to it

For such cases we implemented a facility which stops all users' sessions and disables new logons ECP-wide (on application level). Our aim was to prevent extra Caché restarts on data servers by any price, as each restart means loosing the global cache and slowing down of many app functions for ~1 hour or even longer.

Without this facility maybe I'd choose to temporarily stop %Service_ECP.