Hello,
I will test the 64/32 bit 4.2 branch against this test suit.
I'll keep you posted.
Bye
Rainer
On 27.12.2013 17:02, Mark Miesfeld wrote:
On Fri, Dec 27, 2013 at 7:10 AM, Rainer Tammer tam...@tammer.net
mailto:tam...@tammer.net wrote:
The current ooRexx 4.2 branch does build under
Hello,
The current ooRexx 4.2 branch does build under AIX 6.1 (64Bit) without a
problem. All sample programs do work.
Which text suite should be used for ooRexx 4.2 branch??
Bye
Rainer
--
Rapidly troubleshoot
)
Rick
On Mon, Jun 24, 2013 at 11:04 AM, Rainer Tammer tam...@tammer.net
mailto:tam...@tammer.net wrote:
Hello,
I am very sorry, this is the error:
source='./interpreter/classes/ObjectClass.cpp'
object='librexx_la-ObjectClass.lo' libtool=yes \
DEPDIR=.deps
Hello,
the current SVN branch for 4.1.3 BETA does (after two small changes)
compile on AIX (32/64).
* Which test suite is the correct one for 4.1.3?
Bye
Rainer
--
This SF.net email is sponsored by Windows:
Build for
24, 2013 at 7:27 AM, Rainer Tammer tam...@tammer.net
mailto:tam...@tammer.net wrote:
Hello,
the current SVN branch for 4.1.3 BETA does (after two small changes)
compile on AIX (32/64).
* Which test suite is the correct one for 4.1.3?
Bye
Rainer
Hello,
I'll test the AIX code in the next days...
Bye
Rainer
On 13.05.2013 16:38, David Ashley wrote:
I have no objections to a 4.1.3 bug release. Just let me know what the
target date is and I will do the Linux builds for it.
David Ashley
On Sun, 2013-05-12 at 10:04 -0700, Mark Miesfeld
Hello,
OK, I will provide the new 4.1.2 builds, but I have to go on a business
trip to Sao Paulo in a couple of days.
I'll be back 2012-09-15.
Maybe I can squeeze in the build in the next couple of days, but this
would be very tight.
If this does not work out I'll provide the packages as soon as
Hello,
I just tried to compile ooRexx 4.1.2 (oorexx/main/branches/4.1.2/trunk,
8193) on AIX 64, but I get an compile error.
Is this a known problem??
xlC_r -DHAVE_CONFIG_H -I. -DORX_VER=4 -DORX_REL=1 -DORX_MOD=2
-DORX_FIX=0 -DORX_SYS_STR=\AIX\ -DORX_CATDIR=\/opt/ooRexx/bin\
Hallo,
I am a little confused.
What is the correct SVN URL to download the release 4.1.2 source???
This is working:
https://oorexx.svn.sourceforge.net/svnroot/oorexx/main/releases/4.1.1/
This is not working:
https://oorexx.svn.sourceforge.net/svnroot/oorexx/main/releases/4.1.2/
Bye
Rainer
Hello,
Yes, the problem was the disk size...
Thanks for the heads up.
Bye
Rainer Tammer
On 14.06.2012 18:42, Jean-Louis Faucher wrote:
About the three failures TEST_MANY_CHARS.
I have them under windows, when running the test from an USB drive.
http://sourceforge.net/mailarchive/message.php
Hello,
any ideas before I start the real AIX builds??
Bye
Rainer
On 12.06.2012 09:37, Rainer Tammer wrote:
Hello,
I just found out, that URL was not correct...
To be sure that there are no bigger problems with the 4.1.1 release I
just build a 32 4.1.1 ooRexx and executed the test suite
Hello,
On 08.06.2012 19:51, Mark Miesfeld wrote:
Hi Rainer,
We haven't heard from you in awhile. Are you still lurking around?
Yes,
but currently I am buried in SAP migraption projects...
If so, is it possible for you to build an AIX package for ooRexx 4.1.1?
Yes,
I will try to build the
Hello,
I just found out, that URL was not correct...
To be sure that there are no bigger problems with the 4.1.1 release I
just build a 32 4.1.1 ooRexx and executed the test suite:
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter: REXX-ooRexx_4.1.1(MT) 6.03 12 Jun
Hello,
I'll just try the 4.1.1 on AIX...
Is this the correct branch:
https://oorexx.svn.sourceforge.net/svnroot/oorexx/main/branches/4.1/
And is this the correct test branch:
https://oorexx.svn.sourceforge.net/svnroot/oorexx/test/branches/4.1.0
Bye
Rainer
On 25.02.2012 06:06, Mark Miesfeld
Hello,
this is the test suite output for AIX 5.3 / ooRexx 4.1.1beta 64 bit:
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter: REXX-ooRexx_4.1.1(MT) 6.03 27 Feb 2012
Addressing Mode: 64
ooRexxUnit: 2.0.0_3.2.0ooTest: 1.0.0_4.0.0
Tests ran: 18993
Hello,
this is the test suite output for AIX 5.3 / ooRexx 4.1.1beta 32 bit:
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter: REXX-ooRexx_4.1.1(MT) 6.03 27 Feb 2012
Addressing Mode: 32
ooRexxUnit: 2.0.0_3.2.0ooTest: 1.0.0_4.0.0
Tests ran: 18993
Hello,
I will commit this change to head this evening (German time).
Bye
Rainer
On 14.03.2011 20:03, Jean-Louis Faucher wrote:
Hi Rainer
2011/3/14 Rainer Tammer tam...@tammer.net mailto:tam...@tammer.net
Hello,
I changed the extension a bit:
I think that this version should
Hello,
I changed the extension a bit:
#
[^]
# svn diff
Index: rxsockfn.cpp
===
--- rxsockfn.cpp(revision 6571)
+++
Hello,
I think that the /platform/unix/xxx version is cleaner.
Bye
Rainer
On 25.02.2011 16:36, David Ashley wrote:
All (but especially Rick) -
I am going to reconfigure the platform specific source for rxapi while I am
at
SHARE next week. I am going to take Rick's suggestion that we
Hello,
that's great to hear.
It looks like reorderQueues() mixes things up.
Bye
Rainer
Henning Gammelmark wrote:
Hi
I have applyed the new rxapi to my
system.
After the fix has been applyed I have
not
(yet) been able to recreate the rxapi loop problem.
I have just
Hello,
On 11.01.2011 15:51, Mark Miesfeld wrote:
This is directed to Rainer.
Not to put any pressue on you Raniner, I know you're busy. But, if
some time you could put together a 4.1.0 buidl on AIX with Rick's fix
for this bug, I'm sure the opener (Henning Gammelmark) of the bug
would test
Hello,
the fix test for the problem is available for 96h on:
http://www.tammer.net/ooRexx/6571/
Bye
Rainer
On 11.01.2011 15:51, Mark Miesfeld wrote:
This is directed to Rainer.
Not to put any pressue on you Raniner, I know you're busy. But, if
some time you could put together a 4.1.0
Hello,
just a short first answer here (a more detailed will follow).
On AIX it's the best thing to run the daemon under the control of the
subsystem resource controller (SRC). This way you get
fancy error log entries and automatic restart of the daemon
in case of a failure.
There is only one
Hello,
On 03.12.2010 20:01, David Ashley wrote:
All -
I have created the ooRexx 4.1.0 release folder in the SourceForge Files
section
and uploaded a bunch of files to it. I also created the Docs 4.1.0 folder and
uploaded the docs to it.
All we lack are the Windows, mac and AIX install
Hello,
I have two questions regarding the SysGeterrnomsg() function:
1. What is the purpose of the following code ??
..
State not recoverable,
Operation not possible due to RF-kill,
};
if (en sizeof(en) / sizeof(char *)) {
return
Hello,
this is the result of the AIX 64 bit test suite run:
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter: REXX-ooRexx_4.1.0(MT) 6.03 30 Nov 2010
Addressing Mode: 64
ooRexxUnit: 2.0.0_3.2.0ooTest: 1.0.0_4.0.0
Tests ran: 18986
Assertions:
Hello,
currently I am preparing the ooRexx 4.1 RC for AIX.
I do know that the installation directory changed on Linux.
Do you think that it is acceptable to stay with /opt/ooRexx
on AIX, at least for the 4.1 branch?
This build does currently not show the problem with
TIME.testGroup, so this
to work this out over the holidays.
David Ashley
Bye
Rainer
On 11/30/2010 09:18 AM, Rainer Tammer wrote:
Hello,
currently I am preparing the ooRexx 4.1 RC for AIX.
I do know that the installation directory changed on Linux.
Do you think that it is acceptable to stay with /opt/ooRexx
Hello,
sorry for the delay...
I will prepare the AIX builds in the next days.
CAUTION: I will use AIX 5.3 as build system.
All older build were done on AIX 5.2.
Bye
Rainer
On 26.11.2010 16:22, Mark Miesfeld wrote:
We don't seem to be getting any new bug reports with 4.1.0. I've been
Hello,
I tried that. It seems that the problem is moving around.
The machine does nothing during the test.
I have added the extended assert to cbNa assertTrue() tests:
This is one sample failure:
[failure] [20101103 08:15:07.738747]
svn:r4227 Change date: 2009-02-26 19:38:21 +0100
Hello,
I am currently testing the ooRexx 4.1 tree on AIX.
The whole thing compiles, that way it look good.
I did not yet run the test suite.
I have notice one difference, the installation directory
changed from /opt/ooRexx to /usr.
Is there a specific reason for that ??
Bye
Rainer
Hello,
On 02.11.2010 14:02, David Ashley wrote:
Ranier -
We have always gotten a lot of complaints about our install methodology on
*nix
systems. So after some consideration we decided to change it to a more
traditional approach, even though this possibly violates the spirit of the
Hello,
this is the result for the test suit on AIX 5.3 / 64 bit.
The test suite does show 3 (unexpected?) failures:
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter: REXX-ooRexx_4.1.0(MT) 6.03 2 Nov 2010
Addressing Mode: 64
ooRexxUnit: 2.0.0_3.2.0ooTest:
Hello,
On 02.11.2010 16:04, Mark Miesfeld wrote:
On Tue, Nov 2, 2010 at 7:12 AM, Rainer Tammer tam...@tammer.net wrote:
this is the result for the test suit on AIX 5.3 / 64 bit.
The test suite does show 3 (unexpected?) failures:
Rainer,
Be sure you are using the 4.0.1 test suite:
sorry
On Thu, Sep 16, 2010 at 1:52 AM, Rainer Tammer tam...@tammer.net wrote:
Hello,
I just tried to compiler the 4.1 branch on AIX, but there are some
problems with the code:
1. YACC
Index: configure.ac
===
--- configure.ac
),
REXX_TYPED_ROUTINE(SysGetservbyport, SysGetservbyport),
REXX_TYPED_ROUTINE(SysWordexp, SysWordexp),
Bye
Rainer
David Ashley
On 09/17/2010 01:05 AM, Rainer Tammer wrote:
Hello MArk,
On 16.09.2010 16:21, Mark Miesfeld wrote:
Rainer,
I don't think you have a clean 4.1.0 source tree, or your
Hello,
I just tried to compiler the 4.1 branch on AIX, but there are some
problems with the code:
1. YACC
Index: configure.ac
===
--- configure.ac(revision 6196)
+++ configure.ac(working copy)
@@ -59,7 +59,7 @@
Hello,
I will build the AIX versions as soon as possible.
Bye
Rainer
On 05.05.2010 02:34, Mark Miesfeld wrote:
The ooRexx team is pleased to announce that the official release of
ooRexx 4.0.1 is now available at:
http://sourceforge.net/projects/oorexx/files/
ooRexx 4.0.1 is a bug fix
Hello,
I just tried to compile ooRexx trunk on AIX
There is one small problem in common/platform/unix/SysFile.cpp which I
just fixed (not yet committed).
And there are other problems in
extensions/rexxutil/platform/unix/rexxutil.cpp:
* AIX dos not have #include sys/syscall.h
- I have to teach
Hello,
one question regarding the naming:
This this thing be called RC2 or beta 2 ??
I will provide an AIX build 32/64 for AIX 5.3/6.1.
Bye
Rainer
On 14.04.2010 17:27, Mark Miesfeld wrote:
We haven't had any bugs opened specifically for the beta 1 build.
There was just this one: 2981692
in
September. So for a short time at least these will be three supported
versions of AIX eg. 5.3, 6.1, and 7.1.
I try to get a beta of 7.1 as soon as possible.
Bye
Rainer
On 04/04/2010 08:05 AM, Rainer Tammer wrote:
Hello,
I just have sent the BETA1 binaries to Mark.
This binaries
Hello,
what exactly did you change do fix the
/Users/bjskelly/4.0.1/ooRexx/base/bif/VALUE.testGroup in 32 bit mode ???
Bye
Rainer
CVBruce wrote:
Hi Mark,
I updated the code that was failing, in the test, and I now have a
version of ooRexx 4.0.1 that passes all of the tests.
ooTest
Hello MArk,
On 28.03.2010 18:05, Mark Miesfeld wrote:
On Sun, Mar 28, 2010 at 8:16 AM, Rainer Tammer tam...@tammer.net wrote:
I am getting one error on AIX 32 bit. The second error is expected.
Any ideas ??
I ran the test suite on 4 different Linux systems yesterday and didn't
see
Hello Mark,
On 28.03.2010 18:05, Mark Miesfeld wrote:
On Sun, Mar 28, 2010 at 8:16 AM, Rainer Tammer tam...@tammer.net wrote:
I am getting one error on AIX 32 bit. The second error is expected.
Any ideas ??
I ran the test suite on 4 different Linux systems yesterday and didn't
see
Hello,
I am getting one error on AIX 32 bit. The second error is expected.
Any ideas ??
Interpreter: REXX-ooRexx_4.0.1(MT) 6.03 28 Mar 2010
Addressing Mode: 32
ooRexxUnit: 2.0.0_3.2.0ooTest: 1.0.0_4.0.0
Tests ran: 18980
Assertions: 575819
Failures:2
Hello,
this is the result of the 4.0.1 test suite on AIX (64 bit mode).
The second failure is expected as the test suite was called under root.
# rexx -v
Open Object Rexx Version 4.0.1
Build date: Mar 1 2010
Addressing Mode: 64
This looks correct...
Is this because of api/oorexxapi.h
#define
Hello,
OK, thanks.
Bye
Rainer
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why
Hello,
the AIX 32 bit version is also OK.
The test suite shows the same two failuers (which are no real failures).
Bye
Rainer
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed
Hello,
this is a good idea. I'll test the branch on AIX.
Bye
Rainer
On 12.02.2010 17:11, Rick McGuire wrote:
Ok, I've created a branch we can use to start merging revisions into.
Most bug fix changes to trunk should merge fairly cleanly, though I
suspect there are a couple that might need
Hhello,
On 01.02.2010 19:47, Rick McGuire wrote:
On Mon, Feb 1, 2010 at 1:38 PM, David Ruggles da...@safedatausa.com wrote:
I'm not sure what macrospace is so I don't know. What is macrospace?
macrospace is a means of loading programs into storage and keeping
them there that dates
Hello,
the test suite passes all tests on svn: 5509 (64 bit build).
Bye
Rainer
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities
Hello,
IBM fond something interesting
I have to test this but it seems that the nobody problem on AIX could be
solved...
- IBM mail ---
Rainer Tammer,
The problem seems to be the priority set for call to pthread_create,
File
ooRexx-4.0.0/common/platform/unix
Hello,
I think that there is a small problem in ooRexx 4.0 trunk:
common/platform/unix/SysThread.cpp
...
// create a new thread and attach to an activity
void SysThread::createThread(void)
{
pthread_attr_t newThreadAttr;
int schedpolicy, maxpri, minpri;
struct sched_param
Hello,
the SVN 5272 is working on AIX (at least in 32 bit, need to check the 64
bit build and the test suite)...
Bye
Rainer
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer
Hello,
(Rick please read the note at the end)
yug k wrote:
Hi All,
I've been trying to compile the source code of ooRexx 4.0.0 on AIX 5.3
OK what exact compiler version do you use?
The code is very sensitive to the C compiler.
The gcc compiler does not work. If you are using a IBM compiler
Hello,
I have a question regarding memory allocation in rxapi:
In rexxapi/common/platform/unixSysAPIManager.cpp
void *SysAPIManager::allocateMemory(size_t l)
{
return malloc(l);
}
In rexxapi/clientRegistrationAPI.cpp
void *REXXENTRY RexxAllocateMemory(size_t size)
{
return
Hello,
to get a better look at the core file I would need a snapcore:
snapcore core /opt/ooRexx/bin/rxapi
The output is in: /tmp/snapcore
This archive contains the core + the binary + the dependent shared
libraries.
Bey
Rainer
yug k wrote:
Hi All,
I've had a core dump with rxapi while
debugging
code added.
regards,
Yugandhar
Bye
Rainer
On Wed, Aug 26, 2009 at 2:04 PM, Rainer Tammer tam...@tammer.net
mailto:tam...@tammer.net wrote:
Hello,
please could you also post the output from:
dbx rxapi
(dbx) where
...
The core should
Hello,
yug k wrote:
Hi Rainer,
Please find the snap core file *snapcore_630798.pax.Z* attached in
the mail .
Herez the output of the snapcore comand that was run :
[root]/opt/ooRexx/bin snapcore core /opt/ooRexx/bin/rxapi
Creating directory /tmp/snapcore ...
Core file core created by
Hello,
yug k wrote:
Hi All,
I've had a core dump with rxapi while testing ooRexx 4.0.0 on AIX
5.3.0.0 . I've raise a bug for the same couple of days ago bearing Bug
ID 2844093 on SF . Please find the core dump attached in this mail .
What is the output of:
oslevel -s
lslpp -L xlC.rte
lslpp
Hello,
please could you also post the output from:
dbx rxapi
(dbx) where
...
The core should be in the same directory as rxapi.
Bye
Rainer
yug k wrote:
Hi All,
I've had a core dump with rxapi while testing ooRexx 4.0.0 on AIX
5.3.0.0 . I've raise a bug for the same couple of days ago
Hello,
Rick McGuire wrote:
Hmmm, something very strange going on here, most likely a memory
overlay of some sort. From the stack trace, the nil value passed to
sessionTerminated() is clearly wrong, which results in an access of
0x005c getting used for the list, causing the trap. My only
Hello Rick,
Rick McGuire wrote:
I doubt this a synchonization problem. The APIServerThread instance
is only accessed by the local thread and really just has a few fields.
The call in question occurs here:
/**
* Dispatch the newly created reader thread to do it's work.
*/
void
Hello,
the current trunk (5100) does not compile:
cp ./interpreter/RexxClasses/*.orx .
cp ./interpreter/platform/unix/*.orx .
./rexximage
exec(): 0509-036 Cannot load program
/daten/source/ooRexx/main32/trunk/.libs/lt-rexximage because of the
following errors:
rtld: 0712-001 Symbol
\
I'll commit the fix...
Bye
Rainer
Rainer Tammer wrote:
Hello,
the current trunk (5100) does not compile:
cp ./interpreter/RexxClasses/*.orx .
cp ./interpreter/platform/unix/*.orx .
./rexximage
exec(): 0509-036 Cannot load program
/daten/source/ooRexx/main32/trunk/.libs/lt-rexximage
Hello,
the commit was not working ... someone was a bit faster :-))
Bye
Rainer
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and
Hello,
currently I am preparing the AIX release of ooRexx 4.0.0.
The packages will be ready on Monday.
Bye
Rainer
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your
Hello,
the SVN 5077 4.0 beta looks good on AIX.
The 32 bit and 64 bit 4.0.0 test suite passes to 100%.
The callrexxN examples are working. I can see no obvious problems.
Bye
Rainer
David Ashley wrote:
All -
Are we ready to deliver 4.0? The number of bugs opened has slowed to a
crawl and
Hello,
this is a very simple test program:
* build53.some.org resolves and exists
* build55.some.org does not resolve and does not exist
#!/usr/bin/rexx
If RxFuncQuery(SockDropFuncs) then
do
rc = RxFuncAdd(SockLoadFuncs,rxsock,SockLoadFuncs)
rc = SockLoadFuncs()
end
say SockGetHostByName(
Hello,
Rick McGuire wrote:
I think in general, it is bad practice to set result variables in the
case of a failure. But with regards to the 4.0 release, since this
has worked this way in prior releases, it should not be changed on the
eve of shipping the 4.0 release. This is something that
Hello,
Moritz Hoffmann wrote:
Rainer Tammer schrieb:
Hello,
I want to cleanup the different types of #defines in ooRexx.
What could help would be shifting away from command line defines to a
config.h file that contains all the defines.
Yes,
this was my long term intention.
* In the first
-- resend / the first version got messed up --
Hello David,
David Ashley wrote:
Moritz -
This is exactly what the configure script does.
It creates files including config.h, Makefile,
etc from the information in the configure.ac file
and dynamic testing of platform. All this depends
Hello,
I think that the last paragraph in the INSTALL read me should be changed:
Suggestion:
snip ---
Checkout, Build, and Install from the Subversion Repository
===
The entire source tree for
/base/class/File.testGroup
Line: 79
Failed: assertEquals
Expected: [[0], identityHash=570711194]
Actual: [[18446744073709551615], identityHash=664037636]
Any ideas ??
Bye
Rainer Tammer
--
Let Crystal
Hello,
Rick McGuire wrote:
It means I haven't had a chance yet to debug the new file class code
in a unix system yet. Now that we're about to release the the 4.0
version, the brunk branch is back into an unstable state with new
development going in.
OK, I see.
Bye
Rainer Tammer
Rick
(AIX)
#if defined(OPSYS_AIX)
#ifdef AIX
...
What is the preferred way ?
Do we really need the OPSYS_ version ??
Should I changed this to:
A: OPSYS_AIX, OPSYS_LINUX, OPSYS_SUN, ...
B: AIX, LINUX, SUN, ...
I would vote for version B.
Bye
Rainer Tammer
Hello,
Rick McGuire wrote:
The cleanup for #defines in the platform-specific code is far from
complete. A lot of this was inherited from the original IBM code,
which was not done very consistently. I'm not even sure how/where the
GENERIC_OS and GENERIC_OPSYS flags are used. This is
Hello,
I am checking the possibility to setup en build environment for the
ooRexx DOCs on AIX.
Which _exact_ versions of the build tools are currently used ??
From README.txt
* DocBook = 4.2
* OpenJade = 1.3.2
* TeX = 7.4.5 with passivetex installed
Especially TeX gives me a headache. I
Hello,
currently I am having a problem with ooRexx on AIX 6.1 - its not working...
I have no idea why. My current compile looks 5017 looks good on AIX 5.2
and 5.3...
The rxapi starts without a problem. But if I try to run the samples
ooRexx fails.
The interpreter just hangs...
rexx usepipe.rex
-
Hello,
the hang occurs here:
PID: 524304 is rexx
r...@build61 rc:0 # dbx -a 524304
Waiting to attach to process 524304 ...
Successfully attached to rexx.
warning: Directory containing rexx could not be determined.
Apply 'use' command to initialize source path.
Type 'help' for help.
reading
Hello,
Rick McGuire wrote:
It's waiting for a reply back from the rxapi daemon for a request to
create a session queue for that interpreter instance. The problem is
most likely occurring in the daemon.
yes,
but I can not imagine a reason why this happens...
I have to admit that my last
Hello,
Rick McGuire wrote:
The accept() call is the thread where the daemon is waiting for new
in-coming connections. There should be a second thread in the process
that's servicing the request for the hung process. Since the client
process is waiting for a return response, the accept()
Hallo,
there is one strange thing in the call stack:
ClientMessage.ClientMessage::send(SysClientStream*)(this =
0x2ff20260, pipe = 0x30c13978), line 82 in ClientMessage.cpp
..
ClientMessage.ClientMessage::send()(this = 0x2ff20260), line 59 in
ClientMessage.cpp
I do not understand why both
Hello Rick,
Rick McGuire wrote:
Not much of a mystery there, the first send() method calls the second.
That's a perfectly normal looking call stack. You're probably going
to need to debug ApiServer::processMessages() method, which is what
should be on the other end of this client
Hello,
strange thing...
When I start the daemon in foreground then ooRexx works...
Bye
Rainer
Rick McGuire wrote:
Not much of a mystery there, the first send() method calls the second.
That's a perfectly normal looking call stack. You're probably going
to need to debug
Hello Rick,
Rick McGuire wrote:
This really sounds to me like you might somehow be picking up the old
version that listens on the old port. I don't have any new advice
other than what I've already given you.
I think I have nailed the problem. The switch to nobody is not working.
If I
Hello,
Mark Miesfeld wrote:
Rainer,
Didn't you have a problem in the past picking up the old rxapi?
Not really :-)
But this time it looks like the UID switch causes the problem.
I have disabled this functionality and now its working.
I have changes this:
APIService.cpp
// run as nobody
Hello David,
David Ashley wrote:
Rainer -
It appears that sarting with AIX 6.1 an application that uses setuid
must be marked in some way with the security management feature. If this
is not done the API will fail.
That was all I could find in the differences paper on AIX 6.1. Maybe you
Hello,
I think that I have found the solution.
Many thanks to David, he pointed me in the right direction.
It looks that if I set the suid bit on rxapi then the setuid() switch is
working. This is really new in AIX 6.1... grrr
Bye
Rainer
Hello,
sorry my last mail was a bit to fast. It's not working. It's only
working if rxapi is running as root.
Bye
Rainer
--
___
Oorexx-devel mailing list
Hello Rick,
Rick McGuire wrote:
Rainer,
I have a serious suspicion there is a 64-bit type portability problem
with the SockSetSockOpt andSockGetSockOpt functions when using the
SO_SNDBUF and SO_RCVBUF options. The fix for this is probably more
than just a couple of lines of code, so before
Hello,
I just read ID: 2821430.
Is it possible that this is not implemented at all?
I can find SetErrno() and SetH_Errno() in rxsock.cpp.
These two functions are never called.
The SetH_Errno() looks kinda fake:
/*--
* set h_errno
Hello,
Rick McGuire wrote:
It looks like the fact these were not getting called was my fault. In
previous releases, the rxsock package registered all of the functions
using the same DLL entry point. When called, it searched a table and
dispatched the call to the actual target. This was a
Hello,
Rick McGuire wrote:
This sounds like there is a problem with try/catch. Not sure there's
much we can do about that. We're sort of at the mercy of the
compilers actually working consistently. You might try turning off
optimizations to see if that works, but given you do have a
Hello,
I have found a (serious) problem which is probably related to 64 bit.
64 bit Rexx:
say rxsock version: SockVersion()
host.!addr = SockGetHostId()
say addr : host.!ADDR
::requires 'rxsock' LIBRARY
Output:
rxsock version: 4.0.0
addr : 0.0.0.0 - this sould be the IP of
Hello Rick,
could you please delete the unnecessary line:
RxVarSet(pszStem,addr,inet_ntoa(addr));
just after the first patched line ? I see no reason why this line is
there two times.
Bye
Rainer
bigr...@users.sourceforge.net wrote:
Revision: 4996
Hello,
Rick McGuire wrote:
Rainer,
should this be applied to the 4.0 brank as well?
What is _4.0 brank_ ? :-))
This patch requires some 4.0 trunk changes to APIService.cpp.
The 4.0 beta misses some code needed for the AIX RSC daemon variant.
This code does only affect AIX. Without this
Hello,
I plan to prepare an AIX RC2 over the weekend.
Which SVN tag should I use ??
Bye
Rainer
Mark Miesfeld wrote:
All,
I know that because of the fixes for the memory / handle leaks we had
for RC1, Rick would like to do another release candidate.
It seems to me we should go ahead and
Hello,
OK, I will build an RC1 for AIX over the weekend.
Bye
Rainer
Mark Miesfeld wrote:
Okay, I've built the beta at svn revision 4861 on a number of
different Linux systems and Windows systems. I don't get any errors
running the test suite on any system now.
The number of bugs being
Hello,
if I did not miss something there is no explicit signal handler for
SIGTERM in the API daemon.
Sometimes a simple kill does not terminate the daemon.
Would it be a problem if I add a signal handler for SIGTERM ?
My idea is to add an handler which calls apiServer.terminateServer(); ...
Is
1 - 100 of 182 matches
Mail list logo
