Conference iosg::all-in-1_v30

    Clive,
    
    Interesting - We just had two of these horseless CARTS over here and on 
    one it stack dumped at the same point. In our case the CART cleaned up 
    after itself so we didn't have any datafiles or reports to look at
    On the other it looped and all we could see was a very eccentric 
    definition of the OA$SITE logicals.
    
    Did you get any reports or datafiles left around and what do you
    OA$SITE thingies look like.
    
    In the firstcase the customer was not prepared to run the CART again for
    another 12 hours and decided to go ahead and just do the upgrade
    unfortunately so we didn't make it a STARS article or anything. The
    other is still being worked I think.
    
    Hopefully your customer has a little more data to go on and we can track
    this one down.
    
    Regards,
    
    Andrew.D.Wicks

    Hi,
    
    	Clive is definitely not on his own with this problem - I only sit a
    few feet away from him, and I am seeing the same problem as well for
    another customer. Customer is currently checking his process quotas,
    but again the problem occurs by a customer running the CART on v2.4.
    The only difference is it access violates on Creating CART script...
    
    
    	Could there be any problem associated with v2.4 causing the
    problem, that would not be seen by running the CART on v3.0 (clutching
    at straws here!!)
    
    
    
    			Julie

    
    I tested the CART, and to be honest I never saw it ACCVIO like that.
    
    Don't forget that if if crashed in creating the site elements report
    then you should have the other reports which are those which tell you
    about the conflicts etc.  The Site elements report is simply a
    list of element in your Site areas which aren't in CM.  So you should
    at least have some reports to be working on.
    
    Check the other reports to see if they look resonable.  We can then
    cut down the possibilities.
    
    Ta,
    
    Mike

    Given that it is accvio'ing at different reporting stages I guess it
    has something to do with MERGE under V2.4 since this is what we use to
    generate the reports.
    
    Are there any quota probs with building large reports with MERGE under
    V2.4?
    
    Remember you can always run the CART again when you get to V3.0 - if the
    reports work using the interactive CART then I guess it does have
    something to do with V2.4.
    
    Kevin

    Clive's Customer appears to be patched upto 603 and has the WPS-PLUS
    V4.0 option installed.
    
    Julie's customer hasn't got any patches
    
    So does anybody have any other ideas
    Suzanne 

    Andy,
    
    	Suzanne's theory today seems to be the old gem Channelcnt,  only
    have to convince the customers to run the Cart AGAIN.  
    
    Suzanne 

    What SYSUAF parameters are set for the account running the CART? I like
    to see lots of BYTLM, PGFLQUOTA, large WSEXTENTS, WSQUOTAs etc. 
    Clearly the system also needs to be able to satisfy process demands, so
    CHANNELCNT may come into play too.
    
    Tony

    Tony,
    
    On our latest report the customer had already run pre-check and upped
    all the parameters it reported as being too low to the v3.0 recommended
    values and SYSUAF values for the ALLIN1 account matches the v3.0 doc set.
    
    Does the CART when run on v2.4 really require higher values than for
    a v3.0 upgrade? or does it depend on the size of the report that it's
    trying to generate.
    
    On this site the CONFLICT$ELEMENTS and SITE$ELEMENTS files are huge
    - well a lot bigger than anything I saw in Field Test or I suspect
    Mike saw in IOSG.
    
    Regards,
    
    Andrew.D.Wicks
                                       

    I'm pretty sure that the size does matter.  After all, you're giving
    ALL-IN-1 more work to do (records to deal with, etc.), and VMS process
    quotas seem to help.  At least, any time I have met this kind of
    problem (trying to work with somewhat more data than normally
    expected - with products other than ALL-IN-1), an increase in some of
    the process quotas seemed to help.  DECwrite comes to mind in this
    instance.
    
    Try it - better to do something rather than sit on ones' hands.  Double
    the recommendations given in the installation guide and see what
    happens.
    
    Tony
    
    P.S. HOw many records are in these files?

    Incidentally, if you want to run the CART from the installation and
    bypass some of the checks it does then you can set the following
    logicals to Y before running VMSINSTAL:-
    
    OA$CM$CART$QUIET - do not log details to screen
    OA$CM$CART$NOSANITY - bypass the checking of valid live and development
    versions
    OA$CM$CART$NOSCAN - bypass scanning elemenst for calls to deleted
    elements.
    
    If you are running the CART more than once from the installation
    procedure then these logicals can help speed up subsequent runs. (these
    logicals are set automatically when using the interactive CART based on
    the answers given to the various questions).
    
    Also, the reporting part of the CART reports on details held in the
    file CM$CART$CONFLICT$ELEMENTS.DAT (which will be in the top level
    site directory). If this file is not deleted when the CART bombs out
    then at least you can have a look at it interactively to get a list of
    the status codes given to any elements that were in conflict.
    
    HTH somewhat,
    Kevin

    I found this article in STARS and thought that it might be helpful here
    as I am not sure if this has been fixed or not as the Engineering
    response implied it would be some time in the future.
    
    This may be a clue but may not apply as Simon stated that
    the CART does not use compiled BLPs.
    
    Faith
    
*****************************************************************
Boilerplate Compiled In TXL When Executed Generates Errors


COPYRIGHT (c) 1991, 1992 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.

PRODUCT: ALL-IN-1 V2.3

SOURCE: Customer Support Center/Atlanta USA

\by Faith Donohue 
\OA943, THR-10544, SRF

PROBLEM:

The MAILMEMO1.BLP and MAILMEMO2.BLP boilerplates were modified on the 
system in ALL-IN-1 V2.3.  In testing, when used by the MERGE function 
they worked correctly. But when these same boilerplates were compiled 
into the TXL and used with the MERGE function they generated either 
errors as specified below or Access Violation and Stack Dumps and the 
user is terminated abnormally from ALL-IN-1.

Error messages generated:

   OA-F-VMGETFATAL, LIB$GET_VM failure, 111 bytes at 7FEE9E70 - 
OA$MSG_PUT_LINE    LIB-F-FADBLOADR, bad block address 

   LIB$FREE_VM failure, 2493 bytes at 004D3DE0 - in OACBT\oa$cab_at...Press
 RETURN    LIB$FREE_VM failure, 204 bytes at 004D7C38 - - routine
OA$SEL_DELETE_PTAB 

CAUSE:

The boilerplate experiencing the problem contains at least one (logical)
line (command/merge directive) which is very long (i.e. over 512 bytes) 
which overlaps a physical line using continuation markers (<->).
            
After the boilerplate is compiled in the TXL, the ALL-IN-1 function:

 <OA$TXL_LIST newblp,BLP,CMTXL

display will also be corrupt if the boilerplate contains a directive which
exceeds this limit, it may display this error:

%OA-F-VMGETFATAL, LIB$GET_VM failure, 68 bytes at 00000000 - OATXL Dummy-RAB
-LIB-F-BADBLOADR, bad block address
            
This limitation did not exist in V2.2 of ALL-IN-1.

SOLUTION:

The problem which you have described arises from an undocumented
restriction of the current ALL-IN-1 product. Boilerplate files, which
are processed internally in VLF format, cannot have lines which exceed
512 bytes in length. This length limit applies to lines after they have
been parsed and continuation lines have been joined together meaning
that the restriction applies to the total length of a logical line
(irrespective of how many continued lines it occupies).

We hope to lift this restriction in a future major release of the
ALL-IN-1 product, but until that time, we recommend that you limit
lines in boilerplates to less than 512 characters. We shall attempt to
include this restriction in future versions of the ALL-IN-1
documentation set.
       
If the logic in the boilerplate which exceeds the limit is part of a
 <&OA directive, you may consider creating a script which contains
the necessary code, and invoking the script in the <&OA directive
in the boilerplate.

    
    

    I moved 884.13 to note 918.5 where I felt Marty's speech about the
    first amendment (or whatever) was more appropriate (:==:)
    
    Regards,
    
    Andrew.D.Wicks

    
    	Has anyone found a algoritum for calulating what authorize and
    sysgen parmaeters need to be set to.  As any site with the original
    problem managed to run the Cart yet?
    
    (were no further forward here either.)
    
    Suzanne
    
      

    
    Hi,
    
    I've tried to reproduce the problem, but up untill now no success. 
    
    In case the size of the CM$CART$SITE$ELEMENTS (better, number of
    records) would be the culprit, I loaded a dummy one with �17,000
    records. The V2.4 system itself contained another 100 customizations,
    but no luck.
    
    The account used (ALL-IN-1 MANAGER) has some quota which are over the
    suggested ones, so I've reduced them and started the test again.
    
    The system running is ALL-IN-1 V2.4, no patches, some Assets.
    
    Andrew, as I haven't any documentation of any patches around, can you
    recall if one of the patches did something with the MERGE code (or came
    very close to it)?
    
    Trying...
    
    	Simon
    

    Simon,
    
    There's a fix in K602 and another in K603 that deals with MERGE and some 
    others in other patches that might come into play but unfortunately the 
    documentation we receive with each patch is sanitised for customer eyes so
    some of the problem descriptions are very ambiguous and it's difficult
    to tell.
    
    So far we've had little success here in encouraging our customers to
    run the CART again - you know the old saying "you can lead a horse to
    water, but you can't make him pull the CART" - groan!
    
    Regards,
    
    Andrew.D.Wicks
    

    
    I've been working on trying to reproduce this problem and you guessed it
    ,to no avail.
    
    I am running the CART from the ALL-IN-1 account and have set the
    account parameters to that of the customers account.  I have dumped
    in 600 or so files to create a nicely sized site elements report and 
    drop the disk space *real* low incase I can get merge to ACCVIO like
    that.
    
    I'm currently re-rerunning the CART again.  If I still cannot get it to
    ACCVIO then I may add lots of records to CM$SITELOG and see if actual
    records in CM$SITELOG will help squeeze an ACCVIO out of it.
    
    Mike

	Hi,

	Our IS people ran the CART on our tools cluster here in Brum and 
	a stack dump at the same stage as that mentioned in 884.0 occured.
	It exited without producing any .Txt files as described in the manual
	but has created the .Scp file as well as a few CM$CART*.dat files, one
	of which (CM$CART$BASE$CHANGES$OA$V30$PRIMARY.Dat) is about 3.5k blocks
	It is running V2.4 (not Core) with no patches on it. There is a log 
	file with it so I checked it for the status codes...we had 2 with a 
	status of "M"....form Default and Mailmemo2.Blp....Default also returned
	a status of D. I advised them to move those 2 into CM. Because of time 
	limitations IS have decided to move ahead with the upgrade regardless
	but if any of you can make use of the files listed below, drop me a mail
	@Bio and I'll get em to you. I can sort of understand Default as its got
	stuff in there from about V2.1 of ALL-IN-1, however the boilerplate is
	standard.
	
	Regards,
		Se�n 

-----------------------------------------------------------------------
	Directory DISK$ALLIN1:[ALLIN1.SITE]

	CM$CART$BASE$CHANGES$OA$V30$PRIMARY.DAT;1
                       3522/3522    16-MAR-1992 14:19:08.19
	CM$CART$BASE$MESSAGES$OA$V30$PRIMARY.DAT;1
                         81/81      12-MAR-1992 09:49:13.08
	CM$CART$CONFLICT$ELEMENTS.DAT;1
                        204/204      2-JUL-1992 09:32:38.74
	CM$CART$DELETED$ELEMENTS.DAT;1
                        123/123      2-JUL-1992 09:32:41.66
	CM$CART$SITE$DIRECTORIES.DAT;1
                          9/9        2-JUL-1992 09:31:51.99
	CM$CART$SITE$ELEMENTS.DAT;1
                         15/15       2-JUL-1992 09:32:05.31
	CM_CART_SCRIPT_V30$PRIMARY.SCP;3
                        546/546      2-JUL-1992 12:12:38.35
	CM_CART_SCRIPT_V30$PRIMARY.SCP;2
                        546/546      1-JUL-1992 20:00:31.08
	CM_CART_SCRIPT_V30$PRIMARY.SCP;1
                        546/546      1-JUL-1992 16:32:29.99

	Total of 9 files, 5592/5592 blocks.

    
    
    
    
    ALL,
    
    I'm a happy man.
    
    I reproduce it!
    
    I added lots of dud files to generate a large site elements report but 
    that didn't give me the ACCVIO.
    
    I copied a CM_SITELOG from one of our other systems with over 450
    records and got the following
    
    Could not copy CART Script file
    R7QUAE$DIA4:[SYS0.SYSUPD.A1030]CM_CART_SCRIPT.S
    Please run the CART again to get a new report
    %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
    address=7FF3A6CC, P`
    
      Improperly handled condition, image exit forced.
    
            Signal arguments              Stack contents
    
            Number = 00000005                656C6946
            Name   = 0000000C                00000020
                     00000000                00282778
                     7FF3A6CC                00000001
                     8032B250                08FC0000
                     03C00001                7FF02404
                                             00236C39
                                             00000000
    
    The only differnce is the message about unable to copy CM_CART_SCRIPT
    but I think that is more to do with it being low on disk space, I shall
    run it again will more diskspace just to be sure.
    
    I shall then start playing around with the A1 account parameters and
    let you know the results!
    
    I haven't been this happy producing an ACCVIO for a long time!
    
    Mike

    Mike,
    
    Well it is a different ACCVIO isn't it. Maybe there is more than one??
    We're attempting to get dial-in to the customer site now but the one
    on the internal site in Birmingham looks EXACTLY the same ACCVIO so why
    not get a copy of their files and quotas and thingies and have a look
    at that?
    
    Regards,
    
    Andrew.D.Wicks

    
    Hmm,
    
    It seems it's not the MERGE of the actual reports and procedure which
    causes the ACCVIO. The fact that .19 showed that CM_CART_SCRIPT_*.SCP
    was available indicates that the generation of the reports had
    finished. After copying the CART Script procedure some error checking
    takes place and then the 3/4 other reports are copied to the [.SITE]
    directory. 
    
    I've almost completed another run (17,000 conflicts, 75,000 Site
    elements), but looking at the size (204 blocks) of the
    CM$CART$CONFLICT$ELEMENTS.DAT of .19, it's not the size of the datafile
    (number of records) which seems the cullprit. 
    
    Watch this space.
    
    	Simon
                                                    

    
    I freed some diskspace and as I suspected I didn't get the
    CM_CART_SCRIPT problem so I think that there is only one ACCVIO.
    
    However as Simon said it may not be the merge after all.
    
    I'm currently running the CART again having doubled some account
    parameters to the following.  
    
    Bytlm: to 72000
    WSdef: 512
    WSquo: 1024
    WSextent: 4096
    
    I let you know as soon as it ACCVIO's
    
    Mike

    
    Latest.
    
    Still doing tests.  So far can't get rid of the ACCVIO by modifying
    account parameters.  
    
    Have done a trace and it looks like the ACCVIO might be caused by
    TEXT_FILE OPEN/READ
    
    Does anyone know of any known problems with TEXT_FILE
    
    As soon as a solution is found I'll let you know.
    
    Ta
    
    Mike

    More you want more?
    
    Upped ever parameter in sight (well almost) 
    ASTLM 200	BIOLM 130  BYTLM 100000 DIOLM 130 ENQLM 2000
    FILLM 150   JTQUOTA 20000 PGFLQUOTA 50000 PRCLM 20
    TQELM 200   WSDEFAULT 600 WSEXTENT 3000 WSQUOTA 1500 ETC ...
    
    Noted that there were some strange logicals in the OA$SITE tree
    e.g OA$SITE_LIB_SHARE = DISK$ALLIN1:[ALLIN1.SITE.LIB_SHARE]
    		            OA$SITE_LIB_CORE_SHARE
        OA$SITE_LIB_CORE_SHARE = DISK$ALLIN1:[ALLIN1.CORE.LIB_SHARE]
    
    however the SiteDirectories file doesn't 'see' the CORE directories
    at all so we don't get the now-infamous DROF CART CPU loop.
    
    The SETHOST of the RC shows that the Summary and Full reports  and the
    resolution procedure were built but only the Script is on disk - this
    bit I don't understand, where did the other two go.
    
    File Sizes well ConflictElements is 408 blocks and contains I hope
    you're sitting down:
    402 A's, 18 B's, 9 C's, 46 D's, 358 E's (yes that many!)
    4 G's, 21 H's, 1 I, 10 M's, 6 O's, 105 P's (another biggie)
    3 Q's and 1 R
    [almost got the full-set there]
    
    DeletedElements checks in at 123 blocks, SiteElements at only 51
    CheckedElements is 57 blocks
    
    OH what else SiteHist is 2103 blocks and SiteLog is 1029
    
    result of all this well you've guessed it an Accvio in the same spot
    
    Sigh - brink back Sender/Fetcher ACCvios I understood those.
    
    Regards,                       
    
    Andrew.D.Wicks

    
    
    
    A report that gives A,D,E,M and P is ok SITELOG is 321 blocks
    			A,B,C,P,R  gives ACCVIO and is 933 blocks long.
    
    I shall reduce the no. of records in sitelog that gives the ACCVIO
    until it stops and check to see if it is a status problem or size
    problem.  
    
    I personally think that this is a SYSGEN parameter that is causing
    the problems that is giving the ACCVIO.
    
    I've also had the ACCVIO moving to checking deleted elements.
    
    Ta
    
    Mike

    
    Latest:
    
    I noticed that if you do
    
    <TEXT_FILE OPEN/READ WRTOIUWROIU WERWERR
    
    you get an ACCVIO pretty similar to one I and others seem to get.
    As you might have guess the file WERWERR doesn't exist.  
    
    The CART ACCVIO on an OPEN/READ but it will only do this if the file
    does exist.  
    
    So I'm currently testing around this area for problems.
    
    We've run a sort of debug image of ALL-IN-1 and it appears that the
    stack gets corrupted.  I guess that's why TEXT_FILE falls over
    but I don't know what is doing the corruption nor why
    
    I'll keep you informed.
    
    Ta
    
    Mike

    Hi,
    
    	I have tried the command
    
    <text_file open/read testy testy2
    
    on two ALL-IN-1 2.4 systems - one produces an access violation, and the
    other doesn't (file not existing).
    
    System with acc vio - Patched up to K603 (without wps-plus v4.0), as
    well as EARS, MICA, SFCP.
    
    System which produces no errors - Patched up to patch 605 with wps-plus
    v4.0.
    
    	Any more news on this??
    
    		Thanks
    
    			Julie

    
    Julie,
    
    Can you do a test for me. 
    
    On both systems can you tell me what happens if you open a file that is
    already opened using TEXT_FILE OPEN/READ for this test the file should
    exist.
    
    We don't have any patched systems here so I can't try this out for
    myself.
    
    Thanks,
    
    Mike

    
    And another thing...
    
    Can you try the TEXT_FILE OPEN/READ with a file extension.
    
    Another thought, have you run the CART on both of these systems?
    
    Thanks,
    
    Mike

    Hello Mike,
    
    	If I try to 
    
    text_file open/read test "existing filename"
    
    then it does not access violate on either system, with a .wpl or .lis
    file. The second time I try to open it I get the message "File test not
    open".
    
    	The only way I can get it to access violate is if the file does not
    exist.
    
    		Hope this helps,
    
    			Julie

    Hello,
    
    	The machine that is causing the acc vio is on VMS 5.4-2. 
    
    	The machine that is not causing the acc vio (and where CART runs
    successfully) is VMS 5.4-3
    
    
    		Julie

    My customer system is 5.4-2 and they get the acc vio,  the also have a
    mass-11 intergration.
    
    Suzanne

    Hi,
    
    	Unfortunately, I have just run the CART on the system that access
    violates on text_file if the file is non-existent, and it worked
    perfectly!!
    
    			Julie

    
    Hi,
    
    I think I have a solution.  Well put it this way, it works for me.
    
    The script CM_CART_DRIVER.SCP needs to be modified (it's in the saveset
    A1LUS030.L).
    
    After the line
    
    .LABEL DRIVER_FIND_OTHER_ERROR
    
    add the line
    
    TEXT_FILE CLOSE CART_ERR
    
    And the ACCVIO appears to go away.
    
    Can someone internal who gets the ACCVIO do this to make sure it works,
    before we tell the whole world?
    
    Thanks,
    
    Mike

    Customer has just confirmed that the problem has been fixed by that
    mention in .37
    
    Thanks
    Suzanne
    

    Hi,
    
    	At long last my customer has just come back and found that the fix
    mentioned has allowed the CART to run through without any stack dumps,
    
    	Thanks for all the help,
    
    		Julie