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



Glenn,

Wow!  Lots of suggestions - and I don't like any of them :)

I guess that's not completely true, because I agree with those that
suggest disabling profiles is an incomplete solution because it does not
bounce users who are already working on your files - if they are active
at the time you disable them, they will still be active and could
potentially muck with your files even after you disable them.

The suggestions regarding QINTER, or the user's initial program (INLPGM)
are unappealing because they assume that users can only connect to the
database through workstation (telnet) devices - and that is simply not
accurate.  Even if you end QINTER, your users can still launch ODBC or
FTP request against your files.  And even if they don't change the data,
they could still lock the files and mangle your other process. (And now
I'll put my security hat on and say that this can be a problem 24x7 -
but list members have heard this refrain from me too often).

Allocating the library is not an option because A)You cannot exclusively
lock (*EXCL) a library (the ALCOBJ command won't let you), and B)Though
you can get an exclusive read-only lock (*EXCLRD) on the library, a
read-only lock will not prevent someone from changing the contents of a
database file that resides in that library :(

I think your best option is to lock the individual files in question.
If there are a lot of them, you can list them in a file and spin through
the list with a program.  The only complication you'll have is writing
an exception routine to deal with any file that cannot be allocated
(send a message to the User, or QSYSOPR, etc.).  This is the only method
I have seen that is sure to keep users out of the files - everything
else is a "best guess".

That's my .02.

jte



--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Thompson, Glenn
> Sent: Monday, February 06, 2006 9:13 AM
> To: Midrange Systems Technical Discussion
> Subject: Technical and Philosophy
> 
> I'm new to at the Iseries world and I need some help both,
> technical and
> philosophical.
> 
> 
> 
> I need to keep users out of my files after 7:00 PM.
> Someone has
> suggested that we allocate the files and that would keep
> the users out.
> Another suggestion was that we secure the users out by
> disabling the
> user profiles.
> 
> 
> 
> Which approach would be best/easiest?
> 
> 
> 
> 
> 
> --
> 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 ...

Follow-Ups:

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.