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
(Continue reading)
RSS Feed