You can define applications and subapplications by using High-Level (HL) architecture members. HL architecture members allow you to categorize groups of related load modules, object modules, and other software.

You can maintain one HL architecture member to define an entire application for a project. This HL architecture member references other architecture members that eventually reference every component in the application. It can also reference the source directly, with the language of the source defining the outputs to be produced. By using this HL architecture definition as input to the build or Promote functions you can ensure that the entire application is up to date or is promoted to the next group in the project hierarchy. A build or promote of an HL architecture member results in the building or promotion of every software component referenced. In this way, you can guarantee the integrity of an entire application.

You can also use an HL architecture member to define subapplication software components. Subapplications can be a combination of load modules or merely a list of internal data items to be controlled. Subapplications can, in turn, reference other subapplications to any depth. Conscientious use of HL architecture members contributes to application modularity.

SCLM can control and track ISPF panels, skeletons, and messages that are not processed by a compiler or linkage editor or used to invoke processors. Because these unique forms of software are not processed by compilers, linkage editors, or other processors, they are considered data dependencies and, therefore, can be controlled by using the PROM statement.

In most cases, you do not want panel, skeleton, and message dependencies in LEC, CC, and generic architecture members. Use HL architecture members to control all dialog software. For example, you can use one HL architecture member for panels, one for skeletons, one for messages, and one for the entire dialog that references the three previous HL architecture members.

The PROM statement date_check parameter allows SCLM to bypass date checking for the referenced member, thereby eliminating the need to build before promoting when that member is modified. Careful use of the PROM statement in this manner can eliminate unnecessary SCLM processing and improve efficiency.