Conference iosg::all-in-1_v30

    Jack,

    Note 884 handles about the CART stack dumping, likely caused by a MERGE
    in which a boilerplate with <-> is being used.

    No solution so far ...

    FWIW,
    Sjaak.

    
    Sjaak,
    
    You're right... It appears to be the same (or at least a very closely
    related) problem.  The boilerplates that we've seen that have the 
    problem don't ACCVIO when taken out of the TXL, if that's helps
    anyone.
    
    Thanks,
    
    Jack
    

    
    Jack, Sjaak,
    
    There is a difference however. The boilerplates used during the CART
    run from the installation are NOT in the TXL. The boilerplates come
    from saveset A1L<country code>030.L and are used from the VMI$KWD:
    directory (the installation directory).
    
    Now this doesn't explain the behaviour in 884.*. 
    
    Checking...
    
    	Simon   

    
    We have seen similar problems at the CSC, here is the STARS
    article describing it. I don't know if this is fixed in
    a later available version or not, as the article does
    not indicate. 
    
    Hope this is helpful,
    
    Faith Donohue
    
    ************************************************************** 
    
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.

    

The least that should be done to fix this problem is to notice it during the
compile and display warnings THEN instead of ACCVIOs and such when the TXL is
used.  We are allowing "corrupt" data to make it through a "compile" process.
No other "compiler" that I know of would be allowed to ship with this kind of
problem.

This is a serious problem with our product.  It is also a real productivity
drag for the application developer and probably the CSCs as well.

If an IPR is needed I'll be glad to raise one.  It sounds to me like engineering
already have it on their list.  Apply "my" fix above if a full fix is taking
too long.

	standing up on soapbox...

Long range changes should be planned to remove or extend artificial limitations
on line lengths in boilerplates, editor buffers, text DSABs and the like, and
line count limits in the Named Data editor and reorganizer. Our customers are
demanding it and so are Digital products, projects and pilots.  Time is being
wasted trying to find and get around these limitations and time is money.

One person in engineering should be chartered with doubling (or more) such limits
for the next PFR of our favorite application development platform product.  By
doubling I don't mean making there be twice as many limits!  512 should be 1024.
3000 should be 6000.  Take the time and just do it for all of us, or at least
put the limits into the control of the customer through linker options or
something.

	dismounting from soapbox...

/Marty

    I agree.
    
    Unfortunately, I don't make the decisions about what work gets done on
    what is my favourite product too. (I just spell favourite differently
    from you :-) )
    
    <<< Our customers are demanding it and so are Digital products, projects
    <<< and pilots.
    
    That's obviously not visible here, if you have customer reports on this
    or can name names, it would be very helpful.
    
    <<< Time is being wasted trying to find and get around these
    <<< limitations and time is money.
    
    Unfortunately, it isn't money that is coming out of our budget, and
    hence in the new world of business profitability, this doesn't seem to
    be a serious problem. I think this way of deciding how projects are
    financed stinks, since all the invisible benefits don't appear....
    
    Please tell the people in Product Management how this is hurting the
    business, with names and supporting evidence, and we'll see what we can
    do!
    
    Trying to be cheerful,
    
    Graham

    I agree.
    
    Unfortunately, I don't make the decisions about what work gets done on
    what is my favourite product too. (I just spell favourite differently
    from you :-) )
    
    <<< Our customers are demanding it and so are Digital products, projects
    <<< and pilots.
    
    That's obviously not visible here, if you have customer reports on this
    or can name names, it would be very helpful.
    
    <<< Time is being wasted trying to find and get around these
    <<< limitations and time is money.
    
    Unfortunately, it isn't money that is coming out of our budget, and
    hence in the new world of business profitability, this doesn't seem to
    be a serious problem. I think this way of deciding how projects are
    financed stinks, since all the invisible benefits don't appear....
    
    Please tell the people in Product Management how this is hurting the
    business, with names and supporting evidence, and we'll see what we can
    do!
    
    Trying to be cheerful,
    
    Graham

Graham,

I almost spelled favorite your favourite way just to show my respect for
the contributions that are made by our world-wide team.  But I stuck with my
spelling because is was shorter.

The pressures of business are different!  There are good things and bad things
to say about developing ALL-IN-1 today versus 10 years ago.  One of the ideals
I miss most is being able to made it "right".  Back then if I came up with a
code change I could see it get implemented.  Today I believe if I came up with a
change it would not be accepted, without giving merit to the benefits.
Admittedly, benefits are sometimes small but they all add up to a greater whole.

I know, preaching to the converted.  But even the converted need to be preached
to on a regular basis so that they remember what religion is all about.

/Marty

No requirements got through to us on API and since we hope to close phase 0 
soon, any new requirements will have to be formally ECOd

Since these could be described as defects in the functionality rather than 
requirements for a PFR, I suggest you send in an IPR stating all the 
deficiencies. One of the quirks of the system is that only those 
requirements with a high QFD rating get considered, and we dont get to 
implement anything that did not come from the QFD .... but there is 
another way.

We have an almost open ended commitment to fix bugs. If you have evidence 
that this has a high customer impact, raise a bug against it and it least it 
will get discussed internally and will compete against the other bugs.

However, any that are genuine suggestions will be routed to the product 
manager rather than being added to the bug list.

- eileen