Action Dispatching

What does the message: "Doing <no-node>" in the action server log file mean?

This is generally an indication that the action server has a different view of an open tree than the process which dispatched the action. When actions are dispatched to an action server, the nid number of the node is sent to the server. A nid number consists of a tree index and node index and is only valid if both the process submitting the action and the action server have the same access to the tree files. When a process opens a tree, the top tree is assigned index 0, the next tree is assigned index 1 and so forth. If the process dispatching the action is missing an tree path environment definition of one of the subtrees, then the nid numbers will not match up correctly with those on the action server.

What is actmon and how do I use it?

Actmon is an action monitor utility. If you use the action dispatching commands in TCL, DISPATCH/BUILD and DISPATCH/PHASE, you can use the actmon utility to monitor the execution of the actions. To use actmon you will need to set up an actmon server which is just another action server. This action server, instead of executing action, simply fans out action execution messages to running actmon programs. If you set up an actmon server for example on host foo, port 8106 then you would modify your action dispatching scripts to use:

How do you make a general data accessor for MDSplus?

Installation

How do I get MDSplus to set protection on new tree files?

When new MDSplus files are created on unix systems, the software attempts to invoke a script called SetMdsplusFileProtection with the full file specification of the file that it created. A sample script is provided which contains the following:

#!/bin/sh
#
# Change group of file to that of the container directory
# Change mode to allow user and group read,write and other read
if test -d $1
then
chmod 0775 $1
else
chgrp $1 --reference=`dirname $1`
chmod 0664 $1
fi

This script will set the grp of the file to the same as its parent directory. It will then grant read and write access to the owner and group of the file. The script must be executable and be in the users path.

How do I install MDSplus?

The installation procedure is different depending on the operating system you are using. First you must go to the MDSplus download page and download the kit that matches your operating system. If there is no kit for your operating system you will need to build MDSplus from the sources available via cvs.
If you are using Linux then you will need to install the OpenMotif kits also found on the download page. The UNIX type operating systems use kits in the rpm format (Redhat Package Manager). You would use the rpm command on these systems to install the kit. You may need to download the rpm kit from the MDSplus download page for some systems if it is not already installed on your system.

For OpenVMS, the kit is installed using the product command:

$ product install mdsplus

On Windows, it is recommended that you use Internet Explorer to download the kit. This will enable you to install directly from the download page.

Note: There are kits listed in the download page which are marked "Globus enabled". You should not install these kits unless your system has been configured to be used with the Globus Security Infrastructure. For more information on this go to the Fusion Grid web site.

If you cannot find a kit appropriate for your operating system you can obtain the MDSplus sources:

Remote Access - MDSIP

Where is the Fusion Grid FAQ?

What options do I have for remote access to MDSplus data?

There are four different access methods to access data stored in MDSplus trees:

1) Local

2) Thin client

3) Thick client

4) Distributed

The "Local" method is used when no explicit connection to an MDSplus server
is performed and the tree path definition refers to local file systems. All
expressions are evaluated in you process context and the files are accessed
using direct file I/O.

The "thin client" method is used when you do an mdsconnect to an MDSplus data
server. All expression evaluation and file I/O is done by the server. No
tree path definitions are required on the client machine. This method places
most of the cpu and I/O load on the server machine. Since the data is
decompressed and evaluated on the server before sending the results to the
client, this method usually results in a heavy load on the network.

The "thick client" method is used when no explicit connection to an MDSplus
data server is made and the tree path definition is in the form "host::". In
this access mode, all expression evaluation is performed on the client but
the tree file I/O is done by the server. The server uses its local tree path
definition for finding the trees and the server uses tree access routines to
retrieve data from the trees and return it to the client.

The "distributed" mode of access is used when no explicit connection to an
MDSplus data server is made and the tree path definition is of the form:
"host::dir-spec". In this mode, all expression evaluation and data decompression
is done by the client. The server performs efficient low-level file I/O on behalf
of the client. This mode fully supports "distributed" trees in that subtrees can
reside on different hosts.

Traverser

How do I prevent traverser failures on 'Setup Device'?

This problem has now been fixed. The fixed code will be in the next release after 1.5-0. In the meanwhile: The the motif device setup forms in the traverser needs the environment variable 'LANG' to be set to en_US. On some stock RH installations it gets configured as en_US.UTF-8. This breaks the motif compound string text extraction called by xmdsshr. Check:

What happened to the 'add child' button in the edit menu of the traverser?

Both members and children are now added with the 'add node' button. Do not specify any leading punctuation. If the 'structure' usage is clicked the node being added will be a 'child', any other usage will cause the node be added as a memeber.

Trees

What is a shot number?

MDSplus keeps data in MDSplus tree files. These files are indexed by tree name and shot number. The shot number identifies an instance of a given tree. Shot numbers are stored in a 32-bit signed integer so the largest shot number is 2^31. Two shot numbers have special meaning. The shot number -1 refers to the model tree. New shots are usually created by replicating the model tree. Shot number 0 is another special shot number and represents the "current" of a tree. Normally when new shots are created the "current" shot is incremented. Users may develop applications which open shot number 0 to get to the more recent data for an experiment.

How do I get MDSplus to set protection on new tree files?

When new MDSplus files are created on unix systems, the software attempts to invoke a script called SetMdsplusFileProtection with the full file specification of the file that it created. A sample script is provided which contains the following:

#!/bin/sh
#
# Change group of file to that of the container directory
# Change mode to allow user and group read,write and other read
if test -d $1
then
chmod 0775 $1
else
chgrp $1 --reference=`dirname $1`
chmod 0664 $1
fi

This script will set the grp of the file to the same as its parent directory. It will then grant read and write access to the owner and group of the file. The script must be executable and be in the users path.

What options do I have for remote access to MDSplus data?

There are four different access methods to access data stored in MDSplus trees:

1) Local
2) Thin client
3) Thick client
4) Distributed

The "Local" method is used when no explicit connection to an MDSplus server
is performed and the tree path definition refers to local file systems. All
expressions are evaluated in you process context and the files are accessed
using direct file I/O.

The "thin client" method is used when you do an mdsconnect to an MDSplus data
server. All expression evaluation and file I/O is done by the server. No
tree path definitions are required on the client machine. This method places
most of the cpu and I/O load on the server machine. Since the data is
decompressed and evaluated on the server before sending the results to the
client, this method usually results in a heavy load on the network.

The "thick client" method is used when no explicit connection to an MDSplus
data server is made and the tree path definition is in the form "host::". In
this access mode, all expression evaluation is performed on the client but
the tree file I/O is done by the server. The server uses its local tree path
definition for finding the trees and the server uses tree access routines to
retrieve data from the trees and return it to the client.

The "distributed" mode of access is used when no explicit connection to an
MDSplus data server is made and the tree path definition is of the form:
"host::dir-spec". In this mode, all expression evaluation and data decompression
is done by the client. The server performs efficient low-level file I/O on behalf
of the client. This mode fully supports "distributed" trees in that subtrees can
reside on different hosts.

MDSplus does limited checking when data is stored into a node and prevents the entry of data types which are inconsistent with the usage of the node. Some tools use different icons depending on the node usage and some search for nodes based on their usage.

Can I monitor the activity of MDSplus trees?

There is some limited capability to add a plugin to the MDSplus library, TreeShr, which contains the routines for accessing or modifying MDSplus trees. To utilize this plugin you must create a shared library called TreeShrHooks with one entry point called Notify. When applications perform the following operations, the Notify routine will be called before the operation is started:

Open tree

Open tree for edit

Retrieve Tree - see more info below

Write Tree

Close Tree

Open characteristics file for write

Open datafile for write

Get node data

Get node characteristics

Write node data

Write node characteristics

The Notify routine will be called with four arguments:

TreeshrHookType operation - the operation being performed.

char *treename - name of the current tree.

int shot - the shot number

int nid - the node id of a node or 0 if not relevant to the operation

When developing the Notify routine, you should include mdsplus/include/treeshr_hooks.h.
The shared library must be located in a directory where the system will find it (i.e. in a directory included in the LD_LIBRARY_PATH environment variable or a system library directory
such as /usr/lib or /usr/lib64 etc...).

The special retrieve tree hook was originally added to provide a mechanism for retrieving
the files for a tree from a data archive which had "offline" storage such as an optical jukebox. This hook is called when a tree open fails to find the tree file. If the Notify routine is able to restore a tree to the local file system and returns a status with the low bit set, MDSplus will try again to open the tree.

Note: The usage of treeshr hooks may be useless in an environment where distributed trees are used. In this case the tree operations are being executed on the individual hosts so to
fully track tree usage you would need to provide the hooks on all the systems that might
access the trees using either distributed access or distributed files systems.

Firewalls

What are some firewall considerations needed when utilizing MDSplus?

Normally when you install MDSplus it will be configured to use the standard "mdsip" port of 8000 for allowing remote access to MDSplus data. You should probably open tcp port 8000 for incoming connections on firewalls to permit remote systems to make connections to your MDSplus data servers to access data. Of course the firewall rules may be customized to only permit connections from known hosts or ip subnets.

If you are using long running mdsip servers for things like action dispatching, you will need to open up the tcp ports that you are using for these mdsip server processes. Normally these would be open to your local area network only. Another tcp port range used for the asynchronous reply from action servers to the dispatcher process is ports 8800-9055. Incoming connections to this port range should be open for input on the server where you are running an action dispatcher. The action servers will connect back to the dispatcher on a port in this range. Again you would only need to open up this port range on local area networks and only for the ip addresses of servers that your dispatcher will be sending jobs to execute.