Design: I chose to create 1 PCF table, and put it into the COMMON tablespace. Reasons: simple (fewer objects to manage, fewer points-of- failure, simpler to perform daily checks, simpler EXECs, easier maint- enance for Those Who Come After (espec when adding a component later).
Note that coding to insert, update, delete rows in a DB2 table is vastly simpler than the equiv for ISPF tables or flat files! Disadvantages: if you lose the COMMON tablespace, you're stuffed anyway, so there's no difference from any other solution.
LATER: experience shows that DB2 LOAD flattens EVERY table in a tablespace, not just the one you are aiming at! Since the ZZZUSER table (27K entries, filled by LOAD from batch) was also in SCOM, the PCF table got flattened too!. Disconcerting until we found out why (I thought I'd run PCFDEL without noticing...how in hell did I do that?). Thus it turns out that the right solution is for the ROYUSER table to have its own tspace. Quick to fix if you've done it before.
--more-- The PCFLOG exec registers a log dataset from inside a jobstep by entering the dataset on the DRLLOG DDname into the PCF table. This is how SLR PCF worked. My extension PCFREG exec looks up in the MVS catalog using a pattern of the dataset name, and registers all logs that haven't been collected.
--more more -- EPDM R2 introduces 'Log Data Manager option', which is PCF made confusing (In My Humble Opinion).