Hi all,
 
In the interest of making sure that everyone who's following this thread
is "on the same page", I'd like to take a moment to clarify some of the
information in Rick's original post.
 
I'm the MPE/iX Expert Center engineer who was working with the Response
Center engineer on Rick's call; at no time was a lab engineer involved.
So, any comments/viewpoints attributed to "the lab" would have been
interpretations of what I or the RCE said; i.e. if there's any heat
that's going to fly on this, aim it my way; the lab's blameless.
 
That being said, here's my take on the situation:  I agree it's neither
optimal nor desirable that people can cut a tape on a 5.0 system, restore
it to a 4.0 system, and unknowingly create a problem which will appear
after they update to 5.0.  (No, I didn't change my mind; I always believed
this.)
 
In reading Rick's post, it seems to me that the only thing we really
differed on at the time I worked on this call is whether or not this
behavior is due to a defect, or should be resolved with an enhancement
request.  I felt it was not a defect; more on this later.  Submitting an
SR was not at issue in my mind; just whether it would be termed a "defect
report" or an "enhancement request".
 
As for the priority which would have been given to the SR, whether a defect
report or an enhancement request, I believed at the time that it wouldn't
be very high.  Not because of the duration of the support life for 4.0 or
because people won't be storing files on 5.0 and taking them to 4.0, but
because there are a number of simple workarounds, most of which Rick
mentioned.  Also, as a correction to Rick's post, the problem won't hit
everyone who stores files on 5.0 and does a :RESTORE;ACCOUNT= on 4.0, nor
will it hit every file stored/restored in this way; it will only affect
files which have non-zero GID values in the file label, where the account
into which the files are restored don't match the GID in the file label.
Most MPE-named files on 5.0 have GID = 0; these files will not cause any
problem.  (Note that :LISTFILE,-3 and "ls -l" are misleading here; for
files with GID = 0, they report a GID equal to the account in which the
file resides, or to which it has been attributed, so they'll make it seem
like more files will be affected than is really the case.)
 
A final word on priority:  if, in future, we'd gotten data indicating that
these simple workarounds were either impracticable or insufficient, the
priority for resolving this defect/enhancement would have gone up appro-
priately.
 
So why didn't I consider this a defect?  At the time, I felt that this
behavior, while certainly not optimal or desirable, was not a defect
because it is a result of a change in file characteristics between 4.0
and 4.5/5.0, as reflected in the file label (specifically the field which
holds the GID), and both 4.0 and 4.5/5.0 are behaving properly and consist-
ently with respect to their understanding of the significant fields in a
file label.  It's only once the 4.0 system is updated to 5.0, revealing the
values in the file's GID, that access problems can occur.  Again, this is
consistent with 5.0's altered understanding of the contents of a file label.
So, everyone's doing what they're supposed to do; no defect.  However, it
certainly would be nice if these different file label interpretations
played together better; that's an enhancement.
 
Okay.  So much for my perspective/opinion at the time Rick last spoke with
the Response Center about this.  Ironically, by the time Rick's post hit
cyberspace, I'd tried a few more things, because while I'd looked at what
could be done with these files once a problem had been detected on 5.0, I
hadn't yet had a chance to see if there was a way to avoid the problem
altogether, by clearing it up on the 5.0 side when the STORE was done in
the first place.  Here's what I found:
 
1.  Given the fact that the ;TRANSPORT=MPEXL option of 4.5/5.0 STORE is
    supposed to allow files with ACDs to be taken back to 4.0 because
    their 4.5/5.0-format ACDs are translated into equivalent 4.0-format
    ACDs, it would be nice if it also cleared the field in the file label
    which contains the GID value.  Yes, this field is not used on 4.0
    so resetting it is not required for its successful access there, but
    leaving it set does have longer term implications; i.e. possible
    access problems once the system's updated to 5.0.  (Enhancement)
 
2.  The :STORE;RENAME feature is supposed to be the front-end equivalent
    of :RESTORE;GROUP=, ;ACCOUNT=, etc.; i.e. it changes the file name
    that's stored to the tape itself, rather than having the person
    restoring the file change the name.  Changing the name using either
    method should change the access to the file so it's appropriate to
    its new location.  On 4.0 this was true, since all that was needed
    was to change the file's name.  On 5.0 however, :STORE;RENAME doesn't
    do the full job; it renames the file, but doesn't change the GID
    to match.  :RESTORE;ACCOUNT= on 5.0 does.  (Defect; :STORE;RENAME
    should change GID to match new account location, as :RESTORE;
    ACCOUNT= does.)
 
I've asked the Response Center to enter an SR for each of these, so you
don't have to, Rick.  I'll post the SR numbers when I've got them.  I
don't yet know what the priority will be for resolving them.  I know the
5.0 STORE/RESTORE lab folks have been making various modifications to
their code to resolve known/newly-discovered defects; it's possible they
will consider rolling the :STORE;RENAME fix into this.  I'll post a follow-
up when I've got some info on this.
 
A final note to Rick:  I'm sorry you got the impression that we weren't
concerned about this problem.  Having been an MIS/IT programmer/analyst
in a previous incarnation, I've had some experience managing and working
in a multiple-HP3000 environment, often where the systems were on different
releases.  So, I took this problem very seriously.  The only things to
which I plead guilty are a difference of terminology (defect vs. enhance-
ment) and a difference of opinion on the priority of a resolution (at
least temporarily).
 
 
Sandra Iwamoto
MPE/iX Worldwide Technology Expert Center (what a mouthful!)
Hewlett-Packard Company