Common Uses of Database Procedures

Writing Database Procedures › Common Uses of Database Procedures

Common Uses of Database Procedures

Compression and Decompression

Data compression replaces repeating characters (most frequently blanks and binary zeros) and common character combinations with codes that decrease the amount of data stored in the database. Data decompression returns compressed data to its original form for use by an application program. A compression procedure (IDMSCOMP) and a decompression procedure (IDMSDCOM) are provided with CA IDMS/DB in source and object form.

The IDMSCOMP database procedure compresses record occurrences before storage, as follows:

Converts repeating blanks into a 2-byte code
Converts repeating binary zeros into a 2-byte code
Converts other repeating characters into a 3-byte code
Converts a number of commonly used character pairs into a 1-byte code

Data that does not fall into any of the above categories remains as is. Each group of as-is data is prefixed by a 2-byte length code.

CA IDMS/DB decompresses records after retrieval through the IDMSDCOM database procedure. These procedures are invoked automatically by CA IDMS/DB if you have coded the appropriate CALL parameters in the schema RECORD and AREA definitions.

Note: You can also use CA IDMS Presspack to compress data. For more information, see the CA IDMS Presspack User Guide.

Data Validation

Data validation involves checking data being stored to ensure that items :

Are alphabetic or numeric
Fall in user-specified ranges
Are equal to specific values

If an item fails the check, the procedure can disallow storage of the record.

Privacy/Security

You can use database procedures to perform the following privacy/security functions:

Encoding/decoding data to ensure physical data security
Prohibiting programs from reading restricted data (record-occurrence level)
Requiring passwords for access to restricted data (area level)
Restricting use of a qualified ERASE DML command

Data Collection

Data collection procedures accumulate statistics and other information from areas and records being accessed.

Record Length for Variable-Length Native VSAM Records

Use the IDMSNVLR database procedure, provided with CA IDMS to transmit the length of a native VSAM variable-length record from an application program to the DBMS before a STORE or MODIFY DML command, and from the DBMS to the program after a GET DML command. The IDMSNVLR procedure is intended for use by programs accessing native VSAM variable-length records that do not contain an OCCURS-DEPENDING-ON field. IDMSNVLR allows the length to be communicated in the record's DBA-DEFINED-RDW (RECORD-DESCRIPTOR-WORD).

To use IDMSNVLR, the schema record description must provide for a standard DBA-DEFINED-RDW field (two-byte field plus two bytes of filler) as the last field in the record. The schema record description must be defined as follows:

     record description.
         record name is record-name
         record id is record-id
         location mode is ...

         call idmsnvlr before store.
         call idmsvnlr before modify.
         call idmsvnlr after get.

         03  ...

         03  dba-defined-rdw
             comment 'this word is not maintained in the database.'
             05 rdw-len          pic S9(4) comp.
             05 filler           pic XX.

The DBA-DEFINED-RDW is not part of the physical record stored in the database. Before a STORE or MODIFY DML command is executed, IDMSNVLR strips off the DBA-DEFINED-RDW (the last four bytes of the record) by specifying RDW-LEN minus 4 as the record length. The DBA-DEFINED-RDW always includes the length of the DBA-DEFINED-RDW itself.

Before issuing a STORE or MODIFY DML command, the application program must move the length of the variable-length record (since that record was defined in the subschema) into the RDW-LEN. IDMSNVLR passes this value (minus 4) to the DBMS. After a GET DML command, IDMSNVLR returns the length of the subschema view of the record in the RDW-LEN field.

Although the schema description must specify the DBA-DEFINED-RDW as the last field of the record, the subschema description can specify the DBA-DEFINED-RDW as the first field of the record.