Document revision date: 5 July 2000

When you run this program, the following results occur:

$ run test1d $ %DCL-W-ACTIMAGE, error activating image MYSHR $ -CLI-E-IMAGEFNF, image file not found SYS$LIBRARY:MYSHR.EXE $

To allow the image activator to check a directory other than SYS$LIBRARY for your new shareable image, you must define a logical name or you must copy your new shareable image into SYS$LIBRARY. In the following example, a logical name is defined and the program is run again with the following results:

$ define MYSHR sys$disk:[]myshr.exe; $ $ run test1d $ %DCL-W-ACTIMAGE, error activating image MYSHR $ -CLI-E-IMGNAME, image file USER:[MY.CODE.DCE]MYSHR.EXE; $ -SYSTEM-F-NOTINSTALL, writable shareable images must be installed $

The problem is in the myshr.exe image: myshr.exe has PSECTs whose PSECT attributes specify both SHR and WRT. The solution is to add the correct PSECT attributes to the offending PSECTs in the myshr.exe shareable image to myshr.opt . This can be done on the command line, as follows:

$ link/share/exe=myshr.exe/map=myshr.map - test1_mgr,test1_sstub,dce:dce.opt/opt,sys$input/opt psect= TEST1_V0_0_S_IFSPEC, shr,nowrt,gbl psect= RPC_SS_ALLOCATE_IS_SET_UP, noshr,wrt,gbl psect= RPC_SS_CONTEXT_IS_SET_UP, noshr,wrt,gbl psect= RPC_SS_SERVER_IS_SET_UP, noshr,wrt,gbl psect= RPC_SS_THREAD_SUPP_KEY, noshr,wrt,gbl psect= RPC_SS_CONTEXT_TABLE_MUTEX,noshr,wrt,gbl psect= TEST1_V0_0_C_IFSPEC, shr,nowrt,gbl ctrl-z $

All of the PSECTs that existed in the myshr.map mapfile that had SHR and WRT attributes were changed so that the PSECT was either SHR,NOWRT or NOSHR,WRT. The choice depends upon your use of the data item. IFspecs are usually shared and nonwritable. The RPC_SS PSECTs are written and not generally shared among program images linked against the shareable image.

The following example tries to relink the main program again, but another problem occurs:

$ link/exec=test1d/map=test1d.map test1_main,sys$input/opt $ PSECT= TEST1_V0_0_S_IFSPEC, shr,nowrt,gbl $ myshr.exe/share $ ctrl-z $ %LINK-W-MULPSC, conflicting attributes for psect TEST1_V0_0_C_IFSPEC in module TEST1_MAIN file USERE:[MY.CODE.DCE]TEST1_MAIN.OBJ

Because the PSECT attributes of the TEST1_V0_0_S_IFSPEC PSECT was changed in the shareable image, its reference in test1_main.obj is not correct. To solve this problem, add the correct PSECT attribute. For example:

$ link/exec=test1d/map=test1d.map test1_main,sys$input/opt $ PSECT= TEST1_V0_0_S_IFSPEC, shr,nowrt,gbl $ PSECT= TEST1_V0_0_C_IFSPEC, shr,nowrt,gbl myshr.exe/share ctrl-z $

In the final example, the test1d program is run and the desired results occur:

$ run test1d ncacn_ip_tcp 16.32.0.87 3314\bold) ncacn_dnet_nsp 63.503 RPC270002590001\bold) ncadg_ip_udp 16.32.0.87 1485

14.9 Integrated Login Problems

The following sections describe problems that may occur when Integrated Login is enabled on your system, and solutions to those problems.

14.9.1 No Logical Name Match Error When Integrated Login Is Enabled

If you receive the error:

\*C%SYSTEM-F-NOLOGNAM, no logical name match)

when you try to set host to another system, the problem may be occurring because the SYSGEN parameter LGI_CALLOUTS has been set nonzero, but the logical name LGI$LOGINOUT_CALLOUTS has not been defined.

This situation can only occur as a result of one of the following:

• An incomplete startup or shutdown of DCE
• A privileged user altered the SYSGEN parameter LGI_CALLOUTS or the logical name LGI$LOGINOUT_CALLOUTS

To solve this problem, enter one of the following commands to reenable Integrated Login by running DCE$SETUP or DCE$STARTUP, as follows:

$ @sys$startup:dce$setup start $ @sys$startup:dce$startup

14.9.2 Potential Integrated Login and SYSGEN Problems

The Integrated Login component of DCE uses the SYSGEN parameter LGI_CALLOUTS. LGI_CALLOUTS must be set to 1 only in the ACTIVE SYSGEN parameter set when DCE is running with Integrated Login enabled. LGI_CALLOUTS must never be set to 1 in the CURRENT SYSGEN parameter set --- this would prevent all logins from occurring on a subsequent reboot of the system. See the chapter on Integrated Login for more information.

The following paragraphs explain how to solve this problem if it occurs.

If you cannot log in because LGI_CALLOUTS is set to 1 and DCE is not running, there are two solutions, as follows:

• If you are already logged in to the system, use SYSGEN to correct the problem.

  $ RUN SYS$SYSTEM:SYSGEN SYSGEN> SET LGI_CALLOUTS 0 SYSGEN> WRITE ACTIVE SYSGEN> EXIT $

• Reboot the system with a conversational boot and ensure that the LGI_CALLOUTS parameter is zero.

  SYSBOOT> SET LGI_CALLOUTS 0 SYSBOOT> C

The Application Developer's Kit of Compaq DCE for OpenVMS VAX and OpenVMS Alpha contains 17 example programs. These programs are located in subdirectories of the following directory:

SYS$COMMON:[SYSHLP.EXAMPLES.DCE]

The examples demonstrate some of the basic capabilities of DCE as well as the steps required when writing DCE distributed applications. All of the example programs are written in Compaq C or Compaq C++ except the Payroll example, which is written in Compaq Fortran.

Each example is in a separate directory and contains the following files needed to build and run the example:

• Source files for the example
• <example>.readme file, which explains the steps required to build and run the program
• <example>.com file, which compiles and links the program

The example programs vary in complexity. The RPC Test Programs and Hello_svc programs are elementary; the Generic_app and Timop_svc programs are more complex. The example programs illustrate some of the DCE interfaces and services.

Table 15-1 briefly describes each example program located in subdirectories of SYS$COMMON:[SYSHLP.EXAMPLES.DCE]:

Table 15-1 Example Program Features

Example Program	Description
[.GENERIC_APP]	This sample application illustrates the recommended procedures for writing DCE distributed applications. The code is as generic as possible, and demonstrates what most servers need to do. The application is mostly initialization and cleanup code, with extensive examples of ACL management, serviceability code, security setup, and signal handling.
[.GSSAPI]	The ECHO application demonstrates how a distributed application secures itself using the GSSAPI security interface.
[.PWD_MGMT]	This example provides a sample application for the password management server, a cell-wide service for enforcing the password selection policy users must follow when updating their passwords.
[.RPC.BOOK]	The Distributed Calendar (BOOK) program is a fairly sophisticated client/server application that uses several DCE services. The client sets up a search context that imports a binding handle for a book server from the directory service.
[.CONTEXT_APP]	The context_app server maintains a storage area that the client will write to and read from. The client accesses the storage area using a context handle obtained from the server.
[.RPC.DATA_TEST_APP]	This example demonstrates the use of various RPC data types.
[.RPC.PAYROLL]	The payroll software is a simple client/server application that makes minimal use of the DCE services. Its purpose is to show a complete example application with FORTRAN.
[.RPC.PHONEBOOK]	RPC PHNBK is an application that distributes a phone number directory. The server registers transport endpoints with the RPC endpoint mapper, and binding information is exported to the directory service.
[.RPC.TEST1]	RPC Test Program #1 (TEST1) is a very simple client/server program that makes minimal use of the DCE services. It is useful for acquiring the basics of client/server programming. The server does not register transport endpoints with the RPC daemon, and no binding information is exported to the directory service. The user has to manually transfer the server binding information to the client.
[.RPC.TEST2]	RPC Test Program #2 is a simple client/server program that makes slightly more use of the DCE services than does the RPC Test Program #1. In this program, the server registers transport endpoints with the RPC daemon, and exports binding information to the directory service. The client uses the auto-handle mechanism to import server binding information.
[.RPC.TEST3]	RPC Test Program #3 is a simple client/server program that makes minimal use of the DCE services. The server does not register transport endpoints with the RPC daemon, and no binding information is exported to the directory service. The user has to manually transfer the server binding information to the client.
[.RPC.IDLCXX.ACCOUNT]	This C++ example tests inheritance, binding to an object using another interface, binding to an object with an unsupported interface, and the reflexive, symmetric, and transitive relation properties of the bind() API.
[.RPC.IDLCXX.ACCOUNTC]	This C++ example tests the same properties as the account example, but uses the C interfaces for all the APIs.
[.RPC.IDLCXX.CARD]	This C++ example tests the passing of C++ objects as parameters using the [cxx_delegate] attribute and the polymorphism property of the base class.
[.RPC.IDLCXX.STACK]	This C++ example tests the passing of C++ objects as parameters using the [cxx_delegate] attribute and a user-defined stack class.
[.SVC.HELLO_SVC]	This is the Hello World example program for the DCE Serviceability API, a simple illustration of the new serviceability functionality.
[.SVC.TIMOP_SVC]	The timop program is a tutorial DCE application example. It exercises the basic DCE technologies: threads, RPC, security, directory, time and servicablity.

Please see the Compaq DCE for OpenVMS VAX and OpenVMS Alpha release notes for current restrictions on using the example programs.

This appendix provides information on using the Namespace Editor (NSedit). Note that at this time NSedit is only a prototype of a system management tool. Note also that this release of NSedit does not yet have complete functionality.

NSedit is a graphical user interface to the namespace. A namespace is a collection of names that one or more CDS servers know about, look up, modify, and share. Usually only one namespace is associated with a particular cell.

A.1 Starting NSedit

To start NSedit, you must first log in to DCE as cell_admin . Then, enter the following command:

$ MCR DCE$NSEDIT

A.2 NSedit Functionality

NSedit is a graphical user interface for CDS. Although it does not provide the complete functionality of the CDS clerk interface, it does provide a user-friendly environment for creating, viewing, and modifying entries in a namespace.

NSedit provides an additional level of namespace data caching. The NSedit cache is used to store data read from the clerk's local cache or from the CDS server. This allows for faster retrieval of data at the expense of accuracy. (Changes may have occurred in the namespace that are not reflected in the NSedit cache.) The tradeoff between speed and accuracy can be controlled by setting the appropriate mode in the Display menu of the tree browser.

NSedit consists of three windows:

• Tree Browser Window
  The entire left window of the NSedit screen is a tree browser that allows users to view the hierarchical structure of the namespace and to create and delete entries.
• Entry Attributes Window
  The top right window is a list management utility that allows users to view, modify, and delete attributes and values of namespace entries.
  Note that most of the features in this window are Read Only for this release.
• ACL Window
  The bottom right window is a second tree browser that allows users to view, modify, and delete ACLs of namespace entries.

The tree browser lets you view the namespace and create and delete namespace entries. Each CDS entry is represented in the tree browser by a rectangle containing the name of the entry and an icon indicating the entry type. A CDS entry can be one of the following:

• Directory: A directory contains objects, soft links, or other directories (child pointers) as its children. The icon is a filled square.
• Object: An object represents a physical resource in the network. Its icon is an empty square.
• Group: A group is a set of names in the network. The icon is a set of seven small squares.
• Soft link: A soft link is a pointer to a CDS entry. The icon is a right arrow.

The tree browser provides the user with the ability to expand a node and view all its children (objects, subdirectories, or soft links) by clicking Mouse Button 3 (MB3) on a tree node or by specifying the appropriate maximum tree level to display, as described in Section A.3.1.

A.2.2 Entry Attributes Window

The Entry Attributes window is the part of NSedit that lets you create, view, modify, and delete attributes and values from an existing object, directory or soft link. When you select a CDS entry with the tree browser, the attributes and values of this entry are shown on the Entry Attributes window. You can then add, modify, or delete attributes from this entry, as described in this appendix.

A.2.3 ACL Window

This window lets you perform the following functions.

• List the ACL entries.
• Add an ACL entry.
• Modify an ACL entry.
• Delete an ACL entry.
• Substitute all ACL entries with a new ACL entry. This function is not yet implemented.
• Load an ACL from a file. This function is not yet implemented.
• Save an ACL to a file. This function is not yet implemented.
• Copy an ACL entry to another. This function is not yet implemented.
• Copy an ACL to another (for example, an Object ACL can be copied onto an Initial Container Creation ACL for the selected object). This function is not yet implemented.
• Delete all ACL entries except the user_obj entry (kill the ACL). This function is not yet implemented.
• List the available permission tokens.

The following sections describe what you can do with NSedit.

A.3.1 Expanding and Collapsing Tree Nodes

To expand a tree node and view its children, click MB3 on the node. This works only for directory and soft link nodes. For example, by successively expanding nodes, you can see all of the hosts's children as well as their children.

To collapse a tree node whose children are at a higher level than the maximum tree level specified by the user (with the Set Level selection of the Display menu), click MB3 on the node. The node will not collapse if the level of its children is lower than the maximum tree level. The default maximum tree level is 1, which means that only the children of the root node are displayed.

A.3.2 Creating an Object or a Directory

To create an object or directory:

1. Type in the name of the new object or directory in the top left selection area and press RETURN. The create_entry_dialogue_popup appears.
2. Select Object, Directory, Group, or Soft Link and press OK.

If the object or directory has been successfully created, a new rectangle with the name of the new object or directory appears as a child of the specified parent directory. If CDS cannot create the object or directory, an error message appears.

A.3.3 Creating and Viewing a Soft Link

Note that the following functionality is not yet supported.

1. Click the left mouse button on a rectangle, to define the target of the soft link to be created. This target entry appears highlighted.
2. Type in the name of the new soft link in the prompt window and press RETURN.

If the soft link has been successfully created, a new rectangle with the name of the new soft link is displayed as a child of the specified parent directory. To verify the creation of the soft link, you can click the right mouse button on the soft link rectangle. If CDS could not create the soft link, an error message appears.

A.3.4 Deleting an Entry

To delete an entry:

1. Click the left mouse button on a rectangle, to define the target to be deleted. This target entry is displayed highlighted.
2. Select Delete from the Edit menu.

If the entry has been successfully deleted, the rectangle will also disappear from the tree structure. If CDS could not delete the entry, an error message is displayed.

A.3.5 Viewing Attributes and Values

To view the attributes and values of a CDS entry, click the left mouse button on this entry in the Tree Browser window. The attributes and values of this entry are displayed in the Entry Attributes window. An alternative way to view an entry is to type its full name in the top left selection area. Then the attributes and values of this entry are displayed in the Entry Attributes window (or an empty list will appear if the entry does not exist).

A.3.6 Creating a Group and Adding Members

To create a group, follow the steps described in Section A.3.2. Select Create Group from the create_entry_dialog_popup .

A.4 NSedit Menus and Dialog Box

There are three pull-down menus in NSedit and one popup dialog box:

• File Menu
• Display Menu
• Edit Menu
• Create Entry Pop-up Dialog Box

The File menu has the following choice:

• Exit: This selection exits NSedit.

The Display menu has the following choices:

• Set Root: This selection allows the user to specify the root of the tree structure to display. After a root is specified, only entries that are children of the root will be displayed by the tree browser.
• Set Depth: This selection allows the user to specify a maximum tree depth to display. Nodes deeper than the specified depth are not displayed, unless explicitly selected for expansion (by clicking the right mouse button).
• Show Entry: This selection toggles between enabling and disabling the Entry Attributes window. When the Entry Attributes window is disabled, no text can be typed in its text input areas and these areas as well as the area where attributes and values appear grayed.
• Show ACLs: This selection toggles between enabling and disabling the ACL window. When the ACL window is disabled, no text can be typed into its text input area. These areas, as well as the area where ACLs appear, are grayed. The ACLs menu selections also are greyed to indicate that no operations are possible at that time.
• Caching: This menu sets the level of caching for NSedit operations:
• Internal: This selection tells the program to read the children of a directory from the program's own cache and not from the namespace. Every time a directory's children are read from the namespace, they are placed in a local cache (data structure) by NSedit. In Internal mode, every time a node is collapsed and reexpanded, its children are read from this cache. You want to use this mode most of the time, unless you suspect that new entries have been created in the namespace. In that case you have to collapse the directory entry, select either Local mode or Server mode, and click the right mouse button on the directory to reexpand the directory and see the new information.
• Local: This selection tells the program to read the children of a directory from the CDS local cache (as opposed to reading them from the program's own cache or querying the CDS server) when you click the right mouse button on a directory entry. This selection is useful when new information is stored in the CDS local cache but NSedit is not aware of it (because it has already stored some old information in its own cache).
• Server: This selection tells the program to query the CDS server when reading children of a directory (as opposed to reading them from the program's own cache or from the CDS local cache) when you click the right mouse button on a directory entry. This selection is useful when new information has been stored in the namespace (and the server is aware of it), but is not yet propagated to the CDS local cache (as, for example, when another user creates a new object on a different machine).

	privacy and legal statement
6532_DCE_PG_PRO_012.HTML