Conference iosg::all-in-1_v30

    Eileen,
    
    Shame on you - EARS moved to OASS:: some 6 months ago home of your
    friendly Atlanta CSC. I announced the move in here and in
    EASYNET_CONFERENCES.
    
    So we can take the question over there - since EARS v2.2 which runs
    just fine and dandy on an ALL-IN-1 v3.0-1 system hasn't shipped yet
    and is a third party product i'm not sure what more I want to say here.
    
    Regards,
    
    Andrew.D.Wicks  
                                                     

    EARS for ALL-IN-1 V3.0 was submitted to the SSB yesterday, according to
    information provided to me by Don Vickers, whose consulting firm was
    responsible for the upgrade.  In the U.S. I would contact Adrian
    Leighton @MKO, the manager responsible for EARS, while in Europe I
    don't quite know what to do because EARS was supplied as a PASS through
    ASSETS, and I am not sure whether ASSETS will pick up the V3.0 kit.
    
    Tony

    Cross-posted from the EARS Conference.... with typos corrected
    
    Can anyone confirm that I can't read or think correctly and tell me
    what I am doing wrong?
    		<Art>
    
    
                <<< OASS::$7$DUA2:[NOTES$LIBRARY]EARS.NOTE;2 >>>
                -< Electronic Authorization and Routing System >-
================================================================================
Note 357.0             > Mail Defer broken for EARS user <            No replies
GLDOA::HALLBERG "Dr. Detroit Lives!"                 39 lines  22-SEP-1993 22:16
--------------------------------------------------------------------------------
    I am assisting a customer who was recently upgraded to ALL-IN-1 V3.0
    and EARS V2.2   (YES, I know we are slow here in Detroit but we do TRY
    to stay up-to-date with software released this decade...)
    
    The customer reported that EARS users could no longer DEFer normal mail
    messages after the upgrade and I have confirmed that the ARG Form
    EARS$EMMDEF, which takes the date to defer until, seems to decide there
    is nothing to execute if the item being processed in NOT an EARS_MAIL
    message.  The 'offending' code is in the /POST processing of the
    datetime field as follows:
    
    /POST='.IF #OAVALID == "1" THEN DATE_CONVERT DATETIME,DATETIME,3
    \\GET #DATETIME = DATETIME
    \\.if #EARS_MAIL eqs OA$YES then do EARS_SEND_DEFERRED else xop "~~DEFER~~"'
    
    My brain is not working well these days but when I did a full trace of
    the execution of this form #EARS_MAIL eqs OA$YES evaluated to false,
    which was correct, and the else was NULL.  My head says there must be
    something wrong with the syntax of the /post but I can't find a similar
    example that works to compare it to.  (Yes, I still do HALLMARK
    programming, when you care enough to steal from the very best...)
    
    Did I get caught in a mis-formatting of the named data?  Used to be
    missing spaces at beginnings of lines cause problems in the scan.
    
    Suspecting the customer must have customized either the EARS$EMMDEF
    form or something executing prior to it I have installed V3.0 English,
    the V3.0-1 CSCPAT 3065, and EARS V2.2 on my home test system and it
    does the same thing here.  I tried looking on ATLPAT for other patches 
    that might apply but the list (patch 9999) only goes back three months 
    so I can't tell if I am missing any.  
    
    Could some kind soul point me in the right direction so I can get this
    done this week before the @#@&%# hits the fan.
    
    	Thanks,
    			<Art>
    
    
    

    Hi,
    
    The syntax of the .IF is wrong. Here's why:
    
    The code is:
    
  .IF #OAVALID == "1" THEN 
      DATE_CONVERT DATETIME,DATETIME,3
    \\GET #DATETIME = DATETIME
    \\.if #EARS_MAIL eqs OA$YES then do EARS_SEND_DEFERRED else xop "~~DEFER~~"
    
    What happens is that the first .IF breaks into a THEN component and an
    ELSE component, and so is:
    
    .IF #OAVALID == "1" 
    
    THEN
    DATE_CONVERT DATETIME,DATETIME,3
    \\GET #DATETIME = DATETIME
    \\.if #EARS_MAIL eqs OA$YES then do EARS_SEND_DEFERRED
    
    ELSE
    xop "~~DEFER~~"
    
    So on the case where #OAVALID is not "1" the xop "~~DEFER~~" will run.
    In the case where #OAVALID is "1" and #EARS_MAIL is not OA$YES then
    nothing will happen.
    
    The Named Data can be changed to something like:
    
    .IF #OAVALID == "1" 
      THEN 
        DATE_CONVERT DATETIME,DATETIME,3\\
        GET #DATETIME = DATETIME\
     .IF #OAVALID == "1" AND #EARS_MAIL eqs OA$YES then do EARS_SEND_DEFERRED\
     .IF #OAVALID == "1" AND #EARS_MAIL NES OA$YES then xop "~~DEFER~~"
    
    Nested .IFs are still a pain in Named Data, but in scripts you can use
    .THEN and .ELSE to avoid such problems.
    
    Cheers
    
    Stuart

    	Stuart,
    	Have tried to make the suggested changes to the EARS V2.2 form but
    ran into another glitch...
    
                <<< OASS::$7$DUA2:[NOTES$LIBRARY]EARS.NOTE;2 >>>
                -< Electronic Authorization and Routing System >-
================================================================================
Note 358.0        > CM locations wrong for V2.2 after upgrade <       No replies
GLDOA::HALLBERG "Dr. Detroit Lives!"                 30 lines  23-SEP-1993 15:51
--------------------------------------------------------------------------------
    Same site with a recent upgrade from ALL-IN-1 V2.4 & EARS V2.1 to
    ALL-IN-1 V3.0-1 and EARS V2.2.
    
    After the upgrade I find that the Customization Management entries for
    the EARS elements still point to the [EARS...] directory tree for both
    the location of the base element, like the EARS.FLB and for the live
    location of the SITEEARS.FLB.
    
    Since I didn't do the upgrade I am not sure if there was a choice but
    the live EARS.FLB, V2.2, is now in [ALLIN1.LIB_ENGLISH] and the
    SITEEARS.FLB is in [ALLIN1.SITE.LIB_ENGLISH].  Neither of these two
    location surprizes *ME* but it has confused the heck out of the
    Customization Manager.
    
    Is there a way, other than deleting the EARS application and
    re-installing it to clear or reset the locations for both the base
    elements and the live location for every EARS related element.  The
    application name seems to still say EARS V2.1 but haven't gotten a
    chance today to see if the V2.2 kit installed on my uncustomized
    system says the same thing.
    
    I would prefer to not break this system and/or have ALL-IN-1 down for
    any length of time if I can avoid it.
    
    	Thanks in advance for any assistance,
    			<Art>
    
    	P.S.
    	Will cross-post in ALL-IN-1
    
    

    	Re: .5
    	Stuart,
    	The suggested fix is on my system and now deferred mail works.
    	As soon as I figure out the problem in .6 I'll get it installed at
    the customer site.
    
    	Considering the demise of EARS is it worth SPRing the error in the
    EARS$EMMDEF form?
    
    	Is the presence of the suggested fix here sufficient to let the
    field people who discover this gem how to fix it?
    
    			<Art>

    Art,
    
    I don't know about SPR - since EARS is a 3rd party product but I will
    forward the relevant parts of this notes stream to EOS.
    
    regards,
    
    Andrew.D.wicks

    Does anyone know where I can find an EARS kit on the net? The notes
    conference is no more and the kit location hotair::ears$kit is no
    longer valid.
    
    Dick

    Dick,
    
    what EARS kit do you want 2.1 or 2.2?
    
    regards,
    
    Andrew.D.Wicks

    Re .9
    
    <<< The notes conference is no more
    
    OASS::EARS ???
    
    Or did you mean it was closed?
    
    Graham

    It's closed - the product's support agreement expired on June 30th.