Re: IFS Reading Question.... -- RPG400-L

Hi John,

Your IFS directory code isn't working because it's corrupting memory.Although the problem is in your code, it's actually corrupting thevariables inside the readdir() API, and causing it to fail.

The reason it works with some filesystems in the IFS, but not with others,is because the code that IBM wrote for reading a directory is a littledifferent for each filesystem, and you happen to be corrupting somethingdifferent in the /QDLS case than you are in other cases.

The fact that your code works today on te "root" filesystem, does not meanthat it'll work tomorrow, or after applying the next PTF, or when you do arelease upgrade. You're just "lucky" that it works today.


Let's look at your code:


Rtn = *Zeros;

@Dir = '/QDLS/FCCASES';

// Open the Directory
 d = opendir(%Trim(@Dir));
 If d = *Null;
   Rtn = -1;
 Else;

Up til this point, the code is okay. One comment I wanted to make,though, is that this is terrible error handling. When your program failsand you have to write a message to the screen or to a log that tells auser why it failed, simply saying "-1" or "it failed" is frankly not goodenough.

You need to, at a very minimum, retrieve an error number. I'd go beyondthe minimum and actually get an error message that describes the problem.Just returning -1 is not adequate.

   x = *zeros;
   p_dirent = readdir(d);
   dow p_dirent <> *Null;

// Always in the beginning of the DIR you get . twice
if %SubSt(d_Name:1:1) <> '.';
 x = x + 1;
 contents(x) = %Trim(d_Name);
endIf;

%TRIM(d_name) is wrong. You can't do that -- d_name is a variable-lengthspot in memory. Although it's probably defined as "640A" in your RPGprogram, it's not REALLY a fixed-length RPG variable.

The readdir() API will make the size of the d_name variable different forevery single filename it reads. So if you have a file named "XXX" thed_name field will be 3A. If you have a file named "test.txt" the size ofthe d_name field will be 8A. If you have a file named "Todays Blue ChipPricing Report.pdf" the d_name field will be 35A.

The problem is, your program can't dynamically change teh size of thed_name field. You have to define ONE length and then keep using itthroughout your program.

So in my examples, I define it as 640A. Then, I'm always VERY careful tomake sure that I only refer to the part of the field that was populated.Never refer to anything past that part.

The API will tell you which part of the d_name field is populated in aseparate variable called "d_namelen".


So, your code above should look like this:

    contents(x) = %Trim(%subst(d_Name:1:d_namelen));

However, once you've coded that, you'll find that the %TRIM is completelyunneceesary, since there won't be any spaces in the filename to beginwith. So you may as well code it this way:


    contents(x) = %subst(d_name:1:d_namelen);

Now, on to the really big problem with your code:

/ Clear the Name field for fresh Start
d_Name = *Blanks;

This is the one that's causing your code to fail, and causing memory to becorrupted. Keep in mind what I said about d_name having a dynamic size...sometimes it 3A, sometimes it's 8A, sometimes it's 12A, sometimes it's35A...

In fact, since the first directory entry in your program will just contain".", the first time through the loop, it'll be a 1A field.

Since you have it defined as 640A, when you set d_name = *blanks, whathave you done? You've overwritten the one "." with a blank. And then thenext 639 bytes of memory after that blank -- memory that doesn't belong toyou -- memory that's being used for something else inside the readdir()API -- is being set to x'40'.

Ouch. That's REALLY dangerous. Not to mention, it's completelyunnecessary. I suspect that the reason you're doing this is so that theearlier %TRIM will work properly -- however, now that you're using %SUBSTrather than %TRIM it's completely unnecessary!


Just remove the "d_name = *Blanks" line.

Hope that helps.