I found a doc with the list of generic options but I do not see a way to
change the authorizations.. it refers to SQL options.
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/ddp/rbal1faquserofdb2connspecify.htm
you could try to set the package owner as a special role (goup profile)
and makes you and the production user member of that group profile
Paul
From: Jan Moeyersons <jan.moeyersons@xxxxxx>
To: "midrange-l@xxxxxxxxxxxx" <midrange-l@xxxxxxxxxxxx>
Date: 03/08/2018 18:27
Subject: *SQLPKG created by remote BIND from DB2 z/OS and
authorisation
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Dear Midrangers,
I have the need to run a COBOL program on mainframe (z/OS) and access from
that program a table on iSeries through embedded static SQL. So, I prepare
my COBOL program (pre-compile, compile, BIND) on mainframe and then run a
remote BIND (just a regular BIND in DB2 mainframe, but with the location
name of the iSeries database specified in the package name) to create the
*SQLPKG required at runtime. So far so good.
But....
The *SQLPKG is created with the OWNER (as specified in the BIND statement)
as the owner of it (well... what would you have expected?) and with three
entries in the DSPOBJAUT list:
- *PUBLIC *EXCLUDE
- <owner group> *ALL
- <my GrpPRF> *ALL
Now, when this COBOL program will run in production, it will run under a
production user profile (not mine, of course). That production user
profile is not a member of the <owner group> and, obviously, not a member
of my default group. In order to grant the production user the authority
to execute the package what I actually want to see in the output of
DSPOKBAUT is:
- *PUBLIC *USE
- <owner group> *ALL
Let's please not start to discuss the security implications of granting
*USE (or indeed anything) to *PUBLIC. I know, I know...
My question is: How can I go about on mainframe, during program
preparation, to tell the iSeries that the authority on the *SQLPKG must be
different from the default settings?
I have googled already a lot, but could not find anything that would do
the job. Yes, of course, I can change the authority once the *SQLPKG is
created, but that would require a manual intervention on the iSeries and
that is just not acceptable. Remember: the program preparation is run by
the developer when in the development environment, then later when the
program is promoted to production, by the change management suite that is
running under a dedicated production user profile.
So, is there any means of specifying the authority settings in the BIND
command? I see there is the GENERIC option in the z/OS BIND command to
specify options to be transmitted to the target DB2. But what options
should I specify in there (if at all there are any to be understood by the
iSeries)?
Thanks and very best regards,
Jantje.
midrange.com
