Re: Permissions of IFS file created with QZRUCLSP

   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-/[email protected]>  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. :-(
>>
_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mi400
or email: MI400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.