Conference iosg::all-in-1_v30

Could you clarify some of the information in .0 please? You say that LONDON is 
remote, and that's where the recips are getting the multiple copies, but the 
MRID implies that the messages were SENT from LONDON. Which node has produced 
the MRINF file?

And to confirm that the remote users got 11 copies, and the local ones got 
only 1 - even though they're addressed via the local MR?

g (slower than usual today!)

    Grahame
    
    Sorry if the base note was confusing
    
    GFALTD (in Sydney) was where 11 copies were received by its users. Mail
    was sent from LONDON (presumably in London) to both systems, and I
    believe LONDON users got only 1 copy of the mail.
    
    The MR's INF file were from GFALTD system and all observations in the
    base note should apply to this node
    
    Thanks for your interest and further comments
    
    Hong
    

So it has to be the Fetcher on GFALTD which is doing the 11 deliveries. But NO 
errors in OA$MTI_ERR? And No errors in OA$ROOT:OAMTIMAIL.LOG? In that case, 
there's nowhere else to look! 11 would imply that the message got stuck on the 
Fetcher queue - an attempt to delete this should have raised an error. Maybe 
someone's rolled over the log files since the problem? Is there an older one?

Sorry, I can't think of anywhere else to look! 

g

A possibility has just occurred to me . . . if the Fetcher was run under a 
different username from Postmaster's (usually ALLIN1), then it might be 
possible for the mail to be delivered, but that the other user would not be 
able to update either the Pending file or the error file. And you wouldn't get 
any .LOG files either . . .

Has anyone else been running the fetcher? Either interactively or in batch? 
It's possible that the user may now have a POSTMASTER_NBS_MAIL_FROM_MR folder.

g

    Grahame
    
    Thanks for these possibilities...
    
    This site was a small site and the Mgr himself rarely uses ALL-IN-1
    account; almost sure Fetcher/Sender jobs were run with default
    settings.
    
    Also unlikely the Fetcher was run interactively when the multiple
    delivery incidents occurred since they were recorded very shortly after
    the arrival of remote mail (from London) about 3am local time; i.e. the
    end of business day on remote system. 
    
    POSTMASTER_NBS_MAIL_FROM_MR exists as a temporary folder only, doesn't
    it ? This would make exhaustive searching for this folder in all users
    FILECAB futil.
    
    Any other ideas. Thanks
    
    Hong

                       <<< Note 2139.5 by GIDDAY::LEH >>>
                         -< any other possibilities ? >-

>    POSTMASTER_NBS_MAIL_FROM_MR exists as a temporary folder only, doesn't
>    it ? This would make exhaustive searching for this folder in all users
>    FILECAB futil.

Well, as you know, there's no such thing as a temporary folder - once a 
message is in it, it's permanent. Anyway, it was a pretty desperate longshot.

>    Any other ideas. Thanks
    
Even though it's only Tuesday, I think I've used up this week's quota of 
ideas! Without any evidence in logfiles etc, I'd be tempted to put it down to 
a low-flying aeroplane . . .

grahame

Grahame

>    POSTMASTER_NBS_MAIL_FROM_MR exists as a temporary folder only, doesn't
>    it ? This would make exhaustive searching for this folder in all users
>    FILECAB futil.

What I meant was this folder, POSTMASTER_MAIL_NBS_FROM_MR (just looked up the 
correct name) existed only for the duration of Fetcher delivery to Postmaster 
filecab and the latter delievered it locally. Once the last local delievery 
was made, the folder would cease to exist until the next Fetcher delievry.

BTW, searching all FILECABs revealed nothing.

More dial-in sessions showed a number of failed deliveries, stored in another 
Postmaster folder, POSTMASTER_MAIL_NBS_FAIL. Incidents in this base note, were 
also seen in this folder; i.e. in addition to 11 actual delieveries to some 
local addressees, fetcher failed after 11 attempts to deliver other local 
addressees. In one instance, it involved a hardcopy printer as a local 
addressee, i.e. the local system set up a terminal printer queue as a remote 
mail collector, which was incidentally having various queue setup problems.
I can't think of relevant connections between the malfunctioning of this 
hardcopy 'addressee' and the current problem in discussion.

Again, nothing in OA$MTI_ERR. MR's .INF files showed normal transaction and 
unrelated errors.

Thanks for help so far

Hong

Hong,

Well, we can just keep plugging away - let's hope everyone's entertained . . .

For thos messages in Postmaster's ...FAIL folder you should have had mail 
messages to Manager (the 'failed to fetch' message).

Also, if a fetched message is to be delivered to more than one recipient, and 
the delivery is only failing on (say) the last one, then the earlier recips 
will get 10 (or 11) copies - every time the fetcher retries it will deliver 
successfully to the recips with no problem.

g

Grahame

Am afraid this entertainment is going to end, at my pleasure !

What has been missing from verbal discussions with customer (I totally 
overlooked it, also) was the role of a hardcopy 'addressee', which was 
designed as message collector of remote mail delivery. My first dial-in 
session overlooked this detail, and wondering why fetcher delivered 
extra 10 times to other local addressees; hence, this base note.

The customer is going to review this problem and happy with the explanations

>> For thos messages in Postmaster's ...FAIL folder you should have had mail
>> messages to Manager (the 'failed to fetch' message).

Are those msgs coming from Postmaster ? The customer and I myself never came 
across it except those "..Delivery Failure Notif.." mail msgs and NBS files 
placed in OA$MTI_DATA. 



Many thanks


Hong

I am unclear as to how this problem was resolved,

>overlooked it, also) was the role of a hardcopy 'addressee', which was 
>designed as message collector of remote mail delivery. My first dial-in 

By "hardcopy addressee" do you mean that one of the remote addressees has a 
mail destination set to PAPER MAIL, and because of this ALL-IN-1 
delivered/fetched the message 11 times to the other remote addressees on this
node until the retry limit exceeded.

Surely this isn't correct behaviour, I cannot reproduce it here.

>The customer is going to review this problem and happy with the explanations

One of my customers likes to send to the remote address 

subscribers:@a1@remote 

It appears that one of your "hardcopy addressee's" are causing the mail to be
sent to every remote subscriber 11 times. This didn't occur with ALL-IN-1 V2.4
and is causing severe user inconvenience - I can't think of an explanation that
she will be happy with!

Can you please clarify exactly what causes the problem so that I may reproduce 
it here.

Thanks 
Aston Clarke
UK CSC

Aston in .10

>>By "hardcopy addressee" do you mean that one of the remote addressees has a 
>>mail destination set to PAPER MAIL, 

Correct

>>and because of this ALL-IN-1 
>>delivered/fetched the message 11 times to the other remote addressees on this
>>node until the retry limit exceeded.

No, only when delivery failed on one of the remote addressees on the list. It 
happened, I was told, e.g. when the PAPER MAIL printer was off-line or 
malfunctioning.

>>The customer is going to review this problem and happy with the explanations

He got rif off PAPER MAIL addressee. 

>>One of my customers likes to send to the remote address 
>>subscribers:@a1@remote 

It's highly likely in your case that one failed delivery to one subscriber 
would cause the resending to ALL subscribers. If this is true, a couple of 
alternatives may be worth considering:

o reduce the fetcher retry limit
o split @SUBSCRIBERS into smaller groups
o constantly sanitize SUBSCRIBERS to weed out problem addressees

Hong
CSC Sydney

Engineering have supplied me with a fix to this problem. It also fixes a 
problem with second class local delivery of attachments to paper mail addresses
causing the sender to access violate.

Change oa$do:wppbgformat.scp as follows;

from

  377       .if OA$SCROLL_SELECTED eqs "" -
  378           then get #PRINT_TEMP = #PRINT_SELECTED -
  379           else get #PRINT_TEMP = OA$SCROLL_SELECTED

To

  377           get #PRINT_TEMP = #PRINT_SELECTED
  378           .if OA$FORM_NAME nes "" then -
  379              .if OA$SCROLL_SELECTED nes "" then -
  380                  get #PRINT_TEMP = OA$SCROLL_SELECTED
                                                             
I will pen a Stars article to document this.

Regards
Aston

    
Re: Original Problems
    
    Can anyone clarify if there is a problem when hardcopy mail fails to
    print (printer not available/existent) or is it just Sender/Fetcher
    failing with an ACCVIO ?? 
    
Re: PAPER MAIL problems
    
    This problem is related to OA$SCROLL_* symbols causing ACCVIOs when you
    touch them in /NOINIT mode. Support are considering a patch for this at
    the minute.
    
    In fact, there are about 4 different scripts which may need to be     
    changed depending upon the document formats being handled. I suggest
    you SEARCH OA$LIB:*.SCP for OA$SCROLL and if the script can be invoked
    during printing then you may have to make an equivalent change.
    
Re: STARS article
    
    The CSC specialist who CLD'd this ACCVIO originally was asked at least 3
    times to SPR it and in spite of this - no SPR - and hence no article in
    STARS. I had to IPR it to make sure it got into any PFR.
    
    I'm sure the rest of the field will thank you for the article.
    
    
    Paul.

    Dear Paul,
    
    I originally CLD'd it,  the number was CLD UVO2057.  Why did I need to
    SPR it??????? Who did you ask 3 times to spr it , as it wasn't me!!!!!!!!
    I don't understand why this is causing such a problem.
    
    Suzanne

    
    OK... SPR's versus CLD's:		(one more time!)
    
    
    The problem is being patched because it was the subject of a CLD and
    'cause we think its worthy of a proper fix. 
    
    BUT... because there was a workaround, we didn't have to patch it.
    
    And CLD's don't normally go to Development. [for fixes in PFRs]
    
    And CLD's don't normally go to STARS. [for CSC's et al. to see]
    
    And CLD's are supposed to be followed up with an SPR. [for tracking]
    	[or even get submitted before a CLD - radical!]
    
    And CLD's may not get the complete answer before closure. [like this one]
    
    CLD's are a Corporate exception mechanism. SPRs are the proper [hence
    preferred] support channel. This conference is a totally informal channel.
    
    Get the idea? That's why we asked for an SPR. Nothing arrived, so
    we followed up the problem anyway. But a STARS entry might have saved
    this notes topic. But I guess I'm just here for the chit-chat anyway! ;-)
    
    It's not a big problem. It's been sorted now - so relax. No harm done.
    
    But there is your problem with '=' in DDS addresses... :-)
    
    Paul.
    
    
    P.S. Please don't hit me - I'm only kidding - honest!