[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

1645.0. "Form in DEVELOP gives ACC VIO" by TAV02::CHAIM (Semper ubi Sub ubi .....) Thu Oct 22 1992 14:22

I just got finished diagnosing a problem with a customer and although I know
the cause and what to do to "fix" the problem, I do not understand the
underlying problem.

The customer has a very highly customized ALL-IN-1 with lots of code level
integration. Recently they decided to start using DDS. Since then, certain users
would receive access violations using their customized applications which
involved mail address validation. Our first discovery was that ONLY the users
which had APPPRV were affected. Then we weeded it down to a form in the
DEVELOP.FLB. This form is a very simple ENTRY form which referrences a data
file containing entries for those users who are permitted access to this
application. The form in DEVELOP is identical to that in oa$lib:siteoaform. In
fact we exchanged the forms and receive the same results.

The bottom line is, remove the form from DEVELOP and the application runs O.K.
As long as the form is in DEVELOP, then all users with APPPRV will get an ACC
VIO using this application.

Anyone have any ideas?

Thanks,

Cb.
T.RTitleUserPersonal
Name		DateLines
1645.1rweAIMTEC::BUTLER_TThu Oct 22 1992 15:0611
    cb,
    
    have other forms been added to develop before/after removal of the
    entry form?
    
    is the filename pointed to by the entry form the same on both the
    devleop and site versions?
    
    have you doubled checked file ownership/protection/acl?
    
    Tim
1645.2Answers to .1 ..TAV02::CHAIMSemper ubi Sub ubi .....Thu Oct 22 1992 15:2924
Re. .1:

>    
>    have other forms been added to develop before/after removal of the
>    entry form?

Not sure I understand your question. What is the relavence?

>    
>    is the filename pointed to by the entry form the same on both the
>    devleop and site versions?
>    

Yes, the forms are identical. Just to make sure we even switched them
(extracted from siteoaform into DEVELOP and vice versa) and got the same
results.

>    have you doubled checked file ownership/protection/acl?
>    

You bet! Besides we were working with all privs.

Thanks,
Cb.
1645.3AST again?IOSG::TALLETTGimmee an Alpha colour notebook...Thu Oct 22 1992 15:455
    
    	Do they do AST level processing in the CLI functions?
    
    Regards,
    Paul
1645.4size and index file usedAIMTEC::BUTLER_TThu Oct 22 1992 17:0111
    Cb,
    
    re .2
    
    I was just checking to see if size of the library was a factor and
    if the actual index file used was different.
    
    Let me look through some old stuff and see what I can find.
    
    
    Tim
1645.5Form set?SCOTTC::MARSHALLThu Oct 22 1992 23:4817
Hi,

Does the form contain /MORE, .MORE, .FORM_SET, etc?  If so, the other forms
thus referenced must be in the same form library:

Suppose these other forms are in SITEOAFORM, but not DEVELOP.  Then if the
"bad" form is in DEVELOP, and DEVELOP is in the affected users' search orders
before SITEOAFORM, then they will pick up the DEVELOP version of the form.

ALL-IN-1 will therefore look for the "more" forms in DEVELOP, and be unable to
find them, and an error is signalled.  (cf if all the forms are in, and only in,
SITEOAFORM, all the forms are found without error)

Normally, this results in an error message.  But if you're doing something odd
(eg Paul's suggestion of ASTs) then an ACCVIO sounds reasonable! :-)

Scott
1645.6/MORE accepts forms in other form librariesCESARE::EIJSAll in 1 PieceSat Oct 24 1992 10:3212
    
    Hi Cb,
    
    A '/MORE' in the form shouldn't be the problem, a .MORE and .FORM_SET
    on the other hand with the missing forms might (as suggested).
    
    Remember that when a form is moved to the Live area the form is deleted
    from DEVELOP.FLB (unless the customer changed that 'feature').
    
    Ciao,
    
    	Simon
1645.7I don't think so ....TAV02::CHAIMSemper ubi Sub ubi .....Sun Oct 25 1992 10:5012
Re. .3:

>    
>        Do they do AST level processing in the CLI functions?
>    

Not that I am aware of, however I will be meting with the one of the
programmers, and I will pose this question to him.

Thanks,

Cb.
1645.8FMS Working Space was 0...TAV02::CHAIMSemper ubi Sub ubi .....Mon Nov 02 1992 14:3023
Using the debugger we were able to trace the ACC VIO to a SET$WKSP call to FMS
with a WKSP value of 0. 

The customer's code does its own FMS form management. Before doing anything,
this code issues an FDV$RETCX call to retrieve the current WKSP so that it can
return this value before returning to the A1 code. 

Normally, the WKSP would NOT be a value of 0, and indeed when the form being
referrenced is exclusively in SITEOAFORM then the value is not 0. However, when
the form being referrenced in is in DEVELOP.FLB, then the WKSP value returned
is 0.

Does this "starnge" behavior have any logical explanation?

1. Does A1 erase the WKSP under certain circumstances?
2. Why would the placement of the form change the behavior?

Thanks,

Cb.