FIXES TO DCC/2 1.10, DC FOR DAE 1.10 and 7524 Interface Support 1.0X
--------------------------------------------------------------------
This file catalogs fixes made to DCC/2 1.10 since we shipped on 11-18-94.
DC for DAE 1.10 was shipped 7-7-95. 7524 Interface Support was originally
shipped 2-24-95.
This file also explains how to install the fixes from the DCC110FX.EXE
self-extracting zip file. We have also added a section which describes all
messages that were added to DCC/2r since the initial ship. The last message
documented in our manual is DCX-258. Any messages added after that are
documented below under: DESCRIPTION OF NEW MESSAGES ADDED TO DCC/2r SINCE
INITIAL SHIP.
See the bottom of the file for the date of the last change.
If you have the file DCC110FX.EXE you can either create a diskette from
which to install the fixes or you can expand the self-extracting zip file
on the hard drive in any subdirectory and run the installation from that
subdirectory.
IMPORTANT NOTE 1:
These fixes can only be installed if your PC has been rebooted since you
installed DCC/2 or DC for DAE 1.10 . The installation makes use of some
environment variables that are defined by CONFIG.SYS.
IMPORTANT NOTE 2:
Since this fix package also contains fixes to 7524 Interface Support you must
apply the fixes after 7524 Interface Support is installed (if you are using
that product). Therefore in the situation where you had already installed
DCC/2 1.10 and had applied the fix package and later you installed 7524
Interface Support, you will need to reapply the fix package so that both
DCC/2 and 7524 Interface Support are at the same level.
EXPANDING AND INSTALLING FROM THE HARD DRIVE
--------------------------------------------
To expand and install DCC110FX.EXE from somewhere on your hard drive,
perform the following steps:
1) Create or choose an empty directory anywhere on your harddrive. For
example: C:\TEMP
2) Copy or download DCC110FX.EXE to that directory
3) Make sure that directory is the current directory and then run the
executable by typing:
DCC110FX
This will expand all the files into the current directory.
4) To install the fixes, first make sure none of the components of DCC/2
(or DC for DAE) are running and that the current directory is the one
containing the expanded contents of the DCC110FX executable. Issue the
following command:
INSTALL
5) Continue with the section below marked: SPECIAL INSTALLATION INSTRUCTIONS.
EXPANDING AND INSTALLING USING DISKETTES
----------------------------------------
The files in DCC110FX.EXE self-extracting exectuable, cannot fit on a single
diskette. The necessary diskettes can be created using the command file,
MAKEDSKS.CMD, which is part of DCC110FX.EXE. Perform the following steps:
1) Create or choose an empty directory anywhere on your harddrive. For
example: C:\TEMP
2) Copy or download DCC110FX.EXE to that directory
3) Make sure that directory is the current directory and then run the
executable by typing:
DCC110FX
This will expand all the files into the current directory.
4) To create the diskettes, first get two completely blank, formatted 1.44
3.5 in. diskettes. Then run the following command file from the current
directory:
MAKEDSKS
This will prompt you for each diskette and copy the appropriate files to
each.
5) To install the fixes contained on the fix diskettes, first make sure none
of the components of DCC/2 (or DC for DAE) are running and make sure the
first fix diskette is in drive A: Issue the following command:
A:\INSTALL
Additional diskettes will be prompted for as needed. (Of course drive B:
could be used for installation as well).
SPECIAL INSTALLATION INSTRUCTIONS
---------------------------------
Running INSTALL will copy all files to the proper locations. There is one
file, ARTIC.ISF, which should be copied on to the first installation diskette
as well. See the problem for 1/15/95 described below.
Another file BT.ISF should be copied to the third installation diskette
(contains the buildtime files). See the problem for 2/8/95 described
below.
DESCRIPTION OF NEW MESSAGES ADDED TO DCC/2r SINCE INITIAL SHIP
--------------------------------------------------------------
Following is documentation regarding all DCC/2 messages that do not yet
appear in the 32-bit runtime manual. Some of these messages are actually
generated by 7524 Interface support. The messages covered are DCX-258
through DCX-269 with the exception of DCX-260 and DCX-264 which are internal
messages that you should never receive.
----------------------------------------------------------------------------
Message: DCX-258: Trying complete download for terminal 'name' because
partial download was not successful.
Description: This message applies to 7526 terminals which have received a
request to load a CFR or one or more validation files. If any
of the files to be loaded are larger than the terminal's
current version of that file, the terminal will not allow the
file to be loaded by itself. To get around this, DCC/2r
automatically retries the download, but this time loads the
entire job to the terminal. The 7526 terminal will accept the
larger file if all other files in the terminal are first erased
and are then reloaded to it.
Action: No action necessary - informational message only.
----------------------------------------------------------------------------
Message: DCX-259: In file 'filename', invalid terminal definition for
'terminal name'; 7524 terminals can only be on RF serial port.
Description: In the DCC/2r configuration file, it was found that either a
terminal was defined to be of type 7524 and was assigned to a
line other than the RF serial port - or a terminal was defined
to be of a type other than 7524 and it was assigned to the RF
serial port. The only communications line a 7524 terminal can
be assigned to is the RF serial port. Likewise, the RF serial
port can only have 7524 terminals assigned to it.
Note: 7524 terminals must use 7527 type jobs because there is
currently no ability to create jobs specifically for the 7524.
Action: Correct either the terminal type or the line assignment.
----------------------------------------------------------------------------
Message: DCX-261: Received unexpected data from RF terminal 'name',
length is 'nn': 'data...'
Description: This message indicates that DCC/2 received a response to a
message that it was not waiting for at the time. This can
happen in the following scenario:
1) Assume the timeout for the RF serial port is set to 10
seconds
2) DCC/2 sends a command to an RF terminal
3) Due to slow RF communications, it takes longer than 10
seconds for the command to get to the terminal.
4) After 10 seconds, DCC/2 times out waiting for the response
and moves on to a command for another terminal
5) After another second (total of 11) the terminal receives
the command and responds to it
6) DCC/2 receives the terminal's response, but it is no longer
waiting for it and thus considers it unexpected.
In UHF systems, temporary slowdowns can occur when the call
sign is broadcast by the base. This occurs every 15 minutes
and could last anywhere from 3 to 30 seconds.
In UHF and SST systems, heavy RF traffic can slow down the
response times. See the actions below for several ways to
improve response times.
Another scenario that can result in unexpected data at DCC/2 is
when a terminal is moved out of range of the nearest base or is
powered off. If any command is issued by DCC/2 to this
terminal during this time, it is very likely that DCC/2 will
time out waiting for the response to that command. The RF
controller, however, buffers commands that are destined for
terminals that are currently powered off or are out of range.
When the terminal is eventually powered on or comes back into
range, the buffered messages are sent to the terminal which
will respond to those messages. As a result, DCC/2 may receive
responses to messages that it had issued and timed out on
minutes or even hours before.
Action: If this message occurs very infrequently, it can be ignored.
Otherwise there are several ways you can improve the
performance of the RF network:
- Using the Setup notebook, make sure the timeout for the RF
serial port is set to at least 10 seconds (100 x 0.1 secs).
- Make sure you have installed at least level 1.08 (November
1995) of the fixes for DCC/2 1.10 32-bit runtime (those fixes
also include fixes for 7524 Interface Support). Version 1.1
of 7524 Interface Support includes all fixes from the
November 1995 package as well.
- Make sure the level of 7524 ETS in the terminal is at least
1.01 (October 1995).
- In the 7524 terminal's configuration, there is a parameter
called the RF POWER TIMER which should be set to at least 60
seconds. This timer determines how long the terminal will
maintain power to its RF receiver so that it can hear
messages sent from DCC/2. Once the timer expires, the
terminal goes into a cycle where the power to the RF receiver
is on for 2 seconds and off for 8 seconds. Whenever a
message is received, the timer is restarted and (if set to
60) the terminal will keep the power on for 60 more seconds
before going into the 2 on/8 off cycle.
If the timer value is set to low, it will take much longer
for terminals to respond to DCC/2 if they are caught in the 8
second off period of the on/off cycle. This is especially
apparent during downloads to many terminals.
- In UHF systems, in the RF Controller under the configuration
for the COMx ports, there is a parameter called MAX RTC
SLOTS. This parameter can be tuned for maximum performance
by observing the Heart Beat monitor on the 7524-301
controller's display panel (listed underneath HB on the
display). Observe the maximum value shown during typical
operation and set the MAX RTC SLOTS to this value.
Setting the value too high will result in lower response time
to active terminals as inactive terminals are given a time
slot in which to communicate. Setting the value too low will
result in excessive collisions of terminal communications
back to the bases.
If you have 15 or more terminals in use, this value should
probably be set to the maximum of 20.
- Leaving the controller showing the screen which asks
VIEW CONFIGURATION? can also improve performance. When
on the screens which show terminal/base status, the
controller must use processing power to update the screen
with the current status.
- We have found that when downloading many RF terminals, it is
best to do a few at a time rather than all at once. This can
be accomplished by setting the LOAD_MAX parameter in the
\DCC2R\DATA\EXTRA.CFG file to 3 or 4. This allows you to
issue downloads to a whole group of terminals at once and
have DCC/2 dispatch those downloads 3 or 4 at a time.
----------------------------------------------------------------------------
Message: DCX-262: Received transaction before previous one was released
for RF terminal 'name': 'transaction . . .'
Description: Indicates that 7524 Interface Support received a transaction
from a particular terminal and before DCC/2 had a chance to
log the transaction and release it, the terminal sent the
transaction again.
In the RF environment, terminals are not polled for
transactions. Rather, the terminals send transactions one at
a time or when told explicitly to resend the oldest
transaction. Whenever a 'start poll' command is issued by
DCC/2 to a terminal, 7524 Interface Support interprets that
as a "you can send me transactions now" command to the
terminal. When this command is given to a terminal, that
terminal will automatically send the first transaction in its
buffer - even if it had just sent it.
Another scenario that can cause this message is if a terminal
is going in and out of range of the nearest base. Each time
the terminal looses communications with the base and regains
it, it sends a message to DCC/2 indicating it is back in
range again. In response to this, DCC/2 sends the "you can
send me transaction now" command if that terminal is allowed
to send transactions. This in turn causes the terminal to
send the oldest transaction it has. So a terminal that is on
the edge of coverage could resend the same transaction several
times.
A terminal with a low battery could show these same symptoms
as it tries to maintain enough power for its RF transmitter
and receiver.
Action: For the most part this message can be ignored. It probably
indicates a terminal has been on the edge of coverage or has
a low battery. But if those problems are corrected and the
message continues to occur frequently, it could be an
indication of other problems in the RF communications: poor
signal, interference, ...
Receiving this message is akin to receiving a duplicate
transaction message; no data is lost and DCC/2 does not store
the same transaction more than once.
----------------------------------------------------------------------------
Message: DCX-263: The RF_UHF_OR_SST parameter must be either UHF or
SST; default of SST is being used
Description: In the EXTRA.CFG configuration file, there is a parameter
called RF_UHF_OR_SST which is used for defining whether your
RF system is UHF or SST.
The value to the right of the equal sign must be either UHF
or SST. This error was logged because the value was neither
of the valid values. DCC/2r and 7524 Interface Support
continued their start up using the default setting of SST
rather than shutting down because of the error.
Action: Use any text editor to edit the EXTRA.CFG file, which is
located in the \DCC2R\DATA directory, and change the value to
the right of the equal sign to be one of UHF or SST. The line
containing this parameter can also be removed from the file if
the default setting is acceptable.
----------------------------------------------------------------------------
Message: DCX-265: Shutting down RF network; it may take 15 or 20
seconds...
Description: DCC/2r issues this message when it is being shutdown and it
finds that RF terminals have been configured and it therefore
will need to shut down 7524 Interface Support. Part of 7524
Interface Support takes 15 to 20 seconds to shutdown - even
after the rest of DCC/2r has shutdown. You don't always see
this message because often the DCC/2r message logger has shut
itself down before this message can be issued. But even in
this case it may take another 15 or 20 seconds for 7524
Interface Support to completely shut down.
The best way to tell when 7524 Interface Support is completely
shut down is to look for the OS/2 window containing the
program DCXCPOS2.EXE. If that window still exists, 7524
Interface Support which is started as a child of DCC/2r, is
not yet completely shutdown. The Operate notebook will
actually show that DCC/2r is shutdown - which is in fact
true - during the 15 or 20 seconds that 7524 Interface
Support is finishing up its shut down.
Action: No action necessary - informational message only.
----------------------------------------------------------------------------
Message: DCX-266: The SLOW_POLL_CYCLE parameter must be (1 - 255)
minutes; default of 1 is being used
Description: In the EXTRA.CFG configuration file, there is a parameter
called SLOW_POLL_CYCLE which is used for specifying how
frequently DCC/2r will poll terminals that have not been
responding. This parameter is also used by 7524 Interface
Support to determine how often that program will send an
"are-you-there" query to terminal that are expected to be
responding but which have not sent any transactions or had
any other communications since the last query.
The value to the right of the equal sign must be in the range
of 1 to 255 indicating a number of minutes. This error was
logged because the value was not in this range. DCC/2r and
7524 Interface Support continued their start up using the
default value of 1 minute rather than shutting down because
of the error.
Action: Use any text editor to edit the EXTRA.CFG file, which is
located in the \DCC2R\DATA directory, and change the value
to the right of the equal sign to be in the range 1 to 255.
The line containing this parameter can also be removed from
the file if the default setting is acceptable.
----------------------------------------------------------------------------
Message: DCX-267: The RF_ENHANCED_POLL parameter must be 0 or 1;
default of 0 is being used
Description: In the EXTRA.CFG configuration file, there is a parameter
called RF_ENHANCED_POLL which is used for specifying the kind
of polling that 7524 Interface Support will use between itself
and the 7524 RF controller. We added the ability to set this
parameter in the EXTRA.CFG file and then later found that
communications rarely works with the setting of 1. So in
effect this parameter should really be removed from the file
or always be set to 0.
The value to the right of the equal sign must be either 0 or
1. This error was logged because the value was neither of
these. DCC/2r and 7524 Interface Support continued their
start up using the default value of 0 rather than shutting
down because of the error.
Action: Use any text editor to edit the EXTRA.CFG file, which is
located in the \DCC2R\DATA directory, and change the value to
the right of the equal sign to be 0 or remove the line
containing this parameter from the file.
----------------------------------------------------------------------------
Message: DCX-268: Command exceeds max length: 'nn' in program 'name'
in file 'filename'
Description: When trying to retrieve information from the specified
transaction program in the specified transaction program
file, DCC/2r found a program command that exceeds the maximum
length indicated in the message. Due to internal buffer
sizes, DCC/2r can only accommodate the size mentioned which
should be sufficient for any program. If indeed the data is
valid, the DCC/2r maximum may need to be increased.
However, if this program has successfully been downloaded or
accessed in the past, the file may have been corrupted.
Action: If you suspect the file has been corrupted and you have a
backup of it, restore the program file from the backup and
retry the operation.
If you do not have a backup, use the DCC/2r Migration
Facility to migrate the specified program file.
If the problem persists, contact your support group.
----------------------------------------------------------------------------
Message: DCX-269: Creating new message log for 'nn' records . . .
Description: When the DCC/2 message logger starts up, it looks for an
existing message log and, if found, makes sure it has valid
pointers in it. If the message log is not found or the
pointers are not valid, a new message log is created and
this message is issued indicating how many records it will be
able to hold.
Action: No action necessary - informational message only.
----------------------------------------------------------------------------
CHRONOLOGICAL SUMMARY OF FIXES/CHANGES
--------------------------------------
11-23-94: If any terminal name contains a hyphen, whenever the Setup or
Operate notebooks are started a warning pop-up is displayed stating
that an invalid terminal name was assigned to a particular group - the
name specified is the portion of the name following the hyphen from the
name that contains the hyphen.
This is a harmless warning - no data is lost or changed as a result of
this problem.
Fixed files: \DCC2R\BIN\SETUP.EXE
\DCC2R\BIN\OPERATE.EXE
11-23-94: If the list of terminals assigned to a group exceeded 256
characters - including the key word " GROUP_TERMINALS=" the Setup
notebook would trap when trying to save the file. The configuration
file could be corrupted or incomplete as a result.
As a work around, create several different groups with smaller numbers
of terminals - all using the same transaction IDs - and assign them to
the same export.
Fixed file: \DCC2R\BIN\SETUP.EXE
11-23-94: If a save resulted in warnings being shown and then the problems
were corrected, the next save would show a blank verification pop-up.
No data is lost or changed as a result of this problem.
Fixed file: \DCC2R\BIN\SETUP.EXE
12-1-94: On the Communications page of the Operate notebook, if an RF
terminal was selected, any selected terminals below that RF terminal
in the list would not be monitored. This was fixed. This page now
also preserves its position in the list when switching away from the
page and back again.
Fixed file: \DCC2R\BIN\OPERATE.EXE
12-1-94: The Communications Monitor program has pop-ups for all of the
different kinds of commands that can be sent between terminal and PC.
Some of these commands have blocks of data that are shown on the
pop-ups. All characters in those blocks of data that have ASCII
values less than or equal to 32 or greater than 127 are shown in
hex enclosed in angle brackets. (Before they were shown in decimal and
the range was only less than 32.)
Changed file: \DCC2R\BIN\DCXMON.EXE
12-15-94: The PGM.CMD file used for migrating DCC/2 .PGM files to the
32-bit .PGM file format did not migrate the comments properly. The
word 'Data' followed by blanks was being substituted for the comment
text that was in the original DCC/2 .PGM file.
Since the comment text is not downloaded to terminals, this does not
cause any immediate problems. However, whenever a 32-bit buildtime is
implemented it would not have had the proper comments in the .PGM file.
Changed file: \DCC2R\BIN\PGM.CMD
1-5-95: Fix for APAR PN65771 involving the 16-bit runtime. Occasionally,
duplicate Interactive transactions from 7526 terminals would not be
filtered out of the DCC/2 logfile. A program logic error was found
and corrected.
Changed file: \DCC\DCCTREXE.EXE
1-5-95: Fix for APAR PN64808 involving the Buildtime files. If the System
Monospaced font was unavailable, the Transaction Program Editor and Terminal
Configuration Editor would silently exit (really, a divide by zero problem
caught by the C runtime system, but masked by PM.) The fixes cause the
programs to display an error message, and exit if they are unable to load
the required font.
Changed files: \DCC\DCCPRGRC.DLL
\DCC\DCCTCFRC.DLL
\DCC\DCCTDFC.EXE
\DCC\DCCTDFP.EXE
1-15-95: The ARTIC installation did not put the ICA*.MSG files in the
right place. They were put in the \DCC2R\BIN directory and they
should have been put in the root directory of the OS/2 drive.
When these fixes have been applied, the file ARTIC.ISF should be
copied from the \DCC2R directory to the first diskette for DCC/2 1.10
(or DC for DAE 1.10).
Changed file: \DCC2R\ARTIC.ISF (also on diskette 1 as A:\ARTIC.ISF)
\DCC\ARTIC.ISF (same as above)
1-18-95: 7526 terminals downloaded by the 32-bit runtime would generate
hot-key-like transactions for all keys that were supposed to have no
program assigned. This is actually also a problem in the 7526
microcode but has been corrected by a change to the 32-bit runtime.
Previously a simple record separator character was downloaded for all
empty programs. Now :9 (which is a no-op to the terminal) is downloaded
followed by the record separator.
Changed file: \DCC2R\BIN\DCXCPOS2.EXE
1-23-95: A couple of changes were made to the 32-bit runtime to accommodate
the future release of the 7524 Interface Support program. These include:
- Allowing the port task to send an unsolicited request to say a terminal
is now responding. This allows RF terminals to be recognized as soon
as they are powered on.
- Fixed a trap that would occur if a start polling command was issued
to an RF terminal and no RF terminal had yet been powered on since
DCC/2 was started (which means NUI_SERV.EXE was not yet started).
Changed files: \DCC2R\BIN\D2XNSUGW.EXE
\DCC2R\BIN\DCXRSUGW.EXE
1-26-95: Fixed trap in MIGRATE.EXE that would occur if DCX2.INI does not
exist - trap occurred in attempt to display appropriate error message.
Also fixed problem where switch from Program to Val or Cluster and back
when Name was selected for Partial Configuration would not cause the
list box to be properly updated.
The default partial configuration option is now Programs.
Changed file: \DCC2R\BIN\MIGRATE.EXE
1-26-95: In Setup notebook on terminals page if changes were made and then
saved, choosing Exit would give pop-up stating changes would be lost if
Exit were completed.
Changed file: \DCC2R\BIN\SETUP.EXE
1-30-95: In the Monitor the data that is displayed for load commands now
is displayed 40 characters per line.
Changed file: \DCC2R\BIN\DCXMON.EXE
2-4-95: Fixed problem where downloads to 7526 terminals would not allow
messages greater than 40 bytes in length. That has been increased to
128 bytes in length. This problem was APAR number PN67735.
Also made more changes to accommodate the future release of 7524
Interface Support. These include increasing the maximum amount of data
that can be loaded to a 7524 terminal in one message to the terminal.
This is now 470 bytes or so. It also includes changes to allow
7524 terminals not to be slow polled.
Changed files: \DCC2R\BIN\DCXCPOS2.EXE
\DCC2R\BIN\D2XNSUGW.EXE
\DCC2R\BIN\DCXRSUGW.EXE
2-5-95: Fixed Trap in the Monitor program that would result if you tried
to look at the details of an interactive response that was sent to a
terminal.
Changed file: \DCC2R\BIN\DCXMON.EXE
2-8-95: The Buildtime Modules installation did not create the .\VAL, .\CFR
or the .\GPH directories. The affected file BT.ISF resides only on
diskette - diskette 3. It must be copied there before running the
buildtime installation.
If the buildtime has already been installed, then running the
installation for these fixes, as described at the top of this file, will
automatically create these directories.
Changed file: A:\BT.ISF (On diskette 3)
2-8-95: Fixed potential trap if invalid transactions are received
from terminals. In an attempt to log a message that would show
the bad transaction, the code would cause a trap if the length
was too long. This problem had to do with the size of the
variable used to store the length. The size of that variable
was changed to fix the problem. Because the routine which logs
messages is used in more than one module of DCC/2, the fix
affects more than one executable.
Also increased the wait for a terminal response to a given
download command to 60 seconds from 30 seconds. This accommodates
the RF network where longer timeouts are used on the line.
Changed files: \DCC2R\BIN\DCXCPOS2.EXE
\DCC2R\BIN\DCXIAPI.EXE
2-9-95: Minor problems fixed - affecting only RF network code.
When terminal is identified, two start poll messages were sent
to the port task from the gateway. In the RF environment this
caused a terminal without any files to request two downloads -
one for each message and so DCC/2 would start one and queue
the other. The terminal would thus be downloaded a second
time unnecessarily. Also when RF terminals went into
not-responding state one slow poll was sent to these terminals
for the next interval; none should have been sent because
they are RF terminals.
Changed files: \DCC2R\BIN\DCXRSUGW.EXE
\DCC2R\BIN\D2XNSUGW.EXE
2-14-95: Fixed spelling error in the job migration command file.
Changed file: \DCC2R\BIN\JOB.CMD
2-20-95: Change made to gateway task which cuts time in half that was
spent waiting for a start download request to fail when it was sent
to a non-responding terminal. This change affects all but the 7527
terminal. This change has the biggest effect for RF terminals whose
command response timeouts are usually much longer than the other
terminals.
Also made change to prevent the A0X command from actually being sent
to RF terminals when the terminals are being put in the not-responding
state.
Changed files: \DCC2R\BIN\DCXRSUGW.EXE
\DCC2R\BIN\D2XNSUGW.EXE
2-20-95: Change made to download tasks to set their command timeout
based on the timeout configured for the communications line to which
the downloading terminal is attached. This is most useful in the RF
environment where longer communications timeouts are used.
Changed file: \DCC2R\BIN\DCXCPOS2.EXE
2-21-95: The DCC/2r slow polling rate is now configurable via the EXTRA.CFG
file. A new parameter called SLOW_POLL_RATE can be added to the EXTRA.CFG
file that is located in the \DCC2R\DATA directory. The valid values are
1 to 255 minutes. The default is:
SLOW_POLL_RATE = 1
See the sample EXTRA.CFG file on the PTF diskette for more details. This
file is not copied during installation of the other PTF files so as to
preserve any existing parameters in the 'live' file.
Changed files: \DCC2R\BIN\DCXCPOS2.EXE
\DCC2R\BIN\DCXRSUGW.EXE
\DCC2R\BIN\D2XNSUGW.EXE
\DCC2R\BIN\DCXRPO.EXE
\DCC2R\BIN\D2XNPO.EXE
\DCC2R\DATA\DSKMGFIL.TXT
2-22-95: DCCDMIS.EXE does not start up properly if configured as an
application to be started from the 32-bit runtime. DMIS generates
a 1123 error indicating a database error. The problem is that it
cannot find DCCDM.BND. DCCDMIS requires that DCCDM.BND be in the
current directory when it is started.
Note: DC for DAE 1.10 already incorporates the fix for this problem.
DCCDM.BND is located in the \DCC directory (or whatever directory the
environment variable DCCROOT indicates); however, applications
started by the 32-bit runtime are started such that the current directory
is the OS/2 root directory. So to fix the problem, the DCCDM.BND
file must be copied to the OS/2 root directory. The installation script
file for DMIS, DMIS.ISF, has been changed to do this.
If you have already installed the DMIS component, you can simply copy
the file \DCC\DCCDM.BND to the root directory of the drive on which OS/2
is installed. Or you can run the installation again after copying the
new DMIS.ISF file to the 4th installation diskette for DCC/2 1.10.
Changed file: A:\DMIS.ISF (On diskette 4 of DCC/2 1.10)
2-27-95: Increased the communications line timeout range to 255 times 0.1
seconds. Previous maximum was 100. Change was made for RF environment
where longer timeouts are necessary.
Changed file: \DCC2R\BIN\SETUP.EXE
2-28-95: Fixed bug in migration which caused the same validation file to
be downloaded twice if it was used for fast-clocking and in any
transaction program. The migration program did not properly set up the
list of validation files to be downloaded; it listed the fast-clocking
validation file twice.
Changed file: \DCC2R\BIN\JOB.CMD
3-16-95: Increased the timeout for a start port command from 30 seconds to
60 seconds. This was done to handle RF ports which could have a very
large timeout.
Changed file: \DCC2R\BIN\DCXCPOS2.EXE
3-23-95: Added support for a new API that can set more than one user
variable at a time. The 32-bit version is called DcxSetNTermUserVariables
and the 16-bit version is called DccSetNTermUserVariables. This API can
only be used with the 32-bit runtime - although the application can be
16 or 32 bit.
This API was added primarily for support of 7524 RF terminals where
communications is generally slower than fixed terminals. However, it
can be used for all terminal types which can have user variables set
(all but the 7525). DCC/2 automatically figures out what the
appropriate command is to send to the terminal.
There is no limit to the number of user variables that you can
specify to be set by this API. However, DCC/2 does need to break
up the list into chunks of approximately 450 bytes of data to be
handled at one time. So if all of the data for the variables to
be set - including 3 bytes for each user variable number - fit
into that 450 bytes, those user variables will all be set
consecutively down at the terminal - before any command to any
other terminal is handled. This will make the processing faster
than before where for each user variable the data had to be
passed up and down from the API level to the terminal level and
back.
The format for the new 32-bit API is:
short LINKAGE DcxSetNTermUserVariables(PSZ termname, HTERM acquire,
USHORT numvars, USHORT * vars, PSZ * vartext);
where:
'termname' is the same as for DcxSetTermUserVariable
'acquire' is the same as for DcxSetTermUserVariable
'numvars' is the number of user variables that are to be set.
Space should be allocated for the 'vars' and 'vartext'
arrays greater than or equal to that necessary for the
number of variables specified by the numvars parameter.
'vars' is an array containing the list of user variables to be set.
The order in which the numbers appear in this array is the
order in which they will be set.
The valid values in this array are 10 through 19 for the
7527 and 7524 terminals or 1 through 999 for 7526 terminals.
'vartext' is an array containing pointers to null-terminated strings
that the corresponding user variables, specified in 'vars',
should be set to. For example, the user variable specified
in vars[0] will be set to the string pointed to by vartext[0].
The maximum length of the string is 118 bytes for all terminal
types. If a user variable is to be cleared, a pointer to a
NULL string ("") should be put in the proper element of the
vartext array. Do not use NULL as the pointer itself.
Refer to the explanation DccSetTermUserVariable API for
additional information about how to include special characters
in the user variable string.
This is found in the new \DCC2R\TOOLKIT\DCX.H provided in this fix package.
The format for the new 16-bit API for use with 16-bit compilers is:
USHORT EXPENTRY DccSetNTermUserVariables(PSZ termname, USHORT numvars,
USHORT * vars, PSZ * vartext);
This is found in the new \DCC2R\TOOLKIT\DCC2.H provided in this fix package.
The format for the new 16-bit API for use with 32-bit compilers is:
USHORT EXPENTRY DccSetNTermUserVariables(PSZ termname, USHORT numvars,
USHORT * _Seg16 vars, PSZ _Seg16 * _Seg16 vartext);
This is found in the new \DCC2R\TOOLKIT\DCC2386.H provided in this fix
package.
For 32-bit applications, you must link to the new \DCC2R\TOOLKIT\DCX.LIB
provided with this package. For 16-bit applications, you must link to the
new \DCC2R\TOOLKIT\DCC2.LIB in order to use the new API. A new DLL file
called DCCNEW.DLL will be added to both \DCC\DLL (for 16-bit) and to
\DCC2R\TOOLKIT. This DLL is if you are using the 16-bit APIs. An updated
\DCC2R\TOOLKIT\DCX.LIB containing the 32-bit APIs is also provided.
As mentioned above, this new API is available only if you are using the
32-bit runtime - although both 16-bit and 32-bit applications can used it.
However, if you have included this API in a program you have written, you
can still run that application with the 16-bit runtime - provided the API
is never called for the 16-bit application. To explain this better, I'll
mention what probably will happen with our HISS/2 (or DBITS/2) products.
HISS/2 will probably have a new command that can be called to set a
group of user variables at once. The new HISS/2 code will therefore
have to include this API call. That API will only be called if the new
command is included in a HISS script. In that case, that HISS script
could only be used when the 32-bit runtime is being used. But if the
HISS script does not include the new command, then that HISS script
could be used with either the 16-bit or 32-bit runtimes.
If the you are running the 16-bit runtime and this new API is issued, the
return code will be DCC_NOT_RUNNING - provided the dll file DCCNEW.DLL is
in the LIBPATH. If that new dll is not in the LIBPATH, then you won't be
able to start the program containing the API call.
Changed files: \DCC2R\BIN\DCXCPOS2.EXE
\DCC2R\BIN\DCXRSUGW.EXE
\DCC2R\BIN\D2XNSUGW.EXE
\DCC2R\BIN\DCXMON.EXE
\DCC2R\TOOLKIT\DCX.LIB
\DCC2R\TOOLKIT\DCX.H
\DCC2R\TOOLKIT\DCX.DLL
\DCC2R\TOOLKIT\DCC2.LIB (this is new)
\DCC2R\TOOLKIT\DCC2.H (this is new)
\DCC2R\TOOLKIT\DCC2386.H (this is new)
\DCC2R\TOOLKIT\DCXNEW.DLL (this is new)
3-24-95: Several fixes made to 7524 Interface Support. Fixed trap that
occurred if a message of length 2 was received. Fixed another trap if
a message greater than 500 bytes was received. Fixed problem relating
to handling of a DC2 message sent by a 7524 when that terminal lost and
regained the carrier.
Also added a command line switch which can be turned on to show all
communications which are occurring at the DCC/2 level on the RF network.
By running NUI_CFG from the \DCC2R\BIN directory and changing the
defined application from '~\dcxrfos2.exe xCON' to '~dcxrfos2.exe xCON 1'
you can specify that the output be printed. Changing the 'CON' in the
first parameter to a file name will cause the output to be logged in
that file instead of the screen.
Changed file: \DCC2R\BIN\DCXRFOS2.EXE
3-24-95: Minor changes made to communications code to handle timeout
situations better. In one case if status response was not received in
time the data from the previous command was being used for the status
data and thus was improper interpretations could be made as to whether
a terminal had transactions in it to be flushed. Also made change to
retry status if the response that came back was not the valid 12 byte
status string. Previously it just returned an error. Now an error
will only be returned after a certain number of retries that fail.
Both of these changes are minor. The problems only showed up with
7524 terminals when the timeout was very low for the RF serial port.
Changed files: \DCC2R\BIN\DCXRSUGW.EXE
\DCC2R\BIN\D2XNSUGW.EXE
3-28-95: Fixed problem where closing the password entry window acted as
if a valid password had been entered.
Changed files: \DCC2R\TOOLKIT\DCC2PWRD.DLL
4-4-95: Fixed problem with new API DccSetNTermUserVariables. Previous
version worked OK if you used a 32-bit compiler and DCC2386.H. However,
using a 16-bit compiler, the API call trapped. The prototype for this
API has been changed in DCC2386.H to be:
USHORT EXPENTRY DccSetNTermUserVariables(PSZ termname, USHORT numvars,
USHORT * _Seg16 vars, PSZ _Seg16 * _Seg16 vartext);
The difference is that '_Seg16' was added after the 'PSZ' and before '*'
for the parameter 'vartext'. This change in turn requires that when using
a 32-bit compiler, the array of pointers to strings must be an array of
16-bit pointers. For example, the following array 'vartext' can be passed
to the API:
PSZ _Seg16 vartext[3] = { "Var1", "Var2", "Var3" };
NOTE:
If using a 32-bit compiler with the 32-bit API (DcxSetNTermUserVariables),
nothing has changed; you would not include the '_Seg16' shown above.
Changed files: \DCC2R\TOOLKIT\DCCNEW.DLL
\DCC2R\TOOLKIT\DCC2.LIB
\DCC2R\TOOLKIT\DCC2386.H
4-4-95: Regarding the new API, DccSetNTermUserVariables: If this API is
included in a DCC/2 application that should be able to run with both the
16-bit and 32-bit runtimes, then a couple of things must be done:
- Even though the API is in the program, it should only be called if the
32-bit runtime is in use. If the 16-bit runtime is currently being used
and this API is called, the return code will indicate (DCC_NOT_RUNNING) -
provided the following item is done.
- If the 32-bit runtime has not been installed, you must copy the following
files to the \DCC\DLL directory:
DCX.DLL
DCCNEW.DLL
If you do not copy these files, and you try to run your application,
OS/2 will give you an error saying it couldn't find one or both of
these files.
4-4-95: The CFRAPI24.LIB provided with 7524 Interface Support does not work
properly with the IBM C/2 linker - a message about an invalid object
module is generated. This library does work fine with the Microsoft
linker. The problem was that the object file in the library was built
with the Microsoft 8.0 compiler and so the IBM C/2 linker didn't understand
the format.
A new CFRAPI24.LIB is in the route directory of the fix diskette. This
was built with the IBM C/2 compiler.
By the way, valid compile options for building a 7524 CFR are:
-c -nologo -ALw -Zpe -Ox -G1s -W3 -Zp1
and valid link options are:
/NOI /DO /NOD /DO
Changed file: A:\CFRAPI24.LIB
4-7-95: We found that if you install the 32-bit Runtime and the Buildtime
Modules - but do not install the 16-bit Runtime, there is one DLL file
that is not copied from diskette: DCCRC.DLL. This file is on the
diskette in the self-extracting zip file RT16ALL.EXE but it should
be in ALLALL.EXE so that it is installed both when the 16-bit runtime
is installed and when the Buildtime Modules are installed.
To get this file after installing the Buildtime Modules, just run the
installation for these fixes as described at the top of this file.
This of course does not fix the original installation diskettes themselves.
But if you want to patch your current set of diskettes, you can do the
following:
1) Copy the BT.ISF file from this set of fixes to diskette 3. See the
problem about BT.ISF described above for 2-8-95.
2) Copy \DCC\DLL\DCCRC.DLL to diskette 3 (A:\DCCRC.DLL).
3) Edit the BT.ISF file on diskette 3 and make the following change:
Line 93 should currently be the following:
RUNPROGRAM %SRCDRIVE%\dcc2help.exe "-o %OS2DRIVE%\OS2\HELP"
Keep that line there and add the following line after it:
COPYFILE %SRCDRIVE%\dccrc.dll %INSTROOT%\dll\dccrc.dll
Once these changes have been made, installation of the Buildtime Modules
should work properly.
Changed file: \DCC\DLL\DCCRC.DLL was not installed
4-7-95: Fixed problem where address 0 on any communications line was showing
up as address Z on the Terminals and Communications page of the Operate
notebook.
Changed file: \DCC2R\BIN\OPERATE.EXE
4-11-95: Fixed problem where DCC/2r download process would flag an error if
it encountered a transaction program command it did not know about (not
known by DCC/2, Data Collector or DC/X). Customer reported ;7 (APNDSTR)
was being rejected. Changed the code to accept any command it did not
know about provided it started with a ; or :
Changed file: \DCC2R\BIN\DCXCPOS2.EXE
4-11-95: Minor change to Setup notebook to smooth out the update of the
transaction window of the Groups page.
Changed file: \DCC2R\BIN\SETUP.EXE
4-11-95: Found out that 7524 Interface Support was not verifying the
checksums of transactions received from RF terminals. Responses to
commands were verified, but transactions were not. So if a byte was
dropped in the transmission, the transaction would be passed through
to DCC/2 without a complaint by 7524 IS. DCC/2 might eventually complain
if the byte was lost in the date/time stamp or sequence number.
The checksum verification for transactions has been added. If the checksum
fails, the transaction is NAKed - which will cause the terminal to
retransmit it.
Changed file: \DCC2R\BIN\DCXRFOS2.EXE
4-11-95: APAR PN69854, 7527 ETS: File A was not correctly mapping shift chars
File A (keyboard remap file) was not correctly mapping shifted
characters. The ETS file manager was incompletely handling the
conversion from byte to word per entry. This caused data in the second
packet to partially overwrite data from the first packet, thus corrupting
the table. Also, the location of file A was subject to change as other
files changed size. Because the 7527 BIOS stores a pointer to custom
keyboard mappiong tables, movement of the table, without updating the
BIOS, would likely have resulted in a completely useless keyboard. This
has been changed to store the remap table in a static array within ETS.
Changed files: ETS7527.EXE
ETS7527.MAP
This fix is no longer available in this fix package due to royalty
implications. Request a free upgrade to release 1.03 of 7527 Extended
Terminal Services through your normal ordering channel.
4-13-95: Discovered that running through steps in Chapter 5, Getting Started
of the 32-bit Runtime User's Guide result in the DCC/2 Configuration
Editor complaining about changes in the validation files directory.
The problem is that when COPYSAMP.CMD is run, it creates a DCC.INI file
that specifies that D2R_SAMP.VAL is part of each cluster, however that
validation file is not created by COPYSAMP.CMD. The DCC/2 Configuration
Editor issues a warning when it cannot find a validation file that is
referenced by a cluster.
To eliminate the warning, you can use the DCC/2 Validation Editor to create
D2R_SAMP.VAL.
8-30-95: The installation of fixes will now create/update the following
files so that COPYSAMP.CMD will set up the validation file properly.
Changed files: \DCC2R\SAMPLES\COPYSAMP.CMD
\DCC2R\SAMPLES\D2R_SAMP.VSM
4-13-95: Added ability to handle new parameter in \DCC2R\DATA\EXTRA.CFG
file. It is called RF_ENHANCED_POLL and it can be set to 0 or 1. This
is for use with 7524 Interface Support only. If the parameter is set to
0, the RF controller must have its ENHANCED POLL parameter under HOST
CONFIGURATION set to NORMAL. If the parameter is set to 1, the RF
controller must have that parameter set to ENHANCED.
This parameter was added in the hopes that allowing ENHANCED POLLING
to be set to ENHANCED would improve performance. However, our initial
testing shows that it actually impedes performance. Therefore, so far
this appears to be a wasted exercise. But that might change in the
future so the parameter will stay.
The default is:
RF_ENHANCED_POLL = 0
See the sample EXTRA.CFG file on the PTF diskette for more details. This
file is not copied during installation of the other PTF files so as to
preserve any existing parameters in the 'live' file.
Changed files: \DCC2R\BIN\DCXCPOS2.EXE
\DCC2R\DATA\DSKMGFIL.TXT
4-20-95: Found that if you created a transaction program file using the
DCC/2 Transactions Program Editor and you created a program in that
file that just had a name but had no steps, then the migration of the
program file to the 32-bit format would lose the program following
the empty one. Had to change migration to check specifically for
empty programs.
Changed file: \DCC2R\BIN\PGM.CMD
4-20-95: Changed the low level DCC/2 code so that it no longer sends out
a status command following a set user variable command if the target
terminal is a 7524. This cuts down network traffic and thus improves
performance in the RF network when user variables are being set frequently.
Changed files: \DCC2R\BIN\DCXRSUGW.EXE
\DCC2R\BIN\D2XNSUGW.EXE
4-28-95: APAR PN68274 Master Clock sometimes stops working (16-bit runtime).
A new version of DCCMCLCK.EXE offers a command line argument to
increase the process's priority. If the argument 'highpriority' is
provided (not case sensitive) the process will run at the lowest level of
the time-critical priority class. Without the command line argument, it
will run at its normal, default priority.
Changed files: \DCC\DCCMCLCK.EXE
4-28-95: APAR PN65085 MAPICS transactions sometimes not processed by the
Export Validation program, especially during DCC/2 startup and shutdown.
This problem affects both the 16-bit and 32-bit runtimes. However the
fix provided now is only for
Because the Export Validator (DCCEXPVA.EXE) was an application to DCC/2 it
was started after all DCC/2 internal processes were up and running -
including the terminal polling and transaction logging process. Because of
this arrangement there was a window of time during which transactions could
be polled and logged but during which the Export Validator was not yet
running. Therefore some transactions would not be syntax checked properly.
In addition any MAPICS/DB transaction containing a real number field
(quantity, amount or cost) would not have that real number put into the
proper format expected by the AS/400.
To fix the problem, the Export Validator was made an internal process of
DCC/2 so that it could be started before any transactions were received
from terminals. Because there can only be one "syntax checker", the
undocumented APIs previously used have been withdrawn. This will prevent
an external program from interferring with the now internal checking.
The trigger mechanism to enable checking is still the inclusion of
DCCCEXPVA.EXE as a user application. Since the configuration tool
requires the existence of any configured user application, a version is
still provided. All it does is load and block on a semaphore. This gives
anybody using PSTAT the impression that their selected application is
still there, even though it actually doesn't do anything.
A new error has been added "DCC0652 - Export Validation Initialization
failed." This is usually caused by a syntax error in one of the .XPV
files. Previously, this caused the checker program to pop up an error
panel, and exit. Now, it will cause DCCTREXE.EXE to log the error and
then generate a component error which will cause DCC/2 to shutdown. This
was done to prevent transactions from sneaking through the system without
going through the checker, which, of course, is the whole reason for the
APAR.
The remainder of the checker should exhibit identical behavior to the
previous version.
Changed files: \DCC\DLL\DCCCONF.DLL
\DCC\DLL\DCCCONF2.DLL
\DCC\DLL\DCCTRANS.DLL
\DCC\DCCERROR.EXE
\DCC\DCCTREXE.EXE
\DCC\DCCEXPVA.EXE
\DCC\DATA\DCCERRS.MSG
5-4-95: The Setup Notebook allowed the setting of an export logfile's capacity
to be in the range from 200 through 99999. However, if you set it to any
value from 200-499 both the Setup and Operate notebook complained that the
value was invalid. The Setup and Operate notebook now accept 200-99999.
Changed files: \DCC2R\BIN\OPERATE.EXE
\DCC2R\BIN\SETUP.EXE
5-12-95: Enhanced 7524 Interface Support by making the 'Are-you-there?'
polling asynchronous. This polling is done once a minute - or whatever
the SLOW_POLL_RATE currently is - to all terminals which DCC/2 believes
are communicating but which have not done any communications since the
last Are-you-there poll. Previously, 7524 IS would wait for the response
to an Are-you-there poll before handling any other command for any other
terminal. The code has been changed to send out the Are-you-there poll
and then handle other commands while waiting for the response. This
change now prevents a terminal that has been powered off from adversely
affecting system performance due to the Are-you-there polling.
Changed file: \DCC2R\BIN\DCXRFOS2.EXE
5-25-95: There's been a long standing bug in the DCCMAPDB.TTF file in
the cluster definition for the 7526 model 100. The cluster name in
the file was incorrectly spelled:
MD_34_TIMEATT_M2
it should be spelled:
MD_34_TIMEATT_M3
The symptom of the problem is that MAPICS/DB time and attendance
transactions are rejected by the DCC/2 MAPICS/DB Host Interface
program because their cluster name is not found in the translation file.
To fix the problem, simply use a text editor to open the file and
correct the spelling of the cluster name as described above.
The installation fix diskette does not provide an updated file
because of its size and because to fix the problem requires a simple
edit of the file. Furthermore, simply replacing the existing file
with the fixed default file during installation of fixes would cause
changes to be lost for anyone who has customized their transaction
translation.
Changed file: \DCC\DATA\DCCMAPDB.TTF (not part of fix package)
5-31-95: Potential trap fixed in the installation program. There were
several kinds of errors which, if encountered during an installation,
would cause a trap during the attempt to display an appropriate error
message. Two of the errors which would result in the trap are:
insufficient disk space and unable to write to the OS/2 INI file.
The affected file, DCXINST.EXE, is found on diskette 1. It is also
copied to the \DCC2R\BIN directory as DCXINST.EBK during installation
of the 32-bit runtime and is copied to the \DCC directory as DCXINST.EBK
during installation of the 16-bit runtime. Installation of this fix
package will automatically update the 16-bit and 32-bit directories.
However, in order to update diskette 1 the new file should be copied to
that diskette after the installation of the fix package is complete.
To do this, change to either directory (\DCC2R\BIN or \DCC) which you
are using, put diskette 1 in drive A: and issue the following command:
COPY DCXINST.EBK A:\DCXINST.EXE
Changed file: \DCC2R\BIN\DCXINST.EBK (also on diskette 1 as A:\DCXINST.EXE)
\DCC\DCXINST.EBK (same as above)
6-15-95: Found problem when flushing terminals during a download. The
transactions would all eventually be polled out, but the download would
be retried several times in the process because of duplicate transactions
and transaction release failures. Problem had to do with issuing a quick-
poll during a flush which resulted in the same transaction being polled
out twice in a row. The quick poll is no longer done during a download
and it solves the problem.
Changed files: \DCC2R\BIN\DCXRPO.EXE
\DCC2R\BIN\D2XNPO.EXE
7-07-95: Window refresh problem with DCC/2 Main - a minor cosmetic annoyance
with the DCC/2 - Main panel. If you overlap the frame with another window,
and then move that other window off of DCC/2's window, the text in the item
with the selection bar, which had been under that other window, will not be
redisplayed properly.
Changed files: \DCC\DCC.EXE (for DCC/2)
\DCC\DCCRUN.EXE (for DC for DAE product)
7-10-95: APAR PN68117.
Under Warp, several DCC/2 programs would trap if they were shut down as a
result of DCC/2 shutting down. All of the DCC/2 export programs were
affected: COPICS Interface, MAPICS Interface, DMIS and DAE Interface. In
addition an internal module of DCC/2 was affected because it used OS/2
signals.
Changed files: \DCC\DLL\DCCABOUT.DLL
\DCC\DCCCOPIC.EXE
\DCC\DCCMAPIC.EXE
\DCC\DCCDAEIF.EXE
\DCC\DCCDMIS.EXE
7-19-95: APAR PN73030.
When submitting validation file(s) to DCC/2 that resulted in multiple
terminals being downloaded, file open errors would eventually result. The
problem was that files were being opened and not closed and the loader
eventually ran out of file handles.
Changed files: \DCC\DLL\DCCCONF.DLL
\DCC\DLL\DCCCONF2.DLL
\DCC\DLL\DCCLOAD.DLL
\DCC\DCCLOAD.EXE
7-31-95: Added tool for manipulating DCC/2 16-bit logfile.
New file: RELEASE.EXE
8-10-95: Found that transactions created via API (DcxWriteTransaction or
DccWriteTransaction) that went through the 32-bit export validator
caused the following 3 messages to be displayed:
DCX-015 referencing a queue named /QUEUES/.DcX
DCX-031 referencing CP_TXLOG_WRITE
DCX-032 with an incomplete parameter showing as %s
In addition the call to Dc?WriteTransaction would never return. There
turned out to be 3 separate problems to be fixed. They all were based
on the condition that interactive responses are not supposed to be used
to respond to API-initiated transactions.
Changed files: \DCC\DCCEXP32.EXE
\DCC2R\TOOLKIT\DCX.DLL
\DCC2R\BIN\DCXCPOS2.EXE
8-15-95: Suddenly realized the installation of the fixed DCCTRANS.DLL for
the 4-28-95 fix would cause applications using certain 16-bit APIs (such
as DccOpenTransaction) to say DCC/2 was not running if the 32-bit runtime
was in use and the 16-bit runtime had been installed before the 32-bit
runtime.
The problem is that while the API environment is set for the 32-bit runtime,
some of the .DLL files in \DCC\DLL are renamed to *.STP so that OS/2 does
not find them when looking for the DCCTRANS.DLL. Instead OS/2 should
find the 32-bit version in the \DCC2R\TOOLKIT directory. The installation
of fixes did not check to see whether the DCCTRANS file was currently
named .DLL or .STP and was simply copied in. Thus if \DCC\DLL was in
the LIBPATH before \DCC2R\TOOLKIT, the 16-bit version of the DLL would
be found and the wrong code executed.
The installation command file now checks to see whether DCCTRANS.DLL has
been renamed to *.STP and copies the fix to the proper name.
Changed file: The installation for these fixes - A:\INSTALL.CMD
8-17-95: 32-bit runtime download task limited transaction program commands
to 256 bytes. Some ONKEY commands are longer than this. Increased that
maximum to 1024 bytes. Also when this error occurred, no informational
message explained what failed; only a 'download aborted' message was
given.
Changed files: \DCC2R\BIN\DCXCPOS2.EXE
\DCC2R\DATA\DSKMGFIL.TXT
8-21-95: New CFR APIs for the 7524 have been added. These include:
INT AliasTransID (UCHAR NewId);
VOID QueryTransactionCnt(PUSHORT numtxtns, PUSHORT numfree);
INT SendTransaction (VOID);
AliasTransID() is used to change the transaction ID field of the current
transaction. Valid values are 1 through 255. This works the same as
it does in 7526 and 7527 CFRs.
QueryTransactionCnt() allows you to find out how many tranasactions are
currently in the terminals queue and how many additional transactions
can be added to the queue. All 7524 terminals have a capacity of 736
transactions regardless of what size was specified for the transaction
buffer in the General Parameters configuration.
SendTransaction() is just like the 7526 API of the same name; it sends
the current contents of the transaction buffer to the host as a
transaction, adding the current transaction ID, time stamp and sequence
number.
Not only do you need the latest CFRAPI24.LIB and CFRAPI24.H but you must
also have a flash level later than 8-20-95 in order to use these CFR APIs.
To determine your 7524 flash level, go into the menus. If option 4 is not
INFO/STATUS then your flash is not late enough. If option 4 is
INFO/STATUS, select it and then select option 1) VERSION INFO. The second
line on the screen will give the date of your flash.
Changed files: A:\CFRAPI24.LIB
A:\CFRAPI24.H
8-22-95: In Setup Notebook of 32-bit runtime, found that sometimes all of
the transactions that were highlighted for an export group were not saved
properly. After saving, Setup indicated all went well. However,
shutting down and restarting Setup so that the file was reread would
cause all transactions specified after a certain point not be highlighted
like they should be.
Problem resulted when it required multiple lines in the DCX2.INI file
to list the transactions for the group. All lines after the first one
were missing the equal sign.
Changed file: \DCC2R\BIN\SETUP.EXE
8-23-95: Changed wording for first option on second screen that deals with
switching the API environment. The wording now talks about switching which
run time is being used - which is the deciding factor.
Changed file: \DCC2R\BIN\MIGRATE.EXE
9-6-95: On the Groups page of the Setup notebook, the Transaction window
showed DI points numbered 1 through 8 - they should be numbered 0 through 7.
Changed file: \DCC2R\BIN\SETUP.EXE
9-6-95: If it took more than 10 seconds for the initial message log to be
created by the 32-bit runtime, it would shut down and no message would
be given. This could be reproduced by specifying the maximum message
log size of 99999. The code was changed to wait up to 60 seconds for
the message logging task to start. It will also now wait up to 60 seconds
for the transaction logging task and validation task to start. Also added
message to show when message log was being created.
Changed files: \DCC2R\BIN\DCXCPOS2.EXE
\DCC2R\DATA\DSKMGFIL.TXT
9-6-95: 7524 Interface Support was changed to allow sending of Are-you-there
queries to terminals that currently have polling disabled. This was done
to take care of the situation where DCC/2 puts a 7524 terminal into the
not responding state when the cable between the PC and controller was
disconnected. Without this change, the terminal would never automatically
go back into the in service state after the cable was reconnected.
Changed files: \DCC2R\BIN\DCXRFOS2.EXE
9-19-95: Added 16-bit version of DcxGetTermUserVariable which is
DccGetTermUserVariable. This is valid only for 7526 terminals and
can only be used if the 32-bit runtime is being used. You must compile
and link with the latest DCC2.H (or DCC2386.H) and DCC2.LIB. The parameter
syntax is the same as for DccSetTermUserVariable.
Changed files: \DCC2R\TOOLKIT\DCC2.H
\DCC2R\TOOLKIT\DCC2386.H
\DCC2R\TOOLKIT\DCC2.LIB
\DCC2R\TOOLKIT\DCCNEW.DLL
9-19-95: In DCXRFOS2.EXE for 7524 Interface Support, found problem where
reads waiting for a response to a message sent to a terminal did not
always wait the proper delay. Redid the timing to fix this.
Changed file: \DCC2R\BIN\DCXRFOS2.EXE
9-19-95: The installation for the fixes had a REXX error due to two missing
End statements. The error occurs after putting in the second diskette.
Changed file: A:\INSTALL.CMD for fixes
9-19-95: Fix for 16-bit version of DCCGEN.DLL. In the words of our business
partner: "it repairs an obvious code flaw."
Changed file: \DCC\DLL\DCCGEN.DLL
10-2-95: Several problems fixed in the Setup notebook:
- A trap would occur if no terminals were defined and an attempt was made
to add one. Along with this, when no terminals were defined all of the
other fields on the Terminals page were blank
- When no export groups were defined, the Transactions list box was empty
on the Groups page.
- When no export groups were defined, the Add pushbutton on the Exports
page was disabled. This is correct. However, when a group was added,
the Add pushbutton remained disabled.
Changed file: \DCC2R\BIN\SETUP.EXE
10-5-95: Changed way parameters are specified for DCXRFOS2.EXE. Although
never documented, in the past you could have specified the name of the
file in which messages generated by DCXRFOS2.EXE were stored. By default
this was CON which meant they went to the screen (the session in which
DCXCPOS2.EXE was running). You could also specify a second parameter which
specified that all messages to and from terminals should be logged.
These options are still there but the way they are specified has changed:
N=CON - Name of file in which to log DCXRFOS2 messages. The default
is CON.
L=NO - Specifies if messages to and from terminals should be logged.
By default they are not.
Q=NO - New parameter specifying whether or not terminals that are
currently not being polled should be sent Are-you-there polls.
By default they are not.
Are-you-there polls are always sent to terminals that are being
polled but which have not done anything in a while - to ensure
that they are still powered on and communicating. Since the
polling that is normally done to hard-wired terminals is not
done for RF terminals, the periodic Are-you-there polls are
needed to help keep the states of the terminals accurate on
the Operate notebook Terminals page. Terminals that fail to
respond to Are-you-there polls are put into the not-responding
state.
Are-you-there polls are sent out approximately once a minute or
at whatever rate the SLOW_POLL_RATE parameter is set to (see
the 2-21-95 change above).
Setting Q=YES will cause Are-you-there polls to be sent even
to terminals who are not currently being polled - which
can be the case both if the user explicitly turned off polling
for the terminal or if the terminal is in the not-responding
or bad terminal state.
Setting this to Yes will allow automatic identifying of terminals
that are currently not responding due to the fact that the cable
between the PC and the controller had been disconnected for some
period of time and then reconnected - or for any other reason
that prevents the terminal that is actually powered on and
communicating from answering an Are-you-there poll resulting
in the terminal being put into the not-responding state.
Other mechanisms are already in place to handle the case where
a terminal was put into the not-responding state because it had
been powered off or had lost radio contact with the base.
This option should probably be left as No for now. It was
added in anticipation of a fix that is to be provided for
NUI_SERV.EXE which will allow it to recover if the controller
is rebooted or if the cable is disconnected for an extended
period of time. Right now there is a side effect that occurs
if Are-you-there polling is sent to terminals that were
responding but which no longer are - and we are not yet sure
if this side effect is harmful or not. The side effect is that
the controller responds with a 10 for every Are-you-there poll
that is sent to one of these not responding terminal. This is
an invalid response to DCC/2 and thus a message is logged for
each one. The terminal does work properly when powered on but
we're not yet sure of the impact to the overall performance of
the RF network.
In order to change any of these parameters, you must do the following
after applying the fixes in this package:
1) Shut down DCC/2 32-bit runtime if it is running
2) From an OS/2 prompt, change to the \DCC2R\BIN directory
3) Run 'nui_cfg'. It will present a menu on which option 2 is Applications.
4) Choose option 2. The first application listed will be:
~.\dcxrfos2.exe xN=CON L=NO Q=NO
The ~ at the start indicates this application is to be used by all
terminals - it must be there in order for 7524 IS to work properly.
The .\dcxrfos2.exe must also be there to specify the proper application
to be started.
The 'x' before 'N=CON' is there to get around a bug in NUI_SERV.EXE
which causes the first character of the first parameter to be
dropped.
The parameters shown are the defaults that you will get if
no parameters are specified at all. All parameters are optional
and can also be specified in any order. The parameters can be entered
in upper or lower case.
5) To change the parameter list, type 1 and press Enter. The cursor
will move to the ~ for the application. You cannot use the arrow
keys in NUI_CFG - so you have to retype the tilde and the application
name - then enter the parameters as you want them.
6) When done, make sure the cursor is at the end of the line and press
Enter. This will move the cursor back down to the bottom of the
screen. Then type E and press Enter to Exit. You'll be asked if
changes should be saved - press Y and Enter to confirm. This brings
you back to the main menu. From there press E again and you'll be
back at an OS/2 prompt.
7) Now DCC/2 32-bit runtime can be restarted.
Note: If you had previously changed the parameters for the application,
installation of these fixes will replace those changes with the defaults.
So you will have to reenter those changes using the new parameter style.
Changed files: \DCC2R\BIN\DCXRFOS2.EXE
\DCC2R\BIN\NUIF_APP
10-9-95: APAR PN76647, 7527 ETS: File A was lost after terminal reset.
File A (keyboard remap file) was not being correctly reregistered with
the BIOS after a terminal reset. This made it seem that the file was
lost after a terminal reset. The logic causing the table to be registered
with the BIOS was modified to always do so if the size of the file is
correct rather than only when the file is initially downloaded.
Changed files: ETS7527.EXE
ETS7527.MAP
This is version 1.03a of 7527 ETS. It is currently only available by
request from IBM support personnel provided you already have a license
for 7527 ETS.
10-16-95: Fix for APAR PN76745 - problem with DCC/2 COPICS Interface not
sending transactions with large timeout. The large timeout value caused
certain calculations to overflow signed variables such that they had
negative values. These variables were changed to unsigned variables to
fix the problem.
Changed file: \DCC\DCCCOPIC.EXE
10-18-95: The DMIS bind file was not updated with the latest change to
DCCDMIS.EXE (7-10-95). This made it impossible to successful run that
version of DMIS. These files are a set; when one is changed, the other
must be changed as well.
Changed files: \DCC\DCCDMIS.EXE
\DCC\DCCDM.BND (also put in root directory of OS/2 drive)
10-18-95: Dual-port ARTIC card now support by 32-bit runtime. Before the
code only allowed the Multiport, Multiport/2, Model 2 and Portmaster ARTIC
cards.
Changed file: \DCC2R\BIN\DCXIAPI.EXE
10-20-95: Large timeout values for a line cause negative numbers to show up
in the message that says how long it might take for the line configuration
to complete. Sometimes the system would not start as a result - often
giving a DCX-239 message.
The type used in the calculation should have been a long instead of a short.
Changed file: \DCC2R\BIN\DCXCPOS2.EXE
10-31-95: Increased the timeout period that the 32-bit runtime waited for
a download command to be processed. Was not taking into account that it
can take a while for the terminal to process an in-service command. As
a result if you downloaded a bunch of terminals on the same line, one or
more of the downloads at the end of the bunch would fail with the following
sequence of messages: DCX-143, DCX-044, DCX-159, DCX-015, DCX-031 and
DCX-032. These basically said that a time out occurred and an attempt
to write to a message path failed and so the download was aborted.
The failed downloads would be retried and would work the next time around
because this time there were fewer terminals downloading.
Changed file: \DCC2R\BIN\DCXCPOS2.EXE
11-02-95: In 32-bit runtime fixed problem where, with 7527 terminals, you'd
sometimes see the display plastered with a bunch of messages. We found
that if the parallel port switch was in the wrong position when a download
was about to complete, the terminal would show all of these message in its
attempt to display the single error message. The problem was resolved by
correcting one of the download commands that was sent to the terminal -
although in reality the one we were sending should not have caused any
problems.
This problem ultimately resulted in the terminal memory apparently being
corrupted to the point where an ETS download would fail with a -505 error
on the an ETS load command. The terminal would have to be cold-started
to get out of the situation. The first download after the cold-start would
work properly, but subsequent downloads would result in the display of a
chunk of the message file.
Also changed terminal communications code to consider it an error if the
terminal status indicated the terminal was still working on the previous
command - even after 40 status requests. Before we were not treating this
like an error when we should have been.
Changed files: \DCC2R\BIN\DCXCPOS2.EXE
\DCC2R\BIN\DCXRSUGW.EXE
\DCC2R\BIN\D2XNSUGW.EXE
11-14-95: In 32-bit runtime, fixed problem where invalid transactions were not
being released properly.
Changed files: \DCC2R\BIN\DCXRPO.EXE
\DCC2R\BIN\D2XNPO.EXE
11-29-95: In 32-bit runtime, increased the number of status requests it took
to fail a download if all attempts indicated the terminal was still busy
working on the last command. In fact, a period of time is now used (20
seconds) instead of a number of attempts (40). At least one customer's
downloads began to fail because 40 attempts was not sufficient. These 40
attempts occurred in about 8 seconds, so making 20 seconds the threshhold
should more than reasonable.
Also now initialize the CFR at the start of a complete load of 7527 files.
Other minor changes made to handle certain error situations.
Changed files: \DCC2R\BIN\DCXRSUGW.EXE
\DCC2R\BIN\D2XNSUGW.EXE
\DCC2R\BIN\DCXCPOS2.EXE
12-22-95: Added feature to 7524 IS which helps it more accurately set the
time in RF terminals. In order for this change to be completely effective,
at least version 1.02 of the 7524 ETS flash is needed. However, older
versions of the 7524 ETS flash will still work properly (as they did
before) with this latest version of 7524 IS. The new feature allows
7524 IS to recognize a set time request from the terminal and responds
to it with the current time. The request and response contains a
sequence number so that the terminal can verify the response is correct
and can ensure the time is accurate within a certain number of seconds
(currently 7).
Changed file: \DCC2R\BIN\DCXRFOS2.EXE
1-18-96: Added to this readme a section which describes all DCC/2r messages
after DCX-258. This section is near the beginning of this file and is
called: DESCRIPTION OF NEW MESSAGES ADDED TO DCC/2r SINCE INITIAL SHIP.
Changed files: DCC110FX.RME
1-18-96: Found that migrating exports which used the 'by cluster' option
did not always work right. Corrected typo in INI.CMD.
Changed files: \DCC2R\BIN\INI.CMD
1-23-96: Found that doing an Entire migration specifying 'Only files newer
than target' did not properly migrate job files if the only change to
the job was in the cluster definition (e.g. which validation files were
selected for download). As a result of the fix, choosing this option
will always remigrate the DCX2.INI file, but the cost of that is very
little.
Changed files: \DCC2R\BIN\ALL.CMD
1-24-96: Fixed problem in 32-bit runtime where two sets of time synchs would
be done when only one synch time was configured.
Changed file: \DCC2R\BIN\DCXCPOS2.EXE
1-25-96: Fixed problem in 32-bit runtime where certain invalid transactions
were not being released properly. DCC/2r did not actually consider these
transactions invalid because they had digits in the date/time stamp and
sequence number position. However, the code that set up the release command
and the code which made sure the release was successful used two different
method for figuring out where the sequence number is in a transaction. Both
methods do work fine for valid transactions (otherwise we'd have seen this
problem along time ago).
Changed files: \DCC2R\BIN\DCXRPO.EXE
\DCC2R\BIN\D2XNPO.EXE
2-14-96: Fixed problem in migration of clock synch times. We did not
properly migrate the configuration when the 16-bit configuration had
clock synching turned off. Instead the migration set up clock synchs
for every other hour. We now set up no clock synchs on the 32-bit
side when synching is turned off on the 16-bit side.
Changed file: \DCC2R\BIN\INI.CMD
2-27-96: In the Operate notebook, when the runtime was not running, selecting
the Terminals, Communications or Applications page caused a warning pop-up
to display but it did not have the focus. This problem has been fixed.
Changed file: \DCC2R\BIN\OPERATE.EXE
2-27-96: In the Operate notebook, on the Exports page, selecting the Clear
option did not give any error when the call to DcxClearExport was called.
The return code is now checked and an appropriate message is given.
Changed file: \DCC2R\BIN\OPERATE.EXE
2-27-96: Removing a terminal from the 32-bit runtime configuration using the
Setup notebook properly removed it from the Job that referenced it but that
terminal was not removed from any Export Group that referenced it. This has
been fixed.
Changed file: \DCC2R\BIN\SETUP.EXE
Last modified: April 24, 1995