|
But that's different than a shared MYSECOFR. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Bruce Barrett" <bruce.barrett@xxxxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 02/09/2004 06:34 PM Please respond to Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> To "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx> cc Fax to Subject RE: Can We retire the QSECOFR userid? At our shop, each of the system programmers has a "Q" profile. It has the same authority as QSECOFR but, is part of the QSECOFR group. The owner of the owner is the *GROUP. This way I have the authority I need to do my job, and we review by user if necessary. The only time we use QSECOFR is when we load a new third party product that requires or checks for QSECOFR. Bruce Barrett -----Original Message----- From: Vern Hamberg [mailto:vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx] Sent: Monday, February 09, 2004 3:17 PM To: Midrange Systems Technical Discussion Subject: RE: Can We retire the QSECOFR userid? I can think of a couple reasons not to use QSECOFR all the time: 1. Object ownership - it might be possible to exceed the limits on number of objects owned 2. Audit trail - using the generic IDs means you have no idea who did what to whom Vern At 04:49 PM 2/9/2004 -0500, you wrote: >Does anyone really see a difference between having the generic QSECOFR or >a generic MYSECOFR with the same authorities? Granted, there are some >very limited applications where you must be QSECOFR, (ptf's ain't one of >them). But does creating the MYSECOFR give you any additional security? >None that I can think of. Oh, I suppose you could disable QSECOFR and >then a hack trying it would have a bear of a time getting in. But, other >than that? If so, why bother? > >Rob Berendt _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
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.