SysWorks® Developer

SysWorks® Developer builds software applications and products for OpenVMS Alpha and VAX. It also manages sources for multiple versions and environments such as development and maintenance.

Briefly, SysWorks® generates MMS scripts and invokes MMS to build software. It extends CMS by providing enhanced use of classes and a rules based system for migrating sources to provide the version and environment contexts.

SysWorks® Developer is useful for almost all OpenVMS software development and maintenance tasks. It is especially useful for:

• New application development;
• Legacy application maintenance;
• VAX to Alpha migration;
• TDMS to DECforms migration;
• Year 2000 tidying/rebuilds;
• Porting software to OpenVMS;

SysWorks® Developer is based on the existing DECset products. It uses CMS to manage sources and MMS to build software.

A working knowledge of CMS and MMS by at least one team member is desirable. SysWorks® extends the functionality of CMS so that developers use single commands to perform a single function. Extra activities such as inserting a generation into a class are performed automatically. A fuller understanding of CMS classes and generations is useful when trying to understand what SysWorks® is doing.

Almost all OpenVMS development products from Digital and Oracle are supported. This includes most traditional programming languages (Ada, Basic, C, C++, Cobol, Fortran, Macro, Pascal, PL/1 and UIL) and products such as ACA Services, ACMS, CDD, DECdocument, DECforms, ObjectBroker, Rdb, Runoff, RTR and TDMS. For a complete list, please read the SysWorks® Developer Software Product Description (SPD).

SysWorks® documentation is divided into reference manuals and how-to guides.

• The reference manuals describe the actions, qualifiers and/or arguments for the various DCL commands and callable routines.
• The how-to guides describes techniques for using SysWorks® to perform typical development and maintenance tasks such as setting up an application environment, how to manage shareable images or language usage requirements.

All SysWorks® manuals are provided in Bookreader, HTML, PDF and PostScript forms. Reference information is also available using online help.The latest versions of the manuals are progressivly being put on-line at this web site.

A BUILD command is provided which executes in several phases. Each phase performs a task such as updating the working directory with the latest sources from a CMS library, analysing the source for dependencies to generate MMS scripts or using MMS to build the final software.

The list of phases can be extended to include activities such as generating sources based around database tables.

Yes. Concurrent development for both platforms is achieved using architecture specific directories for files such as objects and executables and common directories for sources and documentation.

Shareable images can be driven from a simple Macro-32 source containing vector statements. This source is used directly with OpenVMS VAX. SysWorks® converts the source into a linker options file for use with OpenVMS Alpha.

Sources which are specific to a single architecture are identified using a suffix on the source name. A common use of this feature is for complex Linker options files which use a different syntax on Alpha versus VAX.

A combined build may be used in which all phases are executed on an Alpha node and only a subset of phases are executed on a VAX node.

Yes. By default, all builds are incremental. Only new sources are analysed for dependencies. This results in faster incremental builds compared to products which need to analyse all sources as part of a build.

Yes. By using the /FROM_SOURCES qualifier, an additional phase is used at the start of the build which deletes files from the application directory structures. This forces the subsequent phases to fetch each source from the CMS library, compile them and link or otherwise build new versions of software.

SysWorks® uses a number of techniques to improve build performance. These include:

• A separate algorithm to fetch the latest CMS generations into the working directory in a distinct phase. This is faster than using MMS to fetch a source before compiling it;
• Sources are analysed individually for dependencies. Only sources which have been changed are analysed in an incremental build;
• A kept sub-process is used to define objects in a CDD repository. This reduces the number of binds to one and can reduce build elapsed time by up to 80%;
• Tag files are used to represent CDD objects. This reduces the need for MMS to access the CDD;

SysWorks® uses Linker options files as the source for an image. For existing applications which simply link certain objects to create images, a utility is provided to generate an options file for each such image.

Normally a single CMS library is used. Each environment and version is based around a class within the library. For heavy use environments such as development, a separate CMS library may be used.

When source generations are migrated between environments or marked for release, appropriate actions are taken. Within a CMS library this may mean updating a class. Where multiple CMS libraries are used, this may mean copying the source from one library to another.

Each application environment exists as a SysWorks® context. These contexts consist of a set of structures such as a logical name table, logical names within that table, a set of directories, certain specific DCL procedures and a CMS library. They are similar to but more comprehensive than DECset contexts.

Site wide naming conventions can be established for context structures such as logical name formats and directory names. Individual applications can use the context management DCL procedures to change the standard context by defining extra directories or using different names for them.

A DCL command is provided to move between contexts. This command creates the application logical name table if necessary and executes the context management procedures.

SysWorks® supports multiple environments for developing, testing and maintaining applications. The default configuration uses six application environments. These are:

1. Application Common which contains the common CMS library and release kits;
2. Development where raw application development is undertaken;
3. Development Testing where newly developed versions are tested and kits are released from;
4. Maintenance where existing versions of an application have bugs fixed and minor enhancements made;
5. Maintenance Testing where the bug fixes and minor enhancements are tested and where updates are released from;
6. Production where released kits and updates are installed and used;

Individual sites can use any combination of these environments or add extra ones as required. For example, a site may not specifically use the SysWorks® production environment.

Version management tools provide functions to move sources between environments and rebuild the software. They are also used to formally release a version or update.

For applications or products which need to maintain multiple versions concurrently, SysWorks® subdivides the maintenance environments into separate version based areas.

Migration always occurs to the same version eg. V1.2 in maintenance would be migrated to V1.2 in maintenance testing.

The latest version being maintained is the default version within a maintenance environment.

Developers working within an application environment can use a single common area or may use developer specific areas. If the common area is used, each developer sees the latest compiled changes of other developers.

If the specific area is used, developers have a set of sub-directories in which their builds take place. Each directory based logical becomes a search list so that the developer sees their own sources and objects first and then those in the common area.

A two stage replace is used with sources such that a developers changes are not seen by others until they are explicitly promoted back into the common area. This is achieved by extending CMS to support a search list of classes.

Yes. There are two ways of managing sub-projects.

Applications may have relationships with other applications. This allows a parent or utility application to be used by subordinate applications. One way of managing sub-projects is to use this feature.

The other way is to use application variants within an environment. This is similar to the common/specific areas mentioned before. When working within a particular variant, a developer sees the sources, objects, executables etc associated with the variant and then those in the common area. The variant model may be combined with the common/specific model.

The main report indicates which generations are in which environment and version. It highlights inconsistencies within the generation hierarchy such as a source in a maintenance environment being older than that in the release which is being maintained.

Yes. It can automatically create a VMSINSTAL kit. Template KITINSTAL.COM procedures are provided. More complex kits can be built by providing a KITBLD.COM procedure which defines which directories and/or files should be placed in which savesets.

A Run-Time Library of utility functions is used by SysWorks® products to log error messages and crash dumps etc.

This RTL can also be used by applications. The interfaces to these functions are specified in a the SysWorks® Callable Routines Reference Manual.

No. SysWorks® Developer is only required on development and maintenance nodes.

If an application uses the SysWorks® Run-Time Library, at least SysWorks® Base needs to be installed on production nodes.

Many utilities and tools are provided with SysWorks® Developer. Some of the more useful include:

• Extensions to CMS to reserve sources from a list such as output from a SEARCH/WINDOW="0" command;
• A search and replace utility available from the DCL command line;
• Enhanced CMS functionality available to LSEDIT and even callable CMS;
• Enhanced EDIT command which can use a kept sub-process editor or directly feed a DECwindows LSEDIT session.

SysWorks® provides the following products:

• SysWorks® Administrator - an OpenVMS system management toolset including automated user registration and application environment setup;
• SysWorks® Base - a production RTL - included with all SysWorks® products;
• SysWorks® Example Application - included with SysWorks® Developer;
• SysWorks® Public Domain Utilities - included with all SysWorks® products;

SysWorks® can provide loan licenses and direct sales of SysWorks® Developer.

SysWorks® can also provide a number of related services. These include:

• Installation and configuration;
• Training in the use of SysWorks® products;
• Migration of existing applications to use SysWorks®;
• General OpenVMS development and maintenance work;

SysWorks® also provides an enhancement service for products not yet supported by SysWorks® Developer.