 |
 |
|
|
 |
|
|
|
Support Frequently
Asked Questions Introduction This document lists some of the FAQ concerning Open M on Unix platforms.
The answers provided are the most probable solutions to the associated
queries, not the only possible answer. This is intended to supplement
the documentation provided with the Open M for Unix product. The current release is 6.2-rel.01 which is being distributed with F.9
SQL add-on. *** HOT NEWS - 6.x backup bug with multi volume backups fix available
*** see item 4.3 I have added an index and future releases of this document will have
change marks ("*") in this index enabling faster identification
and retrieval of new information. The third piece of the question number
will be used to mark revisions of the information. The questions are organized into 5 broad categories. Although some
questions may fit in more than one of this categories, they are only
listed once. The categories are:
Index 1. Support questions 1.1 What will you be asked about your system when you call about an issue? 1.2 * How can I use mst when M is in a non-standard directory? 2. Installation and Kernal 2.1 What system kernel parameters require changing to install Open M? 2.2 The parameter SEMMNS is not available in the scoadmin menu on SCO Server 5. 2.3 There is an <ERRTRAP> message during minstall and the subsequent startup fails. 2.4 The minstall or mstart scripts fail - how do I check the key? 2.5 On Solaris 2.4 the minstall script fails when it tries to create the MUMPS.DAT file. 2.6 How do I install an adhoc? 2.7 What limits the number of users that can get into M? 2.8 What is the maximum volume size? 2.9 M/NET daemons seem to count against the user license. 2.10 mstart no longer works after upgrading the OS. 2.11 * 6.2 gets invalid argumnet errors during install and mstart 3. Platform specific 3.1 <STORE> errors occur much more frequently on OSF or Digital Unix than other platforms. 3.2 mstart on SCO generates invalid argument messages. 3.3 Long printouts are being truncated on a LAT printer with OSF version 3. 3.4 The mstart script on Solaris fails complaining about invalid arguments. 3.5 Cannot open /dev/lp on AIX even if the permissions are correct? 3.6 Line drawing on the console of SCO Server 5 is done with alphanumeric characters. 4. Version specific 4.1 What does the version string denote? 4.2 Version 5.10 (and later) can startup but not let users in. 4.3 * The online Backup utility never stops when a second volume is used. 5. Utility 5.1 There is an <UNDEFINED> error in the SPOOL utility when I try to print a file without starting at the first page. 5.2 Selecting a print from the SPOOL menu prints the wrong file when a sub list is generated. 5.3 Why does %SS hang? 5.4 What is a ghost process? 5.5 How is $ZA useful? 5.6 The INTEGRIT utility reports map block code errors - "Block ddd which is pointed to by block ppp has code 255 in the map block mmm whereas code 1 was expected."? 5.7 %RO output cannot be read by DSMs %RR utility. 5.8 How do I determine what my active configuration is? 5.9 How do I determine what the default start-up configuration is? 5.10 How do I delete the default M/NET configuration to be brought up at mstart, so that no network configuration is started? 5.11 How do I determine the version of the Visual M server in ISM? 5.12 How do I select globals with long names in INTEGRIT? 5.13 Why is $H different in foreground and background processes? 1 - Support Questions1.1 What will you be asked about your system when you call about
an issue? Before support starts to investigate any issue there is a minimum amount
of information that we will need to help isolate the problem: What platform What version of the OS Which version of Open M When was the last change made to any part of the system Can the problem be reproduced at will Do you have any custom C code linked into the product Do you have any automated jobs interacting with M (backups, reports
etc) Then we can get into the specifics of the problem at hand. 1.2 How can I use mst when M is in a non-standard directory?
Use the -s option to specify the correct M manager directory. Since mst is installed in the manager's directory then the dot notation for current directory is sufficient: # ./mst -s. -a1 2 - Installation and Kernel2.1 What system kernel parameters require changing to install
Open M? In general a basic installation will work on an untuned kernel, the default values being adequate for this operation. For a productive system, the more memory that can be allocated as shared memory the better, and the more semaphores that can be allocated will enable more users to interact with the M application. However there are some systems (such as AIX) that do not need any such tuning and grant the requests dynamically so the settings are not common across various Unix implementations. If a system is used by other applications together with Open M then these requirements need to be accounted for too. Open M uses a minimum of 3 and a maximum of 5 shared memory regions. Typically the limits on these are either by individual segment size (SHMMAX), or by a total shared memory allowance (SHMALL), as well as number of shared memory regions. Of the three basic regions, the "MCOMMON" area is typically 1MB but depends on the M configuration itself, the global buffers section is 2.2K * # of buffers required, and the routine buffers section is # of buffers * buffer size, where the routine buffer size defaults to 16K or 24K depending upon the version, and is a maximum of 32K. The other regions are for M/NET and for the performance monitor (version 5.10 and up) and are usually less than 1MB each. Open M uses 2 message queues - the default kernel parameters are large enough. Open M uses a number of semaphore arrays - the configuration of these
is determined by 3 parameters, SEMMNS for the number of semaphores system
wide, SEMMNI the number of semaphore arrays in the system, and SEMMSL
the number of semaphores per array. Semaphores are allocated to a process
(or application) on an array by array basis so there may be spare semaphores
in a given array that are not available to other applications on the
system. Open M requires 1 semaphore per job including all system daemon
jobs. 2.2 The parameter SEMMNS is not available in the scoadmin menu
on SCO Server 5. For SCO Server 5 the kernel tuning file must be edited directly to modify this parameter, whose default value is still 60. The file is /etc/conf/cf.d/stune, and a line should be inserted that reads: SEMMNS 200 and then the kernel needs to be rebuilt, and the machine rebooted.
2.3 There is an <ERRTRAP> message during minstall and
the subsequent startup fails. This is usually caused by a lack of space, and occurs most often during
upgrades rather than first-time installs. Space needs to be allocated
within the manager's MUMPS.DAT by setting the maximum size higer with
the MSU utility. The space to grow also needs to be available at the
Unix level. Typically an upgrade to 5.10 requires 5-10 maps available
space, and an upgrade to 6.1 requires 10-15 maps free space depending
upon the original version. 2.4 The minstall or mstart scripts fail - how do I check the
key? There is a debug option that will test the key when mstart fails. This
command should NEVER be run when M is active - it will destroy the msql.ids
file and prevent further users getting into the application. The command: mux -cd will report any errors with resource allocation and an improper key,
although it will not necessarily indicate why the key is bad. An "incorrect
product" message means that the key and msqlm file product numbers
do not match, for example a SUNOS key will not run on Solaris. 2.5 On Solaris 2.4 the minstall script fails when it tries to
create the MUMPS.DAT file. This happens when the version of Open M was built on a different Solaris than 2.4 and is due to Solaris having hard-coded version strings in certain libraries. To correct this the executable nneds to be relinked with the mlink script. The mlink script itself will need editing to remove the references to switch.so and tcpip.so on the last line. The mlink script builds an output file msqlm which needs moving to msql.bin before the minstall script will work correctly. Versions 5.1 and the first cut of 5.10 were built prior to Solaris 2.4. We recommend that you contact InterSystems for the latest version 5.10
for Solaris 2.4 which does not require these modifications. 2.6 How do I install an adhoc? Adhocs are generally shipped from support and should include 3 files: msqlo.o, msql.bin and mst. When these three files have been saved in the manager's directory than the tape can be loaded. If the manager's directory is not /usr/msql or if there are user defined $zf functions then the mlink script needs to be run to regenerate a new msqlm. Then at the net convenient time the M environment needs to be shutdown
and the new executable copied to /usr/bin before M can be restarted.
Care needs to be exercised to ensure that the link between msqlm and
mux in /usr/bin is retained (or recreated if destroyed). 2.7 What limits the number of users that can get into M? There are four parts that directly influence the user count in M: a) the license b) the number of processes specified in the Open M configuration file (startup.def or msql.def) c) the number of routine buffers allocated (there will be 1 more routine buffer than allowable users) d) the number of semaphores allocated in the kernel (1 per user) This does not include any Unix limitation on the number of processes,
or number of processes for a given id - which are usually configurable
Unix kernel level limitations. 2.8 What is the maximum volume size? 16GB. A volume set can consist of up to 8 volumes. Each volume can
be upto 2GB in size irrespective of any larger partition limits in Unix.
For now the 16GB limit can be circumvented by having certain globals
in different volume sets and setting up translations or implicit references
to these other volume sets. The limitation will be raised in a later
version of Open M (around version 7.x) 2.9 M/NET daemons seem to count against the user license. In cases where more than 3 daemons are spawned for the network traffic
the extra ones can count against the license. In these cases InterSystems
will provide a larger license to offset the lost user count. 2.10 mstart no longer works after upgrading the OS. minstall puts files into the /usr/bin directory which need to be restored after such an upgrade. The files are available in the manager's directory. muxs can
be copied directly. If mlink was run then the msqlm file can be copied
directly, otherwise msql.bin needs to be copied to /usr/bin/msqlm. After
this msqlm needs to be linked to mux in the /usr/bin directory. The
minstall script also creates a script file msql and links this to msqlmenu.
If this script is not used it does not need to be recreated. If it is
required then the appropriate part of the minstall script needs to be
extracted and run in isolation.
Version 6.2 has a larger MCOMMON shared memory area - larger than 1/2MB
which is the default individual shared segment size (SHMMAX) on most
systems. The kernel needs to be tuned to enlarge this parameter before
M can be installed. 3 - Platform Specific Queries3.1 <STORE> errors occur much more frequently on OSF
or Digital Unix than other platforms. The user partition size does need to be at least 50% larger than other
Unix platforms for most applications, and may need to be up to 100%
larger. The partition size is part of the first screen in the SYSMGR
configuration utility or by the bbsiz parameter in the configuration
file startup.def. 3.2 mstart on SCO generates invalid argument messages. If the kernel configuration is correct and the version of SCO is 3.2.4
then there is an SHM allocation bug in SCO which may be the cause of
this error. There is a patch, reference QFS39 which is available on
the InterSystems ftp server which provides a new kernel driver object.
This requires a rebuild of the kernel and subsequent reboot of SCO to
fix. 3.3 Long printouts are being truncated on a LAT printer with
OSF version 3. OSF version 3 had LAT re-engineered, and an adhoc version of 5.10 is
required to correct the behaviour with the new LAT. Alternatively upgrading
to 6.1 will also correct the problem. 3.4 The mstart script on Solaris fails complaining about invalid
arguments. The mstart script supplied for Solaris assumes a System V Unix environment
rather than BSD. If the user had /usr/ucb ahead of /usr/bin in his path
then the BSD version of common utilities (such as ps) will be used.
This will cause the mstart checking to fail. /usr/ucb should not be
in the path at all, according to Solaris documentation, but where it
is required it needs to be at the end of the path. 3.5 Cannot open /dev/lp on AIX even if the permissions are correct?
There is a bug in AIX where the tty() system call incorrectly identifies the lp as a tty device and Open M subsequently tries to use tty style ioctl() calls to manipulate the port. This can be avoided by setting the line discipline to posix: # stty get < /dev/lp will return the current settings # stty disp posix < /dev/lp will set the discipline to posix (the '<' is intended) Another approach would be to pipe the output to lp. 3.6 Line drawing on the console of SCO Server 5 is done with
alphanumeric characters. SCO Server 5 has the concept of mapped channels for the console devices
(tty00 through tty12). The default mapping is set to 'ibm' whereas OpenM
normally uses 'ansi'. The file /etc/default/mapchan needs to be modified
and the "ibm" changed to "ansi" to allow the line
drawing to function normally. The system needs to be rebooted for this
modification to take effect 4 - Open M Version Specific4.1 What does the version string denote? Up to version 6.1 the Version string typically consists of 3 sections not including the text on either side of the actual version number. The normal format would be M.N-P.Q (rel-nn) where
P.Q is the major and minor release of the DBMS engine, eg E.3 or F.7 rel-nn is the build identifier for the M engine With 6.2 and later releases the only place that the SQL version and
system code version are seen together is in the %SS display. The commands
w $zversion will both only report the system code version - the M.N (rel-nn) portion
as described above. This is to prevent confusion when more than one
combination of system code and SQL version are available. The $zv string
is built into the system code and therefore assigning an SQL version
is not appropriate. 4.2 Version 5.10 (and later) can startup but not let users in.
Version 5.10 was enhanced to not allow users to access M during the
startup sequence. Now, if an error occurs in STU or in ZSTU (or if the
ZSTU halts instead of quitting) the very last part of STU that enable
user access will not be run. There is a bypass flag that will work provided
the startup has reached a certain point. The command: mux -B will allow a process to get into M when the system is locked in a "installation
or startup in progress" state. The error in STU or ZSTU should
be identified and fixed and M restarted after running the ^SHUTDOWN
routine. Alternatively the STU post-processing can be run by the process
that has bypassed the user lockout by running EXIT^STU. This is not
recommended as there may be after effects of the STU/ZSTU not having
completed normally. 4.3 The online Backup utility never stops when a second volume
is used. This is a bug in 6.1 and 6.2-rel-01. Contact Technical support and
ask for the multi-volume backup adhoc. Be sure to have your platform
information ready. 5 - Utilities5.1 There is an <UNDEFINED> error in the SPOOL utility
when I try to print a file without starting at the first page. Modify the routine %SPLPRIN at line BB+4 Midway through the line there is a test for PG being equal to variable %B, this needs to be changed to the variable R: Change .... I PG=%B .... This is fixed in version 6.1 and later. 5.2 Selecting a print from the SPOOL menu prints the wrong file
when a sub list is generated. Modify the routine %SPLFND at line Find+12 At the end of the line an assignment is made using the variable R instead of the line array indexed by R: Change .... S ..=R Q 5.3 Why does %SS hang? %SS works by sending a signal to each job in an internal M process
table. For each process we retry several times before giving up. Normally
processes respond to the first signal. However ghost processes cannot
respond, and other processes that are currently uninterruptible will
not respond so the pause that you see in %SS is the retry loop being
exhausted. 5.4 What is a ghost process? A ghost process is an M process that has exited the system abnormally.
An abnormal exit would occur if the M process core dumped, or received
some signal causing its death (such as kill -9). A normal process exit
cleans up itself and closes all its devices, locks and releases any
resources it may hold before finally exiting. A process that dies abnormally
has not gone through this cleanup processing and while it no longer
exists at the Unix level, it still retains ownership of all its resources
in M. This can cause M hangs if the resource is critical to other jobs
in the application. The correct thing to do in this case is to correct
the cause of the ghost rather than attempt to free unowned held resources.
5.5 How is $ZA useful? $ZA holds status information for terminal and tape devices. 5.6 The INTEGRIT utility reports map block code errors - "Block
ddd which is pointed to by block ppp has code 255 in the map block mmm
whereas code 1 was expected."? Up to and including version 5.1, InterSystems differentiated between blocks in use by users and in use by the system itself. The code 255 meant that the block in question was in use by the system. After version 5.1 this scheme was revised and code 255 became obsolete, and the block is now simply in use (by anyone). Therefore this specific error can be ignored. To fix the error, the Map allocation table in map block mmm needs to be changed from FF to 1. Otherwise the INTEGRIT could be modified to allow the code 255 to be ignored. This is done in routine CHECK0 at line CM(X): change ... I $V(B,0)'=X D ER5^CHECKERR 5.7 %RO output cannot be read by DSMs %RR utility. The %RR utility requires a minor change to extract the name of the routine correctly from Open M %RO files. It is probably better to copy %RR to %RRISM and make the modification in the copy at line %SAV: change K %NOSAVE ... 5.8 How do I determine what my active configuration is? There are two ways (from the M prompt): a) >w $zu(86) b) >w ^SYS("runconfig",1) And from the Unix prompt, the config name is kept in the 'config' parameter
in the configuration file startup.def: c) $ grep config startup.def If the startup.def file does not exist then M starts up from the msql.def
file. 5.9 How do I determine what the default start-up configuration
is? From Unix, which ever config is named in the startup.def file in the M manager's directory. From M: a) >w ^SYS("startconfig",1) 5.10 How do I delete the default M/NET configuration to be brought
up at mstart, so that no network configuration is started? For version 5.10: >d ^SYSMGR For version 6.x: >d ^SYSMGR 5.11 How do I determine the version of the Visual M server in
ISM? Enter the line: >d ^%mvb The result will be something like: Visual M Server Program. Version 6.4.002 Please refer to the documentation on how to start the Visual M Server. 5.12 How do I select globals with long names in INTEGRIT? Long Global (and routine) names were introduced in version 6.1. The INTEGRIT utility allows the selection of individual globals but was never updated to account for the long names. In the main routine itself, there is a $Extract of the global name from the user input. This $E currently extracts the first 8 characters and needs to be changed to extract the first 31 characters. This bug will be fixed in a later release (after 6.2-F.9). To make the change, edit ^INTEGRIT and modify line GL+1: S GLO=$E(GLO(1,8) to become S GLO=$E(GLO,1,31) 5.13 Why is $H different in foreground and background processes? Although not a normal occurrence, this is certainly common around DST changes on a system. All foreground processes take the $H from the Unix shell environment when M is invoked. Background processes, however, are forked from the MCP process and not from the process that issued the JOB command. The MCP process is the first process started by mstart. If the timezone has changed since M was started, for example in the transition to or from DST, then any background jobs that are generated will keep the version of time from MCP and will appear different to foreground jobs. There is no way to update the MCP with a new time, except by shutting down and restarting M.
Home | M Technologies | Support | Company | Contact ©
Copyright 1996-2000 InterSystems Corporation. All Rights Reserved. |
|
|