× 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: Big Owners (of Objects)
  • From: MacWheel99@xxxxxxx
  • Date: Sat, 15 May 1999 13:47:50 EDT

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


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.