What's New In MaxL Release 6.5

New Functionality

  1. Setting an I/O Access Mode on a Database
  2. Using Special Characters in User and Group Names
  3. Read-Only Operations Allowed During Database Export
  4. Creating Externally Authenticated Users
  5. Setting a Message Level on Startup of MaxL Shell
  6. Invoking MaxL Shell to Prompt for User Name and Password
  7. Using MaxL Shell Variables in New and More Flexible Ways

Changes and Enhancements

  1. Validating Existing Partitions Independently of Creation
  2. Displaying Advanced Partition Information
  3. Displaying Custom-Defined Functions and Macros in Four Different Ways

New Functionality

  1. Selection of the input/output (I/O) access mode Essbase will use is now controlled per database, instead of as a system-wide selection. Essbase runs by default under buffered I/O, but direct I/O is an option. Direct I/O is needed if you wish to use Essbase's cache memory locking feature. Direct I/O is also required if you wish to use your operating system's no-wait (or asynchronous) I/O. For important information about how direct I/O affects database cache-sizes, please see the Hyperion Essbase Installation Guide.

    With Release 6.2, you could switch to direct I/O for all databases by using a essbase.cfg setting, DIRECTIO TRUE. With Release 6.5, the DIRECTIO config-file setting becomes obsolete. With Release 6.5, if a DIRECTIO setting exists in the .cfg file, all newly created Release 6.5 databases and all databases migrated to Release 6.5 will read the I/O access mode specification from essbase.cfg one time, and copy that information to the Essbase security file (essbase.sec). Thereafter, if you wish to change the I/O access mode used by any database, you must change it at the database level using the database settings.

    The database setting for I/O access mode in MaxL is part of the alter database statement.
    Example: alter database Sample.Basic set io_access_mode direct;
    Changes to the I/O access mode are effective the next time the database is started. If you set a database to use direct I/O, Essbase will attempt to use direct I/O the next time the database is started. If direct I/O is not available on your platform at the time the database is started, Essbase will use buffered I/O, which is the default. However, Essbase will store the I/O access mode setting that you specified in the security file, and will attempt to use that I/O access mode each time the database is started.

  2. The MaxL Shell allows single quotation marks to be used within user or group names. Although single quotation marks are used to separate units of MaxL statements that contain special characters, they can now be used also within user and group names, with backslash used as an escape sequence.

    Example:
    create user 'O\'Brian' identified by 'password';

    See complete quoting and escape-sequence rules for both MaxL and the MaxL Shell.

  3. Database exports allow users to log in and perform read-only operations while the database export proceeds. Instead of disallowing user connections during the entire database export process, the export process in Release 6.5 sets the database to read-only mode. The database is restored to the normal state when the export process completes. This eliminates the need to use begin-archive and end-archive utilities before and after performing a database export.


  4. Creating a user can be done in two ways: Users can be created to use the standard Essbase security model for logging in, or users can be created whose logins are externally authenticated using an outside authentication protocol such as LDAP.
    Release 6.2 introduced the ability to create externally authenticated users in Essbase. With Release 6.5, the MaxL create user statement enables creating externally authenticated users with the MaxL language interface.


  5. The MaxL Shell has invocation flags that can be used to accomplish various tasks in advance before the shell is launched; for example, the -l flag allows you to specify a login host as an argument to the shell. With Release 6.5, setting the message level returned by the shell is also available as an invocation option, the -m flag.

    Example:
    essmsh -m error
    Sets error messages as the only type of message to be returned by the MaxL Shell. Values for the -m flag include: default, all, warning, error, and fatal. The default value is all (same as default).


  6. The MaxL Shell can be invoked using -u and -p options in interactive mode, for passing the user name and password to the shell upon startup. To be prompted for both username and password, use the -s option with the host name of the OLAP Server. More information


  7. The MaxL Shell (essmsh in the Bin directory), which is used to run MaxL scripts or conduct interactive MaxL sessions, contains enhanced variable handling.

    In the MaxL Shell, you can use variables as placeholders for any data that is subject to change or to which you refer often. Prior to Release 6.5, the MaxL Shell allowed variables to be either positional parameters or environment variables. In Release 6.5, the flexibility of positional parameters is increased; also, a new type of variable can be used: locally defined shell variables.

    Positional Parameters:
    These variables are passed in to the shell at invocation time as arguments, and can be referred to generically by the subsequent script or interactive MaxL Shell session using $n, where n is the number representing the order in which the argument was passed on the command line.
    For example, if the shell is started with the variable values provided,
    essmsh -a arg1 arg2
    The MaxL statements in the subsequent session can use $1 to refer to arg1, $2 to refer to arg2.

    Additionally, with Release 6.5, you can change $1 to mean arg_new in the same MaxL Shell session, using the following syntax:
    set 1 = arg_new;
    In other words, you can reset the value associated with the positional parameters, without needing to exit the shell and start again, passing new arguments.
    Note: If you nest MaxL Shell scripts or interactive sessions, the nested shell does not recognize positional parameters of the parent shell. The nested shell should be passed separate arguments, if positional parameters are to be used.

    Locally Defined Shell Variables:

    With Release 6.5, you can create variables of any name in the MaxL Shell without the use of arguments or positional parameters. These variables persist for the duration of the shell session, including in any nested shell sessions.

    Example:
    MaxL>login user1 identified by password1;
    MaxL>set var1 = sample;
    MaxL>echo $var1; /* see what the value of $var1 is */
    sample
    MaxL>display application $var1; /* MaxL displays application "sample" */

    Note: Locally defined variables can be named using alphabetic characters, numbers, and the underscore (_). Variable values can be any characters, but take note of the usual quoting and syntax rules that apply for the MaxL Shell.

Changes and Enhancements

  1. You can use use MaxL to validate an existing database partition definition. To validate a partition definition, use the create partition statement with the validate only keywords at the end. The statement validates an existing partition definition; it does not re-create it. Partition definitions are always validated upon creation with the create partition statement, but validate only enables validation without re-creation.


  2. The display partition statement contains an optional advanced keyword. When the advanced keyword is used, MaxL displays full information, including areas and member mappings for local and remote pieces of partitions.


  3. MaxL displays of custom-defined functions and macros have enhanced selection criteria. With Release 6.5, you can display custom-defined functions or macros in four different ways, depending on which syntax you use in the display statement.

Copyright 1991-2002 Hyperion Solutions Corporation. All rights reserved.