| Previous | Contents | Index |
[V2.4-3]
The new appl_CMS_GROUP logical name in the application logical
name table is used to control access to an applications common CMS
library.
2.7.6 appl_CMS_PATH
[V2.6]
The appl_CMS_PATH logical name now supports a search list of generations. It must also be used in place of the appl_CMS_CLASS and appl_CMS_GENERATION logical name.
During the transition from V2.5-2 to V2.6 of SysWorks, it is possible to have both the appl_CMS_CLASS or appl_CMS_GENERATION logicals names defined at the same time as appl_CMS_PATH. This allows applications to change their LOGICALS.COM before V2.6 installation, and still work immediately afterwards.
To do this the folowing steps must be performed:
$ CMS INSERT GEN *.*/GEN=1+ FIN_DEV "Ready for V2.6" |
$ CMS CREATE CLASS FIN_DEV_JONES_AB "Ready for V2.6" |
[V2.4-3]
The new appl_CMS_VARIANT logical name in the application
logical name table is used to control access to an applications common
CMS library.
2.7.8 envr_DEVELOPER_STYLE
[V2.4-3]
The meaning of the envr_DEVELOPER_STYLE logical name has been
changed. The values of COMMON and SPECIFIC no indicate the default
entry scope when an APPLICATION or ENVIRONMENT command is used.
2.7.9 appl_GROUPS
[V2.4-3]
The new appl_GROUPS logical name in the application logical
name table is used to place ACMS task group definitions in a specific
dictionary directory rather than CDD$DEFAULT.
2.7.10 appl_MENUS
[V2.4-3]
The new appl_MENUS logical name in the application logical
name table is used to place ACMS menu definitions in a specific
dictionary directory rather than CDD$DEFAULT.
2.7.11 appl_MSGHLP_LIB
[V2.4-3]
The new appl_MSGHLP_LIB logical name in the application
logical name table is used to identify the HELP/MESSAGE data file used
by the application (if any).
2.7.12 appl_TASKS
[V2.4-3]
The new appl_TASKS logical name in the application logical
name table is used to place ACMS task definitions in a specific
dictionary directory rather than CDD$DEFAULT.
2.7.13 appl_TDMS_REPLACE
[V2.4-3]
The new appl_TDMS_REPLACE logical name in the application
logical name table is used to indicate that TDMS sources (i.e. request
and request library definitions) contain RDU utility commands such as
create or replace, and that SysWorks should not issue these commands.
By default, SysWorks issues these commands.
2.7.14 SWDEV_DEVELOPER_STYLE
[V2.4-3]
This logical name defines the default entry scope used when a developer
enters an application environment with the APPLICATION or ENVIRONMENT
commands. It is overridden by the appl_DEVELOPER_STYLE logical
name when that is present (eg. defined in an application's LOGICAL.COM
procedure).
2.7.15 SWRK_ENVR_envr
[V2.5-1]
The SWRK_ENVR_WRK_envr and SWRK_ENVR_VACL_envr logical names in the LNM_SWRK_DATABASE logical name table have been superceded by the SWRK_ENVR_envr logical names which contain all the information about an environment. For public level installations of SysWorks, these logical names are usually defined in the site specific pre startup procedure SWRK_LCL_DIR:site_PRE_STARTUP.COM which should be changed to reflect the new logical names.
The following DCL commands illustrates how one of these logical names might be defined:
$ DEFDAT := DEFINE/TABLE=LNM_swrk_DATABASE $ DEFDAT SWRK_ENVR_DEV "SCOP=SPECIFIC\WORK=1\VACL=0\VRNT=0\VRSN=0" |
Note that the equivalence must be in uppercase and inside quotes. The five properties have the following meanings:
| Property | Value | Meaning |
|---|---|---|
| SCOP | COMMON | Only the common scope is supported |
| SPECIFIC | Both command and specific scopes are supported | |
| WORK | 0 | No work directories are supported |
| 1 | Work directories are supported | |
| VACL | 0 | CMS variants should not be used |
| 1 | CMS variants should be used | |
| VRNT | 0 | No multi-variant support |
| 1 | Multi-variant support | |
| VRSN | 0 | No multi-version support |
| 1 | Multi-version support |
The following are the standard defaults:
| Environment | Properties |
|---|---|
| APPL | SCOP=COMMON\WORK=0\VACL=0\VRNT=0\VRSN=0 |
| DEV | SCOP=SPECIFIC\WORK=1\VACL=0\VRNT=1\VRSN=0 |
| DTST | SCOP=COMMON\WORK=1\VACL=0\VRNT=1\VRSN=0 |
| FDEV | SCOP=SPECIFIC\WORK=1\VACL=0\VRNT=1\VRSN=0 |
| MNT | SCOP=SPECIFIC\WORK=1\VACL=1\VRNT=0\VRSN=1 |
| MTST | SCOP=COMMON\WORK=1\VACL=1\VRNT=0\VRSN=1 |
| PROD | SCOP=COMMON\WORK=0\VACL=0\VRNT=0\VRSN=0 |
| TRNG | SCOP=COMMON\WORK=0\VACL=0\VRNT=0\VRSN=0 |
Note that if ACMS is present on a computer node, the scope property is
overridden to be common, since ACMS cannot support the SPECIFIC scope
context.
2.7.16 SWRK_ENVR_VACL_envr
[V2.5-1]
The SWRK_ENVR_VACL_envr logical name has been superceded by the SWRK_ENVR_envr logical name.
[V2.4-3]
Revised SWRK_ENVR_VACL_envr logical name (in the
LNM_SWRK_DATABASE logical name table for non-private installation
levels) is used to specify CMS variant class control flags. If this
logical has a true value, the generations in the application
environments CMS class must be variants.
2.7.17 SWRK_ENVR_WRK_envr
[V2.5-1]
The SWRK_ENVR_WRK_envr logical name has been superceded by the SWRK_ENVR_envr logical name.
[V2.5]
New SWRK_ENVR_WRK_envr logical name to control which
environments should have work areas. This logical name should be placed
in the LNM_swrk_DATABASE logical name table, which will be system wide
when SysWorks is installed at or above the public installation level.
For sites which install SysWorks at or below the public level, this
logical name should be defined in the site specific SysWorks pre
startup command procedure.
2.7.18 SWRK_UTILITY_LOGICALS_SCOPE
[V2.5-1]
This logical name has an equivalence of SYSTEM or USER and controls
where the utility logical names supported in SysWorks are defined.
2.7.19 SQL$USER and LNK$LIBRARY_nn
[V2.6-1]
The SQL$USER logical name is no longer defined as a LNK$LIBRARY_nn logical name. This is to allow the use of multi-variant DEC Rdb and part of a trend away from using LNK$LIBRARY_nn logical names. In order to use the SQL$USER object library, each the Linker option file for each image shich uses SQL should include a line such as:
sql$user/library |
Regarding the trend away from LNK$LIBRARY_nn logical names, application Linker options files should include a line similar to the above for each library they need to link against. It is recommened that each library be represented by a logical name.
The preferred SysWorks format for such logical names include the following:
| Logical Name | Equivalence | Usage |
|---|---|---|
| appl_HELP_LIB | appl_DOC_DIR: applHLP.HLB | Application help library |
| appl_IMAGE_LIB | appl_SFT_DIR: applIMG.OLB | Application shareable image library |
| appl_OBJECT_LIB | appl_LIB_DIR: applOBJ.OLB | Application object library |
| appl_SYMBOL_LIB | appl_LIB_DIR: applSYM.OLB | Application symbol library (if separate from the object library) |
| appl_TEXT_LIB or appl_COPY_LIB | appl_LIB_DIR: applTXT.TLB | Application Cobol, DECforms and/or Fortran include library |
The following routines were provided as part of SysWorks as a public
interface into the SWRKSHR shareable image.
2.8.1 SWRK_BINARY_SEARCH
[V3.2]
This routine searches an ordered table of keywords using a binary
algorithm.
2.8.2 SWRK_CLOSE_OUTPUT
[V2.6-1]
This routine closes the SysWorks standard output stream.
2.8.3 SWRK_DISPLAY_HELP
[V3.2]
This routine displays OpenVMS help.
2.8.4 SWRK_DUMP_IMAGE_INFO
[V2.6]
This routine dumps an image list and frame analysis. It takes one
argument which is the address of an outout callback routine. If this
routine is not present, the output is directed to SYS$OUTPUT.
2.8.5 SWRK_ESTABLISH
[V2.6]
This routine established the SysWorks exception handler. Its behaviour
changes depending on the execution mode of the caller, or whether the
caller was within the main image or an executable image. If the
debugger is present, no exception handler is established, since it is
assumed that the debuggers exception handler will suffice.
2.8.6 SWRK_EXCEPTION_HANDLER
[V2.6-1]
This routine now detects PCA$COLLECTOR in addition to DEBUG for the purpose of not handling most exceptions. This is so that these images can trap exceptions.
This routine is the actual exception handler which is established by
SWRK_ESTABLISH. It takes the arguments specified in the OpenVMS
Introduction to System Services manual.
2.8.7 SWRK_EXTENDED_FILE_SEARCH
[V3.3]
This routine has been enhanced to support the /SELECT qualifier. As a
consequence, all SysWorks commands which use SWRK_EXTENDED_FILE_SEARCH
now support the /SELECT qualifier. All such commands have had their
documentation updated to reflect this.
2.8.8 SWRK_HANDLE_IMAGE_VECTOR
[V2.6-1]
This JSB routine is used to handle SysWorks format shareable image
vectors.
2.8.9 SWRK_HANDLE_QUALIFIERS
[V3.3]
This routine has been enhanced to allow a leading double ampersand to be interpreted as a single ampersand rather than as a symbol substitution operator.
[V3.2]
This routine has been enhanced to allow a leading ampersand to be
interpreted as symbol substitution operator. The command parameter or
qualifier value will be that of the symbol name following the ampersand
rather than the value initially passed by the used. If the symbol named
after the ampersand is not defined, a blank value results.
2.8.10 SWRK_OPEN_OUTPUT
[V2.6-1]
This routine opens the SysWorks standard output stream.
2.8.11 SWRK_PUT_OUTPUT
[V2.6-1]
This routine writes a line to the SysWorks standard output stream.
2.9 Macros
This section briefly describes the new and changed Macros provided in
SysWorks.
2.9.1 FIXUP
[V2.6-1]
The FIXUP macro replaces the previoud UPDATE macro. It is used to fixup
address information in a data structure explicitly at runtime rather
than at image activation time.
2.9.2 UPDATE
[V2.6-1]
The new UPDATE macro performs an update on a file and is thus now
related to the CREATE, GET, OPEN and PUT macros.
2.10 MMS Generators
This section briefly describes the new or updated MMS generators
provided in SysWorks.
2.10.1 Improvements to All MMS Generators
[V3.2]
All MMS generators have now been enhanced to allow a logical name to be
used for a file based dependency. This feature was first introduced for
Cobol, and is now used throughout all MMS generators which make
dependencies on files. There are a number of important side effects of
this change. For example, in conjunction with the
appl_EXPLICIT_LINK_FLG logical name, it is now possible to
have more than one object library within an application.
2.10.2 ACMS
[V3.1]
All ACMS sources now generate dependencies for %INCLUDE statements. These dependencies now work for both ADU REPLACE and ADU BUILD commands. Note that only complete statements can be present within an include source at this time. Examples of such statements include:
forms are ... ;
procedures are .... ;
tasks are ... ;
workspaces are ... ;
|
[V3.1]
Many improvement and reorganizations have been made to the ACMS Task Group MMS script generator. The aim of these has been to increase the level of automation and reduce the level of application specific MMS script used with these.
The following changes have been made:
For a complete description of all the dependencies generated for an
ACMS Task Group source and the assumptions made in order to generate
them, please refer to the SysWorks Application Development
Guide.
2.10.4 ADA
[V2.6]
There is a new MMS generator variant for ADA sources with a file type
of .ADA.
2.10.5 Basic
[V2.6]
There is a new MMS generator variant for Basic sources with a file type
of .BAS.
2.10.6 Bookreader
[V2.6]
There is a new MMS generator variant for Bookreader bookshelf sources
with a file type of .DECW$BOOKSHELF_SRC.
2.10.7 C
[V3.2]
A now logical name of the form appl_EXPLICIT_LINK_FLG now control whether the MMS generator for C creates link time dependencies in addition to compile time dependencies.
The default value of NO causes the generator to behave as it did previously i.e. it uses .TAG_EP dependencies to correctly build images.
A value of YES stops this behaviour. Under these circumstances, the best method of linking to ensure correct builds is to explicilty list each module in a Linker options file, either as an object file or an included modules from an object library. Benefits of this approach include:
These benefits allow SysWorks to be used with legacy or external code
without the need for substantial modifications.
2.10.8 C
[V3.1]
The MMS generator for C now generates dependencies for include files whose names do not start with the application code. In order to distinguish between application and system include files, a search for the file is made in the application work directory. If it is present, a dependecy is made on it. If it is not present, it is assumed to be a system include file and no dependency is generated (i.e. the previous behaviour).
Note that no search for the file is made if its name starts with the application code (i.e. same as previous behaviour). Thus is is more efficient to continue the practise of using the application code as a file name prefix.
This enhanced behaviour is primarily intended to support legacy or
imported code rather than relaxing the recommendation to prefix all
sources with the application code.
2.10.9 C++
[V2.6]
There is a new MMS generator variant for C++ sources with a file types of .CXX, .HXX and .IXX.
| Previous | Next | Contents | Index |