× 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.


  • Subject: Re: Package Vendor that changes IBM command Defaults.
  • From: email@xxxxxxxxxxxxxxxxxxx (James W Kilgore)
  • Date: Tue, 22 Jun 1999 01:44:47 -0700
  • Organization: Progressive Data Systems, Inc.

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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.