| Previous | Contents | Index |
[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.
| Name | Code | Description |
|---|---|---|
| Computer_Node | CPND | Computer_Node |
| Computer_Type | CPTY | Computer_Type |
| Node | NDND | Node |
[V3.3]
SysWorks V3.3 adds support for the new meta classes listed in Table 2-2.
| Name | Code | Description |
|---|---|---|
| Node_Class | NDCL | Node Class |
| Node_Type | NDTY | Node Type |
[V3.2]
SysWorks V3.2 adds support for the new meta classes listed in Table 2-3.
| 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 |
[V3.1]
SysWorks V3.1 adds support for the new meta classes listed in Table 2-4.
| Name | Code | Description |
|---|---|---|
| Directory_Profile | PFDR | Directory Profile |
| Profile_Item | PFIT | Profile Item |
[V3.0]
SysWorks V3.0 adds support for the new meta classes listed in Table 2-5.
| 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.
| 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 |
[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.
| Product | Minimum NET-APP-SUP License |
|---|---|
| ACA Services | 250 |
| ACMS | 400 |
| DCPS | 250 |
| DEC TCP/IP Services | 200 |
| DECforms | 250 |
| DECtrace | 400 |
| DQS | 250 |
[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:
[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 |
[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
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
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.
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.
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.
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.
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.
| 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 |
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.
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 |