Category: Getting Started

directories nn

where nn is the number of Zim directories that can be accessed at any one time.

Valid Settings

nn = numeric entry 3 to 200

work path path

where path is the disk directory path to the temporary work files for a session. The work path is valid for all users accessing the database and is formed by adding the work path with the user number that is entering the database at that time. For example:

work path /usr/users

Users will get work paths like:

/usr/users/00001
/usr/users/00002

The default work path is the database itself.

Valid Settings

Any directory path.

Related Topics

user name directory

runtime buffers nn

where nn is the number of in-memory data buffers used when writing or reading compiled programs to or from the disk. Each buffer holds 1 KB. Increasing the number of buffers improves system performance, but increases the amount of internal memory needed. Specify any whole number within the permitted range, provided that the computer has enough memory.

The general effect of this option is that, when running compiled applications, the bigger this value, more compiled programs can stay in memory at the same time thus increasing performance of the application.

Valid Settings

nn = numeric entry 100 to 10000

parameter size nn

where nn specifies the maximum size of any single IN-type parameter or local variable used in an application program’s procedures.

IN parameters and local variables are stored internally as VARCHAR variables with a maximum size of nn. If the size of any IN parameters or local variables is larger than the default value of nn, increase nn. Conversely, if all parameters are significantly smaller than the default size, reduce nn to save memory.

Valid Settings

nn = numeric entry 0 to 32000

user name directory yes/no

It specifies that the working directory for the user starting a Zim session must be named after the user number or the user name.

For example, with :

user name directory yes

work path /usr/users

Users will get work paths like:

/usr/users/Chris

/usr/users/Deborah

instead of

/usr/users/00001

/usr/users/00002

The default setting is no.

Notice that the user names must be known by Zim in the Users entity set.

Related Topics

work path

backscreen prompt yes | no

Specifies whether the ZXClient prompt will be available when upon its start-up, that is, the user will not be able to interact with the prompt. The end result is that the user must follow the instructions provided by the Zim application.

Valid Settings

yes indicates prompt is available whereas no indicates the prompt will not be available for the user. The default value is always yes.

sort buffers nn

where nn is the maximum amount of memory (KB) that can be used when sorting data. If the requested amount of memory is not available, all available memory up to the limit specified by nn is used.

During a sorting process, fields of data to be sorted are extracted and put into sort records that are placed into sort buffers. Then, either the entire sort is performed in available memory or, if not enough memory is available, sort records spill into temporary disk files (the zimstxxx files).

A sort that occurs entirely in memory is quickest. If a sort process must use disk space, the records placed in temporary disk files must be merged back into the sorted order, resulting in reduced performance.

A high value for sort buffers has two effects:

• The sorting is able to take place completely in memory.

• The merging process is faster, as fewer passes are required to merge the data in temporary disk files.

Sort buffers space is acquired only during a sorting process and is returned once the sort is completed.

Set operations (UNION, INTERSECT, and MINUS) and the KEEP subcommand generate sort operations internally. Their speed is therefore also affected by the amount of sort buffer space.

Valid Settings

nn = numeric entry 100 to 10000

century threshold n
default century n

where n is a numeric entry (see below for more information)

These two configuration options control the century used when date-masked fields contain ‘ YY’ instead of ‘ YYYY’.

If a field is masked only with ‘ YY’ and not ‘ YYYY’, then the end-user cannot enter the century, and Zim assumes the century is 19. Application developers are strongly urged to either i) use ‘ YYYY’ to mask date fields, or ii) use the two configuration options to automatically increment the century for certain date ranges.

Note:The former approach always works, while the latter works for applications with well-defined input data that falls into certain date ranges.

The default century is a number from 0 to 99 that is copied to the century position of a date when the end-user can enter only two year digits. If the century threshold is -1, then this default century is used verbatim. If century threshold is on the range 0 to 99, then the default century is incremented if the year entered by the end-user is less than n. The table below gives examples of resulting dates given user input and the input mask of ‘MM/DD/ YY’:

In general, if your application must deal with widely-ranging dates, then use an input mask of ‘ YYYY’ to obtain expected results. However, if your application deals with dates of events occurring in the present, such as tagging orders with the order date, then an input mask of ‘ YY’ is sufficient, and set century threshold to a value, such as 50.

Valid Settings – Default Century

nn = numeric entry 0 to 99

Valid Settings – Century Threshold

nn = numeric entry -1 to 99

A number of conventions are used throughout this guide to indicate how to enter commands. These include:

Key Combinations

When you are to press two keys at the same time, they are written as Key1+Key2. This means that you should hold Key1 down and then press Key2.

Command Syntax

When the general syntax of a Zim:X command is illustrated, the command syntax uses these rules:

Note: Zim:X makes no distinction between uppercase and lowercase letters in identifying command names. However, in operating systems such as LINUX, the case of operating system utilities is important. All operating system utility names should be entered in lower case.

Entering Commands and Instructions

The following table describes the methods by which commands and instructions can be entered:

Despite thorough testing, an application can experience operational problems. These problems can result from faulty coding or they can be environmental in origin (e.g., stemming from the interaction of the application and the operating system). In either case, the approach to troubleshooting an application uses the same three-step process:

1. Reproducing the Situation

A fundamental rule of problem-solving in any software system is that if you are unable to reproduce the problem, you are unable to solve it.

Some problems can be difficult to reproduce, but the following guidelines make reproduction simpler.

If a problem arises while you are running an application, make note of what was being done with the application at the time.

When you are ready to attempt to reproduce a problem, make the following preparations:

Back up all files.

Reproduce the external environment as closely as possible. If other processes were running, make sure they run during your test.

Try to carry out the same steps that you were performing when the error occurred. Remember to back up your files before each attempt to reproduce the error. Some problems are data dependent, and using the correct initial data can be crucial to successfully reproducing the error.

If you cannot cause the error to occur, the problem could also depend on commands executed earlier in the session. Try again, making sure to run through exactly the same steps that you did when the error first occurred.

During this phase, it is very important to make careful notes of all your actions; you want to be able to repeat, again and again, the exact situation that caused the problem. You should not be concerned at this point with eliminating unnecessary steps; you can deal with that question when you try to isolate the cause of the problem.

2. Isolating the Cause

Once a problem is reproducible, you can attempt to isolate its cause. Isolation involves eliminating potential causes until you have pinpointed exactly what causes the error to occur.

The following strategies can be used to determine the cause of an environmental problem:

Run the application on another computer system. This process helps to determine if hardware problems are involved.

Remove external processes from your system. If the problem does not recur, it could have been a result of system stresses created by these external processes, or the external processes could be interfering with your application.

Reduce memory requirements by changing various options in the configuration files (e.g., sort buffers,  maximum forms, etc.).

If possible, try changing your operating system configuration (e.g., system limits on resources, such as the number of files, number of locks, and so on) before running your application.

Try these strategies one at a time. If your problem disappears, you may have discovered its cause.

The object of the isolation process is to pinpoint the problem. For example, do not worry if reducing memory usage affects performance. If memory usage is causing the problem, at least you can trade some performance for correct operation.

3. Solving the Problem

Once you have isolated the problem, proceed with solving it.

If you have a hardware problem, components of your computer system can be repaired or replaced. Problems stemming from the operation of external processes can be prevented by ensuring that the external processes do not run simultaneously with the application. If the problem stems from memory usage, changes to the configuration files or memory allocation could be required.