Re: Package Vendor that changes IBM command Defaults.

Roger,

<<MODE(*REQUESTOR)>>

As a software house, what can we do to provide a "painless" initial
install or product upgrade?

If you were in our shoes, what would you do/expect?  How are different
security levels handled?
Do we ignore object security or roll our own? How do we deal with
in-house security beyond our control that may interfere with our install
script?

Now I'm not ragging on you, but if your QSYSOPR has to create profiles,
no can do.  It's beyond their profile authority. Install fails, you bad
mouth software vendor.  Software vendor -needs- QSECOFR to create new
profiles for secured ownership of objects.  Somewhere along the line a
QSECOFR "like" profile has to come into play.

How about this: The software vendor provides a profile characteristic
needed for installation and instructions necessary to create such a
profile (QSECOFR alias QINSTALL) that you can disable after install?

Bottom line: QSECOFR like profile -must- perform install/upgrade.

Wait, I could be wrong.  The entire product is PUBLIC(*YES)
OWNER(QDFTOWNER) or whatever is equivalent to an open barn door.

You pick. I'll deliver either way.  After all, it's your machine. Your
barn door. My lawyer can beat up your lawyer <g>

Roger Vicker wrote:
> 
> Hello,
> 
> <<MODE(*RANT)>>
> I have a customer where a vendor (name withheld to protect the GUILTY) for one
> of their packages, during a version upgrade, changed all the program create
> commands to USRPRF(*OWNER) AUT(*ALL) and all the file create commands to
> USRPRF(*OWNER) LVLCHK(*NO) AUT(*ALL). To top it off they compiled as a member 
>of
> QSECOFR. 
<<snip>>
> 
> <<MODE(*REQUESTER)>>
> 
> What I would like, without creating a total flame war, is a FEW items from 
>this
> esteemed group to show them as a backup to my lesson on how to play nicely as 
>a
> software package vendor. I can accept the USRPRF(*OWNER) _IF_ the owner is a
> special package owner and properly managed but definitely not QSECOFR!
> 
> <<MODE(*HUMBLE)>>
> Thanks In Advance.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---