HP OpenVMS Systems

ask the wizard
Content starts here

DCL PIPE and OPEN questions?

» close window

The Question is:

How can I get the version of the C-compiler into a symbol in a DCL
commandprocedure without explicit use of an intermediate (temporary) file? I
have tried
$ pipe cc/ver | read sys$pipe a
$ pipe cc/ver | read sys$pipe a | b==a
without success. If not possible (maybe because of underlying different
command levels) is there a way to have a new temporary file assigned without
explicitly having to name it?
Another question. How can I get the expanded file spec. of a file opened by
DCL OPEN/WRITE in order to be sure to delete only that file version after
having closed the file (A command like close/delete which rms does support
would have solved this problem

The Answer is :

  You have correctly surmised that the problem here is that symbols
  defined in the PIPE subprocesses are not propagated back into the
  parent process.  There is no way around that.  However, there is a
  logical name table shared by all processes in the same job tree:
  the job logical name table LNM$JOB.  Passing values back via the
  logical name table is thus feasible:
  Also note that the ampersand symbol substitution is required, as the
  more traditional apostrophe substitution pass performed by DCL has
  been completed prior to the execution of the PIPE command component.
  DCL attempts to substitute the symbol value when the command is first
  entered, rather than after it has been set by the READ command. If you
  really need to get the value into a symbol, you can add further commands
  after ";". You may also want to clean up, so the complete command is:
    	(READ SYS$PIPE ver ; DEFINE/JOB/NOLOG ver &ver ) ; -
        ver=F$TRNLNM("ver") ; DEASSIGN/JOB ver
  at the end of which you'll have a symbol "ver" set to the version
  string returned by the CC command. The same technique can, of course,
  be used to convert any single line output command (or indeed the first
  line of output from any command) into a symbol.
  The JOB logical name table size is limited by the process JTQUOTA.
  Your second question -- please, one question to a posting -- is more
  of a problem. There is no documented means for determining the file
  specification of a Process Permanent File (PPF) as created with the
  OPEN/WRITE command.
  Looking at the problem itself, there are obviously ways to deal with
  the issue of potential clashes of file names. Since you are deleting
  the file, you obviously don't really care what the filename is, and
  can therefore choose a name with a vanishingly small chance of a name
  clash.  The OpenVMS Wizard would thus suggest a combination of a
  prefix, the PID and some portion of a timestamp.  For example:
    $ FileName = "prefix$" +-
  Since an OpenVMS Alpha system can generate a prodigious number of
  file names in a hundredth a second (the resolution of DATETIME), the
  truly paranoid programmer will add a further field to ensure all file
  names are really unique. Just make sure all generating code uses the
  same global symbol:
    $ FileNum = FileNum + 1
    $ FileName = "prefix$" +-
        F$GETJPI("","PID") + f$fao("!8XL",FileNum) +-
  You can then use the f$parse lexical function to fill in the various
  other fields in the filename as required:
    $ FileNum = FileNum + 1
    $ FileName = "prefix$" +-
        F$GETJPI("","PID") + f$fao("!8XL",FileNum) +-
    $ TmpDataName = f$parse("SYS$SCRATCH:.TMP",FileName)
  With a filename that is almost certainly unique, how to make sure that
  you have the correct version number?  Rather than using OPEN/WRITE, use
  the CREATE command. For example:
    $ TmpDataName = f$parse("SYS$SCRATCH:.TMP",FileName)
    $ CREATE 'TmpDataName'
    $ FullFileSpec = F$SEARCH(TmpDataName)
    $ OPEN/APPEND TempFile 'FullFileSpec'
       application processing
    $ CLOSE TempFile
    $ DELETE 'FullFileSpec'
  There is obviously a timing window between the CREATE and the F$SEARCH, and
  it is possible that the file returned by F$SEARCH is not the one that was
  CREATEd.  However, once we have successfully OPENed the file, we can be
  guaranteed that the DELETE command will delete the one we wrote to.  This
  is a much tighter window than between the OPEN and CLOSE then DELETE in the
  simpler implementation.  In the case of the timing window being triggered
  by having two processes execute the code simultaneously -- use of the PID
  in the file specification will prevent this -- one of the OPENs will fail
  with a file sharing violation.
  As an aside, note that the method of using CREATE and OPEN/APPEND, rather
  than OPEN/WRITE also allows control over the type of file created and other
  properties like protection. For example, when creating files which will
  be shared with other operating systems, it is often better to create
  STREAM files, than the default VFC files. For example:
    $ CREATE/FDL=SYS$INPUT:/PROT=(W:RE) 'FullFileSpec'
    $ OPEN/APPEND out 'FullFileSpec'
  As mentioned, here is no direct means to back-translate a PPF to the
  file specification from within DCL.  Back-translations from within
  an application module are rather easier.  PPF channels can also be
  viewed via tools such as the SDA command SHOW PROCESS/CHANNEL.
  Another approach at this whole problem is rather more simplistic, simply
  retain the filename used for the OPEN for later use during the DELETE.
  The OpenVMS Wizard believes your suggestion for CLOSE/DELETE or
  CLOSE/DISPOSITION=(DELETE,PRINT,etc) is a good one, and the Wizard
  encourages you to contact your local Compaq Customer Support Centre
  directly, and formally request it.   You may also want to ask for a
  new or enhanced DCL lexical function that generates a unique string
  suitable for use as a filename.

answer written or last revised on ( 29-DEC-1999 )

» close window