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



Maybe some of those vendors decided to put the development dollars into 
improving their product instead of getting around requiring QSECOFR. 
Granted it ain't that much to work around.  But, sometimes it amazes me 
how a "simple change" sometimes adds up.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





qsrvbas@xxxxxxxxxxxx (Tom Liotta) 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
02/09/2004 07:42 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
midrange-l@xxxxxxxxxxxx
cc

Fax to

Subject
RE: Can We retire the QSECOFR userid?







midrange-l-request@xxxxxxxxxxxx wrote:

>   1. RE: Can We retire the QSECOFR userid? (rob@xxxxxxxxx)
>
>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? 

Years ago, perhaps even back in S/38 days, I seem to recall that QSECOFR 
had certain capabilities that no other profile had. This seems still true 
today, but it also seems more limited to the DST QSECOFR thing rather than 
the signon profile that we're more familiar with.

Back even in early OS/400, we didn't have all the APIs so easily 
available. I believe that early vendors had to write more MI programs and 
had to use a bunch of techniques that are no longer needed. By requiring 
QSECOFR, I'd guess there were things that could be done behind the scenes 
more easily. I'm not aware of any such relevant things today.

IBM might have stuff to say about history along this line beyond what Ed 
has given, as would Leif perhaps.

Assuming QSECOFR was actually _required_ for some installations, the 
practice could've become an institution that's no longer relevant. If any 
vendor (not IBM) _requires_ QSECOFR, you can believe I'm gonna want to 
know a reason beyond "because it has all special authorities". Since I can 
obtain all special authorities outside of QSECOFR, there's an implication 
that either (a) something deeper is going on or (b) the install programmer 
needs some education. I'm wary of either possibility.

When I write an install program that needs special authorities, I call the 
QSYCUSRS API and simply check if it says I have those special authorities 
in the current job or not. Doesn't matter whether they come from the job 
user or the job user's group or a profile swap or they're adopted from 
higher up the stack. It's just not that hard to do.

But it _used_ to be much harder and it's probably just persisted.

Tom Liotta

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
New! Unlimited Netscape Internet Service.
Only $9.95 a month -- Sign up today at http://isp.netscape.com/register
Act now to get a personalized email address!

Netscape. Just the Net You Need.
_______________________________________________
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 thread ...

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.