× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks, Scott, for the detailed explanation. It is very helpful.


midrange-l-bounces@xxxxxxxxxxxx wrote on 02/21/2008 12:04:34 PM:

Howdy,

Just to clarify what's happening... there are a few things going on
here...

a) The \ character has a special meaning in C and in many things that
are based on C, including Unix shells. It's the "escape" character, and

it tells the system to treat the next character literally, so that the
next character doesn't have a special meaning.

b) Traditionally, file systems were designed to use / (foreslash, not
backslash) as the separator between filename and directory name.
However, when MS-DOS was devised, the folks that created it were worried

about being a lawsuit if they copied the other predominant operating
systems (Unix and CP/M) too closely, so they changed a bunch of things
to make it look different. One of the things they changed was they used

backslash instead of foreslash for filenames. Therefore, operating
systems that evolved from DOS, such as Microsoft Windows, use the
backslash instead.

c) You can see the conflict. C based tools use backslash as a special
character, but it's a directory separator in Windows!

d) In i5/OS they used Unix as the model for the IFS. They used
foreslashes as separators. However, due to the large number of Windows
folks out there, the CL commands for the IFS all accept backslashes as
well as foreslashes. The CL commands will translate the backslashes to
foreslashes before calling the underlying APIs that they use to do the
work -- the point is -- CL commands like WRKLNK, CPY, REN, RMVLNK, etc,
allow backslashes while the IFS APIs do not.

e) RPG does not treat backslashes as special characters. The HSSF tools

(under the covers) use the IFS APIs. So if you call your file
"\\QDLS\BLAH\BLAH" it will not recognize that you are trying to refer to

directories -- it'll include the whole thing, including the slashes, as
part of a single file name.

f) When you try to use WRKLNK to delete it, it doesn't work because
WRKLNK is a CL command, and it translates the slashes, and therefore
looks for directories instead of files!

g) When you try to use QShell, which is a C-based tool, the backslashes
have a special meaning. So if you do rm \\SOMETHING it will atually try

to delete \SOMETHING instead. Why? Because \ tells QShell to take the
subsequent character literally. So, in \\, the first slash tells QShell

to take the next charactter literally. The next character is \. So you

end up with \SOMETHING. You could work around this by doubling up your
slashes, i.e. "rm \\\\SOMETHING". This will result in it trying to
delete an object named "\\SOMETHING". It's very much like when we
try to put single quotes in a string in RPG -- you have to double them
up. Hope that makes sense.

h) Another way to solve the problem in QShell would've been by using
wildcards instead of the slashes...

i) The EDTF command solved the problem because it doesn't use the CL
commands to delete the files, it calls the APIs. Not sure why EDTF
works differently than WRKLNK, exactly.. I can only guess that it was
written by a different programmer who did things a little differently.

j) You could've also solved the problem by calling the unlink() API
yourself. Since, again, RPG doesn't treat \ specially, and since the
unlink() API doesn't recognize backslashes as directory separators, it
would've worked.

callp unlink('\\WHATEVER\whatever\whatever')

k) Another consideration which isn't directly related, but might be
interesting... Typically when you specify two directory separators
consecutively in a pathname, the IFS will treat them as if you had only
given one separator. For example, the following two API calls delete
the same object, since the double slash is treated the same way as a
single slash:

unlink('//QDLS/WHATEVER/WHATEVER/example.txt');
unlink('/QDLS/WHATEVER/WHATEVER/example.txt');

This did not apply to your situation, however, since you had specified
backslashes instead of foreslashes, and backslashes weren't considered
directory separators by the tools that created your file, so when you
doubled up the filename, it took it literally.

Anyway -- I realize that you already solved the dilemna at hand, I just
wrote your message to help you understand what was happening.



MKirkpatrick@xxxxxxxxxxxxxxxxx wrote:
This is very odd. While testing my RPG pgm (HSSF) to create a XLS
file, I
screwed up the file name. I called the file:

\\QNTC\WDSERVER2\FLASH\ORTHOFLASH\flash_test.xls Yes, that is the
file
name, slashes and all.

Now I cannot delete this file. I have used WRKLNK Opt 4 and the error
is
'Object not found'. Opt 8 , though, show attributes, including a
size. I
IPLed the system and tried again with the same results. I have also
tried using iNav ->File System and the error is 'The file, ...., was
not
found.'

Any suggestions? Thanks.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.






This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone this email or any information contained in this email. If you have received this email in error, please advise the sender by replying to this email, and delete this email immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Western Dental Services, Inc. Finally, the recipient should check this email and any attachments for the presence of viruses. Western Dental Services, Inc. accepts no liability for any damage caused by any virus transmitted by this email.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.