[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

1873.0. "DECnet links to FCS. How many?" by KERNEL::LOAT (Ahead groove factor 5! Yeah!) Mon Nov 30 1992 16:18

    
    VMS 5.5 ALL-IN-1 3.0
    
    A customer is running 3.0, and she is getting a bit sorried about the
    number of DECnet links to and from object 73 on their cluster. When she
    looks, she sees two links for each user (presumably one inbound and
    one outbound). On her ssystem, they have had to up maxlinks from 200 to
    over 400. 
    
    I know that the FCS will be used whenever a user does an operation
    across drawers, but what I need to know is what operations in ALL-IN-1
    will create/use a DECnet link to the FCS, and when should these links
    die? 
    
    Thanx
    
    Steve.
T.RTitleUserPersonal
Name		DateLines
1873.11 per userCHRLIE::HUSTONMon Nov 30 1992 17:259
    
    There will be 1 decnet link per user. The second link could be coming 
    from an IAD if they do this.
    
    The user link will go away when the user exits ALL-IN-1, the IAD link
    will time itself out when it isn't used for a time.
    
    --Bob
1873.2non-MAIN drawer operationsCHRLIE::HUSTONThu Dec 03 1992 21:2622
    
    from within ALL-IN-1, no connection will be made to the FCS until you
    do something that requires the FCS. In other words, if all you do 
    is exactly what you could do in V2.4 of ALL-IN-1 then you will never
    get a connection to the FCS. 
    
    Things that cause a FCS connection are:
    
    1) Remote drawer access
    2) Access to a drawer which is not your MAIN drawer
    3) Cross drawer operations
    4) IAD of a remote system
    5) Any SM function for a partition/remote anything
    6) Drawer sharing (not sure about sharing MAIN drawer, I think so).
    
    So if all you are doing is V2.4 functionality like mail and operations
    within your main drawer you won't connect to the FCS. TL on the other
    hand has no access to the IOS FC without the FCS so any FC access via
    TL will create a FCS link.
    
    --Bob
1873.3I see 2 links as wellFAILTE::EWE::LAAHSAn accumulation of CeltsTue Feb 09 1993 20:3010
Sorry to re-open this but I also see 2 links per user after they have 
performed an operation that requires the FCS.

So is this a problem with the way ALL-IN-1 uses the FCS?

Also, is it possible that max decnet links could become a limiting factor in 
the number of supported users?

Thanks,
Kevin
1873.4What are they doingCHRLIE::HUSTONTue Feb 09 1993 21:2716
    
    Kevin,
    
    What is the user doing? If it involves ANY system management routines
    like performing an IAD, then this will make a second link.
    
    If you are seeing two links, go into the manager account and 
    go to the manage users menu, have it show you the connected users,
    this will show you if they are system management links.
    
    If they are getting two links and they are not doing system management
    or IAD, are they brokering?? This would create a second link out to 
    the remote server. This will also show up in the manage users stuff.
    
    --Bob
1873.5Nothing special happeningFAILTE::EWE::LAAHSAn accumulation of CeltsWed Feb 17 1993 17:2316
Hi,

No system management or brokering is taking place. I have just logged into a 
standalone machine, ran ALL-IN-1, went to EM and then refiled a document 
across a drawer and ended up with the following from NCP:

16603   62.15 (EDOFIS)   0003B3A4  LAAHS              16604 OBJ_73
16604   62.15 (EDOFIS)   000000B9  EDOFIS$SRV73       16603 LAAHS

Logging in as MANAGER and doing a MSC show clients LAAHS and ALLIN1 with 
ALLIN1 with MGT set to Y.

Is this what we should expect as far as DECNET links go?

Thanks,
Kevin
1873.6Not quite sureCHRLIE::HUSTONThu Feb 18 1993 18:4821
    
    Kevin,
    
>No system management or brokering is taking place. I have just logged into a 
>standalone machine, ran ALL-IN-1, went to EM and then refiled a document 
>across a drawer and ended up with the following from NCP:
>
>16603   62.15 (EDOFIS)   0003B3A4  LAAHS              16604 OBJ_73
>16604   62.15 (EDOFIS)   000000B9  EDOFIS$SRV73       16603 LAAHS
>
    Not sure what the second one is, I will check on it.
    
    
>Logging in as MANAGER and doing a MSC show clients LAAHS and ALLIN1 with 
>ALLIN1 with MGT set to Y.
    
This means that you have 1 link to the FCS for each of ALLIN1 and LAAHS
     
    
    --Bob
1873.7Any news?FAILTE::LAAHSAn accumulation of CeltsFri Mar 12 1993 18:056
    Bob or anyone else,
    
    I'd really appreciate knowing if this is a problem or not.
    
    Thanks,
    Kevin
1873.8no problems that I can seeCHRLIE::HUSTONFri Mar 12 1993 18:347
    
    Kevin,
    
    I don't see any problems with what you have described.
    
    --Bob
1873.9So is it a bug?FAILTE::64551::LAAHSAn accumulation of CeltsMon Mar 22 1993 17:5410
Bob,

Ok. But you stated earlier that it should only use one link and that you 
would check why there are two.

Is there anybody out there that only sees one link? I'm trying to establish 
whether it is a local set-up problem.

Thanks,
Kevin
1873.10I'll get back to yaCHRLIE::HUSTONMon Mar 22 1993 18:2312
    
    
    I also am seeing two decnet links per connect, one if the process
    that requested the connect (the user), the other is the server.
    
    Is it a bug? Don't know, if it is, it is a DASL bug. Neither the
    FCS or ALL-IN-1 make DECnet links on their own, ALL DECnet operations
    are done via DASL. I will check with the DASL folks and see what they
    say.
    
    --Bob
1873.11DECnet links terminate 'automatically'GIDDAY::LEHThu May 13 1993 14:17109
Have been observing DECnet links opened by IOS user processes that start 
invoking FCS-related tasks, as mentioned in Bob's previous reply.

It occurred to me in once instance that DECnet links created by one IOS 
seesion terminated themselves although that session never left ALL-IN-1; yes, 
both links, e.g.

***  16676  62.123 (RAKOFF)   00012102  LE                16677  OBJ_73
***  16677  62.123 (RAKOFF)   00000CB3  RAKOFF$SRV73      16676  LE

I recalled changing from SM MFC MS to send an EM, still staying at EM when 
listing of DECnet links didn't show up any of the above links.

Trying to reproduce for the next 15 minutes didn't give any success. I almost 
gave up, left 2 IOS sessions: ALLIN1 and LE in 2 DECwindows sessions and moved 
on to a different session to read VAXnotes.

It must have been some 30 minutes later I went back to the 2 IOS sessions and 
started playing around a bit more, when I did reproduce the original incident 
and recorded it as follws: 


STEP 1 - 2 processes LE and ALLIN1 were idle, staying at EM and WP menus

*** Known Link Volatile Summary as of 13-MAY-1993 17:48:02
*** 
***    Link       Node           PID     Process     Remote link  Remote user
*** 
***   8308   59.980            00000090  REMACP            37894  LE
***   16626  59.980            00000090  REMACP             3081  LE
***   8211   62.123 (RAKOFF)   00000DBD  MUAS$SERVER_000    8212  MRLISTEN
***   8212   62.123 (RAKOFF)   00000B9B  MRLISTEN_8212      8211  SYSTEM
***   8219   62.123 (RAKOFF)   000000BE  TMR$SA_SA1         8220  A1M$MUAS
***   16655  62.123 (RAKOFF)   0000F69C  ALLIN1            16656  OBJ_73
***   16656  62.123 (RAKOFF)   00000CB3  RAKOFF$SRV73      16655  ALLIN1
***   16676  62.123 (RAKOFF)   00012102  LE                16677  OBJ_73
***   16677  62.123 (RAKOFF)   00000CB3  RAKOFF$SRV73      16676  LE

STEP 2 - 2 processes LE and ALLIN1 were still idle, staying at EM and WP menus

*** Known Link Volatile Summary as of 13-MAY-1993 18:36:03
*** 
***    Link       Node           PID     Process     Remote link  Remote user
*** 
***   8308   59.980            00000090  REMACP            37894  LE
***   16626  59.980            00000090  REMACP             3081  LE
***   8211   62.123 (RAKOFF)   00000DBD  MUAS$SERVER_000    8212  MRLISTEN
***   8212   62.123 (RAKOFF)   00000B9B  MRLISTEN_8212      8211  SYSTEM
***   8219   62.123 (RAKOFF)   000000BE  TMR$SA_SA1         8220  A1M$MUAS
***   16655  62.123 (RAKOFF)   0000F69C  ALLIN1            16656  OBJ_73
***   16656  62.123 (RAKOFF)   00000CB3  RAKOFF$SRV73      16655  ALLIN1
***   16676  62.123 (RAKOFF)   00012102  LE                16677  OBJ_73
***   16677  62.123 (RAKOFF)   00000CB3  RAKOFF$SRV73      16676  LE
*** 

STEP 3 - process LE was idle, staying at EM 
process ALLIN1 at WP menu, doing MCD to make a copy of document from one 
folder to another, totally in MAIN drawer

Listing DECnet link no longer showed 2 links from ALLIN1

*** Known Link Volatile Summary as of 13-MAY-1993 18:42:15
*** 
***    Link       Node           PID     Process     Remote link  Remote user
*** 
***   8308   59.980            00000090  REMACP            37894  LE
***   16626  59.980            00000090  REMACP             3081  LE
***   8211   62.123 (RAKOFF)   00000DBD  MUAS$SERVER_000    8212  MRLISTEN
***   8212   62.123 (RAKOFF)   00000B9B  MRLISTEN_8212      8211  SYSTEM
***   8219   62.123 (RAKOFF)   000000BE  TMR$SA_SA1         8220  A1M$MUAS
***   16676  62.123 (RAKOFF)   00012102  LE                16677  OBJ_73
***   16677  62.123 (RAKOFF)   00000CB3  RAKOFF$SRV73      16676  LE
*** 

STEP 4 - process LE was idle, staying at EM 
process ALLIN1 doing SM MFC MS on "Manage Servers"

2 DECnet links were, as expected, back for ALLIN1 

*** Known Link Volatile Summary as of 13-MAY-1993 18:42:57
*** 
***    Link       Node           PID     Process     Remote link  Remote user
*** 
***   8308   59.980            00000090  REMACP            37894  LE
***   16626  59.980            00000090  REMACP             3081  LE
***   8211   62.123 (RAKOFF)   00000DBD  MUAS$SERVER_000    8212  MRLISTEN
***   8212   62.123 (RAKOFF)   00000B9B  MRLISTEN_8212      8211  SYSTEM
***   8219   62.123 (RAKOFF)   000000BE  TMR$SA_SA1         8220  A1M$MUAS
***   16676  62.123 (RAKOFF)   00012102  LE                16677  OBJ_73
***   16677  62.123 (RAKOFF)   00000CB3  RAKOFF$SRV73      16676  LE
***   16700  62.123 (RAKOFF)   0000F69C  ALLIN1            16701  OBJ_73
***   16701  62.123 (RAKOFF)   00000CB3  RAKOFF$SRV73      16700  ALLIN1
*** 

STEP 5 - However, I repeated step 3, and listed out DECnet links 
immediately, which still showed 2 links for ALLIN1

Could it be the time elapsed between steps 1 and 2, almost 1 hour, that 
has caused the links to terminate ? 
Would you expect even the DECnet (user) link would terminate although the
session never leave ALL-IN-1, as in this case, the ALLIN1 process itself?
Any chance they timed out ? Unlikely, I think. Confused, confused ??

Also, Bob, have you been able to find out if the second link is a DASL 
bug ?


Hong
CSC Sydney
1873.12reproducible, just !!GIDDAY::LEHThu May 13 1993 14:4221
About half an hour later when ALLIN1 session was still staying in WP menu 
after having done MCD some 20+ minutes earlier

*** Known Link Volatile Summary as of 13-MAY-1993 19:35:06
*** 
***    Link       Node           PID     Process     Remote link  Remote user
*** 
***   8308   59.980            00000090  REMACP            37894  LE
***   16626  59.980            00000090  REMACP             3081  LE
***   8211   62.123 (RAKOFF)   00000DBD  MUAS$SERVER_000    8212  MRLISTEN
***   8212   62.123 (RAKOFF)   00000B9B  MRLISTEN_8212      8211  SYSTEM
***   8219   62.123 (RAKOFF)   000000BE  TMR$SA_SA1         8220  A1M$MUAS
***   16676  62.123 (RAKOFF)   00012102  LE                16677  OBJ_73
***   16677  62.123 (RAKOFF)   00000CB3  RAKOFF$SRV73      16676  LE
*** 

If this is not a fluke, what governs the termination of those DECnet links

Thanks for any comments

Hong
1873.13Sysman and brokered connects timeoutCHRLIE::HUSTONThu May 13 1993 18:2415
    
    THere are two types of links that time out, system management and 
    inter-server. THey both will time out periodically if not used.
    
    Normal client->server connects will not time out, don't know if DASL
    will "hide" them or time them out somehow if unactive for x amount
    of time.
    
    As for the original question, it has been pointed out via mail that
    there use to be a bug in DASL that would cause this, the explainer of
    this was not a DASL person but a user. The DASL group has been 
    mysteriously quiet about the entire thing.
    
    --Bob