Skip to main content

$dirrename and $ldirrename: $status -13 when not empty?

  • July 15, 2021
  • 3 replies
  • 0 views
Gianni Sandigliano
Forum|alt.badge.img

Hi Unifacers,

is there a technical reason on getting an error $status = -13 while using $dirrename or $ldirrename when the directory to be renamed is under current user full control but is NOT empty?
I mean a directory on which current user has full control and it is NOT in use by anyone, neither is the current directory for actual process, neither has NO lock on it but it contains at least one file.
When NOT empty my expectation is maximum to get a warning, NOT an error.

AFAIK from direct experience on:
- Windows (either with letter disk or UNC)
- DOS (today = Windows Command Prompt)
- Unix (all flavours)
- VMS
- compressed ZIP files
this limitation does NOT exist working directly at interactive (command line) level.

I do not have enough experience on iSeries. Is there someone helping me on iSeries about this context?

Those instructions are almost NOT usable with that limitation!

Thanks in advance for any answer.

Regards

PillarOfWisdom1: Inject yourself with some fantasy to NOT die of realityPillarOfWisdom2: The secret for a long healthy life is: eat half, walk double, laugh three times and love without measure! (Chinese saying)PillarOfWisdom3: Barcollo ma non mollo!

3 replies

G
  • Giuliante Luigi
  • Participating Frequently
  • July 16, 2021

Hi Unifacers,

is there a technical reason on getting an error $status = -13 while using $dirrename or $ldirrename when the directory to be renamed is under current user full control but is NOT empty?
I mean a directory on which current user has full control and it is NOT in use by anyone, neither is the current directory for actual process, neither has NO lock on it but it contains at least one file.
When NOT empty my expectation is maximum to get a warning, NOT an error.

AFAIK from direct experience on:
- Windows (either with letter disk or UNC)
- DOS (today = Windows Command Prompt)
- Unix (all flavours)
- VMS
- compressed ZIP files
this limitation does NOT exist working directly at interactive (command line) level.

I do not have enough experience on iSeries. Is there someone helping me on iSeries about this context?

Those instructions are almost NOT usable with that limitation!

Thanks in advance for any answer.

Regards

Hi Gianni,

I don't know if you can expect a solution in the Uniface area shortly since I imagine that a problem of this type must be appended to many other requests already submitted.
My advice is to resort to another type of solution that you certainly know; that is to make direct calls to the operating system as documented in the Uniface manual.
It is a method that I have been using for some time to solve problems such as: running .exe or .bat, Copy, Rename, Mkdir and the like.
Unfortunately I do not know the iSeries systems (of the great and ancient family S34, S36, AS400) so, unless I have had a look on the Internet, I do not know how to give you details on the commands that interest you.
I wrote a small document explaining the ways of calling the OS we are using (sorry if these are probably things you know widely) but I can't attach you because I can't find a way to do it with my answer.
I am sending it to you separately.

Bye

Luigi


Gianni Sandigliano
Forum|alt.badge.img

Hi Unifacers,

is there a technical reason on getting an error $status = -13 while using $dirrename or $ldirrename when the directory to be renamed is under current user full control but is NOT empty?
I mean a directory on which current user has full control and it is NOT in use by anyone, neither is the current directory for actual process, neither has NO lock on it but it contains at least one file.
When NOT empty my expectation is maximum to get a warning, NOT an error.

AFAIK from direct experience on:
- Windows (either with letter disk or UNC)
- DOS (today = Windows Command Prompt)
- Unix (all flavours)
- VMS
- compressed ZIP files
this limitation does NOT exist working directly at interactive (command line) level.

I do not have enough experience on iSeries. Is there someone helping me on iSeries about this context?

Those instructions are almost NOT usable with that limitation!

Thanks in advance for any answer.

Regards

Ciao Luigi,

Yes...I've already applied the solution you are proposing... 🙂

What I am wondering about is: Why such limitation? It does make any sense?

IMHO: NO, unless it is forced from some operating system rule on iSeries platform.

Gianni


PillarOfWisdom1: Inject yourself with some fantasy to NOT die of realityPillarOfWisdom2: The secret for a long healthy life is: eat half, walk double, laugh three times and love without measure! (Chinese saying)PillarOfWisdom3: Barcollo ma non mollo!
G
  • Giuliante Luigi
  • Participating Frequently
  • July 17, 2021

Hi Unifacers,

is there a technical reason on getting an error $status = -13 while using $dirrename or $ldirrename when the directory to be renamed is under current user full control but is NOT empty?
I mean a directory on which current user has full control and it is NOT in use by anyone, neither is the current directory for actual process, neither has NO lock on it but it contains at least one file.
When NOT empty my expectation is maximum to get a warning, NOT an error.

AFAIK from direct experience on:
- Windows (either with letter disk or UNC)
- DOS (today = Windows Command Prompt)
- Unix (all flavours)
- VMS
- compressed ZIP files
this limitation does NOT exist working directly at interactive (command line) level.

I do not have enough experience on iSeries. Is there someone helping me on iSeries about this context?

Those instructions are almost NOT usable with that limitation!

Thanks in advance for any answer.

Regards

Hi Gianni,

Unfortunately it applies to all operating systems since the Uniface documentation says:

dirrename  DirPath,  NewDirName

Operation Failure
The operation fails if DirPath:

Is not a directory

Does not exist

Is not empty

Is in use (locked)

Is the current directory or root

Does not permit user-renaming due to insufficient authorization level

Has invalid syntax


Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement