Consultor Eletrônico



Kbase 12677: Release Notes for Sun 4 (Galaxy) 6.3B
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   10/05/1998
Release Notes for Sun 4 (Galaxy) 6.3B

ADDITIONAL NOTES FOR THIS RELEASE

PLATFORM: SUN45
MEDIA TYPE: Cartridge Tape
SOFTWARE RELEASE: 6.3B01
EXTRACT COMMAND: cpio -iuvcdBm < /dev/rmt/0
INSTALL COMMAND: ./proinstall

MACHINE NOTES:

Direct I/O errors will occur when using the -directio
startup option on the Sun45 and may cause a system crash.
The -directio option is not supported.

OPERATING SYSTEM NOTES:

UNIX Shared Memory

PROGRESS uses shared memory to allow multiple server processes
and self-service client processes concurrent access to
a database and to coordinate their activities. The shared
memory area contains the buffer pool, lock table, log buffers,
and other shared data structures.

When the database is started (via the proserve command),
the broker creates and initializes the shared memory area
of the required size. The size is based on the values of
various startup parameters which determine the sizes of
the data structures.

In UNIX systems, shared memory consists of one or more
"segments." Each segment is identified by a system-wide
unique number which is assigned by the process that creates
the segment. PROGRESS derives the identifier from the inode
of the .db file.

There are several UNIX kernel parameters that limit the
number and size of shared memory segments. In addition,
PROGRESS has an internal limit on the size of a single
shared memory segment. If the shared memory size computed
by the broker is larger than the maximum segment size allowed,
the broker will create multiple segments to reach the required
total.

The following UNIX kernel parameters control the size
and number of shared memory segments:

SHMMNI - The maximum number of shared memory identifiers
allowed for the system.

SHMALL - The maximum number of in-use shared memory segments
allowed for the system. Some systems do not have this parameter
(e.g., Sun OS).

SHMMAX - The maximum size of a single shared memory segment.
Some systems call this parameter SHMSIZE (e.g., Sun OS).

SHMSEG - The maximum number of shared memory segments
a single process can attach. Some systems do not have this
parameter (e.g., Sun OS).

The total amount of shared memory that can be allocated
is SHMMAX * SHMALL (or SHMMAX * SHMMNI).

When you install PROGRESS, you may have to increase the
values of these parameters. Note that if you are running
other software that also uses shared memory, you must take
into account the combined requirements.

Consult the manuals for your system to find out how to
change these parameters.

Recommended settings:

SHMMNI: Depends on the number of active databases, the
values of startup parameters, and the value of SHMMAX.
The larger SHMMAX is, the fewer segments PROGRESS will
create. 64 is probably a good value to start with.

If you set this value too low, you may get PROGRESS error
1137 or 1138.

SHMALL: Same as SHMMNI.

If you set this value too low, you may get PROGRESS error
1137 or 1138.

SHMSEG: Depends on the number of active databases, the
values of startup parameters, and the value of SHMMAX.
The larger SHMMAX is, the fewer segments PROGRESS will
create. When self-service clients connect to multiple
databases, the shared memory segments for the database
are attached. 16 is probably a good value to start with.

If you set this value too low, you may get PROGRESS error
1175, 1719, or 1720.

SHMMAX: Sequent: 134217728 bytes Others: 16777216 bytes

This parameter limits the size of a single segment. PROGRESS
will create one smaller segment if less shared memory
is needed.

Smaller values will work, as long as they are higher
than 8192, but are not recommended. If you set this to
less than 8192, you will get PROGRESS error 1135.

If you set this value too low, PROGRESS will create many
small segments, possibly overflowing the limits SHMMNI,
SHMSEG, or SHMALL.

The units that you use to specify a value for SHMMAX
vary from system to system. Some units use bytes, others
use "clicks" (page size). Consult your system manuals
for the proper units.

Note that the amount of kernel memory required for shared
memory descriptions (not the shared memory itself), is
relatively small, so setting SHMSEG, SHMMNI, SHMALL higher
than your current needs probably won't affect performance.

Shared memory is not used for single-user sessions.

Clients that connect to a remote database on a server
machine do not use shared memory on the client machine.

You can use the "Activity" option in promon to find out
the total amount of shared memory allocated and the number
of segments that were created for the database.

The table below gives some typical shared memory sizes
(in bytes) for a few different parameter settings on machines
with 1 and 2 kb database blocks:

UNIX Semaphores

PROGRESS uses UNIX Semaphores to synchronize the activities
of server processes and self-service client processes that
are connected to a database. The semaphores are created
and initialized by the broker when the database is started.

Sun 4 (has 1 kb database block size)

proserve demo 204800 (200 kb)
proserve demo -n 10 -B 100 217088 (212 kb)
proserve demo -n 20 -B 100 258048 (252 kb)
proserve demo -n 10 -B 500 663552 (648 kb)
proserve demo -n 20 -B 500 704512 (688 kb)
proserve demo -n 20 -B 5000 5734400 (5600 kb)

Sequent (has 2 kb database block size)

proserve demo 569344 (556 kb)
proserve demo -n 10 -B 100 360448 (352 kb)
proserve demo -n 20 -B 100 421888 (412 kb)
proserve demo -n 10 -B 500 1220608 (1192 kb)
proserve demo -n 20 -B 500 1282048 (1252 kb)
proserve demo -n 20 -B 5000 10973184 (10716 kb)

UNIX semaphores are grouped into "semaphore sets." Each
semaphore set has a unique identifying number called a
semid. Within a semaphore set, individual semaphores are
identified by an integer ranging from 0 to one less than
the size of the semaphore set.

The PROGRESS broker creates a semaphore set when the database
is started. The size of the set is the number of users
(-n parameter) plus the number of servers (-Mn parameter)
plus 4.

The following UNIX kernel parameters control the number
and size of the semaphore sets:

SENMNI - The maximum number of semaphore identifiers allowed
for the system.

SEMMSL - The maximum number of semaphores allowed per
semaphore identifier (semaphore set).

SEMMNS - Total number of semaphores allowed for the system.

SEMMNU - Maximum number of semaphore undo structures allowed
for the system.

When you install PROGRESS, you may have to increase the
values of these parameters. Note that if you are running
other software that also uses semaphores, you must take
into account the combined requirements.

Consult the manuals for your system to find out how to
change these parameters.

Recommended settings:

SEMMNI: One per active database.

If you set this value too low, you may get PROGRESS error
1131.

SEMMSL: Max number of users on any database + Max number
of servers for any database + 4

If you set this value too low, you may get PROGRESS error
1093 or 1130.

SEMMNS: SEMMSL * number of active databases.

If you set this value too low, you may get PROGRESS error
1093, 1131, or 1195.

SEMMNU: Set equal to one per PROGRESS process connecting
to a database. (ie: each server process, self-service
client, page writer, bi writer, ai writer, watchdog, proshut,
promon).

If you set this value too low, you may get PROGRESS error
1081.

Note that the amount of kernel memory required for semaphores
is relatively small, so setting the limits higher than
your current needs probably won't affect performance.

Semaphores are not used for single user sessions.

Clients that connect to a remote database on a server
machine do not use semaphores on the client machine.

TERMINAL NOTES:

SOFTWARE NOTES:

* HIGH SETTING FOR KERNAL PARAMETERS

If kernal parameters are raised too high and PROGRESS
startup parameters -B and -L are large, resource problems
may occur. If a first client is running and a second client
is started, and the second client dumps core you will
need to reduce the kernal parameters and/or reduce the
-B and -L parameters.

* BEFORE-IMAGE BUFFERS

The -bibufs n startup option on the broker startup controls
the number of before-image buffers allocated in shared
memory. The Version 6.3 Documentation Bulletin states
incorrectly that 5 is the highest reasonable value. The
correct starting value for this option is 20 when running
the before-image writer. The value of -bibufs should be
set to 20 or greater when ever the before-image writer
is running.

* TWO-PHASE COMMIT AND AFTER-IMAGING

The following sections describe issues involving two-phase
commit and after-imaging.

After-Image file on a Non-Coordinator Database

If a non-coordinator database has limbo transactions
and you delete or lose the after-image file, you cannot
disable after-imaging until you have deactivated two-phase
commit. To deactivate two-phase commit, use the 2phase
end option of the proutil command. Once you disable two-phase
commit,you can disable after-imaging. They can use the
2phase recover option of the proutil command to recover
any limbo transactions. When finished, you can truncate
the before-image file and backup the database.

After-Image and Transaction Log Files on the Coordinator
Database

If you have two-phase commit and after-imaging enabled,
and if you lose the coordinator database's after-image
file, you cannot recover any limbo transactions. Also,
if after-imaging is not enabled, and you lose the database's
Transaction Log (.tl) file, you cannot recover any limbo
transactions.

Backing up a Two-Phase Commit Database

The PROGRESS Backup utility (PROBKUP) does not backup
the .tl file. When you backup your database, you should
deactivate two-phase commit first, then backup the database
with PROBKUP. Before you re-enable two-phase commit, use
the 2phase new option of the proutil command to truncate
the .tl file.

* X-WINDOWS

The startup parameters -bg -fg -bw have no effect on
the colors or size of a window.

A link for PROGRESS must be created in order to use X-Windows.
For _prox to load the following link must be created:

ln -s /usr/openwin/lib/libx11.so.4 /usr/lib/libx11.so.4

* SERVER/SELF-SERVICE CLIENT VERSION INCOMPATIBILITY

You cannot start a Version 6.2K (or previous) self-service
client against a Version 6.2L or 6.3 server. Likewise,
you cannot start a Version 6.2L or 6.3 self-service client
against a Version 6.2K (or previous) server. In both cases,
the server and self-service client have incompatible version
numbers. If you attempt to start a self-service client
against a server with an incompatible version number,
you should get a message indicating that they are incompatible.
However, if you are running PROGRESS on the following
machines:

D Sequent (Dynix and PTX)

D RS6000

D Data General (V.4)

D Pyramid

you get a misleading message; this message incorrectly
states that no server is running for the database you
are trying to start the self-service client against. The
reason for this message appearing is that the shared memory
IDs of the self-service client and server do not match.
Ordinarily, the self- service client accesses shared memory
and checks the version number of the server for compatibility.
On these machines, the self-service client cannot access
shared memory to check the version number. Therefore, when
you see a message that indicates there is no server running
for the database, do not assume that the database is shutdown.
Check to make sure that no server is running before performing
such actions as moving the database or deleting any database
files.

* ON TAB STATEMENT

Specifying an "ON TAB GO" statement in a procedure may
cause PROGRESS to exit abnormally and give a core dump.

* NETWORKING

If you have multiple clients connected to two or more
servers via TCP/IP, and the system runs out of network
resources, error message 1160 may appear repeatedly in
the .lg file. This may fill the disk containing the .lg
file.

* PROLIB

If you add or delete to PROLIB, the library will continue
to grow. In order to reduce the size of the library, you
must do a COMPRESS when you add to or delete from the
library. To effectively use PROLIB, changes to the library
should be made when development is complete. At this time,
all changes can be made to the library at once, allowing
better management of the library size.

* PROSHUT MESSAGE

If you start a database server with 1 userid and try
to shut it down with a different userid, you (correctly)
get an error message in the .lg file that the shutdown
request was invalid. However, you also get an erroneous
error message: SRV 1: Usernum 1 terminated abnormally
(794).

* DUMP/EXPORT

When trying to DUMP or EXPORT large character fields
greater than 3000 characters you will see the message:
More than 3000 characters of dump data (96) and the session
will be terminated.

* PROMON

Once a server is started, if you enter "PROMON dbname",
then "PROSHUT -by dbname", PROMON will not be disconnected
and the process will still exist.

* MV PARAMETER

To work correctly, the _dbutil utility needs the -Mv
50 startup parameter.

* MULTIPLE CTRL-C

Multiple ctrl-c while running a .p will unset the character
set. To avoid this problem use ctrl-x.

* AUTO CONNECT

The AUTO CONNECT option does not work with an ORACLE
gateway. You will see the error "broker could not spawn
a server".

* AI MOUNTING

PROGRESS will not detect if the .ai file is on an NFS
mounted file system. Therefore, test if the .ai file is
NFS mounted and if so warn the user that after-imaging
integrity cannot be guaranteed.

* IDXBUILD UTILITY

Running IDXBUILD against an empty database will complete
phase 1 and deactivate all of the index blocks. However,
it does not continue to phase 2. You will see a message
"Msg: login.p --could not find file _User in database
emp29". (1494).

* PROMON AND 2PC

PROMON neglects to indicate if 2-phase commit is enabled
or if the database can be a coordinator.

* PROUTIL MESSAGES

When using _proutil on a database that requires truncation,
redundant information is printed. For instance, you may
see the message "This session is being run with the -i
(no-integrity) option. (512)" multiple times.

* NEW KEYWORDS

The following keywords are now available:

FIELDS, GET-PROC-PARAM, PROC-HANDLE, PROC-STATUS,
RUN-STORED-PROC

* COLOR FOR SCROLLING

COLOR settings for SCROLLING under TERMINAL settings
does not function properly. If you set COLOR, then return
to select QUERY from the main menu, a down arrow will
not refresh the previous line. The color will continue
to fill the screen as you press the down arrow.

* PROBUILD

When running a load script created with PROBUILD using
TLI or TCP/IP the warning "ld: warning: File /usr/lib/libnsl.so
attempted multiple inclusion of file libnsl.so" will occur.

* FASTTRACK

FASTTRACK QBF forms will be deleted if you change the
form name without expressly saving the change. You must
use the COMMAND SAVE on the form before exiting the Screen
Painter if you change the name of the QBF form.

* RESULTS IN EXPERT MODE

Expert mode (F5) does not function properly using PROMPT-FOR
(F6). To attempt using it will cause any data entered
to be deleted.

Expert mode is not available in a WHERE clause while
using the QUERY option.

* TLI

TLI54 is not supported in this version of PROGRESS. TLE
under System 5.3 is supported.

ADDITIONAL ITEMS

* The PROGRESS Watchdog

Version 6.3 and later includes a new background process
intended for use in multi-user, shared-memory installations.
This background process is called the Watchdog. The Watchdog
wakes up every five seconds and examines the user table
in shared memory to determine if processes are still connected.
If Watchdog finds a dead process, it will attempt to roll
back any active transactions abandoned by the dead process
and will release record or resource locks held. Appropriate
messages will be recorded in the database log file (.lg
file) when a dead process is discovered.

To start Watchdog, enter: prowdog <database name>

Watchdog will then record a message in the log file indicating
that it has been started, and will continue to run until
the database is shut down or disconnected with proshut.

ADDITIONAL NOTES FOR SYBASE RELEASE

* SYBASE REMOTE GATEWAY AUTO-CONNECT

If you attempt to connect through the data dictionary
to a remote Sybase database with a remote gateway configuration
the session fails with the following messages:

FAILED TO CONNECT TO DATABASE DEMO (2078) FAILED TO
CONNECT TO SYBASE/SQL-SERVER DATABASE (2081)

The session would fail if the Sybase connection information
was defined under SYBASE UTILITIES, EDIT SYBASE CONNECTION
INFORMATION similar to the information below:

LOGICAL DB: SYBASE DB TYPE : SYBASE
CONNECTION PARAMETERS: -H hostname -S service name
-N network type -U user id -P password PHYSICAL
DATABASE NAME: DEMO

The workaround would be to CONNECT through the data
dictionary and change the PHYSICAL DATABASE NAME to
DEMO. The remaining defaults in the auto-connect file
defined under SYBASE UTILITIES are accepted and the
session connects successfully.

* DATE FIELD COMPARISON

Date field comparisons do not function properly. For
example, 02-14-93 will appear to be bigger than 02-15-90
because 15 is greater than 14. As a workaround, use the
yyyymmdd date format for comparision instead of mmddyyyy.

* REMOTE SYSBASE VMS TO UNIX CLIENTS

If you access the SYBASE server (schema holder) on VMS,
then connect to the SYBASE demo database and run "FOR
EACH customer: DISPLAY customer." you will get the following
message: Value -9620703583058598130156833.59 cannot be
displayed using ->,>>>,>>9.99, as well as a core file.

* SYBASE GATEWAYS USING A PRIMARY INDEX

Progress Software Technical Support Note # 12677