 |
Bugs |
|
|
This section will describe bugs I have found and since all my attempts
at reporting bugs to IBM have failed (and I refuse to use the
clumsy 3270 based IBMLINK facility at work) I will provide
the details here.
I have recently found an
official IBM defect report which should
be completed when reporting a bug. It should be sent to the email address
specified. Please where possible include a batch file or a simplified
piece of code. IBM do not want to work through megabytes of source
code, if you can't come up with a small piece of code to
demonstrate the problem then you probably don't know enough to be
reporting it (and the chances are good that the fault is in your code)...
I will be submitting my own testcase to see if IBM accept it soon...
OS/2 REXX BUGS
RxFuncAdd & RxFuncQuery & RxFuncDrop
You can't trust the return code from any of these routines. For an example of a work around
subroutine look at the sample test program in my
RXREGEXP DLL source.
time('Reset') & time('Elapsed')
These functions are flakey and can
cause rexx SYNTAX errors or return the incorrect elapsed time. The code
makes an incorrect assumption and uses the current time to determine
differences (it should use time since IPL).
Try this testcase!
I first reported this for OS/2 version 2.0!
stream('query datetime')
This function is not Y2K complient in WARP 3 anyway (fixpac 28). Not
yet tested under Merlin. For the year 2000 it reports "100" for the
year 2000. For backwards compatability it should report "00" and a new
query created which returns the full year. Rexx now has a new
"query timestamp" option which returns a 4 digit year, the date is
also formatted better, I'm not sure what they have done if anything to the
original query.
SysGetMessage()
This function will truncate retrieved messages at or near 500
characters. If you have a problem in this area you might wish to use the
work around DLL I wrote for my
OS/2 message file decompiler.
SysCreateObject()
See WinCreateObject() bug below.
WORKPLACE SHELL BUGS
Stack Too Small()
I have written a few WPS shell classes over the years and have found that the shells stack
is much too small to be safe. This will show up in "funny" icon effects or
the shell dying. I believe the small stack size is the cause of many of the shells
stability problems. The effects are worst (as more stack used) when extra classes are registered
or classes are replaced (such as with LAN requesters). When I say the stack is small, I
mean there may be a couple of hundred bytes or less available. Now thats cutting it
fine... The worst thing is that there is no reason for this, as it does not save memory,
if the stack starts uncommitted (as is done by IBM C++), only what is required is committed!
OS/2+PM+WPS API BUGS
DosQueryFileInfo()
I have seen this function (within a DosFindFirst/Next loop) incorrectly fill out the
file information structure. The situation I encountered returned the correct
file allocation size etc but picks up the wrong time related information
(picks up previous files info - so more likely did not fill it in). I have only
ever seen this occur when the directory in question is on a network drive. My solution
was to use DosQueryPathInfo() instead. Note that in my situation every
second run of my program had this problem on specific files.
WinCreateObject()
A call to WinCreateObject() for the creation of a program object
with a floppy dir as the startup directory will generate a popup (if no
floppy is in the drive). DosError() does not remove it. Either
WinCreateObject() incorrectly overrides the setting, or
the create runs in a different process (and does not turn
off the popups). Note that the rexx
SysCreateObject() call also has the
popup problem.
_wpclsNew()
This WPS method requires its 3rd parameter (the setup string) to be in read/write
memory otherwise a PV will result. This of course also means it is
modifying this string.
 |
Saturday May 28 2022 at 3:15pm
|
|