|
I had speculated on some of the implications of some numbers & what perhaps I ought to do about it >SSA owns 36,300 objects >QSECOFR owns 29,000 objects There seems to be agreement that it makes sense to have each BPCS environment's unique objects having a different profile as owner. This might also address another of our security exposures. User's security goes to BPCSMENU first then if they F3 by accident too far, they "fall out" of BPCS into OS/400, which is extremely dangerous for ordinary users. One of our consultants created a CL in system library list so that from the OS/400 command line outside of BPCS, the user can key in "BPCS" & enter & it takes them back to the BPCS production library. This has to be qualified because the right environment is no longer in the library list when you F3 accident too far. The security exposure is - suppose the user actually signed onto the test environment & F3 accidentally fell out - do I want a risk of user getting confused as to which environment they really now are in - so I had been adjusting some folks secondary place in profile to *SIGNOFF, to force sign on again to correct environment. Paul King said > (But I'll look up what you say about objects on one profile and consider it) There is so much stuff to learn in IBM class, that it is possible that I did not pick up precisely everything I should have learned, which I why I sought clarification of what kinds of numbers are a potential problem & whether my game plan made sense. There is so much clean up I want to do & somehow never time to do but a small fraction of what ought to be done, I sure don't want to be going down a path that is not in my company's best interests. Here's what my IBM teacher said when I asked about the same kind of clarification. > Subj: Re: Big Owners (of Objects) > > Al, > > Will try, as best I can, to answer your questions, however, you should > definitely take either the Security course *S6050) or the Admin course > (S6019). Even then, you may wish to hire an AS/400 security "specialist" > help you make final decisions on you security issues. I did take both those classes - I come away from each IBM class overwhelmed with stuff I want to apply at work, and need to review the student materials periodically to see what important stuff has been forgotten in the press of other duties. > 1. The performance problem with a single profile owning many objects > occurs primarily at Save/Restore time, not at production run time. Aha - a key point that did not sink into my brain, and stay there, while I was in IBM school. > A bigger problem with object ownership at the group level is that all > members of the group have the same authority (*all) as the group > (*owner). This either creates a security exposure, since all members of > the group have all access to all objects; or it creates a separate > performance problem of its own if you restrict the members' authority to > the objects. I am well aware of this, since when I called SSA to ask about getting the XRF to work, the Help Line told me that the only way for it to work, was to sign onto XRF as the group SSA profile & to have SSA set as an IBM Security Officer. I decided that I did not want XRF badly enough to make everyone a security officer. I have also been periodically alerting co-workers that the way we have set up stuff, to let any user within a department access any communal report of co-workers means that THERE IS NO SUCH THING AS A CONFIDENTIAL REPORT. Data may be confidential while on-line screens, due to BPCS security, but when something goes to spool & is not printed or cleaned up for a while, any co-worker can browse its contents. > The latter also creates something of an administrative > nightmare, trying to keep track of who needs what level of authority to > which objects. I think I might try to reduce the number of BPCS objects > by analyzing whether they're needed, then create another "master" BPCS > profile in addition to SSA. Then either SSA owns the objects and has no > members; and the other profile is a group profile through which your > users gain authority to BPCS objects - or vice versa. > > 2. It's my understanding that an empty file takes approximately 8K on > disk. Would probably be worth deleting unused ones after saving them. > > 3. I'm not surprised that QSECOFR owns 29,000 objects, but would > definitely try to reduce that number by using dummy owner profiles. > > 4. I would think that 36,300 owned objects is somewhat excessive, but if > you can identify and delete unused objects, then I think you should be in > decent shape. > > Good luck. > > Chris A Poole, III Thanks also to Chris Roberts for pointing at IBM AS/400 Support Line Technical Document # 10061758 Title: AS/400 User Profile Size Limit/Limit of Pointers to Objects Owned by a User Profile. +--- | This is the BPCS Users Mailing List! | To submit a new message, send your mail to BPCS-L@midrange.com. | To subscribe to this list send email to BPCS-L-SUB@midrange.com. | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: dasmussen@aol.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.