HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

open/write of 2 files with same logical name oddity

 
SOLVED
Go to solution
tasevms
Occasional Contributor

open/write of 2 files with same logical name oddity

Consider the following in VMS 8.4:

 

$OPEN/WRITE TEST A.A

$WRITE TEST "TEXT"

$OPEN/WRITE TEST B.B

$WRITE TEST "NEW TEXT"

$CLOSE TEST

 

Result is 1 file - A.A with 2 lines:

TEXT

NEW TEXT

 

Shouldn't the second open/write return an error/warning?

Appreciate your input on this.

 

 

6 REPLIES
Duncan Morris
Honored Contributor
Solution

Re: open/write of 2 files with same logical name oddity

This has been the behaviour for a very long time!

 

See the snippet below from the DCL dictionary manual:

 

http://h71000.www7.hp.com/doc/84final/9996/9996pro_151.html#brass_5000

 

Do not use the same logical name when you open different files. If you specify a logical name with the OPEN command and the logical name is currently assigned to another file, no warning message is issued; however, the file is not opened, and the next READ request will access the file to which the logical name was originally assigned.

 

Duncan

H.Becker
Honored Contributor

Re: open/write of 2 files with same logical name oddity

That's the way it is and it is documented - although WRITE isn't explicitly mentioned - in the HP OpenVMS DCL Dictionary  (http://h71000.www7.hp.com/doc/84final/9996/9996pro_151.html#index_x_820):

 

Do not use the same logical name when you open different files. If you specify a logical name with the OPEN command and the logical name is currently assigned to another file, no warning message is issued; however, the file is not opened, and the next READ request will access the file to which the logical name was originally assigned.
David R. Lennon
Valued Contributor

Re: open/write of 2 files with same logical name oddity

Or..get into the habit of doing a (usually redundant) $ CLOSE/NOLOG logical-name

before doing an OPEN with that logical-name. In addition to knowing if you are in the situation described above pretty quickly during testing, it has the benefit of "closing out" any file that may be in the process of being written to from a previous run if the user did a control-y out of the program (and you don't have a DCL "interrupt handler")...

 

- Dave

John Gillings
Honored Contributor

Re: open/write of 2 files with same logical name oddity

CLOSE/NOLOG is a good idea prior to any OPEN, but /NOLOG is a relatively recent addition to the syntax. I don't think it works pre V8. The backwards compatible method is:

 

$ IF F$TRNLNM("logical-name").NES."" THEN CLOSE logical-name

 

This assumes that any non-null value in the logical name represents an opened file. There's no simple way from DCL to check for sure. DCL hides the open file signature word in the logical name translation which is visible from an image. Look for %X001B as the first word in the (unfiltered) translation.

 

There's a freeware image called "PPF" floating around which can determine the file specification from a logical name, and thereby validate an open file.

 

 

A crucible of informative mistakes
Hoff
Honored Contributor

Re: open/write of 2 files with same logical name oddity

Eh?  CLOSE /NOLOG has been around for over twenty years.  

 

It showed up in early V6 if not before, IIRC, and I can find references to it in DCL from 1988 and 1989.

 

So if you're targeting DCL on OpenVMS VAX V5-ish, you might want to check on the command availability.

 

It's been standard DCL defensive programming for quite a while, too.

 

 

John Gillings
Honored Contributor

Re: open/write of 2 files with same logical name oddity

Hoff,

 

   Sorry, my mistake, I was confusing it with DEASSIGN/NOLOG, which is quite recent.

A crucible of informative mistakes