|
How about this situation that I see all too often: Every program and EVERY FILE have *PUBLIC *ALL! It's just amazing what these customer's reaction is when you pull up one of their payroll files in DSPPFM, or CA, or RUNQRY, or SQL, or DFU, or DBU, or FTP, or EXCEL, or .... Incredibly the vendor says: "So if it hurts when you start those servers, don't start those servers. Oh and I'd restrict command line too, that'll cover it!" Simply amaaazing. - Larry alan shore wrote: > > I completely disagree - as would many if not all internal and external >auditors to ANY company. With ALLOBJ authority, to objects in the application >you can really create havoc. > Anything that is in a DEVELOPMENT environment (ONLY), you should have >complete access to, that I agree with. > Anything that is in a PRODUCTION, - or - a User Acceptance QA environment, >you should have USE authority only. > > >>> "Henrik Krebs" <hkrebs@hkrebs.dk> 09/13 2:49 PM >>> > Here is what I as an IT consultant need to work effectively. The same thing >probably > apply to software companies I guess. > > o All-authority to objects in the application (Directly or via GRPPRF). > o A good cooperation with a person at the > customer for (rather infrequent use of) *ALLOBJ and *SECADM - creating > userprofiles, fixing the "oops - Object changed owner when restored" (we > all make mistakes sometime) etc. > o An answer Yes/No to the question "Want a joblog for each job/session?"). > Personally I've only met 'No', even when the infrequent use of *ALLOBJ > was managed with the loan of QSECOFR. > > The sentence "We refused to give them *ALLOBJ rights, period." or "after a >specified > time, it cancels the dial in job," really sounds like a lack of 'good >cooperation' and > more like "Do your bloody job and don't bother us". If I - in that situation >- should do > the bloody job, I should also need *ALLOBJ! > > Henrik > http://hkrebs.dk > > - -----Original Message----- > From: Graziano, Marie [mailto:mgraziano@badgermeter.com] > Sent: Wednesday, September 13, 2000 8:37 AM > To: 'Midrange' > Subject: Why do software companies always want ALLOBJ > > I am currently working with a software vendor that is asking for the userid > for the software to have ALLOBJ. Now we all know that this is a very very > bad move. However, in order to get the product up and running I had to do > it. What are other companies doing? And why do the software vendors not > understand what ALLOBJ is and does. IF the user id was not used to sign in, > then I would not have a problem, but the software signs in with the userid > each day. > > Marie Graziano > > +--- > | 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 > +--- > > +--- > | 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 > +--- -- Larry Bolhuis | Arbor Solutions, Inc | IBM AS/400e - Get There First! (616) 451-2500 | (616) 451-2571 -fax | It's 10PM. Has your NT Server had it's lbolhuis@arbsol.com | therapeutic re-boot yet today? +--- | 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 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.