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@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. :-(