×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
The OS output file feature can CRTDUPOBJ of those files to effect
creation of the named OUTFILE(), even if\when the user is not authorized
to do so. That is, the authority for *PUBLIC need not be any more than
*USE which would allow DSPFFD and DSPFD for a user to learn the details
of the file and fields, to understand how to use the files. An ordinary
user should IMO *not* be able to actually change the attributes of the
[model output] files. When a command that uses the model outfile runs
and the named OUTFILE() is created, the user that issued that command
[normally] gets *OWNER rights to the object that was created, so
AUT(*CHANGE) for *PUBLIC would be moot.
The OP had the authority customized to grant sufficient authority for
the /application profile/ to perform its own CRTDUPOBJ, rather than
allowing the outfile-command perform the request. Applications often
require their own CRTDUPOBJ to perform customizations; e.g. create a
duplicate of the model, then CHGPF SIZE(*NOMAX) for an upcoming request
to DSPOBJD *ALL/*ALL for which the model file has SIZE(10000). For the
case of *PUBLIC having even AUT(*CHANGE), *CHANGE authority is still
insufficient to enable CRTDUPOBJ without using adopted authority [in the
application]; i.e. *OBJMGT is required above & beyond *USE to the object
being duplicated.
If the various /model output files/ are shipped as part of the OS
with *CHANGE as the authority for *PUBLIC, that means *any* user can
issue a variety of requests that change the object; e.g. CHGPF
QSYS/QAFDMBRL TEXT('I just hacked this file') SIZE(1 1 1) Certainly if
true, that is a bad thing?
As /model/ files, these can be and are often customized. However I
would likely not grant a private authority if that private authority was
being propagated to every copy made by the OUTPUT(*OUTFILE) invocations.
Instead I might create a program to duplicate the file. If duplicates
of the files are made into a library from which applications would make
duplicates, system Change Management requires that those files be
created [and customized] again from the copies in QSYS or QSYS29xx after
an upgrade [or in the unlikely event the model file were replaced in a
PTF].
Regards, Chuck
Carel Teijgeler wrote:
I think the authority *CHANGE for user *PUBLIC is understandable on
those files.
The commands using those IBM supplied files, which originally do not
have any members, have to duplicate their associated output file and
add a member to it, before filling it with data.
It is also common practice and advised not to change the default
settings on IBM supplied objects, so I wonder why this setup of
authority, when the commands used create a copy at the moment the
output file does not exist. But then, I do not know the philosophy
behind this setup.
Instead I would have created my own master (base) files for my
application, based on the IBM supplied files.*
CRPence wrote:
Charles Wilt wrote:
<<SNIP>>
After a v5r2 --> v5r4 upgrade on our QA system QAFDMBRL was back
to the IBM default of *PUBLIC change with no additional private
authorities.
That suggests *PUBLIC has *CHANGE? Hmmm... that seems excessive;
i.e. that authority would allow any *peon user to issue a CHGPF
QSYS/QAFDMBRL given that user has access to a command line.?
<<SNIP>>
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.