Documentation:FAQ - MdsWiki
Navigation
Personal tools

From MdsWiki

Jump to: navigation, search
MDSPLUS FAQ


Contents

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:

TCL> DISPATCH/BUILD/MONITOR=FOO:8106
TCL> DISPATCH/PHASE/MONITOR=FOO:8106/NOLOG INIT

Then you can start an actmon process to monitor the actions by issuing the command:

# actmon -monitor foo:8106

The actmon program is only available on Linix based and OpenVMS platforms. A java based action monitor has also been developed by Gabriele Manduchi which will work on other platforms.

Expression Evaluator - TDI

How do I specify where MDSplus looks for TDI functions?

On UNIX platforms, it uses the environment variable: MDS_PATH. This should point to a directory (or list of directories delimited by a semi-colon).

On Windows, this location of the functions is defined in a windows registry entry:

HKEY_LOCAL_MACHINE\SOFTWARE\MIT\MDSplus\MDS_PATH

Like UNIX this should contain a directory specification or a list of directories delimited by a semi-colon.

On OpenVMS, the location of the functions is defined by a logical name specifying a search list. The search list can include wildcarding such as mds$root:[tdi...].

MDSplus will look in this directory (and all subdirectories on UNIX and Windows) for a file named "function-name.fun".

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:

Download MDSplus sources

The MDSplus source code is maintained on github. If you are interested in building MDSplus from the sources we recommend downloading a tarball, or a zip file from there.

  1. choose 'stable' or 'alpha' - ""note alpha is the active development branch and may contain untested code.""
  2. choose 'zip' or 'tar.gz'
  3. download the sources (choose one of):
    wget https://github.com/MDSplus/mdsplus/archive/alpha.zip
    wget https://github.com/MDSplus/mdsplus/archive/alpha.tar.gz
    wget https://github.com/MDSplus/mdsplus/archive/stable.zip
    wget https://github.com/MDSplus/mdsplus/archive/stable.tar.gz

The MDSplus repository can also be cloned from github using:

git clone https://github.com/MDSplus/mdsplus.git
# cd mdsplus
# ./configure
# make
# make install

Remote Access - MDSIP

Where is the Fusion Grid FAQ?

Fusion Grid site is at: www.fusiongrid.org and their FAQ site is at http://d3dnff.gat.com/FAQ_NFC

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:

$ echo $LANG

Fix: comment out the line in /etc/sysconfig/i18n as follows:

#LANG="en_US.UTF-8"
LANG="en_US"

The traverser will eventually be modified to fix this....

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 specify where the MDSplus tree files are to be found?

The mechanism used to define where tree files live is dependent on the operating system being used.

On OpenVMS you define a logical name called treename$DATA to point to a directory. For example:

$ DEFINE MYTREE$DATA DKA400:[MYDIRECTORY]

On UNIX systems you would define an environment variable called treename_path to be a directory. For example:

# mytree_path=/home/mydir/trees
# export mytree_path

On Windows systems you need to add a string key to the Windows registry using regedit called

\HKEY_LOCAL_MACHINE\SOFTWARE\MIT\MDSplus\treename_path

which points to a directory. For example:

\HKEY_LOCAL_MACHINE\SOFTWARE\MIT\MDSplus\mytree_path = C:\MYTREES

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.

What "usage" can a tree node have and what is it used for?

Tree nodes can be classified by their usage. The can be any of the following:

ANY
Unspecified. Can contain any type of data.
STRUCTURE
Child node. Cannot contain data. Used for tree structure only.
ACTION
Contains an MDSplus action. Used for specifying a job to be done during a data acquisition/analysis cycle.
DEVICE
The top node of the data acquisition/analysis device specification.
DISPATCH
Not generally used. Contains the dispatch portion of an action.
NUMERIC
Contains some numeric value generally viewed in tabular form.
SIGNAL
Contains a measurement generally viewed in graphical form.
TASK
Not generally used. Contains task portion of an action.
TEXT
Contains text information.
WINDOW
Not generally used. Contains window portion of a dimension specification .
AXIS
Used for specifying dependent axes such as digitizer clock output.
SUBTREE
Node is a link to another (sub) tree. Contains no data.
COMPOUND_DATA
Similar to DEVICE node. Top of collection of related nodes.


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:

  1. Open tree
  2. Open tree for edit
  3. Retrieve Tree - see more info below
  4. Write Tree
  5. Close Tree
  6. Open characteristics file for write
  7. Open datafile for write
  8. Get node data
  9. Get node characteristics
  10. Write node data
  11. 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.