On 29 May 2013 09:01, CRPence wrote:
On 29 May 2013 08:48, tim.dclinc@xxxxxxxxx wrote:
we have an OCL process that does a RENAME. We are getting the
following error:
SYS6413 More than 1 file exists with old label AP.FILE
I did a wrkobj for that file but only saw 1 out there.
Any ideas?
Ask on a more appropriate list? And perhaps include what was the
failing RENAME request; i.e. the from and to [group] names; best the
prompted view vs the positional, to better explain the parameters to
rusty recollections.
Per a cursory review of the docs, apparently the "File Group Name"
can be used only for SAVE, RESTORE, and DELETE; i.e. not on the RENAME
procedure, so apparently my above reference to an optional\possible
"group" name is not relevant there.
FWiW: Try WRKAUTHLR instead of or in addition to WRKOBJ.
Correction: The command is DSPAUTHLR to list the Authority Holders.
The deprecated *AUTHLR object is an entity that serves as an effective
/place-holder/ for a /file/ name, and thus encounters with them could
result in a confusing error message about a /file/ of the same name.
<<SNIP "group files" comments>>
After re-reading the error message and looking at the "RENAME
Procedure" docs, the "current name" as the first parameter is apparently
what is referred to as the "old label" noted in the message text. That
would imply that the partial request was likely:
"RENAME AP.FILE,"
After following the path of what I write further below [which will
elucidate the origin of the questions], the relevant questions seem to be:
- Does the file AP.FILE have multiple members? The how\why for
there being more than one member would likely be the origin for the message.
- Does the RENAME issue an effective inquiry for which a reply can
effect the rename of all of the /files/ with that name; i.e. is the
error effectively just a warning, and is there any reason not to effect
the rename of the multi-member file?
- Is the use of date-differentiated files in effect, and if so, is
that on purpose?
So given the condition diagnosed as "More than 1 file exists with old
label AP.FILE", we might infer that the request to rename is confused
about that request per that name AP.NAME being multiply-defined. But as
a /file/ of object type *FILE there should be no issue for duplicate
names within a library, and *the library* is the Files Library (FLIB)
for the job [e.g. QS36F]; the distinct name within the library applies
to the *AUTHLR as well, so an Authority Holder named AP.FILE for a file
named AP.FILE also should be of no consequence. And there apparently is
only "1 out there" where the "1" is the file by the name AP.FILE and
"out there" is apparently the established FLIB. But the RENAME can also
rename a FOLDER or a LIBR. Yet there is supposed to be an ordered
resolution for identical names; i.e. file, library, folder. So all we
have left to consider are the /creation date/ values for multiple
file(s) of a certain name.
OK, well for the RENAME, apparently the error message is a known
possibility. The docs for the first parameter inform of this, and seems
to imply that the error is recoverable with an option to continue or
cancel [with the means of the s/36EE, not via inquiry messaging and
reply handling of the native environment]:
"...
_current name_
This specifies the current name of the file, library, or folder.
If more than one file exists with the specified name, a message is
issued. You may choose to rename all of the files with the specified
name or to cancel the job."
So going to the System/36 Environment Reference, we find that the
configuration for the installed S/36EE can enable duplicate names with
date-differentiation, but they are in fact just the database members of
the file:
"...
_i Using File Dates: i_
You can assign the same file label to more than one file if each file
has a different creation date. The creation date is the system date when
an object is created. A system date is the date assigned in the system
values when the system is started. During system configuration, you can
specify that the system prevent a new disk file with a different date
from being created if it has the same label as an existing file. Date
differentiated files are treated as separate members in a single file on
the AS/400 system.
See Chapter 3, 'Configuring the System/36 Environment' for more information.
..."
In CFGS36, the S/36 Environment Values panel can be reached by
selecting 2=Change on the "S/36 environment values Configuration
Description" wherein a "Date differentiated files" option can be set to
indicate whether applications will use "date-differentiated files".
Even without that feature enabled, I presume the existence of an
extra member could be an issue for the RENAME; effecting its warning.
An extra member could have originated from an ALWOBJDIF restore or an
ADDPFM, rather than via a S/36EE procedure such as a copy file feature.
midrange.com
