Calling opendir(), readdir(), closedir() functions from guardian on nonnative objects

[Manas]

Hi,
Is it possible to use the function calls opendir(), readdir(),
closedir() from nonnative guardian objects?
I need to call these functions from a non native guardian object to
get the OSS file names from a particular OSS directory.
Can anyone suggest the best way to do so?

[wbreidbach]

I know that it is possible to open an OSS file from a Guardian process, native or nonnative. I think the problem is that you are using a Guardian process and I cannot imagine that opendir() and the others are supported within Guardian.
But I think there would be another way: Start an OSH-process executing the ls-command and read the output. Reading the output directly could be a bit tricky as the output is an unstructured file with lines separated by the linefeed character (X"10").

[Joachim Schmitz]

wbreidbach wrote:
> Am Mittwoch, 23. Mai 2012 10:36:23 UTC+2 schrieb Manas:
>> Hi,
>> Is it possible to use the function calls opendir(), readdir(),
>> closedir() from nonnative guardian objects?
>> I need to call these functions from a non native guardian object to
>> get the OSS file names from a particular OSS directory.
>> Can anyone suggest the best way to do so?
>
> I know that it is possible to open an OSS file from a Guardian
> process, native or nonnative.

The problem is that the APIs opendir(), readdir() and closedir() are in a
native DLL/SRL only.

> I think the problem is that you are
> using a Guardian process and I cannot imagine that opendir() and the
> others are supported within Guardian.

They should be, in native programs and should even work on Guardian subvols.

> But I think there would be another way: Start an OSH-process
> executing the ls-command and read the output. Reading the output
> directly could be a bit tricky as the output is an unstructured file
> with lines separated by the linefeed character (X"10").

And you'd need to use OSSTTY, e.g.

OSH -osstty -p ls -l /path

Bye, Jojo

[Keith Dick]

Actually, according to the documentation, you probably can use opendir(), readdir(), and closedir() from a Guardian object file.

I have never done this, but there seems to be a thorough description of what functions can be used from what environments in Appendix B of the "Open System Services Programmer's Guide". Many of the library functions can be called either Guardian or OSS programs without doing anything special. That is pretty well-known.

What is probably less well-known is that it is possible to mix in one object file modules compiled for OSS and modules compiled for Guardian. Some library functions that can only be called from a module compiled for OSS can be used in a Guardian process by putting the calls in a module that is compiled for OSS, but included in the Guardian object file. I have never had a chance to try such mixing myself, so I don't know how easy it is to get working (and the manual does seem to say that not every library function works in such a mixed process, so it won't solve all cases).

The opendir() and readdir() functions are listed as ones that can be called from either Guardian or OSS modules. For some reason closedir() is documented as only being callable from an OSS module, but the module can be used in either a Guardian process or an OSS process. I have a feeling that all three of the functions work in the same environments, but I don't know whether the documentation for closedir() is correct or the documentation for opendir() and readdir() is correct. (There is a chance that all of them are incorrect, of course.) If I were you, I would try using the functions in your program or in a small test program compiled for Guardian and see what happens. If that arrangement does not work, try putting the calls to opendir() etc. in a module compiled for OSS and call that module from a test program compiled for Guardian and see whether you can get that to work. If you cannot get it to work, describe what you did and how it fails and we'll try to help.

[Keith Dick]

Oh, I overlooked the "non-native" part of your question. Maybe what I wrote applies only for native object files.

[Keith Dick]

It might be easier to write your own OSS program that accepts request messages on $receive, does the appropriate opendir(), readdir(), or closedir() call, and returns the results in a reply. You could start that program from your Guardian process easier than you could arrange to run the ls command (remember to give it a process name), and the communication with it probably would be easier to manage, too.

[wbreidbach]

Am Mittwoch, 23. Mai 2012 10:36:23 UTC+2 schrieb Manas:

Thank you Jojo for your comments to make things more understandable. Unfortunately I forgot to mention that I was talking about non-native Guardian programs.
Manas, is there any specific reason the program has to be non-native? There only very few exceptions that avoid a program being converted to native.

[Manas]

On May 24, 2:01 pm, wbreidbach <wolfgang.breidb...@bv-

The reason being the program need to be non-native because the
existing program is already on non-native. If I am going to use the
native mode for the particular enhancement then I need to change the
whole of the module for this, not advisable.
Thanks all for their valuable feedback.

[Keith Dick]

That depends on how large the "whole of the module" is, or rather, how much effort it is to convert it to native mode. And I hope you intended to say "whole of the program", since you cannot mix native mode and non-native mode modules in a given program.

Getting your existing program to compile in native mode might be significantly less work than either running an ls command or writing your own server to do the xxxxdir() calls. Without knowing anything about your existing program, I cannot say whether converting it would be easier, but don't dismiss the possibility out of hand. If it is pretty clean C code, it might take very little effort to switch to native mode.

[wbreidbach]

Am Mittwoch, 23. Mai 2012 10:36:23 UTC+2 schrieb Manas:

I completely agree, many or even most programs can be moved to native by just doing a recompile, even in TAL.