[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

1053.0. "ACC VIO editing forms in CM" by TAV02::CHAIM (Semper ubi Sub ubi .....) Wed Jul 15 1992 12:38

A customer who very recently upgraded to V2.4 with patches has complained that
application developers started to ACC VIO trying to edit certain forms in
customization management. Granting SYSPRV to these users alleviates the
problem. The problem seems to exist only with newly selected form.

Any ideas?

Thanks,

Cb.
T.RTitleUserPersonal
Name		DateLines
1053.1SIOG::T_REDMONDThoughts of an Idle MindWed Jul 15 1992 12:524
    Certain forms?  Not all forms?  Is everything in CM (for V2.4) owned by
    OA$PRVAPP or are there some other file ownerships around?
    
    Tony
1053.2What are these 'newly selected' forms?CESARE::EIJSAll in 1 PieceWed Jul 15 1992 13:2916
    
    Hi Chaim,
    
    Are these forms:
    
    	- New created forms in CM?
    	- Forms in Base (ADE) which are being copied to Development area?
    	- Customized Base forms available in the Development area?
    
    All come down to the ownership/protection/ACL on the form libraries,
    and (as Tony indicated) the ownership of the files in the Development
    area. 
    
    Ciao,
    
    	Simon
1053.3OA$DATA_SHARE:CM$FORM$LIBS.DAT W:RWE ...TAV02::CHAIMSemper ubi Sub ubi .....Wed Jul 15 1992 14:0822
O.K. after very extensive investigation using TRACE with me on the phone and
the programmer at her terminal I got it.

First we used DCL trace and realized the ACC VIO was during execution of the DO
script oa$lib:cm_lock_libs.com.

Next using SCRIPT trace we fouund out the command directly causing the ACC VIO
was DATA_FILE OPEN/READ/WRITE CM$LOCK CM$FORM$LIBS.

Then we tried this command interactively and got an insufficient privelege or
protection violation trying to open oa$data_share:cm$form$libs.dat.

This file had W:RE - changed it to W:RWE and everything seems to work fine.

I still cannot understand:

1. Why the protection was changed during the upgrade.
2. Why BYPASS wasn't enough - only SYSPRV was enough.

Thanks,

Cb.
1053.4Some backgroundSIOG::T_REDMONDThoughts of an Idle MindWed Jul 15 1992 14:4720
    The upgrade to V2.4 adds some new records to CM$FORM$LIBS to use for
    the V2.4 locking mechanism.  I don't know why BYPASS wasn't enough,
    ALL-IN-1 was being careful again, I expect.
    
    Note that the script has a small error in the distributed version
    (V2.4).  Immediately after the line
    
    DATA_FILE OPEN/READ/WRITE CM$LOCK CM$FORM$LIBS
    
    there's a line
    
    DATA_FILE LOCK/ON
    
    which should be
    
    DATA_FILE LOCK/ON CM$LOCK
    
    I mention this purely in the interest of trivial pursuit.
    
    Tony
1053.5Protection <-> DATA_FILE commandCESARE::EIJSAll in 1 PieceWed Jul 15 1992 16:0312
    
    Chaim,
    
    I don't have a V2.3 system at hand, but if someone has, please
    check the protection mask for OA$DATA:CM_FORM_LIBS.DAT? 
    
    I wonder if the protection changed from V2.3 to V2.4. I thought it had 
    to do with the DATA_FILE xxx commands introduced in V2.4.
    
    Ciao,
    
    	Simon
1053.6Digital Press EY-H952E-DPWARNUT::RICEA human resourceThu Jul 16 1992 12:029
    Re .4
>>    I mention this purely in the interest of trivial pursuit.
  
    Also mentioned on page 340 of that excellent book "ALL-IN-1 - A Technical
    Odyssey" by the inimitable Tony Redmond.
    
    :-)
    
    Stevie.