Release Notes for Version 6.2G04, 6.2G31, 6.2G71 BTOS & CTOS
920612-elp03
Subject: readme.pro
BTOS/CTOS
ADDITIONAL NOTES FOR THIS RELEASE
SOFTWARE RELEASE: 6.2g31
EXTRACT/MOUNT COMMAND: N/A
INSTALL COMMAND: {see BTOC/CTOS Installation Notes}
MACHINE NOTES:
OPERATING SYSTEM NOTES:
TERMINAL NOTES:
SOFTWARE NOTES:
. The command "TAPE RESTORE" is required for installation by QIC tape.
This command is considered "obsolete" in the new merged version of the
CTOS operating system. The "TAPE RESTORE" command must be added prior
to installing the software. This can be accomplished through the
Command File Editor by copying the "RESTORE ARCHIVE" command to be
the "TAPE RESTORE" command.
. The "-case" option and the "-mem" option have been added to the BTOS
and CTOS commands. The "-case" option allows a command case to be used
with the run file. The "-mem" option tells Context Manager to run the
command in a context of the specified memory size in Kilobytes.
The options are specified before the run file name if used, neither
option is required.
The example below would run the PROGRESS BACKUP utility on the database
"test" in an 800K context.
example:
BTOS SILENT -case 01 -mem 800 [sys]<dlc>probin/dbutil.run
"pro_backup" "test.db" "test.bk".
The memory size can be prefixed with either the letter "v" or "f".
The "v" indicates that the context should be a "variable length"
context. The "f" indicates the context should be "fixed length".
If neither letter is specified, "variable length" will be assumed.
examples:
"-mem v800" or "-mem f800"
The "variable length" context means that if the program you are
running only needs "554K" of memory, the partition will only be
set to "554K", even if you set "-mem" to be "800". Using the
"fixed length" options, guarantees that the context will be the
full size specified.
You can use CTOS´ "version" command to get an estimate of the size that
a program will use. Run the "version" command with details on your run
file. The version command will tell you the program´s "static memory"
size, and "Max dynamic memory" size. Adding these two numbers will give
you an estimate of the memory size for your program. The partition size
will be set to this sum, or to your specified "-mem" size, whichever is
lower.
Some programs, like our "<dlc>progress.run", have the "Max dynamic memory"
size set to "<all>". For these types of run files, the partition size
will be set to whatever you specify with the "-mem" option.
. To improve support for background color, PROGRESS was changed to use
ResetVideoGraphics instead of ResetVideo. Since early versions of
BTOS, CTOS and StarSys do not support this call, PROGRESS version
6.2g04 could not run on these early O.S.´s.
To correct this problem, PROGRESS version 6.2g31 makes a query to
the O.S. to see if the ResetVideoGraphics call is supported. If
not, then the ResetVideo is used.
. The version 6.2g31 does correct processing of "WHERE" clauses on ISAM
composite keys, and correctly processes the CAN-FIND statement.
. The PROGRESS Server now recognizes when a client has terminated due
to a system crash.
. HLC applications can now link using the commercially released version
of the Unisys TCP/IP "language independent ´socket.lib´ file".
. Updating date fields is now handled correctly. In earlier version 6
releases the number of characters entered into a date field were not
checked, and the video display could be corrupted if more characters
were entered than would fit in the field.
. The problem preventing the "FRAME-FIELD" and "FRAME-FILE" functions to
work on shared frames has been fixed.
. The user now has the ability to dynamically set the Byte Stream Buffer
size. This version implements the option "-Nb" for BTOS.
The "-Nb" option will allow the user to specify the number of 1024 byte
blocks to be used for BTOS Byte Steam buffers. The default values are
one (1) for real mode (80186 processors) and ten (10) for protected mode
(80286 and up). Remember that several Byte Streams are used during a
PROGRESS session, and increasing the "-Nb" size will increase all Byte
Stream buffers.
. The PROGRESS Utility run file "<dlc>proutil.run" has been changed to
use all available memory in the partition in which it is running.
This addresses the problem of the bulk loader occasionally running
out of memory on large loads, even though Partition Status showed
that there was still memory available in the partition.
. The occasional problem of Context Manager not allowing a context
running a PROGRESS session to swap has been fixed.
. The way that BTOS/CTOS directories are handled in FAST TRACK has been
corrected. It is now possible to deploy to, and load from, directories
other than the current working directory.
SOFTWARE RELEASE: 6.2g04
EXTRACT/MOUNT COMMAND: N/A
INSTALL COMMAND: {see BTOC/CTOS Installation Notes}
MACHINE NOTES:
OPERATING SYSTEM NOTES:
TERMINAL NOTES:
SOFTWARE NOTES:
GERMAN LANGUAGE SUPPORT
. A collation table for the German language is available. The file is
"[sys]<dlc>prolang/procoll.ger". This collation table allows PROGRESS
to correctly sort alphabetic characters according to the rules of the
German language. Refer to the documentation on "User-Defined Language
Rules" for instructions on how to use this file to create a binary file
which you can use.
PROGRESS QUOTER AND PROGRESS ISAM QUOTER
. If you want to run "Quoter" or "PROGRESS ISAM Quoter," and you intend to
use the -C option with a list of columns that exceeds 256 characters, you
can separate the list into multiple lists. For example, instead of
specifying the following:
-C 1-10,11-20,21-40,41-50,51-55
You can specify:
-C 1-10,11-20
-C 21-40,41-50,51-55
. The PROGRESS Isam Quoter now removes trailing spaces from the
the fields of an ".isam" file, instead of storing the spaces in the
PROGRESS database. PROGRESS does not need to fill character
fields with trailing spaces.
The PROGRESS ISAM QUOTER utility now supports a "-s" (record size)
parameter. You do not need to use this parameter until the release of
CTOS ISAM III. With CTOS ISAM III this parameter is required.
The PROGRESS Isam Quoter also handles converting reQuest Date types
and 4-byte CTOS date-time fields.
The PROGRESS ISAM QUOTER utility now supports COBOL packed data types
(referred to in COBOL as "COMP-3" data types). Refer to the comments
in the beginning of "isamquot.c" for conversion syntax.
The list of valid type specifiers are as follows:
C Character
I Integer (signed)
U Unsigned integer
R IEEE standard Real format
T Date/Time as 32-bit Integer
Q Request Date as 32-bit Integer
P COBOL decimal (COMP-3)
You can customize the <dlc>IsamQuot.c file to convert other data types.
This file contains more detailed information on how to use the various type
specifiers.
PROGRESS ENVIRONMENT VARIABLES
. There is a new command "PROGRESS Print Environment." This command
prints the name and contents of the current user´s environment file.
. There is a new set of background colors defined in the "Protermcap"
file. The "TERM" type for these colors is "BC." You can modify this
"Protermcap" file to suit your application´s needs.
To use background colors, you must have the appropriate hardware and
operating system (BTOS II 3.2, CTOS II 3.3, or higher).
To improve support for background color PROGRESS now calls
ResetVideoGraphics instead of ResetVideo.
. PROGRESS servers run from ".jcl" files at system startup, on a
Master Workstation or on an SRP/XE processor board, will not have
a BTOS/CTOS user name to associate with an environment file (".ENV"
file). There must be a [sys]<sys>progress.env file available.
. You can now set the node name using the PATH command and you can access
a PROGRESS database on another node.
. If FAST TRACK is installed in a directory other than the default
"[sys]<dlcft>," the install directory must be included in the users´
.ENV file both in the PROPATH and as the value of DLCFT.
PROGRESS STARTUP PARAMETERS
. You can now use PROGRESS User Id´s that begin with numeric characters.
. The "System Administration II: General" manual has a "-border" option.
You cannot use this option with PROGRESS Version 6.2g, and PROGRESS
misinterprets the option if you specify it by mistake. If you copy a
PROGRESS parameter file from another operating system, make sure
this option is not specified in the file.
. The "System Administration II: General" manual lists a "-cfg" startup
option. You cannot use this option with PROGRESS Version 6.2g, and
PROGRESS misinterprets the option if you specify it by mistake. If you
copy a PROGRESS parameter file from another operating system, make sure
this option is not specified in the file.
. The "System Administration II: General" manual lists a "-cp" startup
option.
You cannot use this option with PROGRESS Version 6.2g, and PROGRESS
misinterprets the option if you specify it by mistake. If you copy a
PROGRESS parameter file from another operating system, make sure
this option is not specified in the file.
. BTOS/CTOS PROGRESS supports the Extended Alphabet Support Option ("-xc").
This option is sometimes referred to as the "User Defined Collation
Tables" option.
The documentation does not list BTOS/CTOS as one of the Operating
Systems that support this option.
. The BTOS/CTOS PROGRESS Server parameter "[IPC Block Size]" is the
same as the "-Mm" parameter. The "System Administration II:
General" manual treats them as separate options.
. The "System Administration II: General" manual lists
the Maximum Record Size default as 1K in the text, and 2.5K in the
table at the beginning of the discussion. The 1K size is the correct
default for Maximum Record Size (server startup option).
You can also specify the Maximum Record Size with the "-Mb" option.
. The default maximum record size and IPC block size is now 1024.
Record sizes up to 32000 are now supported.
. The PROGRESS ENCRYPT SOURCE executable has been changed to allow it to
encrypt a longer list of files.
. The PROGRESS LOG MAINTENANCE utility now
enables you to print and trim the database log file while the
PROGRESS server is still running. The new command form appears as
follows:
PROGRESS LOG MAINTENANCE
Database Name db-name
Utility -C util-opt
[Server Name -S]
[Options]
You must always specify the "Database Name" and "Utility" arguments.
Valid "Utility" options are "print" and "trim." "Print" will
display the contents of the log file. The "trim" option shortens the
log file, saving only the last 3000 bytes.
The "Server Name" parameter is only necessary if you specified a server
name when you started the server.
You can use this command if no server is running.
The PROGRESS LOG MAINTENANCE utility requests that the server make
a copy of the database log file, so that the Log Maintenance Utility
can display the copy and allow the server to proceed. The PROGRESS
server copies the database log file (db-name.LG) to another file in
the same volume and directory as the log file, except with the name
suffix ".TLG" (db-name.TLG). The server suspends all other
processing until this file copy has completed. Use good judgment
on frequency of use.
To capture the output of the print utility in a file, or send it to
a printer, you must "redirect" the output. To redirect the output,
place on the "options" parameter line a ">" (greater than symbol)
followed immediately by the name of the file or printer. For example,
to redirect the output to the printer [spl]:
PROGRESS LOG MAINTENANCE
Database Name db-name
Utility -C print
[Server Name -S]
[Options] >[spl]
PROGRESS END USER CONFIGURATION DATABASE (PROBUILD)
. Be aware when reading the documentation on using PROBUILD
that the link scripts and executable names are different
depending on which operating system PROGRESS is running. The manual
tries to be generic. However, some BTOS/CTOS names are different
than those in the manual. For example, the PROGRESS executable on
BTOS/CTOS is "Progress.run", and for UNIX it is "_progres".
. The PROBUILD Utility makes certain assumptions about the names of some
BTOS/CTOS files used in the "link scripts":
a. The file "[sys]<sys>samgenall.obj" should exist. In some
environments, only the file "[sys]<sys>samgenall.asm" exists,
and it must be assembled before using the link script.
b. The standard BTOS/CTOS system libraries should exist in the
[sys]<sys> directory.
c. The BTOS C runtime libraries should be installed in
[sys]<BtosC>.
PROGRESS 3GL INTERFACE
. COBOL Embedded SQL (COBOL-HLI) is supported for COBOL2 version 1.0.0.
. BTOS/CTOS PROGRESS does support COBOL-HLI. However, the PROBUILD
application does not create the COBOL-HLI link submits. The Unisys
COBOL/2 object modules and libraries, used in the link submits, are
still too dynamic to include in the PROBUILD application. Instead,
a submit "[sys]<dlcload/uce>hlicbl/ldhlicbl.sub" is provided that you
can modify to generate your COBOL-HLI program. Replace the line in
this submit containing the phrase "PUT OBJECTS HERE" with a list of
your object modules. This submit creates a PROGRESS version of the
file Cobol/2.run version 1.0.0.
You also need to assemble"[sys]<dlcload/uce>hlicbl/CobolGen.asm"
to use the COBOL-HLI link submit.
. You must link COBOL HLI run files with "Linker.run" version 12.1 or
higher. The newer linker is required because of the run file header
size. You must also use the runfile mode "NRelProtected." Unisys´
CTOS COBOL2 version 1.0.0 was used for development testing.
. You cannot use Embedded SQL (HLI) calls from HLC subroutines.
TCP/IP
. The "NOTE" on page 7-16 of the "System Administration I: Environments"
manual should read, "From BTOS/CTOS, you can´t shutdown a PROGRESS
server running on a remote system." The manual section describes
how to shut down a PROGRESS server running on a remote host system
over TCP/IP.
. Both Sirius Internet-CT and Unisys TCP/IP are supported by BTOS/CTOS
PROGRESS Version 6. However, the run file "[sys]<dlc>Progress.run"
can support only one at a time.
The <dlc>Progress.run file provided is linked to support Sirius
Internet-CT 2.0. Another file, <dlc>Progress-UnisysTCP/IP.run,
provides support for Unisys´ TCP/IP.
. Use the "[sys]<dlc>services" file to specify the PROGRESS Servers
running on a server system connected via TCP/IP. This file should be
located in the same directory as the PROGRESS run file (the directory
specified as the DLC variable in the .ENV file).
This file is used to emulate the "/etc/services" file of a Unix
system. Users should refer to Unix system administration manuals
for more information on setting up the "/etc/services" file.
The file contains a table of servers with two pieces of information
needed per server: server name and the remote port number on the
server system.
ex.
# servername remote-port-on-server-system
# ---------- ----------------------------
unxdb 2052/tcp # a broker running on a Unix System
unxdb2 2056 # a broker running on a Unix System
(The "/tcp" after the remote port number is allowed to look like
the Unix "/etc/services" file, but is not being used at this time.
Anything on a line following the ´#´ character is ignored.
Acceptable white space separators are: spaces, tabs, and new-line
characters.)
. Unisys TCP/IP allows a limited number of TCP/IP connections. TCP/IP
connections are not currently being freed up after a PROGRESS client
disconnects from a server running on a system connected via TCP/IP.
To avoid this problem, do not have applications disconnecting and
reconnecting multiple times within the same PROGRESS client session.
BTOS/CTOS O.S.
. Swapping versions of PROGRESS are no longer provided.
. If you are running BTOS on an XE520, you must use BTOS MS8 or higher
and ensure your MS8 version has the MAKE REQUEST SET command.
. PROGRESS version 6.2g and higher uses new request codes. These
different codes resolve the conflicts that existed with request codes
used by the BULL Starsys O.S. When installing the 6.2g request codes
on a system that already has PROGRESS installed, the old request codes
are not removed from your Request.sys file. Your System Administrator
has to remove them if the obsolete codes become a problem for your
system.
. The request codes have been reserved by PROGRESS from Unisys to
allow three more PROGRESS servers. We created request files "server4",
"server5" and "server6."
You can select the server files by specifying the appropriate name
as the "Server Name" parameter ("-S" when using the UNIX-like
parameters).
Previous releases only allowed the default request codes, server2,
and server3.
. If you have used the PROGRESS Version 4 or 5 commands in your own submit
files, or for some reason you do not wish to immediately switch to the
version 6 commands, the old commands are still supported but must be
modified to work correctly. The submit file "FixOldCmds.sub" exists in
your <DLC> directory. This submit file makes the changes necessary to
update the old commands. Use this submit after completing the
installation process for Version 6.
PROGRESS Software Corp. strongly recommends migrating to the new
commands, as the old commands may not be supported in future versions.
. Attempts to install the PROGRESS Server after installing Context Manager
returns the error "End of Medium." The operating system returns this
error message, not the PROGRESS server. System services
cannot be installed after Context Manager is running.
. There is a small amount of memory (approximately 50 bytes) lost to
the client with each disconnection from the server. This memory loss
accumlates to a significant amount if users perform many connects and
disconnects to a server within each client session.
. Each connection from a client workstation to a server running on the
Master Workstation ties up 1 X-Block. There is an Operating System
parameter, specified when the Operating System is generated, that
limits the number of possible X-Blocks each user can have outstanding.
The parameter is "maxXBlocksPerUser" in the pMstr.asm file. By
default, this parameter is set to 4. If the application running on
the cluster workstation connects to several databases at the same
time, the Operating system of the Master Workstation must be
regenerated with a larger number of X-Blocks per user.
. When connecting to a database over APT-Net you must use the Multi-
threaded Request Agent (AptNetMtRqAgent.run) with a "Request Space"
parameter of 10240. Your network configuration file must also contain
the entry "RequestSpace:10240".
. You can turn off the PROGRESS session´s notification of B-Mail by
creating a PROGRESS HLC function call. Create a function that sets
the global integer variable "fcheckmail". Set fcheckmail to zero
from the HLC function, and call your function from your applications´
initialization procedures.
. This release fixes an "stget error" problem, which occurred when the
server tried to allocate more memory after being installed as a
system service. The problem only showed up in servers running with
parameters set significantly below the default values.
. This release of the PROGRESS Server sets its partition name to be
the name of the database it is serving. For example, if you run a
PROGRESS server on the database [d1]<data>Accounting.db, then the
partition name will be set to "Accounting". To view the partition
name, use the BTOS/CTOS PARTITION STATUS command.
This feature is especially useful if a server is left running and
nobody knows which database it is serving. You can now use the
partition name to find out the database name, and then use the
PROGRESS SHUTDOWN command to halt the server. This eliminates the
need to reboot the CPU.
. You can now run PROGRESS´ BTOS and CTOS commands with Context
Manager version 2.3.
. The PROGRESS "TODAY" function now returns the correct value when
the system date is advanced beyond 1997.
. The "PROGRESS RUN-TIME" executable is no longer supplied with the product.
You can, however, still create it with the PROBUILD End User Configuration
(EUC) database. The Full PROGRESS executable, and the "PROGRESS TINY
RUN-TIME" executable are still supplied.
The following capabilities are NOT included IN "PROGRESS TINY RUN-TIME":
. Access to remote servers using TCP/IP.
. Access to single-user databases.
. Ability to run dumb terminals.
. Output to [PTR] or [COMM].
. The commands BTOS OS-QUOTER, and CTOS OS-QUOTER, have been added. These
commands will read an input file and quote each line. The commands take
two parameters: input file name and output file name.
These commands do not require running a separate ".RUN" file in another
context to get the file quoted.
The example below would take the contents of "data.in" and quote the
contents on a line-by-line basis, placing the output in the file
"data.quoted".
example:
BTOS OS-QUOTER "data.in" "data.quoted".
INPUT FROM "data.quoted".
. The BTOS and CTOS commands now set the Context Manager Application Name
to be the command name given. For example, the following command:
BTOS [sys]<sys>files.run Files * y
would show the CM application name "Files."
. The CTOS OS-REQUEST capability was expanded to allow the user to
allocate, manipulate, and free short-lived memory. These enhancements
allow structures with mixed datatypes to be stored in contiguous
memory, and passed with the OS-REQUEST command to a server.
The document [sys]<dlc>ctos_req.doc explains their use more fully.
. XE520 and SRP users have to set the "-B" option ("[Blocks in DB Buffers]")
to 40 or lower or the server will be too large to shut down.
. PC users connecting to BTOS/CTOS PROGRESS Servers via Unisys´ Clustercard
and ClusterShare are only able to connect to and disconnect from a
database a limited number of times. This is due to the way ClusterShare
handles allocating and deallocating exchanges. Unisys has been notified
of the problem.
. PROGRESS no longer supports Cluster Servers running BTOS Classic and
CTOS Classic. Because of the size of the PROGRESS product,
protected mode memory on the Cluster Server is required. Use CTOS VM,
BTOS II and the new merged CTOS II only.
. PROGRESS RESULTS for BTOS/CTOS takes advantage of the BTOS/CTOS
"[scr]<$>" directory, and therefore does not have the requirement
of each user running from a different working directory. It is still
recommended to work from different working directories, but not a
requirement for BTOS/CTOS users.
BTOS/CTOS
ADDITIONAL NOTES FOR THIS PATCH RELEASE
SOFTWARE RELEASE: 6.2g70
INSTALL COMMAND: {Install 6.2g31 according to BTOC/CTOS Installation
Notes before installing this patch}
RESTORE COMMAND: Sumit the file [f0]<sys>install.sub
MACHINE NOTES: N/A
OPERATING SYSTEM NOTES: N/A
TERMINAL NOTES: N/A
FILES in 6.2g70 Patch:
FOR GENERAL PROGRESS FIXES:
<dlc>Progress.run PROGRESS Full 4GL
<dlc>ProTnyRt.run PROGRESS 4GL Tiny Run-Time
<dlc>version PROGRESS 6.2g70 version file
<dlcload/4gl>lg/compiler.lib Library for PROBUILD users
FOR CTOS ISAM GATEWAY SPECIFIC FIXES:
<dlc>prodict/bti/bti_idx.p CTOS ISAM index editor (source)
<dlc>prodict/bti/bti_idx.r CTOS ISAM index editor (compiled)
<dlc>prodict/bti/bti_ich.p CTOS ISAM index definition (source)
<dlc>prodict/bti/bti_ich.r CTOS ISAM index definition (compiled)
<dlc>Progress-CTOSISAM.run PROGRESS Full 4GL w/CTOS ISAM
<dlc>ProRt-CTOSISAM.run PROGRESS 4GL Run-Time w/CTOS ISAM
<dlc>ProTnyRt-CTOSISAM.run PROGRESS 4GL Tiny Run-Time w/CTOS ISAM
<dlcload/4gl>lg/ibbtplog.obj Object file for PROBUILD users
<dlcload/4gl>lg/ibccon.obj Object file for PROBUILD users
<dlcload/4gl>lg/ibcdb.obj Object file for PROBUILD users
<dlcload/4gl>lg/ibcerr.obj Object file for PROBUILD users
<dlcload/4gl>lg/ibcfm.obj Object file for PROBUILD users
<dlcload/4gl>lg/ibcmisc.obj Object file for PROBUILD users
<dlcload/4gl>lg/ibcsm.obj Object file for PROBUILD users
<dlcload/4gl>lg/ibctopro.obj Object file for PROBUILD users
<dlcload/4gl>lg/ibscmp.obj Object file for PROBUILD users
<dlcload/4gl>lg/ibsdb.obj Object file for PROBUILD users
<dlcload/4gl>lg/ibsdbenv.obj Object file for PROBUILD users
<dlcload/4gl>lg/ibserr.obj Object file for PROBUILD users
<dlcload/4gl>lg/ut.lib Library for PROBUILD users
SOFTWARE NOTES:
. Correctly implements the CRC feature for programs using shared buffers
and work files.
. When using the CTOS-ISAM Index Editor or File Editor utilities of the
dictionary, the "SwitchFile" option will now work correctly. Earlier
versions displayed a warning that the file "/prodict/bti/bti_ichg.p"
could not be found.
. The CTOS ISAM Gateway modules are linked with CTOS ISAM II version 1.1.6
. To start a PROGRESS session in multi-user mode against a CTOSISAM
database, you have to use the "-1" (dash one) connection option
following the "-dt CTOSISAM".
For example:
The sample isamdemo.pf file is:
-db demo -1
-db isamdemo -dt CTOSISAM -1
To connect multi-user, start a server against the schema holder "demo".
Then modify the isamdemo.pf file to be the following:
-db demo
-db isamdemo -dt CTOSISAM -1
This applies for Full, Query Report, Run-time, and Tiny Run-time
PROGRESS clients.
. ACCUMULATE and TOTAL BY statement bug is now fixed. This allows the
following sample code to work:
FOR EACH customer BREAK BY st:
ACCUMULATE customer.max-credit (TOTAL BY st).
IF LAST-OF(st) THEN
DISPLAY customer.st "total = " ACCUM TOTAL BY st customer.max-cred.
END.
. All errors returned by the CTOS ISAM API calls are logged in the system
log file log.sys. Each ISAM call will return a ISAM error and possibly
a system related error where applicable. Both of these error codes are
logged. Below is a sample entry:
---------------------------------------
NGENT3, Server WorkStation, No CommIop
SignOn User Name: Lou
MESSAGE TEXT LOGGED - Fri Apr 17, 1992 11:20 AM
PROGRESS ERROR, wks: 0, node: {local}.
CTOS ISAM erc nnnn, ercDetail nnnn
---------------------------------------
where:
"wks:" is the workstation hardward Id or workstation number.
"node:" is the BNet (or Aptnet) Node name.
"erc" is the error code returned by the ISAM Service.
"ercDetail" is the detail error returned by the ISAM Service.
Refer to the Unisys CTOS ISAM manuals for details
of these error codes.
The Node name and workstation number can help identify the specific
workstation where the error occurs.
For example, if a call to OpenISAM failed because the file does
not exist, the erc field in the log entry will be 3122 and ercDetail
will be 203. Error 3122 is an "ISAM Data Store error", error 203,
a system error code is "No such file".
ISAM error 3127 (no more records) and 3143 (record locked) are
not logged, they are common errors that can occur because of
normal processing. All other non-zero errors returned
from ISAM are logged, they may or may not be fatal.
. Fixed a bug related to indexes made up of multiple (contiguous) fields.
For example, if a file, "maillist" has an index, "name" made up
of 3 character fields:
field length description
----- ------ -----------
LName "X(20" Last name
MName "X" Middle initial
FName "X(20)" First name
The following code now works correctly:
DEFINE VAR LName LIKE maillist.LName.
DEFINE VAR FName LIKE maillist.FName.
DEFINE VAR MName LIKE maillist.MName.
UPDATE LName FName MName.
FIND maillist WHERE maillist.LName = LName AND
maillist.MName = MName AND
maillist.FName = FName NO-ERROR.
IF AVAILABLE maillist THEN
DISPLAY maillist.
ELSE
DISPLAY "no such record exists".
. Fixed a problem related to record range checking used by 4GL WHERE
clauses (i.e. FOR EACH CUSTOMER WHERE cust-num > 10). The range
check comparison function now works correctly with the following
CTOS ISAM data types:
Characters (CHAR)
Signed integer (INTEGER)
Unsigned integer (UNINT)
Real (REAL)
The data types Date, Comp3 and UnComp3 are not yet fully qualified. This
means that ISAM files with indexes made up of Date, Comp3 or UnComp3
fields cannot be guaranteed to produce correct results in WHERE clause
statements. This does NOT apply to non-index fields in WHERE clauses.
This problem will be fixed in a later release.
For example, if a file "testcomp" has 2 fields "compfld1" and "compfld2"
both of which are "Comp3" data types and compfld1 is an index. The
following conditions exist:
/* WILL NOT alway produce correct results */
FOR EACH testcomp WHERE compfld1 > 10: /* compfld1 is an index */
DISPLAY testcomp.
END.
/* WILL always produce correct results */
FOR EACH testcomp WHERE compfld2 > 10: /* compfld2 is not an index */
DISPLAY testcomp.
END.
. Record locked conditions. A number of record locking issues were resolved
in this release.
EXCLUSIVE-LOCK - NO-LOCK.
-------------------------
If a user has obtained an exclusive lock on a specific record in an
ISAM file (i.e. FIND Customer WHERE cust-num = 1 EXCLUSIVE-LOCK.)
All other users attempting to access that record (i.e. FIND, FOR EACH,
etc.) will get the following "record locked" message displayed on their
screen:
"Filename is in use by another user. Wait or press ACTION-CANCEL to stop".
where "Filename" is the file that contains the locked record.
When this message is displayed, PROGRESS is waiting for the user to press
ACTION-CANCEL and also waiting for the record to become available. The
user can either wait for the record to become unlocked or abort the
procedure.
A number of options are available to the programmer to code for locked
record conditions, the following are a few examples, consult the PROGRESS
Programming Handbook for more information.
For example:
If user one executes:
FIND Customer WHERE cust-num = 1 EXCLUSIVE-LOCK.
UPDATE Customer.
and user two executes:
FIND Customer WHERE cust-num = 1.
DISPLAY Customer.
User two will see the message:
"Customer is in use by another user. Wait or press ACTION-CANCEL to stop".
If user one completes the UPDATE statement, user two´s FIND will
complete and the newly updated record will be displayed.
NO-ERROR NO-WAIT
----------------
Adding the NO-ERROR NO-WAIT to the FIND statement, as in the following
example, prevents the PROGRESS "record locked" message and returns
control back to the user program.
FIND Customer WHERE cust-num = 1 EXCLUSIVE-LOCK NO-ERROR NO-WAIT.
IF AVAILABLE Customer THEN
UPDATE Customer WITH FRAME Cust-info.
ELSE
DISPLAY "Customer 1 not available".
If Customer record number 1 is locked, the above code will display
"Customer 1 not available" instead of the PROGRESS "record locked"
message.
The amount of time that PROGRESS waits for a record to become available,
is controlled by the CTOS ISAM "SetTransactionParams" API call. The
default time limit is 5 seconds. All ISAM calls that attempt to read
a locked record (ReadNextIsamRecord, ReadISAMRecordByURI, etc.) will
wait the default time of 5 seconds before returning control back
to the caller. This implies, that the NO-WAIT option, is controlled
by this ISAM time limit. In a later release, we will provide a startup
option to allow user control of this time limit.
EXCLUSIVE-LOCK - SHARE-LOCK.
----------------------------
An UPDATE to a record read with the SHARE-LOCK option causes PROGRESS
to attempt to upgrade the lock to exclusive. If the record has
been locked by another user, the following message is displayed:
Filename is in use (Deadlocked). Wait or press ACTION-CANCEL to stop.
where Filename is the file that contains the locked record.
The (Deadlocked) message indicates that PROGRESS will attempt to gain
access to the record 3 times, after which it will automatically abort
the request. (of course, pressing ACTION-CANCEL will abort the request
immediately).
. Embedded FIND statements within FOR EACH loops caused the file associated
with the FIND statement to be opened multiple times and remain open for
the duration of the FOR EACH block.
Example: Customer and State are both CTOS-ISAM files.
FOR EACH Customer:
FIND State of Customer.
END.
In the above example the State file would be opened as many times as
there were customer records in the Customer file, and would remain open
until the termination of the FOR EACH block.
. Attempts to update a record that has been CHANGED are caught and the
following message is displayed: "The record was modified by another
user.". This condition can occur when 2 users are attempting to modify
the same ISAM record. For example:
user 1: FIND FIRST Customer. UPDATE Customer. (leave record on screen).
user 2: FIND FIRST Customer. UPDATE Customer. (change record, press GO).
user 1: change record, press GO. User 1 is attempting to update the
first customer record with an old copy, the message
"The record was modified by another user." is displayed.
. Attempts to update a record that has been DELETED are caught and the
following message is displayed: "CTOS ISAM record deleted by another
user.". This condition can occur when 2 users are attempting to modify
the same ISAM record. For example:
user 1: FIND FIRST Customer. UPDATE Customer. (leave record on screen).
user 2: FIND FIRST Customer. DELETE Customer.
user 1: change record, press GO. User 1 is attempted to update the
first customer record that was deleted by user 2. The message
"CTOS ISAM record deleted by another user." is displayed.
. The CTOS ISAM Dictionary index editor (prodict/bti/bti_idx.p) incorrectly
built the key descriptors for multi-field ISAM keys. This would cause
incorrect results when attempts to find ISAM records using the individual
key field components. For example:
ISAM File: test.Isam, index: CH:5.0.anu
field size
----- ----
1. fld1 CHAR X. key component.
2. fld2 CHAR X(4). key component.
FIND test WHERE fld1 = "B" and fld2 = "0001".
DISPLAY test.
If the file test.Isam contained a record that matched the WHERE clause
it would not be found.
This fix to the index editor, when put in place, will only correct new
ISAM file definitions. To fix existing file definitions use the PROGRESS
dictionary to dump (.df) each file definition to a text file. Edit each
text file and re-order the INDEX-FIELD definitions so they are in the
correct order, then delete and re-load each file definition.
For example, if test.Isam was created before the fix to the index editor,
the .df file would be as follows:
test.df (abbreviated)
-----------------------------
ADD FILE "test" TYPE CTOSISAM
...
FOREIGN-NAME "test.isam"
FOREIGN-SIZE 5
ADD FIELD "fld1" OF "test" AS character
FORMAT "X"
...
FOREIGN-TYPE Char
FOREIGN-SIZE 1
FOREIGN-POS 0
ADD FIELD "fld2" OF "test" AS character
FORMAT "x(4)"
...
FOREIGN-TYPE Char
FOREIGN-SIZE 4
FOREIGN-POS 1
ADD UNIQUE PRIMARY INDEX "inx" ON "test"
INDEX-NUM 0
INDEX-FIELD "fld2" ASCENDING
INDEX-FIELD "fld1" ASCENDING
----------------------------------------
The index definitions; INDEX-FIELD "fld2" and INDEX-FIELD "fld1" are
in the reverse order. You must manually re-order the fields so they
are in the same sequence as the field definitions:
INDEX-FIELD "fld1" ASCENDING
INDEX-FIELD "fld2" ASCENDING
Progress Software Technical Support Note # 9118