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



Ken,

Field level security for "read" has not been enabled since the time that
Field level security was first introduced (Was that V4R1???).  If I
recall, the technical explanation was "performance" IIRC.  If that is
the case, then it's possible that this limitation should be revisited in
light of both the current privacy initiatives and the greater power of
the machines.

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 Graap, Ken
> Sent: Thursday, November 17, 2005 2:18 PM
> To: Midrange
> Subject: Field Level Security
> 
> I'm trying to understand why is isn't possible in DB2/400
> to use field level security to prevent ALL access to a
> column (field) in a *FILE using field level security.
> 
> It looks like the only Data Security attribute that can be
> restricted at the field level is UPDATE... as in:
> 
>       REVOKE UPDATE(oaddat, oadtim) ON KENNETH/CVTOBJAUT
> FROM PUBLIC
> 
> Does anyone know the "technical" reason for not being able
> to do this:
> 
>       REVOKE READ(oaddat, oadtim) ON KENNETH/CVTOBJAUT
> FROM PUBLIC
> 
>                                       or
> 
>       REVOKE ALL(oaddat, oadtim) ON KENNETH/CVTOBJAUT FROM
> PUBLIC
> 
> Note: oaddat and oadtim are fields within the table
> CVTOBJAUT.
> 
> I know field access can be restricted through the use of
> views, but I'm trying to restrict access to certain fields
> when someone uses an ADHOC file editor against a physical
> file.
> 
> 
> Is this just a restriction for DB2/400 or do other DB
> products (MS SQL, Oracle) have the same restriction?
> 
> Kenneth
> 
> ****************************************
> Kenneth E. Graap
> IBM Certified Specialist
> AS/400e Professional System Administrator
> NW Natural (Gas Services)
> keg@xxxxxxxxxxxxx
> Phone: 503-226-4211 x5537
> FAX:    603-849-0591
> ****************************************
> 
> --
> 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 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.