Re: Permissions of IFS file created with QZRUCLSP

... I was just surprised about CL, Chuck, and yanking your chain a little.
:)  Actually, my RPG example was of the pre-ILE variety, just to be sure I
didn't introduce some "fix" by nuance.  Still don't know why that worked,
and I didn't have time to delve into it today.  (Parenthetically, at V5R3
even the O_INHERIT flag didn't help me, so I just hooked into one of our own
service programs that accomplishes the same goal - it reduced my code quite
a bit and everyone's happy.)

Regarding the QZRUCLSP API - you are spot-on about its usability in the
non-ILE world.  One example where I have used this technique, is to add
service program procedure calls to CASE tool-generated code.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"In the game of life it's a good idea to have a few early losses, which
relieves you of the pressure of trying to maintain an undefeated season."
        -- Bill Vaughan 


>    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.