Not so much to prove that I could, but because just by looking at both the MI source and the documentation for the API, it seemed a simple match, but a different language from which to test; i.e. all of the parameters passed by reference along with an "array" of data to suggest that some parameters should be treated by the API as instead having been passed by value when calling the procedure, each supported sufficiently in the CL. It was easy to code the CL from the given MI, while following along with the API docs [open() and call srvpgm proc]. The source compiled and created a stream file on my first try! I was actually surprised when I did not get an error on the API call, then even more surprised when WRKLNK showed the file was there, and finally bummed when DSPAUT showed *NONE.

I had no idea that API existed, but that might explain the [or was that even also a] seven parameter limit on an integrated application server and some other callable interfaces that I vaguely recall.? I am confident the ILE RPG does not use that API to invoke procedures; both exceeding that parameter limit and a trace should easily prove that. I guess any OPM program[mer] like RPG or CLP could take advantage for a program that for whatever reason should not move to ILE; for CL, that could be for use of DDM files with ALCOBJ for example which can cause problems since activation groups are implemented as separate jobs on the target.

I did later break my program when I added both the RMVLNK [del command] and DSPAUT to the CLP so as to avoid them every time I changed and recompiled the CLP. I ended up just removing the failing DSPAUT since I had earlier /corrupted/ the &filename with the null character, so I chose to just leave out the display authority request rather than have two versions of the file name :-) Notice in the source which I included below, that I even had declared [and used] a two-byte binary for the permissions at some point, thinking maybe that what was type mode_t, could have been smallint versus int... but no joy of course; eventually I found the definition where mode_t is declared as int. The docs do suggest the mode must be "a valid value", but I do not recall they mention the effect for having specified an invalid value; probably just to ignore. So perhaps there is something not obvious about the translation from the permission octal values to the integer value, or as alluded, that the API is just not doing the right thing with the parameter being passed to the open(). At this point I am leaning slightly toward defect, but almost as strongly that something might not be coded correctly just because it seems improbable the API is not also implementing similar requests and working fine [e.g. more generically making invocations for features like the IAS].

<code>

dcl &srvpgmnm *char 20 'QP0LLIB1 QSYS'
dcl &x00 *char 01 x'00'
dcl &procname *char 512 'open'
dcl &rtnvfmt *char 4 x'00000003'
dcl &openfmts *char 20 x'00000002000000010000000100000001'
dcl &nbrparms *char 4 x'00000004'
dcl &openflag *char 4 x'0100004A' /* text+creat+trunc+wronly */
/* &openflag *char 4 x'0900004A' /* inh+txt+crt+trun+wronly */
dcl &permiss *char 4 x'000001B6' /* 256 + 176 + 6 */
dcl &permissi *uint 4 438 /* 256 + 176 + 6 */
/*l &permiss *char 2 x'01FF' /* x'1C0' S_IRWXU owner aut? */
dcl &errcode *char 08 x'0000000000000000'
dcl &rtnval *char 2000
dcl &filename *char 20 'dltme.tst'
dcl &ccsid *char 4 x'00000025'

del &filename
monmsg CPFA0A9
chgvar &procname (&procname *tcat &x00 )
chgvar &filename (&filename *tcat &x00 )

call qzruclsp (&srvpgmnm &procname &rtnvfmt &openfmts +
&nbrparms &errcode &rtnval &filename +
&openflag &permissi &ccsid )

</code>

Regards, Chuck

On 3/17/11 6:21 AM, Dennis wrote:
Wow, thanks, Chuck. You did this in CL? What, to prove you could? :)

I really appreciate the follow-up. Strange that that one parameter
would be (apparently) mishandled while the others are intact. It
makes me wish, once again, that I could see code generated by the ILE
RPG compiler, which does handle this properly. Of course, it probably
(?) doesn't go through this API to get there, so there is that.

I can live with inherited rights in this case - thanks for that tip!
Life goes on, and I will march forward with that flag. But this
one's going in my back pocket for occasional review 'cuz it bothers
me. :)

Thanks again.

"CRPence"<CRPbottle@xxxxxxxxx> wrote:

On 3/16/11 12:58 PM, Dennis wrote:
Folks, I have posted MI code at
http://code.midrange.com/9176a9360c.html that:
- Deletes file mi-ifs-file.txt from the current directory
- Creates a new file by same name in the current directory
- Writes a line if all successful
- Closes that file

It creates the file just fine, except that there are no permissions
(flags ----------). I am absolutely convinced that this is my error
(I used the same concept in RPG and it worked great), but my eyes
don't see where I might have gone wrong. Would some kind soul mind
steering me in the right direction?

<<SNIP>>

I created an equivalent CALL to the Call Service Program Procedure
(QZRUCLSP) API from a CLP to invoke the open procedure in QP0LLIB1
and I got what I infer are the same [at least similar] results
creating a file in my directory under /home; i.e. *NONE data
authority was the effect. When I changed the oflag mask to include
O_INHERITMODE I got the same authorities to both *PUBLIC and to my
user\owner as those which were set for my directory under /home.
However attempts at changing the permissions mask for the mode
parameter in that same CLP saw no change for any of the owner,
group, or public data authorities even when passing 0d511. :-(


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2021 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.