Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DELETE/ERASE causes error after recent VMS ECO

248 views
Skip to first unread message

Giganews

unread,
Apr 14, 2017, 4:42:19 PM4/14/17
to

Customer installed several ECO's on their test system
(Itanium V8.4) last week, and today noticed they were
getting ?Error 278073840 deleting work file?. The
application (which was written by me many many years
ago) creates a temporary command file and spawns a
subprocess to execute it. At the conclusion, it does a
"$ delete/erase" of the command file. When the
subprocess completes with an unexpected error, it
displays the error message.

The error translates to "%DELETE-W-FILNOTDEL,error
deleting !AS", which isn't very informative, but our
support staff was able to narrow it down to the "$
delete/erase" at the end, and to reproduce it.

Just create a file and then delete/erase it...

$ create baddie.com
$ show time
^Z
$ delete/erase baddie.com;
%DELETE-W-FILNOTDEL, error deleting DSA21:[JOHN]
BADDIE.COM;1
-RMS-E-PRV, insufficient privilege or file protection
violation

(Granting additional privs, such as BYPASS, and fiddling
with protection codes doesn't make any difference. The
file does get deleted, but we can't tell if it got
erased or not.)


The error occurs on our development system and on the
customer's test system but not on the customer's
production systems.

Our development system and the customer test system both
have all recent ECOs, including VMS84I_UPDATE-V1200 and
VMS84I_SYS-V0700. I suspect either the SYS ECO or F11X-
V0300, which is included in UPDATE.

The customer production systems have UPDATE-V1100, but
no more recent ECOs.

--
John

Craig A. Berry

unread,
Apr 14, 2017, 6:51:26 PM4/14/17
to
On 4/14/17 3:43 PM, Giganews wrote:
>
> The file does get deleted, but we can't tell if it got
> erased or not.)

You could try a DFU UNDELETE on the file and see what the result looks
like to determine whether it's getting erased.

Michael Moroney

unread,
Apr 15, 2017, 9:26:24 AM4/15/17
to
This is intriguing as I've been in that part of the exec, but for VSI
VMS. From the error message, this is a shadowset. Does this happen with
non-shadowed disks? Does the message go away with LOG_IO or PHY_IO
privilege granted?

I will have to look at the HPE changes and see what they did.

John Reagan

unread,
Apr 15, 2017, 10:02:43 AM4/15/17
to
I'm confused. You said adding privs doesn't make a difference
but you immediately said that the file gets deleted. The error
message shown was for the file not being deleted. Which is it?

do a DIR/SECURITY on the file and on the parent directory. Perhaps
there is some ACL that is preventing you from accessing the file.



Stephen Hoffman

unread,
Apr 15, 2017, 6:51:40 PM4/15/17
to
On 2017-04-15 14:02:40 +0000, John Reagan said:

> I'm confused. You said adding privs doesn't make a difference but you
> immediately said that the file gets deleted. The error message shown
> was for the file not being deleted. Which is it?
>
> do a DIR/SECURITY on the file and on the parent directory. Perhaps
> there is some ACL that is preventing you from accessing the file.

The SET WATCH FILE/CLASS=MAJOR command (/CLASS=NONE to disable) and
OpenVMS system security auditing (SET AUDIT et al) are often useful
tools for isolating the common triggers for NOPRIV errors, too.

As for figuring out if the file was erased, create and populate a
scratch file on a scratch (LD or otherwise) disk with a known pattern
and delete the file and then re-mount the disk foreign and SEARCH for
the pattern.

--
Pure Personal Opinion | HoffmanLabs LLC

Robert A. Brooks

unread,
Apr 17, 2017, 11:35:28 AM4/17/17
to
On 4/14/2017 4:43 PM, Giganews wrote:
>
> Customer installed several ECO's on their test system
> (Itanium V8.4) last week, and today noticed they were
> getting ?Error 278073840 deleting work file?
[...]

> The error translates to "%DELETE-W-FILNOTDEL,error
> deleting !AS", which isn't very informative, but our
> support staff was able to narrow it down to the "$
> delete/erase" at the end, and to reproduce it.
This is a known-to-HPE problem.

Please contact them, referencing PTR 73-130-92.
The fix is contained in [SYS$LDR]F11BXQP.EXE

Note that this problem will not occur in any version of VSI VMS for either
Alpha or IA64.

VSI has chosen not to accept the thin provisioning work added by HPE in SYS-700
at this time.

--

-- Rob

Chris Scheers

unread,
Apr 17, 2017, 5:11:35 PM4/17/17
to
Does this mean that VMS has forked and HPE VMS and VSI VMS are different
(and not completely compatible) beasts?

--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ch...@applied-synergy.com
Fax: 817-237-3074

Stephen Hoffman

unread,
Apr 17, 2017, 6:01:04 PM4/17/17
to
On 2017-04-17 21:11:28 +0000, Chris Scheers said:

> Does this mean that VMS has forked and HPE VMS and VSI VMS are
> different (and not completely compatible) beasts?

OpenVMS forked with V8.4-2L1, if not earlier.

There's been a bit of a compatibility mess starting at OpenVMS V8.4,
given that some HP/HPE patches have been adding feature support.
Unfortunately, there's no way to determine what features are present
from within DCL and applications short of parsing PCSI data. There's
also been no good list of what's been added by what, short of rummaging
each of the restricted-access patch release notes.

There's also been a different bit of a compatibility mess with the SSL
API changes in recent releases (SSL 1.3 and prior, SSL V1,4 and later,
SSL1, V8.4-2L1), as well. That's been at least partially sorted with
the V8.4-2L1 release. Unfortunately, I'd expect to be dealing with
the occasional product-breaking changes when upgrading to newer SSL
versions pending the availability of a more stable network API; whether
OpenSSL or otherwise.

Expect to see a push from third-party OpenVMS developers to move their
customers off of HP/HPE releases and forward to the VSI releases, too.

David Froble

unread,
Apr 17, 2017, 7:54:53 PM4/17/17
to
No expectations necessary. All Codis customers are going to be moved to VSI
products. Some already are. Hopefully all by the end of the year. It appears
that VSI may be having some trouble meeting the demand. Jan Erik mentioned some
issues, I've not gotten a call back, and such. Not good that they may be being
swamped. Very good that people want VSI to have their business. I'm sure
response times will get better.

It's really silly for HPE to come up with modifications not endorsed by VSI.
You hate to mention VMS and fork in the same sentence, but, it's HP, what else
do you expect.

clairg...@gmail.com

unread,
Apr 17, 2017, 8:41:25 PM4/17/17
to
VSI VMS and HP VMS have been different since the day we got the sources. We have been extremely diligent in maintaining compatibility so that a customer could upgrade from HP 8.4 to a VSI release without a hitch. However, there have been cases where we chose not to do things exactly as HP has, and this string has brought out the two major ones, namely SYS700 and SSL. We chose to release the SSL upgrade differently, and not to include some of the SYS700 changes, because we felt it was better for our product going forward.

Ian Miller

unread,
Apr 18, 2017, 6:06:45 AM4/18/17
to
See
VMS84I/A_F11X-V0400 andVMS84A_MOUNT96-V0300

John Santos

unread,
Apr 19, 2017, 7:28:37 PM4/19/17
to
In article <5b9e1542-420b-4a80...@googlegroups.com>,
xyzz...@gmail.com says...
We got a warning that the file wasn't deleted, but it is in fact deleted.

I said "additional privileges don't matter", but eventually we discovered
that LOG_IO in fact does prevent the error. (Well, actually it's not an
error, but a warning. However, the distinction is pretty gray. Many
warnings, especially unexpected ones, need to be treated as errors,
depending on context.)

There were no ACLs.

BTW, the problem is now solved with ECO vms84i_f11x-V0400.

According to the release notes for the ECO, the file was getting deleted,
but the erase didn't happen. I haven't verified this.

--
John Santos
Evans Griffiths & Hart, Inc.

John Santos

unread,
Apr 19, 2017, 7:32:37 PM4/19/17
to
In article <oct71v$avb$1...@pcls7.std.com>, mor...@world.std.spaamtrap.com
says...
Actually, all our disks (and customer's disks, if they've configured per
our recommendations) are shadowsets, so I don't know if this was
relevant.

Aside from reliability, shadowsets allow you to migrate storage from
one device/array/SAN to another with no downtime, which is always a
plus in a production environment.

Bob Gezelter

unread,
Apr 19, 2017, 11:50:11 PM4/19/17
to
John,

Indeed. For those who are following this thread and desire references, I did a session at the 2007 conference on this technique (see http://www.rlgsc.com/hptechnologyforum/2007/1512.html).

I also did a column on a variant of this technique (using single member shadow sets) for OpenVMS.org. It should be available via the Internet archive (it is on my "spare time" queue to migrate the content from the old OpenVMS.org to the new one.

- Bob Gezelter, http://www.rlgsc.com
0 new messages