Chapter 8 - StreetTalk Directory Assistance
StreetTalk Directory Assistance (STDA) is a service that allows users and administrators to quickly and easily look up the names of users, lists, print services, file services, and other services located on their Banyan network. The STDA database contains the StreetTalk names and descriptions as well as non-StreetTalk names that you can add.
STDA lets users search for item names:
Alphanumerically By the group to which the user, list, or service belongs By the attributes configured in StreetTalk
STDA is fully integrated with the VINES Intelligent Messaging mail option, so users can look up the name of a recipient or list of recipients and incorporate the names into a mail message. The SETPRINT program has an STDA interface that lets users look up the names of print services on the network.
This chapter presents basic information for planning how to use STDA. It describes how it works and what you must do as an administrator to manage it.
Note: If you are familiar with STDA, you should read Managing Users and StreetTalk for more detailed information on the topics discussed in this chapter.
The next sections describe these STDA components:
STDA database User Interface Services
Every STDA database has two components. One component collects information from other services and the other component arranges information in the first database for display to users. Information in the database is organized into classes.
StreetTalk uses a three-part name to identify all objects in a network (item@group@organization). Items identify names or services. For each item, StreetTalk maintains, along with other information, the item's class.
STDA uses some StreetTalk classes so that the names of users, lists, and services can be efficiently displayed on an STDA screen for a user, or excluded from an STDA service's database (see "Customizing the Database" later in this chapter).
The STDA classes are:
Users - User names Lists - Lists Print - Print services Files - File services Nicks - Nicknames Other - Services other than print services or file volumes (for example, AFP, asynchronous, 3270 SNA, or Netbios)
STDA lets you sort each class by as many strings as you can create from a 31-character StreetTalk item name, or according to other attributes that you configured for the StreetTalk objects in each class. For example, if an item name consists of three separate strings (Diane Lucie Baillargeon), STDA sorts on any of them, depending on how you configure the service. The default sorting algorithm for users is to sort on the first letter of the last name, then the first letter of the first name, then the first letter of the second name, and so on.
STDA User Interface
STDA lets users type in a string of characters that can be searched for and located in its database. STDA automatically scrolls through the displayed list of names as users type in the characters, to quickly locate the exact name you want. After a name is found in the STDA database, the name can be positioned wherever the cursor is placed on the workstation screen. For example, if mail users compose a message, they can run STDA from within mail, select a name, and put that name in the To: field of the mail message.
The STDIRECT command loads the terminate-and-stay-resident (TSR) program STDIRECT.EXE into a workstation's memory. STDIRECT lets users press a defined hotkey to access the STDA database from anywhere within the VINES environment. For example, you can run STDA from within the MSERVICE program. That lets you find the name of a file or a print service that you want to add to a group or manage.
The XSTD command activates the STDA program and attaches to a local STDA service. You can view attribute information associated with StreetTalk objects (for example, users' mailing addresses or telephone numbers) or search for objects based on their attribute values (for example, all users who have the same mail stop). When XSTD displays names in the STDA database, they can only be viewed. They cannot be inserted into a command line.
There are two types of STDA services: STDA master services and STDA satellite services. These services maintain and distribute the STDA database across the network. A Banyan network can have multiple master and satellite services.
Figure 8-1 shows how master STDA services collect information from StreetTalk services and the order, from the top, in which master and satellites can download. Downloading is the process of a satellite retrieving data from a master or satellite service. A server from whose STDA database names are retrieved is called a download server.
STDA master services collect user names, list names, service names, and nicknames in the network from StreetTalk services and place them into their databases. Master services can collect data from an unlimited number of StreetTalk services.
When an STDA master service is first created and started, it collects the StreetTalk names from designated servers on the network. If a server becomes accessible across a transient link, a master service can collect information from that server too. You can create server lists that include or exclude servers with StreetTalk services from which you want to collect information.
A master service builds its initial database with whatever names are found in the databases of the StreetTalk services it is instructed to poll. On a network with more than one master service, each master service may have only a portion of all the StreetTalk names on the network.
A satellite collects data from a master service. In Figure 8-1, the satellite services are pulling data from the master or from other satellite services. You configure the service that retrieves (pulls) the information (for example, the satellite), not the service that maintains the database that is downloaded.
A satellite service can request data from more than one master and satellite service. A satellite service can have all the names on the network because it can collect names from many satellite and master services.
Any names that you add to a satellite service (for example, non-StreetTalk names) are downloaded to other satellite services. Those names will never be in the database of a master service because master services do not retrieve names from satellite services. (However, you can add non-StreetTalk names to a master service.)
You can direct users to satellite services that have all the StreetTalk names that they need to know.
Consider these guidelines when you plan adding master and satellite services:
Create as many master services as your Banyan network needs. The size and topology of your network, or the organization of your company, can determine the number of master services. For example, if your company is in several geographical areas, consider creating a master service for each area. You can also create duplicate master services as backups to collect redundant information. All STDA services that are not master services are designated as satellite services. A server can run only one STDA service, either a master service or a satellite service. Not all servers on a network need to run an STDA service.
Rebuilding the Database
After the initial database is built, every occurrence of a Banyan network event, such as a new server coming on line, causes a master service to collect newly available StreetTalk names. The master service then incorporates the changes into its database, according to a schedule configured from within StreetTalk Explorer or MSERVICE program. This process is known as a scheduled rebuild. When a satellite service rebuilds its database, it requests that another service download its database and then incorporates new names into its database.
You can also use StreetTalk Explorer or the MSERVICE program to rebuild the master or a satellite service at any time (an unscheduled rebuild).
Only those portions of the master database or the satellite database that have changed between rebuilds are downloaded from a master service to a satellite service or from one satellite service to another.
You must schedule the master service to update its database at least once a week. The default schedule for a master service is daily at 1 a.m. If your StreetTalk information changes frequently, you may want the master service to rebuild daily. However, a daily rebuild may not be necessary.
Satellite services can download data once per day but are not required to. You configure how frequently updates are performed. The default rebuild schedule for an STDA satellite service is daily at 4 a.m. If you have many satellites on the network, you should stagger the rebuilds so that each satellite is updated after the service from which it downloads data has rebuilt its database. A download precedes a rebuild. From the user's perspective, downloads and rebuilds are not separately scheduled events.
Figure 8-2 illustrates a rebuild schedule that is staggered.
Note: If you change the default rebuild schedule, it is recommended that you schedule a rebuild in off-hours. Rebuilds are time-consuming, use up StreetTalk resources, and add to network traffic.
Customizing the Database
You can use the inclusion, exclusion, and exception parameters to customize the database of a master or satellite service.
Exclusions prevent StreetTalk names from being included in the database of a master service. For example, it is recommended that you keep AdminLists, sample profiles, and private lists from users.
Exceptions fine-tune exclusions so that they work on all but a few StreetTalk names in the STDA database. For example, you can exclude all AdminLists from the database except those identified as exceptions. Names that qualify as exceptions remain in the database when it is downloaded to satellite services.
Inclusions add non-StreetTalk names (such as those from mail gateways) to the STDA database. Only inclusions added since the last rebuild are downloaded to satellite services from a download server. All STDA services can accept, distribute, and display inclusions. Satellite services can filter the inclusion information they collect.
A service's configuration parameters apply to its own database, and the databases of those services that it downloads. If a service does not use a particular parameter, a satellite that it downloads is not affected by it. The configuration parameters of satellite services do not affect the STDA master services.
A service's exclusions and exceptions must appear together in a single list. You edit the list either in StreetTalk Explorer or the MSERVICE program or in a text file that you create outside of these management programs. Managing Users and StreetTalk describes how this is done.
Planning for STDA includes setting up exclusions, exceptions, and inclusions.
Planning for STDA
Planning for STDA consists of the following tasks:
Calculating disk space requirements Sorting names Configuring attributes Locating STDA services on the network Designating download servers Scheduling rebuilds Creating exclusions, exceptions, and inclusions
Your selection of servers to run STDA determines STDA performance. After STDA is running, you should monitor the performance of your network and make any adjustments that are needed. The next section explains how you do this.
Calculating Disk Space Requirements
The disk space required for an STDA service depends on:
The number of STDA entries in the database of your STDA service The number and size of attributes configured for STDA database entries The size of databases of the master and satellite services that your STDA service retrieves data from Exceptions and exclusions applied to the database (if any)
Each of the two components of an STDA service database requires the following disk space:
800 bytes per database entry (name) for storage when no attributes have been defined for an entry 180 bytes per database entry (name) for storage for each attribute defined for the entry Additional bytes for each attribute representing the size of the attribute when an entry has an attribute defined for it
When you select a disk to use for STDA, multiply the number of entries by 1600 bytes (800 x 2) or 1960+ bytes (2 x 980+) to calculate the total amount of space needed to process the database of one STDA service on one server. If your server retrieves data from download servers, the size of those databases must be added to the size of your STDA service's database.
See Managing Users and StreetTalk for more information.
STDA lets you perform complex sorting operations on the item parts of all classes of StreetTalk names. STDA can perform these operations:
Sort on first, last, or middle names Sort on names while ignoring titles (for example, Jr., Sr., or ESQ.) appended to names Sort names in languages, such as Spanish, in which the father's last name (patronymic) is not the last section of an item name. For example, STDA can display the following names in alphabetic order:
Carlos Salinas de la Garza
Juan Salinas Lopez Garza
Maria de Jesus Salinas Portillo
Pablo Arquez Spinoza
or in the order of the patronymic names, as follows:
Pablo Arquez Spinoza
Carlos Salinas de la Garza
Juan Salinas Lopez Garza
Maria de Jesus Salinas Portillo
Sort lists in which part of the item name represents a different component of business or organization function. For example, STDA can display the following lists alphabetically by the entire item name:
Sales Corn Chicago@Prod1@WCTUS
Sales Corn Winnipeg@Prod3@WCTCA
Sales Wheat Chicago@Prod2@WCTUS
Sales Wheat Winnipeg@Prod3@WCTCA
or in alphabetical order sorted on the third part of the item name:
Sales Corn Chicago@Prod1@WCTUS
Sales Wheat Chicago@Prod2@WCTUS
Sales Corn Winnipeg@Prod3@WCTCA
Sales Wheat Winnipeg@Prod3@WCTCA
To specify an STDA sorting order, you run the MSERVICE program.
To take advantage of STDA sorting, follow these guidelines:
Enter user names in a consistent fashion. For example, avoid entering some names with middle initials and others with middle names if that creates ambiguity. You can enter names in any order (first-middle-last or last-first-middle), but enter all names the same way. Avoid using a prefix or suffix title as part of a name (Dr., Jr., Sr., II, Esq.) unless the title makes the name unique.
When users run the XSTD command, it activates the STDA program. The STDA program displays all the StreetTalk objects according to their class (for example, Users, Lists, Printers, and so on).
For each class, users can perform these tasks:
Tasks for administrators include:
Defining which attributes each STDA service stores and collects. Changing the default attribute labels (for example, changing "Telephone Number" to "Extension") or adding new ones if the defaults are not suitable. You or users supply values for the attributes (for example, telephone numbers).
VINES management programs (for example, StreetTalk Explorer, MATTR, MUSER, and MGROUP) let you add or modify attributes. Chapter 3 has examples of attributes. See Managing Users and StreetTalk for more information.
Locating STDA on the Network
Before installing STDA on your network, study the topology of the network to determine the best placement of STDA master services. Try to place the master services at the most central locations on the network. Servers on which the master services reside should have the shortest path (as measured by the number of hops) to most servers on the network.
Adding a Satellite Service
A satellite service should be added to a server when:
Requests by users must route through two or more servers residing on different LAN segments to reach an STDA service. A server accesses the network over a transient link. If the server has an STDA satellite service added to it, users can get to the STDA database at any time, regardless of whether the link is up or down. Users who connect to the network through a specific server may want or need to have a customized version of the STDA database. That is, through the use of exclusions, exceptions, and inclusions used on that server's satellite service, a group of users on the network may have a version of the STDA database that no one else uses.
In general, every backbone LAN on your network should have at least one satellite service.
Example STDA Services on a Network
Figure 8-4 shows a portion of a network with one STDA master services and two satellite services installed. Note the following features about this network:
Master services are on Servers 1, 4, and 5. LAN Segment A is connected to the rest of the network by a transient link. The transient link justifies a master service on LAN segment A. LAN B is a backbone LAN. Server 5, which is centrally located in the network and routes data between LAN Segment B and LAN Segment C, has an STDA master service on it. The master service on Server 4 collects StreetTalk information from the same StreetTalk services as does the STDA service on Server 5. It acts as a backup to the STDA service on Server 5. Server 8 has a satellite service. Otherwise, users on LAN Segment D would have to route through three servers (servers 6, 7, and 8) to reach the STDA master service on Server 5.
Restricted Links and STDA
When communicating across a restricted link, an STDA master service collects only the names in groups named servername@Servers on the far side of that link. The master service cannot detect other groups on servers on the end of the restricted link, so it does not collect names from those groups.
In Figure 8-5, Server USCHI001 can detect all the groups on Server USCHI002 across the restricted link. Server USCHI001 can detect only the groups USCHI003@Servers and USCHI004@Servers on Servers USCHI003 and USCHI004, respectively. It cannot collect the names in the SalesEast@WCTUS and SalesSouth@WCTUS groups.
Therefore, if a master service is located at one end of a restricted link and more than one satellite service is located at the other end of the link, the databases of the satellite services will not usually contain names from the groups that the master service cannot reach. Locating satellite services across restricted links should be avoided. It is not recommended that you add names to the servername@Servers group (for example, USCHI003@Servers). Server USCHI002 can be made a master service and can collect names from Servers USCHI003 and USCHI004 to avoid downloading over a restricted link.
Designating a Download Server
To set up a link between two STDA services, you specify the name of the server with the established STDA service when the new STDA service is created. The established server is known to the new satellite as its download server.
These guidelines apply to download servers:
One satellite service can download data to another satellite service. Do not designate a satellite service's own server as its download server.
As soon as you start a satellite service, it immediately attempts to receive its database from its download server. The satellite service repeats its request to the download server periodically until the server honors the request. Thereafter, downloads occur according to the service's schedule.
You can use the MSERVICE program to change the download server for a satellite service at any time.
Use the STDA Planning Worksheet, illustrated in Figure 8-6, to plan the location of STDA services on your network. Indicate the names of servers on which STDA services will be started and configured. Identify each of these as a satellite or master service. Each satellite must have at least one server from which it retrieves (downloads) its database. Note that in this worksheet example the WCT branch offices have their own master services. The satellite service on the Canadian server (CAWIN004) downloads from the Canadian master service on CAWIN003 and the American master service on server USCHI006.
An important administrative task is scheduling when the master and satellite services are to be rebuilt.
When you schedule rebuilds for master and the satellite services, schedule the master services to be the first service to rebuild, followed by the satellite services that are downloaded directly from the master services, followed by the satellites that these satellites are downloaded from directly, and so on. (This order is illustrated in Figure 8-1.) If you do not allow enough time for a service to complete its rebuild before the services that retrieve data from it begin to update their databases, the retrieving services may not receive all of the newest information.
Allow at least two hours between the time you begin to rebuild the master database and the time you begin to rebuild the databases of the satellite services that retrieve from the master service. (See Figure 8-2.) Allow more time if your network is large or is connected by many slow-speed links. You can use the STDA service logs to track how long the rebuilding takes, so when you reschedule the rebuilds, the starting times are staggered accordingly.
Rebuilds should occur when the system is subject to very little use. How often an STDA service's database should be updated depends on how often your StreetTalk information changes. When an administrator adds, deletes, or changes the names and/or descriptions of network users and services, the rebuild of every STDA database on the network is affected. In general, rebuilds on most networks should occur once daily.
Keep in mind that if master and satellite services are in different time zones and different countries, scheduling a rebuild can be difficult. A download that begins in off-hours may end in a period of heavy use. To avoid this situation, additional master services should be created.
Creating Exclusion, Exception, and Inclusion Lists
Consider these alternative suggestions when you create exclusion, exceptions, and inclusion lists:
Exclude from master and satellite services all StreetTalk names except those you want to include. Exclude any names with wildcards (for example, *@*). Include on master and satellite services all non-VINES names that users need, such as addresses to mail gateway services. Consider having your master service include all StreetTalk names. Then define the exclusions on the satellite services. This lets administrators of the satellite services customize the database and removes that responsibility from the master service. If you have a common set of exclusions, define them on the master service to reduce the amount of data transferred across the network and to eliminate each satellite's need to exclude the same names. If slow speed links connect master and satellite services, let the master service or satellite services that download other services contain only StreetTalk user names. That prevents lists, nicknames, and non-StreetTalk names from being downloaded to satellites. That shortens the time of a download and saves money.
If you customize master and satellite services, you must also customize user profiles so that users pick up the STDA service that has the StreetTalk names that they need. The !SETSTDA profile command specifies which STDA database a user accesses. The Command Reference describes the command.
As you plan your network, be aware that the following factors affect the performance of STDA:
Transient links Network size Server memory requirements
Transient Links and STDA
Transient links may affect how quickly the STDA service rebuilds. For example, if Server B has a dial-up link to Server A, make sure that the STDA satellite service for Server B is able to retrieve its database from the StreetTalk naming service on Server A at a time when the two are linked. In addition, check that Server B has enough link-up time to complete the download.
A master service collects names automatically when servers across transient links connect to the network, regardless of the master service's schedule. However, the collected names do not appear in the master service's database until after the completion of the next scheduled rebuild of the master database.
If you plan to install STDA on a large network, follow these guidelines:
Place master STDA services on servers that are not heavily loaded. STDA should be one of the few services running, in addition to the VINES services. For example, the local StreetTalk service should be able to respond to STDA and should not be busy with any other services, such as file or print services. For extremely large and complex networks, consider designating additional servers to run STDA master services. You should set specific switches to let users direct STDA requests to specific services, rather than broadcasting requests. In large networks requests that are not targeted for specific STDA services may cause excessive network traffic. Managing Users and StreetTalk explains how to create a batch file for users who enter the STDIRECT command and how to add the !SETSTDA command to user profiles. The Command Reference describes the STDIRECT and !SETSTDA commands.
The memory requirements of STDA are similar to those of StreetTalk: they increase until they reach a plateau. In large networks, a heavily used STDA service can use as much as 100 KB more memory than the service's memory requires at startup. An example of a heavily used STDA service is a master service that has about a 100 users accessing it. Typically, master services have greater memory requirements than satellite services.
For more information on how to measure the memory requirements of STDA and interpret the meaning of this information, see Monitoring and Optimizing Servers.
After you add an STDA service to your network, monitor its performance with the service's log. The STDA log shows you how long a rebuild or download takes for each service. The log can help you to schedule the download times for satellite services that are dependent on other satellite services (or the master service) for an updated database.
Managing Users and StreetTalk describes STDA logs.
Administrator's Check List
Complete the tasks in this list to ensure that you have properly planned for using STDA:
Select the location of the master and satellite services. Designate download servers. Schedule rebuilds. Begin compiling lists of exclusions, exceptions, and inclusions for use when you configure the STDA service. Become familiar with StreetTalk attributes so STDA can be used to its best advantage. Add the !SETSTDA command to user profiles so that users will access the appropriate STDA database.
When you finish reading this chapter, you should be familiar with these terms:
Class - A category of StreetTalk names found in an STDA database. The STDA classes are: File Volumes, Lists, Nicknames, Other Services (for services other than file volumes or print services), Printers, and Users.
Download server - A server whose STDA database is retrieved by another server with an STDA service. You must specify which server can download data from another.
Exceptions - An STDA configuration parameter that can override one or more STDA exclusion parameters operating on the database of an STDA service.
Exclusions - An STDA configuration parameter that prevents StreetTalk names that match it from being added to a database. STDA exceptions override STDA exclusions.
Inclusions - An STDA configuration parameter that adds non-StreetTalk names (such as those from mail gateways) to an STDA database.
Master service - The main STDA services on a Banyan network. Master services collect user, list, and service names from StreetTalk services on other servers on the network and sort them in their databases. You determine the StreetTalk services from which a master service collects information. Satellite services retrieve databases from master services.
Satellite service - An STDA service that either retrieves an STDA database, or has its database retrieved by another satellite service.
STDA - A Banyan directory service that lets users look up the names of users, lists, and services located on their Banyan network. STDA software includes a terminate-and-stay-resident (TSR) program that lets users access STDA from anywhere in a Banyan network.
STDA database - A collection of names that is controlled by an STDA service. The names in a database are ordered within STDA classes when they are displayed on the STDA screen.
STDIRECT - The command that installs the resident version of the STDIRECT program in workstation memory. The program retrieves an STDA database and displays it on the workstation screen.
XSTD - The command that activates the STDA program and attaches to a local STDA service.
For more information on the topics discussed in this chapter, see the following books in the VINES documentation set: