[comp.dcom.lans] Performance problem on Banyan VINES

Dennis.Schmitz@f1505.n106.z1.fidonet.org (Dennis Schmitz) (02/02/90)

In an article of <29 Jan 90 11:12:03 GMT>, ta2@acci.com writes:

 tA>Yet another network we don't know a whole lot about....  This time
 tA>Banyan Vines.  I'm having trouble getting a straight story about the

 tA>My clients application builds a directory listing containing available
 tA>drive names along with subdirectory names for the current default
 tA>drive/directory.  Any drive in the range A-Z is placed on the list if 

 tA>The network administrator has full rights to everything and about 13
 tA>drive mappings.  For him, the directory list takes about 15 seconds to
 tA>build.  The users do not have full rights, they have whatever they need
 tA>to access the subdirectories.  Each user has 4 to 6 drive mappings. For
 tA>them, using the same drive and directory as the administrator, the
 tA>directory list takes about 2 minutes to create. 

The culprit is probably the application program using findfirst and findnext on 
file service paths on which it doesn't have read access. Each dos call to a 
path without access causes a noticable delay.

 tA>Has anyone got anything else to suggest? Part of my problem with

1. if your client has 3.10, use the GetAccessRightsList call before calling 
findfirst. Call the Banyan (Usually 63h) interrupt with:

AX = 0004h
DS:DX = Pointer to arguement block

arguement block:

offset          value or meaning
00h             14
02h             drive designator
03h             0
04h             Segment of path string
06h             Offset of path string
08h             Offset of ARL return buffer
0Ah             Segment of ARL return buffer
0Ch             ARL_cnt, the number of StreetTalk names in the ARL
0Eh             Returned error code

The path string is a null terminated path string max 64 chars.

error 00h = none; 03h = invalid path; 05h = Access denied

arlbuffer is is array of names and accesses the size of the ARL_cnt:

struct {
        char STName[64]; //  streettalk name
        int Access; // 0=N, 1=R, 2=M, 4=C
        };
        
 tA>trying to get more information is that my client is in a panic over
 tA>this. Their enduser is a major corporation who is demanding immediate
 tA>attention -- even if the program is not at fault.

It is their application.

Later,
dEN

(I assume my check is in the mail.)