Release Notes for VAX and Alpha VMS 7.3C08 - readme.pro
RELEASE NOTES
-------------
PLATFORM: Progress for OpenVMS VAX and OpenVMS Alpha
SOFTWARE RELEASE: 7.3C08
INSTALL COMMAND: See Below
These release notes describe problems specific to the OpenVMS
implementation of Progress. Please reference your Progress 7.3C
release notes to reference general Progress issues.
1. GENERAL ISSUES
-----------------
1.1 Product Versions Supported
------------------------------
This release supports the following versions of the OpenVMS operating
system:
VAX: VAX/VMS V5.5-2, VAX/VMS V6.0 OpenVMS V6.1, V6.2
Alpha: OpenVMS V6.1, V6.2
This release has been qualified on the following networking variants:
UCX V3.3 (TCP/IP Services for OpenVMS) TCPware V5.0-3B (Process
Software TCP/IP Services for OpenVMS) DECnet Phase IV Pathworks
Client V5.0C Pathworks Server V5.1
This release has been qualified on the following CDD versions:
CDD V5.3, V6.1
1.2 Addition of CD to Media List
--------------------------------
This version of PROGRESS is available on CD-ROM as well as 4mm DAT
and TK-50 tape. Progress Software encourages use of the CD-ROM
distribution since it will significantly reduce your installation
time.
1.3 Phase Out of TK-50 Media for OpenVMS Alpha
----------------------------------------------
For OpenVMS Alpha, this is the last release of PROGRESS that will be
distributed on TK-50 tape. If you install PROGRESS from TK-50 on
OpenVMS Alpha, you should consider switching to CD-ROM or 4mm DAT.
TK-50 tape distribution will continue to be available for OpenVMS
VAX.
1.4 Installation from SYSTEM Account
------------------------------------
PROGRESS must be installed from a fully privileged account. The
SYSTEM account is recommended but an equally privileged account may
be used if necessary.
1.5 Use of DEC C Sharable Library
---------------------------------
If you are running VMS/VAX V5.5-2 or V6.0, you will have to install
the DEC C Run Time Library included on your PROGRESS distribution
media before you install PROGRESS. This kit is provided to Progress
Software Corporation by Digital Equipment Corporation and is
supported by Digital. Installation of this kit is completed via the
VMSINSTAL procedure. To install, load your installation media and
type the following command from a privileged account:
@SYS$UPDATE:VMSINSTAL AACRT060 ddcu:
where ´ddcu:´ is the tape installation media (TK, MU, MK, etc.).
If you are installing from CD-ROM, type the following from a
privileged account:
@SYS$UPDATE:VMSINSTAL AACRT060 ddcu:[DECC_RTL_VAX]
where ´ddcu:´ is the CD-ROM installation media device (DU, DK, etc.).
The installation utility will ask you some questions; accept the
default answers and let the installation proceed.
Once the DEC C Run Time Library installation is complete, you may
proceed with your PROGRESS installation. If you are running any
other version of the operating system, the required DEC C libraries
are already included on your system and installation of this special
kit is not necessary.
1.6 Transfering Encrypted Sources to OpenVMS
--------------------------------------------
Due to the different OpenVMS file formats, encrypted source files
transfered to OpenVMS must be transfered in variable length format.
This can be done with the bundle/unbundle utilities provided in the
Toolkit installation option. Failure to transfer these files
correctly will result in syntax errors during compilation.
1.7 Double Byte Enable Support Issue
------------------------------------
If you are attempting to use the Double Byte Enable Progress images
on your VMS system, the following will describe the differences
required for VMS. You may use the DLC:PROGRESS_SETUP.COM file as it
will set your logicals for the necessary images. In addition, in
order to use the Progress Utilities via the PROGRESS/UTILITIES=
command, you will need to perform the following steps:
1. Edit the DLC:PROGRESS.CLD file and search for the string:
BIN:_PROUTIL
2. Change it to:
BIN:_PROUTLA
This will allow VMS to invoke the correct image.
If you choose not to use the DLC:PROGRESS_SETUP.COM procedure, then
you will need to define the logicals as follows:
$ DEFINE PROEXE BIN:_PROGRESA.EXE $ DEFINE PROSRV BIN:_MPROSRVA.EXE
1.8 Use of C Compiler for ESQL/C [V7.3C08]
------------------------------------------
Progress Software has been made aware of a number of issues when
compiling C source code to be included in an ESQL client image.
Progress Software uses Digital´s DEC C V5.0 compiler to compile
Progress source code into the objects which are provided in the
Progress directories on your system. Progress uses and recommends
the use of the following syntax when compiling:
CC /STANDARD=VAXC
If you are using an earlier version of the DEC C compiler, Progress
strongly recommends that you upgrade your DEC C compiler to at least
V5.0. If you do not upgrade you may receive link time warnings about
symbols that do not exist. These symbols may be defined in the later
compiler version, but not in the earlier versions.
If you are using the Digital´s VAX C compiler, Progress strongly
recommends you investigate upgrading to at least the DEC C V5.0
compiler. Using the VAX C compiler you will receive link time
warnings about symbols that do not exist. In order to rectify the
symbols from VAX C, you must add the following line to the load
script (by default LDHLIC.COM) created for you when you used the
PROBUILD.COM procedure:
SYS$SHARE:VAXCRTL/SHARE
This line should be added directly above the "stack=20" line. This
will resolve any symbols used by the VAX C compiler.
2. NEW FEATURES
---------------
2.1 You can Install PROGRESS With the VMSINSTAL Procedure
---------------------------------------------------------
The installation of PROGRESS on your OpenVMS system has been enhanced
to allow the use of the SYS$UPDATE:VMSINSTAL.COM procedure.
To install PROGRESS with VMSINSTAL, load your distribution media and
type the following from a privileged account:
@SYS$UPDATE:VMSINSTAL PROGRESSC073 ddcu:
where ´ddcu:´ is the tape distribution media (TK, MU, MK, etc.).
If you are installing PROGRESS from CD-ROM, type one of the following
commands from a privileged account.
For OpenVMS Alpha:
@SYS$UPDATE:VMSINSTAL PROGRESSC073 ddcu:[ALPHA]
For OpenVMS VAX:
@SYS$UPDATE:VMSINSTAL PROGRESSC073 ddcu:[VAX]
where ´ddcu:´ is the CD-ROM distribution media device (DU, DK, etc.).
The installation will ask for the Progress serial number(s) and
control number(s) provided with your Progress kit. Make note of
these numbers before you start the installation.
You can also use the PROGRESS Installation Utility. Please see the
PROGRESS Installation Notes for details.
2.2 PROGRESS Setup File Provided
--------------------------------
The command procedure PROGRESS_SETUP.COM is now provided with
PROGRESS for OpenVMS to allow easy setup of the logicals needed to
run PROGRESS. This command procedure is placed in the destination
directory where PROGRESS is installed (your DLC directory). Please
see this setup file for more information about using
PROGRESS_SETUP.COM.
This file will be used by the multi-user database servers and
DataServers in order to locate the currently installed version of
Progress.
2.3 New Qualifiers
------------------
The following new qualifiers have been added to mimic the UNIX
argument lists.
For Progress in general: (PROGRESS)
/COPY/BEFORE_IMAGE which is equivalent to the UNIX syntax
"procopy... -g bi-file"
NOTE: The Progress 7.3C documentation states to use
"/BI-FILE=bi-file" which is incorrect.
For ESQL/C:
/ESQL_LOG - now is allowed as documented
/ESQL_NO_PAD - now is allowed as documented
For the PROUTIL utility: (PROGRESS/UTIL=<utility>)
/UTIL=CODEPAGE_COMPILER which is equivalent to the UNIX switch
"-C codepage-compiler"
/UTIL=CONV76 which is equivalent to the UNIX switch "-C conv76"
/UTIL=DBIPCS which is equivalent to the UNIX switch "-C dbipcs"
/UTIL=TABANALYS which is equivalent to the UNIX switch "-C tabanalys"
/UTIL=WBREAK_COMPILER which is equivalent to the UNIX switch
"-C wbreak-compiler"
/UTIL=WORD_RULES which is equivalent to the UNIX switch
"-C word-rules"
For the RFUTIL utility: (PROGRESS/UTIL=<utility>)
/UTIL=AIMAGE_TRUNCATE which is equivalent to the UNIX switch
"-C aimage truncate"
(7.3C08)
/UTIL=AIMAGE_EXTENT_EMPTY db-name [extent-number|extent-path]
Prior to 7.3C08, Progress would not accept the extent-number or
extent- path parameter as input from the command line.
2.4 Use of UNIX command line format for Progress on VMS systems
[7.3C08].
-------------------------------------------------------------------
Changes were made to the Progress command line parsing routines to
allow for use of UNIX like commands to execute images on your VMS
system. Thus, if you set the symbol as follows:
PROUTIL :== $BIN:_PROUTIL.EXE
You will be able to execute commands such as:
PROUTIL "-C" aimage truncate dbname
It is very important to use the double quotes ("") when specifying
dash arguments; otherwise, the DEC C RTL will force the use of
lowercase. Thus a -C would be interpreted as -c.
The command this does not work correctly are the PROGRESS/STRUCTURE
commands which would be equivalent to the UNIX "prostrct" commands.
3. SOFTWARE CORRECTION NOTES
----------------------------
3.1 -Nn Parameter Could Not be Greater Than 99
----------------------------------------------
The value of the -Nn startup parameter for a client can now be
greater than 99. Progress now allows a maximum value of 1000.
3.2 4146 Error in /NOINTERACTIVE Batch Process
----------------------------------------------
In Progress Version 7.2E for OpenVMS BATCH mode, errors with the
batch job caused the job to try to obtain information about terminal
characteristics for a non-existant terminal. This issue has been
resolved for Version 7.3C.
3.3 Removal of the Need to Define PROTERM
-----------------------------------------
In Version 7.3C, Progress correctly determines the current terminal
type that was set with the OpenVMS "SET TERMINAL/DEVICE" command.
Defining the logical PROTERM is no longer necessary and is ONLY
needed IF you want Progress to use a terminal definition that is
DIFFERENT than your current terminal setting.
If you receive errors without PROTERM defined, ensure you do not have
the logical TERM defined as well. The code first checks for the
existance of PROTERM then for TERM and if all else fails will
determine your current terminal type name and use it as lookup into
the PROTERMCAP file.
3.4 Removal of the Need to Define PROTERM or TERM in Batch Mode
---------------------------------------------------------------
In Version 7.3C, you can use Progress in batch mode without a defined
PROTERM or TERM logical. When you do, Progress defaults to the ANSI
terminal and issue the following message:
TERM env variable is not set. Assuming an ANSI terminal. (4032)
3.5 UCX$IPC_SHR Not Found
-------------------------
In Version 7.3C, you can run Progress for OpenVMS Alpha without UCX.
3.6 Connecting to a Progress Database Inside P-Code With an
After-Image and/or Before-Image Flag
-----------------------------------------------------------
In Version 7.3C, you can use the following statement to connect to a
database from within the Procedure Editor:
CONNECT test.db -1 -a test.ai -g test.bi
Prior to Version 7.3C, the connection would fail with some part of
the path and the test.ai file name in the error message.
3.7 Undeserved Compiler Errors When Using Syntax: {{&turkey}}
-------------------------------------------------------------
In Version 7.3C, the Progress 4GL compiler no longer produces errors
when you use double braces in the syntax of variable definitions.
PROGRESS errors you may encounter: (247) (254) (198)
3.8 Extra Cursor on the Screen
------------------------------
Prior to Version 7.3C, some complex frames that worked under V6
resulted in an extra cursor appearing on the screen. This issue has
been resolved.
3.9 Rubout (delete) Key on VT Type Terminals
--------------------------------------------
In Progress Version 7.2E, the Rubout (the key just over the return
key) removed the character to the right of the cursor. In Version
7.3C, the Rubout key removes the character to the left of the cursor,
following the Version 6 behavior.
This change required a modification to the PROTERMCAP file, thus if
you have modified this file for your own functions or terminals, you
should compare the changes and merge. In particular, the following
line added to your VT100 definition fixes the problem:
:BACKSPACE(BACKSPACE)=\177:
3.10 TERMINAL= Function Not Working
-----------------------------------
In Version 7.3C, the TERMINAL statement works according to the
documentation. This has been corrected and an updated PROTERM.DAT
file has been provided.
For example, the statement ´TERMINAL="vt300-132".´ sets a VT300 to
132 column mode.
3.11 PROGRESS/TOOLS=QUOTER was Broken on RMS Indexed Files
----------------------------------------------------------
In Version 7.3C, the QUOTER utility would incorrectly quote an
indexed file. This problem has been fixed to correctly quote each
record.
3.12 PROGRESS/DELETE <dbname> caused ACCVIO without SYSLCK Privilege
----------------------------------------------------------
Prior to Version 7.3C, the attempt to delete your database files
using the /DELETE qualifier would not check for the correct
privileges (SYSLCK is required). If you didn´t have the SYSLCK
privilege set, Progress would attempt to perform a task which
required the privilege and the result was an ACCVIO. For Version
7.3C, this has been fixed.
3.13 Using 4GL Statement VMS [SILENT] to Run PROGRESS
-----------------------------------------------------
Prior to Version 7.3C, if the PROGRESS command was not installed in
your system wide DCL tables and if you used the 4GL statement:
VMS PROGRESS/... or VMS SILENT PROGRESS/...
where /... is a Progress command to be run, such as PROGRESS/DELETE
<dbname>
You would get an error message:
DCL-W-IVVERB, unrecognized command verb - check validity and
spelling.
The error was due to the PROGRESS verb not being present for the
spawned process. The problem has been resolved by creating a
temporary command file in your current working directory, then
executing the command file, and deleting after execution. The
command file will do the following:
$IF F$SEARCH("DLC:PROGRESS.CLD") .NES. ""-
THEN SET COMMAND DLC:PROGRESS
$ "YOUR 4GL COMMAND HERE"
$ EXIT
3.14 PROGRESS/CREATE <targetdb> <sourcedb> Displayed an Incorrect
Error Message When <sourcedb> Was in Use
-----------------------------------------------------------------
Prior to Version 7.3C, if you issued the PROGRESS/CREATE command on a
database that was in use, you would receive the following error:
PROGRESS database <sourcedb> was not found.
This message was incorrect and has been fixed to state:
PROGRESS database <sourcedb> in use. Cannot copy.
3.15 Use of Concealed Logicals and Servers/Brokers/Gateways
-----------------------------------------------------------
A problem has been fixed when using OpenVMS concealed logicals
defined in the LNM$JOB or LNM$PROCESS table and attempting to start a
server or gateway. Previously the server or gateway would not start
since it could not find files. The command procedure Progress
creates in order to start the gateway or server process will be
created using the parsed logical rather than the concealed defintion.
In addition, the procedure will search for and invoke the procedure:
DLC:PROGRESS_SETUP.COM
in order to get any logicals and search paths you may have defined
and need for your server or gateway.
3.16 Loading of .D and .DF Files That are Not in STREAM_LF Format
-----------------------------------------------------------------
If when loading your database from .DF and .D files, PROGRESS
determines that the read file is not in STREAM_LF format, PROGRESS
will attempt to convert the file format to STREAM_LF so that the file
can be parsed correctly. If PROGRESS is unsuccessful in converting
the file to the correct format, an error will be generated indicating
you must convert the files to the correct format before continuing.
In order to avoid this issue, you convert your .D file to the correct
format, Stream_LF. You can do this by issuing the following sequence
of commands:
$ CREATE STREAM_LF.FDL
FILE
BEST_TRY_CONTIGUOUS no
CLUSTER_SIZE 3
CONTIGUOUS no
EXTENSION 0
FILE_MONITORING no
GLOBAL_BUFFER_COUNT 0
ORGANIZATION sequential
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL carriage_return
FORMAT stream_lf
SIZE 0
^Z < hold the control key and the Z key >
$
$ CONVERT/FDL=STREAM_LF
<filename>.D <filename>.D
$
Your file should now have the correct record attributes.
3.17 Maximum Length of Path Increased
-------------------------------------
Prior to Version 7.3C, if the full path exceeded 63 characters
PROGRESS might truncate the path or fail to find the file. (A full
path includes the current working directory and filename.) This issue
is resolved in Version 7.3C.
The maximum path is now set to 255 characters, which is the OpenVMS
maximum.
The only instance in which the path length must remain at 63
characters is for the path name in your database structure file
(<dbname>.ST) for multi-volume databases. A database change would
have been required in order allow the use of 255 characters.
3.18 Using Triggers in a PROGRESS Library
-----------------------------------------
Prior to 7.3C, using Progress Library files (<name>.PL) and mixing
UNIX and VMS directory syntax within the database and library files
would not allow triggers to perform correctly. Progress was unable
to find the trigger in the library due to mismatched directory
syntax. This problem has been fixed.
3.19 Clients Incorrectly Passed Local Absolute Path to DataServer
With Error Message "Disconnected from server (436)"
-----------------------------------------------------------------
Prior to 7.3C, when a client passed a database name to either an
Oracle or RMS Data Server, Progress would incorrectly prepend to the
database name the local current working directory to the path causing
the DataServer to not find the database and return the error. This
has been fixed to force the Data Server to determine where the
database exists.
3.20 Provided RESULTS.COM was Incorrect
---------------------------------------
Prior to 7.3C, the Progress supplied file RESULTS.COM was incorrect,
this file has been updated.
3.21 Files Were Missing for Oracle DataServer
---------------------------------------------
Prior to 7.3C, a number of files the Oracle DataServer may have
needed were inadvertantly left off the distribution media. This has
been corrected.
3.22 Fixed Output of PROMON Data
--------------------------------
Prior to 7.3C, the output of the PROMON data for the PID field
incorrectly only displayed the lower word of the OpenVMS PID in
decimal format. This has been corrected to display the full PID in
hexadecimal format.
3.23 Use of PROGRESS/MULTI_USER=SHUTDOWN/DISCONNECT=<pid>
---------------------------------------------------------
Prior to 7.3C, attempting to execute the command:
PROGRESS/MULTI_USER=SHUTDOWN/DISCONNECT=<pid> DBNAME
where <pid> was the PID listed through either PROMON or SHOW SYSTEM
did not disconnect the target process. This has now been fixed.
3.24. Long Error Messages Were Being Truncated in Server Log Files
------------------------------------------------------------------
Prior to 7.3C, long error messages in server log files were being
truncated at 160 characters. This has been fixed to allow the full
255 characters available to be sent to the log file.
3.25 PROTERMCAP File Changes
----------------------------
A number of enhancements and fixes were added to the PROTERMCAP file.
Definitions have been added for using DIGITAL VTxxx terminals in 132
column mode.
The VT100 and VT200 terminal definitions have been updated to remove
unnecessary padding characters.
3.26 Use of the PROHELP logical instead of needing /dlc/prohelp in
PROPATH
---------------------------------------------------------------
You may use the PROHELP logical instead of adding "/dlc/prohelp" to
your PROPATH definition to allow the Progress HELP system to locate
its help files.
3.27 Online HELP no Longer Needs Extra Step for SEARCH Function
---------------------------------------------------------------
When you select HELP with the subheading of ´SEARCH FOR HELP ON´,
you are now correctly placed in the HELP search window.
3.28 Use of ESQL/C systems [7.3C08]
-----------------------------------
The commercial release of 7.3C included a problem on OpenVMS VAX
systems where using ESQL/C would not work. This has now been fixed.
Specifically, the call to ´sqllogin()´ would fail, returning a 2.
In addition, use of the 3rd parameter to ´sqllogin()´ such as:
sqllogin ( 0, (char **)0, "-db sports -1", "" );
would cause an ACCVIO and server crash. These problems have been
corrected.
3.29 Use of PROGRESS/UTILITIES=TRUNCATE_BI without DELETE privilege
to the BI file [7.3C08].
---------------------------------------------------------------------
Prior to 7.3C08, attempting to truncate the BI file by a user who did
not have delete access to the BI file would cause corruption of the
BI file. This has now been changed to allow the user who has
Read/Write access to the file, but no Delete access to merely reset
the RMS pointer in the file to the beginning. Normally, when you
truncate the BI file, Progress will delete the old copy and then
create a new copy. This fix will change the result to keep the same
file only in the case where the user doesn´t have the delete
privilege and just reset the file. The previous size of the BI file
will remain.
3.30 Progress/Multi=Shut/Kill hangs [7.3C08]
--------------------------------------------
Prior to 7.3C08, shutting down multiple databases using the /KILL
option would hang the process attempting the shutdown if a client had
multiple databases connected and had previously received a kill
acknowledgement which was not responded to by pressing space bar to
continue.
3.31 Progress/Save_Temp_Files deletion of SRT* and LBI* files
[7.3C08].
----------------------------------------------------------------------
Prior to 7.3C08, when using the /Save_Temp_Files option, the LBI* and
SRT* files were not deleted upon successful exit of Progress. This
has been fixed.
3.32 Unique OpenVMS Lock Name for Database Server Lock [7.3C08].
----------------------------------------------------------------
Prior to 7.3C08, there was a potential that a database server would
not be allowed to start due to the inability to take out an OpenVMS
Lock request. The work-around was to simply copy the database and
usually the problem would go away. This was caused by the lock name
created to ensure database integrity not having enough uniqueness.
The algorithm basically attempted to take out a lock in the form:
DLC_alloclass_fid0_fid1_fid2
Where the fid was the file id in the INDEXF.SYS for the .DB file.
This caused problems when a database on another disk had the same
exact file id as a database that already had a server running.
The algorithm was modified to also add the disk name (such as DUA10,
DSA20, DKB200, STA1000, etc.) to the string for the lock name. Thus
the lock name now used will be:
DLC_diskname_alloclass_fid0_fid1_fid2
3.33 Additional checks for VMS specific directory naming [7.3C08].
------------------------------------------------------------------
Prior to 7.3C08, there were instances where use of the angle brackes
("<", ">") for directory specifications would not work correctly. A
search of all code was performed looking specifically for directory
syntax and all VMS variations were checked.
3.34 Output to Spooled Devices [7.3C08].
----------------------------------------
Prior to 7.3C08, attempting to output to Spooled device that is
associated with a queue did not work correctly, returning an error
such as "unknown file or device (98)". The following is more
details:
Set a device such as LTA6 as online, allocated, spooled. Initialize a
queue to be that device:
$ set /queue queue_name /on=lta6:
$ set/queue queue_name /start
From Progress Editor:
Output to lta6:. Display "Junk". Output close.
A job should have started on the queue, but didn´t. This has now been
fixed.
3.35 Running ProMon from a command file [7.3C08].
-------------------------------------------------
Prior to 7.3C08, if you ran ProMON (Progress/Shutdown/Monitor dbname)
from a VMS command file (@FOO.COM) and specified an incorrect number
of responses to questions, Progress would loop endless on the last
menu choice expecting input which was not available. This has now
been fixed. Instead of looping endlessly, Progress will quit from
ProMON.
3.36 PROPATH issues [7.3C08].
-----------------------------
Prior to 7.3C08, the PROPATH logical was translated and stored
internally to Progress in UNIX format and some in VMS format. During
execution, Progress used the path to find files and create output.
There were a number of problems that were exhibited over time;
therefore, for 7.3C08 the PROPATH code was rewritten. The new
algorithm will accept either VMS or UNIX or mixed directory syntax as
the PROPATH and convert and store as VMS format.
This change should require no changes at the application end;
however, if there are specific reliances on UNIX format in your code
when relating to the path to a file, then you should ensure that the
returned format from your Progress call is what you expect. From
this release forward, you can expect VMS format to be returned.
3.37 Server Log Files [7.3C08]
------------------------------
Progress V7.3C06 had a problem where the server log files
<db-name>SV.LG were not being written out to the database directory
if the server was started with the command such as:
PROGRESS/MULTI=START [.SUBDIR]DBNAME
Instead they were being written to the current working directory.
This has been resolved and files are now written to the directory in
which the database resides.
4. UNRESOLVED ISSUES
--------------------
Progress Software has identified the following issues that are yet
resolved.
4.1 Client LOGIN Fails on Long Database Path
--------------------------------------------
A remote login will fail if the database path name is too long. For
remote dataservers, this includes user name and password. The server
log will post the following message:
SRV 0: Login refused; client has version 17 and server has version
40.
Do not use database paths greater than 50 characters. A database
path is defined as:
<device>:[directory]<database name>.DB
4.2 PROAIW, PROBIW, PROAPW PROCEDURES Located in BIN not DLC
------------------------------------------------------------
The documentation incorrectly states the location of these utility
procedures as being in the DLC directory. They are located in the
BIN directory. The BIN logical can be defined as:
$ DEFINE BIN <device>:[DLC.BIN]
Then the procedures can be run:
$ @BIN:PROBIW
4.3 BULKLOAD Must be Run Where Data is Located
----------------------------------------------
You must run BULKLOAD from the directory where the data is located or
PROGRESS will generate the following errors:
Data input file "<filename>.d" could not be opened. (1505)
Bulk load aborted near "<filename>" because of errors. (1507)
4.4 CONV67 Fails With PROG/LANGUAGE_USER
----------------------------------------
CONV67 will fail if the database you are converting uses a
user-defined collation table.
Do not convert a database with a user-defined collation table.
4.5 Installation From a Search List Directory Structure
-------------------------------------------------------
Make sure that the target directory (i.e., the DLC directory) of your
PROGRESS installation does not include a search list of logical
names.
For example, do not try to install into SYS$SYSROOT:[DLC], because
SYS$SYSROOT is a search list logical. Pick a specific location or
use the default SYS$SYSDEVICE:[DLC]. The target directory can be on
a logical disk that is a stripe set, a shadow set, or a multivolume
set, as long as it is one logical device.
4.6 Error from PROINSTALL
-------------------------
If you get the following error from PROINSTALL.COM:
TERM not found in VVTERMCAP file
your terminal is not recognized. This is likely to happen if your
terminal type has not been set correctly with the OpenVMS SET
TERMINAL command or you have the logical PROTERM defined in the
system logical name table or within your SYS$SYLOGIN.COM or LOGIN.COM
procedures. To resolve this, issue the SET TERMINAL command to
correctly set your terminal type or clear the PROTERM definition with
the OpenVMS DEASSIGN command or define PROTERM as follows:
$ define PROTERM VT100
4.7 Error from PROINSTALL
-------------------------
Make sure you follow the instructions for PROINSTALL very carefully,
if you get the "Device already allocated" message that means you
forgot to DEALLOCATE the tape device after backing down the first
saveset from the tape and before running PROINSTALL. You must
DEALLOCATE the tape device before your installation can continue
successfully.
4.8 CTRL/U Key Functions the Same as CTRL/X
-------------------------------------------
In the Application Development Environment, the CTRL/U character is
documented as performing a "BACK-TAB" function. Due to the way the
OpenVMS Terminal Driver works, CTRL/U is equated to CTRL/X and
performs a "GO" function.
4.9 Copying Databases From VAX to Alpha or Alpha to VAX
-------------------------------------------------------
If you copy your database(s) from a VAX to an Alpha system or from an
Alpha to a VAX system, you must first truncate your BI file before
performing the copy. You should also truncate your AI files if you
use them as well. This is due to different alignment issues between
VAX and Alpha code.
4.10 Use of DECnet/OSI
----------------------
Progress Software does not support DECnet/OSI in Phase V mode. You
must be running DECnet in Phase IV compatibility mode. In addition,
we have determined that using a Windows for Workgroups V3.11 client
does not work in all cases.
4.11 Editing Progress-Created Files From Non-OpenVMS Editors
------------------------------------------------------------
If you edit PROGRESS created and/or provided files from non-OpenVMS
editors, the file attributes of the resulting file may be changed by
the editor from the type PROGRESS had created and expects to find. In
particular, some editors change STREAM_LF files to some other format,
as determined by an OpenVMS DIRECTORY/FULL command of the file and
the "Record Format" field. In this case, you may need to convert the
file back to STREAM_LF in order for PROGRESS to read it. The
following OpenVMS commands should set your file attributes correctly
again:
$ SET FILE /ATTRIBUTES=RFM:STMLF <file>
Also, since the record length may be affected as well, use the
following command to correctly reset it:
$ SET FILE /ATTRIBUTES=LRL:32767 <file>
4.12 Use of the /EXECUTIVE_MODE on DEFINE´s of logicals [7.3C08].
-----------------------------------------------------------------
Progress specifically does not support the use of the /EXECUTIVE_MODE
when defining logicals. The use of this switch will not allow the
Progress Help to start correctly from within the Procedure Editor.
5. PROGRESS USAGE OF OpenVMS RESOURCES
--------------------------------------
The following sections are designed to assist you in understanding
what kind of OpenVMS system and process level resources PROGRESS
requires in order to perform on your system. These are only
guidelines and some hints.
5.1 PROGRESS Usage of OpenVMS System Level Resources
----------------------------------------------------
OpenVMS system resources are those controlled by the SYSGEN utility.
PROGRESS generally only uses system level resources for sharing data
between multiple users. In particular, PROGRESS makes heavy use of
globally mapped system pages (GBLPAGES and GBLPAGFIL). As you
increase the number of servers and clients to your PROGRESS, RMS, or
Oracle data- bases, the system will require more resources in order
to efficiently access the database. In addition, the GBLPAGFIL
parameter will get used heavily if you use the RMS dataserver. See
the SYSGEN utility help for these parameters for the details as to
how they are used.
Each server to a database takes one OpenVMS process slot and each
client accessing the database will also take an OpenVMS process slot.
Process slots are controlled by the MAXPROCESSCNT and BALSETCNT
parameters. In addition, in order to ensure that your processes get
the most out of the system, you will need to modify the WSMAX and
VIRTUALPAGECNT. These parameters dictate how much physical memory a
process can have and how many pages in the system page file may be
mapped by the process.
If you are unsure how to handle system parameters, use the OpenVMS
AUTOGEN utility with FEEDBACK on a fairly regular basis during heavy
user loads on your system. This utility will help set your system
parameters based on usage it has uncovered. See the OpenVMS System
Managers documentation set for details on using AUTOGEN.
Beyond memory resources, as you increase the number of servers and
clients accessing the system, the demand for CPU and I/O resources
will also be increased. You should periodically do some sort of
capacity planning in order to ensure you are getting the most out of
the system. As you add servers and clients they will begin competing
for the same CPU(s). You must make the tradeoffs between performance
and usability. For I/O, if all your PROGRESS files reside on one
disk, then the bottleneck is the I/O to the files. Keeping PROGRESS
on your system disk will also make PROGRESS compete for I/O resources
with other system operations. Again, you must make the tradeoffs
between availability and performance.
The following section describes the main PROGRESS resource used,
GBLPAGES. When starting a Multi User session, the first PROGRESS
server creates a Disk Mapped Global Section for backing store for
each database in which you have a server connected. This operation
requires the use of disk space and system global pages in order to
allow other servers and clients to map the same section file. The
amount of resources required for this operation depends mainly upon
the parameters used to start the server. Specifically the numbers
used in the following qualifiers will have an effect on the resources
(see the PROGRESS System Adminstration Reference Guide for details on
how to use the parameters).
VMS Qualifier UNIX Equivalent Default Value
-------------------------------------------------------------
/BUFFERS -B 160 [-n * 8]
/TOTAL_PRIVATE_BUFFERS -I 40 [-n * 2]
/HASH -hash 43 [-B / 4] (1)
/BIBUFFERS -bibuf 5
/AIBUFFERS -aibuf 1
/NUMBER_OF_USERS -n 20
/MAXSERVERS -Mn 4
/LOCK_TABLE -L 500
/LKHASH -lkhash 83 [-L / 8] (2)
/EXCESS_SHARED_MEMORY -Mxs 22384 [16384+(300*-n)]
(1) -hash is a prime number greater than 1/4 the -B value where the
prime number is sourced from an internal PROGRESS array from 13 to
98407
(2) -lkhash is a prime number greater than 1/8 the -L value where the
prime number is sourced from an internal PROGRESS array from 13 to
98407
The following equation will give you a rough guess as to how much
resources will be required based on the parameters selected. Note
that the actual may be more or less that your calculated value, since
the values listed are rounded to the nearest tenth, thus you should
always leave room for slight error in calculation. In addition,
Alpha systems tend to take more space due to alignment issues. The
following formula uses the UNIX syntax to determine the value, this
was done to save space.
17000 + (-Mxs) + ( -Mn * 90) + ((-Mn + -n) * 620) + ((-Mn + -n) * 20)
+ ((-B + -I + 2) * 140) + (-hash * 4) + ((-B + -I + 2) * 1030) + (2 *
(20 * (-Mn + -n) + 28)) + (-bibufs * 170) + (-bibufs * 16388) +
(-aibufs * 160) + (-aibufs * 16388) + (-lkhash * 12) + (-L * 20)
Therefore, using the default values:
17000 + 22384 + (4 * 90) + ((4 + 20) * 620) + ((4 + 20) * 20) + ((160
+ 40 + 2) * 140) + (43 * 4) + ((160 + 40 + 2) * 1030) + (2 * (20 * (4
+ 20) + 28)) + (5 * 170) + (5 * 16388) + (1 * 160) + (1 * 16388) +
(83 * 12) + (500 * 20)
The approximate default default size is : 402978 bytes or 788 pages.
Depending on how many database servers you have running, you will
need at least this calculated value for each database. Once the
database has a server mapping to the database .SHM file, each other
server and client will only need to map this many pages.
5.2 PROGRESS Usage of OpenVMS Process Level Resources
-----------------------------------------------------
To understand OpenVMS usage of process resources, you should read the
OpenVMS System Managers Guide. There is a very detailed description
of how OpenVMS uses process resources. In particular, try to
understand how memory is allocated to the process and what happens
when the process when the process reaches its working set quota.
In terms of the authorized quotas for an account, the important
parameters for process memory are WSDEF (working set default),
WSQUOTA (working set quota), and WSEXTENT (working set extent). In
addition, the process page file quota (PGFLQUO) is used to determine
how many pages of memory the process is allowed to use in the page
file.
In general, PROGRESS is a heavy user of OpenVMS process resources.
In particular, PROGRESS uses a great deal of process memory. The
PROGRESS images tend to be larger. Each image must be loaded into the
processes memory space. Portions of the image not used and
eventually are paged out of the processes physical memory into a
section of the system page file which the process is using. During a
normal VMS session, a process will work to keep it´s working set
around the value of WSQUO. If there is free memory in the system, the
process can then allocate up to WSEXTENT pages of physical memory for
its usage. However, if the system finds memory being overutilized,
those processes which are over quota will begin to get "trimmed back"
to the WSQUO value so that other processes that also need the memory
will also be able to access the memory. Those pages that are trimmed
back are paged out.
PROGRESS Client sessions on OpenVMS systems tend to use between
10,000 and 15,000 pages of working set just to get to the PROGRESS
Editor. Thus, in order to keep the entire image in memory, the
working set quota for the account could be set to 16,382. Although,
this value can vary depending on startup parameters and operations
performed.
PROGRESS Server sessions on OpenVMS systems tend to use between 8,000
and 12,000 pages of working set just to get the server running.
Thus, in order to keep the entire process in memory, the working set
quota for the account could be set to 16,382. Again, this value
fluctuates depending on startup parameters for the server.
5.3 Tools to Help Monitor
-------------------------
OpenVMS provides two basic tools to help monitor the activity on your
system. The first is the Monitor utility, which gives you a
character cell interface to view how your system is currently
performing. This utility is included on every VMS system and is
invoked via the DCL command, MONITOR. The MONITOR utility is well
documented in the OpenVMS System Managers documentation set. The
second tool is DECamds, which must be installed and is free to those
that have a VAXcluster, VMScluster-Client, or VMScluster license.
DECamds uses a DECwindows Motif interface to provide a similar view
of system performance as well as an event system to point out where
resources are being over utilized. DECamds with the operating system
distribution kit and has it´s own User´s Guide.
Beyond the free tools, Digital also sells Polycenter Performance
Solutions which is a comprehensive set of tools to give performance
and capacity style information and suggestions. There are also a
number of Digital´s 3rd party vendors which also sell performance
solutions.
Progress Software Technical Support Note # 15956