The ABAPERLS subsystem comprises the AbaPerls system tables that keep track of installed subsystems and SQL objects. There are also a couple of stored procedures that goes with them, and one view which covers SQL Server's system tables.
If you do not install the ABAPERLS subsystem, you still have the table abainstallinfo that keeps track of executions of DBBUILD and update scripts generated by DBUPDGEN.
You install the ABAPERLS subsystem with DBBUILD. The subsystem does not require any certain settings of configuration options or macros, so you can set whichever settings you like for your database and let them apply to ABAPERLS too.
The tables serves different purposes. Some tables are internal help tables, others hold the configuration of subsystems and configuration-options and yet others are auditing tables for the DBA to review. It is perfecty legal to access the tables for reading data, but observe that there is no guarantee that your favourite queries will continue to work in a future version of AbaPerls, as the data model very well could be changed .
You may also have need to modify data in the tables, for one reason or another. Typical example is to modify a configuration setting for a subsystem or clean up abasysobjects. When performing such updates, you must be careful, and be confident that you have a full understanding of what you are doing.
Several of the stored procedures exists for the AbaPerls tool to call, whereas others are utility procedures for a user to use. All stored procedures are completely documented with parameters and result set.
Here and there in the table and column names, you will find the letter combination ss. This reflects AbaPerls SourceSafe-only origins. Whenever you see "ss" you should think "version-control".
Note: the database documentation was generated from PowerDesigner and further processed by the AbaPerls tool PDREP95. Therefore it has not been possible to include links to the remaining AbaPerls documentation in the object descriptions.