SysWorks©

SysWorks V3.5
Release Notes


Previous Contents Index

2.2.12 OpenVMS Alpha 8.3

[V3.5]

SysWorks now supports OpenVMS Alpha Version 8.3 as well as OpenVMS VAX Version 7.3.

2.2.13 OpenVMS Alpha

[V3.0]

SysWorks now supports OpenVMS alpha as well as OpenVMS VAX. As part of this support, multi-architecture application development is also supported. Also, some MMS script generators create slightly different syntax as required by the architecture differences.

2.2.14 Oracle Rdb Version

[V3.1]

This release of SysWorks includes support for Oracle Rdb V6.1 in addition to DECrdb V6.0A, V5.0A and V4.2.

[V2.6]

This release of SysWorks includes support for multi-variant DEC Rdb installations. Previous versions of SysWorks changed some behaviour based upon which version of DEC rdb was installed. These changes will now take place based on which version of DEC Rdb has been selected with the SYS$LIBRARY:DECRDB_SETVER or SYS$LIBRARY:RDBVMS_SETVER command procedure.

2.2.15 Secure Task Actions

[V3.2]

The SysWorks secure tasks now take an argument indicating whether files are to be secured using the default action (i.e. SET SECURITY/DEFAULT) or an explicit action (i.e. SET SECURITY/ACL=(...)/OWNER=.../PROTECTION=(...)).

The advantage of the default secure action is that it is faster and does not change the modification dates of the secured files. This preservation of modification dates stops an incremental build following a secure task turning into an effective full build.

The advantage of the explicit secure action is that it is more thorough. It was also the action used in earlier versions of SysWorks. Note that an incremental build following a secure task using the explicit action effectively becomes a full build since all sources appear to be new.

By default the default action is used.

2.2.16 Security Model Changed

[V2.5]

SysWorks no longer includes the OPTIONS=PROTECTED clause in ACLs. This change is made to allow the use of the /DEFAULT qualifier (and hence the DEFAULT action as indicated above). The SET SECURITY/DEFAULT command only works for ACEs whjich do not have the PROTECTED option set.

[V2.5]

When SysWorks is installed at or below the public installation level, a series of symbols is used to indicate identifiers to be used to provide security for objects which need ACLs.

When SysWorks is installed at or above the system level, these symbols are not necessary, since SysWorks registers and uses identifiers to achieve this end.

In previous versions of SysWorks the value of the ACE_MGR symbol represented the sole identifier which was thus used.

This symbol has been superceded by the ID_MGR symbol. Although ACE_MGR may continue to be used, it may not be supported in a future version of SysWorks. Two other symbols, ID_USR and ID_REP have been added to support a three layer ACL. The symbols are used to grant the following access rights:
Symbol Rights to associated identifier
ID_MGR READ+WRITE+EXECUTE+DELETE+CONTROL
ID_USR READ+WRITE+EXECUTE+DELETE
ID_REP READ+EXECUTE

These symbols wuld normally be defined in an application environment's ENTER.COM and deleted in its EXIT.COM.

2.2.17 SPECIFIC Scope

[V2.6]

This release of SysWorks includes full support for the SPECIFIC scope for application development and maintenance. When using the SPECIFIC scope, developers and maintainers compile and build within their own sub-directories, while still sharing the application COMMON area for sources, objects and images etc. which they are not modifying themselves.

2.2.18 Subprocess Editor

[V2.4-3]

The default EVE or LSEDIT editor is now kept as a subprocess by default. To disable this feature, remove the ED*IT, EVE and/or LSE*DIT components from the SWRK_SPAWN_COMMANDS logical name. Note that if a logical name needs be empty, it has to consist of a space.

2.2.19 Synchronized Batch Jobs Status Message

[V3.2]

Batch jobs which can be synchronized with another batch job (i.e. those submitted by commands which suppport the /SYNCHRONIZE qualifier - this includes the BUILD, COMPILE and DO commands) now set a restart message indicating their synchonizing state. This is similar to the executing phase messages which BUILD jobs provide. This feature allows a user or operator to easily distinguish batchs jobs which are waiting on other batch jobs to complete.

2.2.20 Meta object Model

2.2.20.1 V3.4

[V3.4]

SysWorks V3.4 adds support for the new meta classes listed in Table 2-1.

Table 2-1 Meta Classes added for V3.4
Name Code Description
Computer_Node CPND Computer_Node
Computer_Type CPTY Computer_Type
Node NDND Node

2.2.20.2 V3.3

[V3.3]

SysWorks V3.3 adds support for the new meta classes listed in Table 2-2.

Table 2-2 Meta Classes added for V3.3
Name Code Description
Node_Class NDCL Node Class
Node_Type NDTY Node Type

2.2.20.3 V3.2

[V3.2]

SysWorks V3.2 adds support for the new meta classes listed in Table 2-3.

Table 2-3 Meta Classes added for V3.2
Name Code Description
Architecture ARCH Architecture
File_Type FLTY File Type
Group_User GRUS Group User
IP4_Address INA4 IP4 Address
Internet_Domain INDM Internet Domain
IP4_Subnet INSN IP4 Network/Sub-net
Name_Model NMMD Name Model
NODE_class NDCL NODE class
Oper_Sys OPSY Operating System
Playform OSPL Platform (Operating System Architecture)
Property PROP Property
Property_Type PPTY Property Type
UNIX_Username UNXU UNIX Username
UNIX_Username_Node UUND UNIX Username Node
Variable_Type VBTY Variable Type

2.2.20.4 V3.1

[V3.1]

SysWorks V3.1 adds support for the new meta classes listed in Table 2-4.

Table 2-4 Meta Classes added for V3.1
Name Code Description
Directory_Profile PFDR Directory Profile
Profile_Item PFIT Profile Item

2.2.20.5 V3.0

[V3.0]

SysWorks V3.0 adds support for the new meta classes listed in Table 2-5.

Table 2-5 Meta Classes added for V3.0
Name Code Description
Appl_envr_User AEUS Application Environment User
Base BASE Base Object
DECnet_Address_Number DNNN DECnet address Number
Device_Type DVTY OpenVMS Device Type
Disk_Device_Type DKDT Disk Device Type
Disk_Media DKMD Disk Media
Disk_Media_Format DKMF Disk Media Format
Disk_Media_Type DKMT Disk Media Type
Location_Type LCTY Location Type
Member MBER Member
Member_Category MBCT Member Category
Message MSAG Message
Method MTHD Method
Method_Package MTPK Method Package
NODE_type NDTY NODE type
Owner OWNR Owner
PAK LPAK Product Authorisation Key
Product LYPR Layered Product
Relationship RELN Meta object Relationship
Security_Model ACLX Security Model
System_Job SYJB System Job
Tape_Device MTDV Tape Device
Tape_Device_Type MTDT Tape Device Type
Tape_Media MTMD Tape Media
Tape_Media_Type MTMT Tape Media Type
Tape_Pool MTPL Tape Pool
Tape_Volume MTVL Tape Volume
VMS_Username_Node VUND OpenVMS Username Node

SysWorks V3.0 removes support for or renames the meta classes listed in Table 2-6.

Table 2-6 Meta Classes removed or renamed for V3.0
Name Code Reason
Appl_envr_Node AEND Converted to VMS_Username_Node
Group_Node GRND Converted to VMS_Username_Node
Product LYPD Renamed to LYPR

2.2.21 Test Directory

[V2.6]

This release of SysWorks supports an application environment test directory. Like other application directories, this directory can be adjusted using the SDC_TST and DIR_TST symbols. The default value of the SDC_TST symbol is TST.

The feature of the test directory is that all targets beginning with appl_TST (or appl_sdc-tst if a site specific SDC_TST symbol is used) will be placed in the test directory rather than the standard software directory.

To disable this feature, set the SDC_TST symbol to a space.

As part of this new feature, SysWorks now has a test directory SWRK_TST_DIR which contains a number of tests of SysWorks features. These tests consist of images and DCL command procedures which may be executed at any time.

2.2.22 Utility Logicals Scope

[V2.5-1]

If SysWorks is installed at the public level, the various utility logicals supported in SysWorks such as EDTINI may be defined at the system or user level. The installation procedure ask a question regarding this. The response must be either SYSTEM or USER. Note that with a USER respone, initial user logins after a system boot will be slower.

2.2.23 VARIANT Context

[V3.0]

This release of SysWorks includes support for variant (i.e. concurrent or parallel) development of applications.

To allow specific environments to use this context in a public installation, commands similar to the following should be used to define the appropriate control logical names:


$ DEFDAT :=> DEFINE/NOLOG/TABLE=LNM_swrk_DATABASE 
$ DEFDAT SWRK_ENVR_APPL "SCOP=COMMON\VACL=0\VRNT=0\VRSN=0\WORK=0" 
$ DEFDAT SWRK_ENVR_DEV  "SCOP=SPECIFIC\VACL=0\VRNT=1\VRSN=0\WORK=1" 
$ DEFDAT SWRK_ENVR_DTST "SCOP=COMMON\VACL=0\VRNT=1\VRSN=0\WORK=1" 
$ DEFDAT SWRK_ENVR_FDEV "SCOP=SPECIFIC\VACL=0\VRNT=1\VRSN=0\WORK=1" 
$ DEFDAT SWRK_ENVR_MNT  "SCOP=SPECIFIC\VACL=1\VRNT=0\VRSN=1\WORK=1" 
$ DEFDAT SWRK_ENVR_MTST "SCOP=COMMON\VACL=1\VRNT=0\VRSN=1\WORK=1" 
$ DEFDAT SWRK_ENVR_PROD "SCOP=COMMON\VACL=0\VRNT=0\VRSN=0\WORK=0" 
$ DEFDAT SWRK_ENVR_TRNG "SCOP=COMMON\VACL=0\VRNT=0\VRSN=0\WORK=0" 

These commands are typically defined in SWRK_LCL_DIR:site_PRE_STARTUP.COM. The new SCOP attribute indicates whether only the COMMON scope is permitted or the SPECIFIC scope is allowed as well. The VACL, VRSN and WORK components were described in previous release notes.

2.3 Layered Products

This section briefly describes new and modified layered product support in SysWorks.

2.3.1 New License Recognition

[V2.6]

The NET-APP-SUP license are now recognised as valid licenses for various products. See Table 2-7 for details.

Table 2-7 NET-APP-SUP License Usage
Product Minimum NET-APP-SUP License
ACA Services 250
ACMS 400
DCPS 250
DEC TCP/IP Services 200
DECforms 250
DECtrace 400
DQS 250

2.3.2 New Product Support

[V3.2]

Support has beed added or enhanced for the following layered products and versions:

[V3.0]

Support has beed added or enhanced for the following layered products and versions:

[V2.6]

Support has beed added for the following layered products:

2.3.3 ACA Services Support

[V2.5]

SysWorks now supports ACA Services. It provides MMS generators for .COL and .CRL files, an ACAS convenience command and a DECwindows/Motif Application pulldown menu item.

2.3.4 DECdocument

[V2.6-1]

All SysWorks MMS generators for DECdocument which previously used manual designs now use software designs. SysWorks now provides an enhanced software design file, and no longer provides any manual design files.

2.3.5 DECset V12.1

[V3.1]

Specific SysWorks versions are linked against specific DECset versions. The following table lists these combinations:
SysWorks Version DECset Version
V3.1 V12.1
V3.0 V12.0
V2.5 - V2.6-1 V11.0
If SysWorks is configured to use DECset, they must be of the appropriate version. In a future version of SysWorks, the installation procedure will link against the version of DECset which is present on the installation computer. Special arrangements can be made for customers who need features of a newer version of SysWorks with an older version of DECset i.e. where the DECset version cannot be updated.

2.3.6 DECset V12

[V3.0]

SysWorks now provides enhanced Session Manager and FileView support using the new DECset pulldown menu.

The SysWorkstm CONTEXT command and the SysWorks Administrator Application Management tasks now support DECset environment database and contexts.

2.3.7 DECset V11

[V2.5]

SysWorks now provides enhanced LSEDIT support including the LSEDIT Another File item in the Utilities pulldown menu. The reuseable DECset Debugger is also provided in the Utilities pulldown menu.

2.3.8 Java Support

[V3.2]

SysWorks now supports Java. It provides MMS generators for .CLASS and .JAVA files.

2.3.9 ObjectBroker Support

[V3.0]

SysWorks now supports ObjectBroker. It provides MMS generators for .COL, .IDL, .IML and .MML files, an command and a DECwindows/Motif Application pulldown menu item. Note that SysWorks cannot support ObjectBroker and ACA Services on the same computer node - if both are present it supports ObjectBroker rather than ACA Services.

2.4 Commands

This section briefly describes new and modified commands provided in SysWorks.

2.4.1 ACCEPT

[V3.2]

The ACCEPT command has enhancements to the /CONVERT qualifier and also has a new /HELP qualifier. See HELP ACCEPT for more details.

2.4.2 BUILD

[V3.2]

The SETUP phase now has default actions which are executed if no application specific SETUP procedure is present. These default rules ensure that the standard ENTER.COM, EXIT.COM and LOGICALS.COM procedures exist, are up to date and have been executed.

[V3.2]

The SCAN and RULES phases default actions have been enhanced to include actions for the generated source directory if present.

In previous versions of SysWorks Developer, applications that generated sources needed to provide application specific SCAN and RULES procedure which executed SWDEV_SFT_DIR:SWDEV_BUILD_phase without a parameter for the normal source directory and then again with an appropriate parameter for the generated source directory.

Now, the default action (i.e. when there is no application specific procedure) works as though these two calls were made. Thus, many applications may now remove their application specific procedures for these phases.

[V3.2]

The /FROM_SOURCES qualifier has been replaced by the /FROM[=location] qualifier. The location value can be LIBRARY, SOURCE or WORK. See HELP BUILD /FROM for more details. The default location of SOURCE yields the same effect as the old /FROM_SOURCES qualifier.

[V3.2]

The /RELATED qualifier is now implemented. This allows related applications to be built in a single job.

[V3.1]

The /COMBINED qualifier is now implemented. This allows the Alpha and VAX versions of an application to be built in a single task when the BUILD command is executed on an Alpha.

A consequence of this is that the default names for log files generated during non combined builds have an architecture suffix. For example BUILD/NOCOMBINED will by default generate a BUILD-VAX.LOG log file on a VAX.

[V3.1]

A new GENERATED default phase has been added. This phase is executed between the SETUP and SCAN phases. The default values when /PHASES=ALL is specified (or defaulted to when /FETCH is specified) is now SETUP, GENERATE, SCAN, RULES, DESCRIP.

As a consequence of the introduction of this new phase, the SCAN and RULES phases will now automatically generate a second set of MMS and/or SQL scripts based on the sources in the generated source directory (directory code GEN). For example, in the FIN application, FINMMS.TLB would be used to store the source level MMS scripts and FIN_DEPENDENCIES.MMS would be generated as the combined sript. If there were sources in the FIN_GEN_DIR: directory, FINMMSGEN.TLB would be used to hold the individual MMS scripts and FIN_DEPENDENCIES_GEN.MMS would be generated as an additional large script.

[V3.0]

The RULES and DESCRIP phases now jointly generate the RDO and/or SQL scripts for creating a DEC Rdb database which used to be generated during the SCAN phase. The file names of these generated files have now changed. See Table 2-8 for a comparison of the old and new names.

Table 2-8 Old and New Generated SQL Script Names
Old Script Name New Script Name
appl_CONSTRAINTS.SQL No longer generated
appl_DOMAINS.SQL appl_SCHEMA_DOM.SQL
appl_INDICES.SQL appl_SCHEMA_IDX.SQL
appl_TABLES.SQL appl_SCHEMA_TBL.SQL
appl_TRIGGERS.SQL appl_SCHEMA_TRG.SQL

[V2.6]

The /KIT qualifier has been changed to /KITBLD and the KIT phase has been changed to KITBLD. This is to increase consistency with the VMSOIINSTAL conventions.

The BUILD command SCAN phase now generates an appl_DOCUMENTATION.MMS script in the library directory. This script contains a target called DOCUMENTATION which depends on all the documentation targets.

Application DESCRIP.MMS files should be changed to reflect this by adding the DOCUMENTATION source to the ALL target and including the library directory appl_DOCUMENTATION.MMS script.

See SWRK_SFT_DIR:DESCRIP.TEMPLATE for an example.

[V2.5]

The BUILD/FETCH qualifier now uses the DEVTOOLS CMS FETCH command with an empty remark so that CMS history is not full or BUILD comments. If the BUILD is being performed in the COMMON scope, BUILD/FETCH uses the DEVTOOLS CMS FETCH/TIDY qualifier which deletes intermediate and target files associated with the element being fetched in a similar fashion to the BUILD/CMS qualifier.


Previous Next Contents Index