Notes from DCL Birds of a Feather OpenVMS Boot Camp 2014

Approximately 16 people meet in a conference room during the OpenVMS Boot Camp to discuss the state of DCL and its use and perception in the OpenVMS community.

We began the discussion reviewing scripting languages (compiler-less languages) in general.

We outlined the types of Scripting languages:

  • Programing
    • System logic
    • Application logic
    • Business logic
  • Job/Data
  • Process
  • Data

We then identified several popular scripting languages and how they are currently being used.

  • JavaScript
  • Python
  • Ruby
  • Groovy
  • Perl

Then we discussed DCL (Digital Command Language) specifically and what people were doing with it.

  • No Compiler – RAD Tool
  • Very flexible tool
    • Can be simple
    • Can easily become complex
  • Command language
    • Manipulates System Objects
    • Batch
    • Disk
    • Files
  • Programming language
    • System logic
    • Business logic

There was a heathy discussion about methods and how to use DCL

  • Consensus: There are many ways to do things
    • Statement: There are many complex ways to do things.
    • Statement: There is usually a “Best Way”

This brought up the need for

  • DCL shared experience
    • Best practices
    • Tips and tricks
    • Repository

The need for a means for shared experience segued into a listing of some dislikes

  • Unknown outside the OpenVMS community
    • Try Googling DCL solutions…
  • Disconnected from the broader industry
  • Lack of a code snippet library/archive
  • Dangerous in the wrong hands
  • Slow performance – the speed of execution is a limitation
  • No question and answer forum — Stack Overflow too general

We then outlined a list of possible tools to enhance DCL development existing and wish-listed

  • DCL Editor
    • Available in NXTware Remote
  • DCL Debugger for large projects
    • Available from Brian Schenkenberger
  • Updated Documentation
    • Aid standardization
  • Style Check
    • Enforce standardization
  • Syntax Highlighting
    • Available in NXTware Remote DCL Editor
  • Code Completion
    • Very difficult for languages like DCL where the same thing can be accomplished in many ways
  • Code completion for Lexicals
    • Available in NXTware Remote DCL Editor

Then we discussed updating DCL itself

  • Wish List
    • Execution speed
    • Additional features/capabilities
      • New features/capabilities suggested by Martin Zinser
        • Ability to use/import/include subroutines from a different file in a DCL procedure *which would allow for easier reuse)
        • A hash/dictionary datatype
        • Better control structures (besides if)
      • Acknowledged DCL development challenges
        • Developed in a mix of languages including assembler
        • Difficult to work on
        • Very old code base
        • Backward compatibility
          • Would need to support old capabilities and syntax
        • Debated value
          • Low return on significant investment
          • Questioned its value outside of OpenVMS

We agreed that this was a very worthwhile topic and that we’d continue to work on the items that we could control or initiate, while sharing some of the discussion points with VSI.


Post BoF

Follow-up Actions

  • Forum
    • eCube has developed a new Question and Answer site similar to Stack Overflow for all things OpenVMS with a category specifically for DCL. […]
  • Best Practices
    • There is a DCL subcategory dedicated to Best Practices on
  • DCL Editor
    • eCube will shortly announce new support for Lexical Code completion in its editor and greater availability of the editor itself


  1. Since I haven’t been able to attend the BOF at the bootcamp…

    Parts of the document sound like there was a discussion if there is value in enhancing DCL at all, or if potentially another shell could/should replace it.

    Anybody of the people who where in the room can comment on this?

  2. DCL has served VMS well over all the years. However, enhancing it rather than ensuring complete Support for mondern Scripting languages should be priority.
    Those Scripting languages which run on a JVM, e.g., Clojure, are excellent candidates for the future as they 1) run everywhere and 2) are well supported.

Submit a Comment