README.PRO 7.3C11 Release Notes for VAX and ALPHA OpenVMS
RELEASE NOTES
-------------
PLATFORM: Progress for OpenVMS VAX and OpenVMS Alpha
SOFTWARE RELEASE: 7.3C11
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, V7.0
Alpha: OpenVMS V6.1, V6.2, V7.0
This release has been qualified on the following
networking variants:
UCX V3.3 (TCP/IP Services for OpenVMS)
UCX V4.0 (TCP/IP Services for OpenVMS VAX)
UCX V4.0A (TCP/IP Services for OpenVMS Alpha)
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>
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 priviledge 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
NOTE: The above was removed for the V7.3C11 due to incompatibility found with
servers running on V7.2E. The new algorithm will be replaced in a
future release. To get around the problem you will be required to
simply COPY your database so that the "FID" changes in INDEXF.SYS.
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.
3.38 Protermcap VT220 returns wrong keylabel [V7.3C11]
------------------------------------------------------
Prior to V7.311, the vt220 keycodes (556 - 559) overlapped the range used for
U1 - U10 (551 - 560). The vt220 keycodes have been reassigned to 586 - 589.
3.39 ESQL/C: sqldec issues [V7.3C11]
------------------------------------
The following problems have been resolved:
1. When an esql program fetches a progress decimal value into a HLV
of type xsqldec, all decimal digits are lost.
2. Using sqldec variable type to retrieve information from database
fields containing decimals, the value received is rounded to zero
decimals.
3.40 Use of logical in PROPATH fails to find file [V7.3C11]
-----------------------------------------------------------
A problem was introduced into the 7.3C08 release where if an element of the
PROPATH was simply a logical name pointing to a directory of files, Progress
would not find the files. This has been fixed.
Before logging a problem report with Progress Software for Propath issues,
you should determine whether or not you can use the VMS "Directory" command
in order to find your file by concatenating your "path element" and "file".
In addition, ensure you are using logicals correctly for VMS. When including
files from a directory pointed to by a logical, it is OK to simply "define"
the logical; however, when including files from a directory structure, it
is required to use "define/translation=concealed" syntax. A typical example
is trying to concatenate "logname" to "subdir/file.p". In VMS syntax, this
is similar to trying to open "logname:[subdir]file.p", if you cannot do a
simple directory command using the VMS syntax, then Progress will not be
able to find the file as well. In this case, "logname", should have been
defined with the concealed attribute, since a directory tree structure was
being used.
3.41 Performance issue using TCP/IP as a network transport [V7.3C11]
--------------------------------------------------------------------
Prior to V7.3C11, when using TCP/IP as your network transport to the database,
sequential record by record searches of the database over the network may have
taken up to 5 times as long as the same search using DECnet as the transport.
A problem or inconsistency was found with the TCP implementations on VMS, where
packets not requiring data return would cause a delay for the next data request
packet of up to 00:00:00.20 seconds. For large databases, such as an 11,000
record database, this could take up to 39 minutes to fetch all the records
as opposed to 5-7 minutes using DECnet. The problem was worked around by
changing the unacknowledged packet to an acknowledged packet and this sped
up the Progress Server returning the subsequent data request packet.
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.
4.13 Using the Progress command VMS [SILENT]. [V7.3C11]
-------------------------------------------------------
When using the Progress command VMS or VMS SILENT to perform a VMS command
line operation and you have not set or defined an output stream, Progress will
scroll your output screen based on the number of lines of output the command
generates plus 1 line.
If you wish to perform a VMS command and do not wish to have your Progress
screen scroll, such as using a frame with button selects for various VMS
commands, use one of the following options:
1. Use the OS-COMMAND syntax.
2. Add an "OUTPUT TO NLA0:." to the top of your program.
4.14 CONV76 is unsupported.
---------------------------
The CONV76 option for PROUTIL is unsupported. The option is present in the
PROGRESS.CLD file; however, the implementation was never made.
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 # 16580