cmd.exe and rexx

[Mr. G]

Can anyone tell me why this happens. eCS 2.0 - 104a smp kernel
I run rexx programs maybe 15-20 times, then no rexx programs
will run after that. cmd.exe will open on its own but will close
if I try to run another rexx program. Have to reboot and it starts
all over again. Here's my latest popuplog.os2...

01-01-2012 20:25:16 SYS3175 PID 0363 TID 0001 Slot 009d
C:\OS2\CMD.EXE
c0000005
1ec34b50
P1=00000001 P2=12000000 P3=XXXXXXXX P4=XXXXXXXX
EAX=12000000 EBX=12000000 ECX=12000000 EDX=12000000
ESI=00007b1e EDI=171f0000
DS=0053 DSACC=d0f3 DSLIM=5fffffff
ES=0053 ESACC=d0f3 ESLIM=5fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1ec34b50 CSACC=d0df CSLIM=5fffffff
SS:ESP=006b:0072ff20 SSACC=d0f3 SSLIM=5fffffff
EBP=0072ffcc FLG=00010206

REXX.DLL 0001:00084b50

Can anything be done to rectify this. It's a fairly
recent annoyance.

[Shmuel (Seymour J.) Metz]

Post by Mr. G
Can anything be done to rectify this.

Yes - register at <http://bugs.ecomstation.nl> and create an issue.

[A.D. Fundum]

Post by Mr. G
I run rexx programs maybe 15-20 times, then no rexx
programs will run after that. cmd.exe will open on its
own but will close if I try to run another rexx program.
Have to reboot

Try reseting the WPS instead of a reboot. Most likely the Rexx
interpreter is running out of shared memory.


--

[Andreas Schnellbacher]

Post by A.D. Fundum

I run rexx programs maybe 15-20 times, then no rexx programs will
run after that. cmd.exe will open on its own but will close if I
try to run another rexx program.

Try reseting the WPS instead of a reboot. Most likely the Rexx
interpreter is running out of shared memory.

It sounds as if you've switched to Object REXX. The outdated OS/2
implementation that comes with W4.x is full of bugs, so everyone
recommends to use the Classic REXX version instead, what is the
default selection for any OS/2 and eCS installation. Object REXX
for OS/2 was just (and unfortunately is still) in an alpha state.

[Shmuel (Seymour J.) Metz]

what is the default selection for any OS/2 and eCS installation.

Classic.

[Mr. G]

On Tue, 3 Jan 2012 01:16:46 UTC, Shmuel (Seymour J.) Metz

Post by Shmuel (Seymour J.) Metz

what is the default selection for any OS/2 and eCS installation.

Classic.

I think Andreas meant to type 'which' instead of 'what'.

[Mr. G]

On Mon, 2 Jan 2012 22:45:24 UTC, Andreas Schnellbacher

Post by Andreas Schnellbacher

Post by A.D. Fundum

I run rexx programs maybe 15-20 times, then no rexx programs will
run after that. cmd.exe will open on its own but will close if I
try to run another rexx program.

Try reseting the WPS instead of a reboot. Most likely the Rexx
interpreter is running out of shared memory.

It sounds as if you've switched to Object REXX. The outdated OS/2
implementation that comes with W4.x is full of bugs, so everyone
recommends to use the Classic REXX version instead, what is the
default selection for any OS/2 and eCS installation. Object REXX
for OS/2 was just (and unfortunately is still) in an alpha state.

Thing is, I take advantage of Object Rexx functions
which are not available in Classic.

Been running Object Rexx for years on my OS/2
MCP2 partition without this problem.

[Steven Levine]

On Tue, 3 Jan 2012 02:11:21 UTC, "Mr. G" <***@yahoo.com> wrote:

Hi,

Post by Mr. G
Thing is, I take advantage of Object Rexx functions
which are not available in Classic.

While OREXX has it's nits, it works fine for the vast majority of code
I use it for. For scripts that give it trouble, it's trivial to
invoke a command line session that runs Classic REXX.

Given the trap address, can I assume

rexxtry parse version a;say a

reports

OBJREXX 6.00 18 May 1999

If so, I get this exception now and then. It's a resource issue which
can be resolved with minimal fuss by closing all the open VIO session
windows. I've always suspected it's related to leaked file handles,
but I've never confirmed this.

Post by Mr. G
Been running Object Rexx for years on my OS/2
MCP2 partition without this problem.

Is it possible you recently modified a script that uses lots of files
or large stems?

Steven

[Mr. G]

On Tue, 3 Jan 2012 07:04:55 UTC, "Steven Levine"

Post by Steven Levine
Hi,

Post by Mr. G
Thing is, I take advantage of Object Rexx functions
which are not available in Classic.

While OREXX has it's nits, it works fine for the vast majority of code
I use it for. For scripts that give it trouble, it's trivial to
invoke a command line session that runs Classic REXX.
Given the trap address, can I assume
rexxtry parse version a;say a
reports
OBJREXX 6.00 18 May 1999

Yes, it does.

Post by Steven Levine
If so, I get this exception now and then. It's a resource issue which
can be resolved with minimal fuss by closing all the open VIO session
windows. I've always suspected it's related to leaked file handles,
but I've never confirmed this.

Open items = firefox - 2 or 3 folders - 2 instances of AE text editor.
I tried it after closing FF, same results.

Post by Steven Levine

Post by Mr. G
Been running Object Rexx for years on my OS/2
MCP2 partition without this problem.

Is it possible you recently modified a script that uses lots of files
or large stems?

In a manner of speaking, yes. Latest script uses 12 files, but
only one at a time. Was careful to close each file before opening
the next, so I think I'm safe there. Stems aren't large (15 elements),
but there are about 200 of them. Is that the issue?

Post by Steven Levine
Steven

[Steven Levine]

On Tue, 3 Jan 2012 17:08:39 UTC, "Mr. G" <***@yahoo.com> wrote:

Hi,

Post by Mr. G
Open items = firefox - 2 or 3 folders - 2 instances of AE text editor.
I tried it after closing FF, same results.

I decided to look at this a bit more . It turns out we have a
matching .sym file for this orexx.dll build which makes analysis a lot
easier.

The trap is caused by something going wrong in the shared memory heap
logic. My guess that it is file related is probably not correct. For
reasons yet unknown 0x12000000, which is supposed to point to a block
in the shared heap, is not accessible. We both fail for the same
address, which may mean something.

Next time this occurs here, I'll capture a process dump and see what
it reveals.

Post by Mr. G
only one at a time. Was careful to close each file before opening
the next, so I think I'm safe there. Stems aren't large (15 elements),
but there are about 200 of them. Is that the issue?

Could be, although I suspect memory corruption of some sort. The
reason closing VIO sessions resolves the issue is because eventually
rexx.dll will unload and the its presumable corrupted shared memory
heap will be released.

I'll know more once I see what the headers of valid heap blocks look
like.

Steven

[A.D. Fundum]

Post by Steven Levine
My guess that it is file related is probably not correct.

File handles, and so on: not worth mentoining, if relevant at all.
File functions, like CharIn() and FileIn(): correc, even if you don't
store the return value (i.e. the data) in a variabet.

Post by Steven Levine
I suspect memory corruption of some sort.

Running out of shared memory seems to be more likely, unless it
overflows and tries to use the same memory again. But then it's still
running out of unfreed memory. Maybe th etype of memory is used to
support "objects" (used by nobody).

Porting a stable version of ooRexx like 3.2.x is a better bet, who
really needs OO in an INSTALL.CMD. But please be aware of the fact
that it'll deserve an extremely low priority. A regular user of ORexx
only will have problems in a few situations, like when trying to
install a GenMac WPI file (WPI doesn't detect the ORexx interpreter).
Rexx is about INSTALL.CMDs, thanks goodness I've never seen a serious
OO app written in Rexx. Going OO is the worst thing that ever happened
to the language, and Regina (not embedded) probably is the best
Classic Rexx interpreter.


--

[Steven Levine]

On Tue, 3 Jan 2012 19:26:07 UTC, "A.D. Fundum" <***@neverm.ind>
wrote:

Hi,

Post by A.D. Fundum

Post by Steven Levine
I suspect memory corruption of some sort.

Running out of shared memory seems to be more likely,

Unlikely.

Post by A.D. Fundum
unless it
overflows and tries to use the same memory again.

Not based on the location and nature of the trap. Have you actually
looked at the code at the trap location?

Post by A.D. Fundum
Porting a stable version of ooRexx like 3.2.x is a better bet,

Are you volunteering? All it takes is sweat labor.

Steven

[A.D. Fundum]

Post by Steven Levine

Post by A.D. Fundum
Running out of shared memory seems to be more likely,

Unlikely.

The number of executions doesn't matter, as long as it's at least one.
The size of the data used does matter. Try splitting a large file in
parts of 15 MB, and most likely the next Rexx app will "EXIT" the
whole session. Without looking at broken code, running out of memory
is anything but unlikely (while it still may be as wrong as "file
handles").

The app doesn't have to store the data in a variable, ISTR this enough
to cause a possible crash:

CALL Charout 'OUT',CharIn'(IN',,15*1024*1024))

Post by Steven Levine

Post by A.D. Fundum
Porting a stable version of ooRexx like 3.2.x is a better bet

Are you volunteering? All it takes is sweat labor

Didn't I mention the priority it deserves (according to other people)?

And I didn't mention my skills... ;-) Besides that, wtf cares about
ooRexx? Not to mention that ooRexx doesn't care about OS/2. If your
Rexx doesn't have to be open (i.e. any idiot can add any silly
Unix-specific macro to it), and if your Rexx doesn't have to be OO
(I'm not aware of any meaningfull ORexx/2 app), I'ld say Regina/2 is a
better bet than using an early ooRexx-version to repair a single bug.
If it can run CRexx apps, you're done. New "stuff" like its execution
speed, ANSI-compliant syntax checking and improved functions are
extras.


--

[Remy]

 >> Running out of shared memory seems to be more likely,
 > Unlikely.
The number of executions doesn't matter, as long as it's at least one.
The size of the data used does matter. Try splitting a large file in
parts of 15 MB, and most likely the next Rexx app will "EXIT" the
whole session. Without looking at broken code, running out of memory
is anything but unlikely (while it still may be as wrong as "file
handles").
The app doesn't have to store the data in a variable, ISTR this enough
CALL Charout 'OUT',CharIn'(IN',,15*1024*1024))
 >> Porting a stable version of ooRexx like 3.2.x is a better bet
 > Are you volunteering?  All it takes is sweat labor
Didn't I mention the priority it deserves (according to other people)?
And I didn't mention my skills... ;-) Besides that, wtf cares about
ooRexx? Not to mention that ooRexx doesn't care about OS/2. If your
Rexx doesn't have to be open (i.e. any idiot can add any silly
Unix-specific macro to it), and if your Rexx doesn't have to be OO
(I'm not aware of any meaningfull ORexx/2 app), I'ld say Regina/2 is a
better bet than using an early ooRexx-version to repair a single bug.
If it can run CRexx apps, you're done. New "stuff" like its execution
speed, ANSI-compliant syntax checking and improved functions are
extras.
--

Using variable, try use DROP of the variable before using it again to
fully free memory.
RD.

[A.D. Fundum]

Post by Remy
Using variable, try use DROP of the variable before using it again
to fully free memory.

Which has no use, there's no variable involved at all in a few:

CALL CharOut 'FOO',CharIn('BAR',,3354432)


--

[Mr. G]

Post by A.D. Fundum

Post by Steven Levine
My guess that it is file related is probably not correct.

File handles, and so on: not worth mentoining, if relevant at all.
File functions, like CharIn() and FileIn(): correc, even if you don't
store the return value (i.e. the data) in a variabet.

Well I do use LineIn() on about 305,000 lines in the files.

Post by A.D. Fundum

Post by Steven Levine
I suspect memory corruption of some sort.

Running out of shared memory seems to be more likely, unless it
overflows and tries to use the same memory again. But then it's still
running out of unfreed memory. Maybe th etype of memory is used to
support "objects" (used by nobody).
Porting a stable version of ooRexx like 3.2.x is a better bet, who
really needs OO in an INSTALL.CMD. But please be aware of the fact
that it'll deserve an extremely low priority. A regular user of ORexx
only will have problems in a few situations, like when trying to
install a GenMac WPI file (WPI doesn't detect the ORexx interpreter).
Rexx is about INSTALL.CMDs, thanks goodness I've never seen a serious
OO app written in Rexx. Going OO is the worst thing that ever happened
to the language, and Regina (not embedded) probably is the best
Classic Rexx interpreter.

[A.D. Fundum]

Post by Mr. G
Well I do use LineIn() on about 305,000 lines in the files.

That'll be the main cause, even if the lines aren't that long. If you
reduce the number of number (e.g. by using GREP, a Rexx DLL,
whatever), you'ld expect a number of tries better than 15-20 before
you've to perform a reboot/WPS reset. Let's hope Levine's code studies
will confim this.

In my most annoying case, I've written executables to read the 305k
lines and to create a summarized report. Rexx just processes that
small report instead of the far larger original data files, with the
exception of a Rexx file that's harder to port to an EXE (lack of
skills, I'm not a programmer).


--

[Mr. G]

Post by A.D. Fundum

Post by Mr. G
Well I do use LineIn() on about 305,000 lines in the files.

That'll be the main cause, even if the lines aren't that long. If you
reduce the number of number (e.g. by using GREP, a Rexx DLL,
whatever), you'ld expect a number of tries better than 15-20 before
you've to perform a reboot/WPS reset. Let's hope Levine's code studies
will confim this.
In my most annoying case, I've written executables to read the 305k
lines and to create a summarized report. Rexx just processes that
small report instead of the far larger original data files, with the
exception of a Rexx file that's harder to port to an EXE (lack of
skills, I'm not a programmer).

Data files were created as small as possible.
Every piece of data in each file is used.

[Steven Levine]

On Tue, 3 Jan 2012 23:03:48 UTC, "Mr. G" <***@yahoo.com> wrote:

Hi,

Post by Mr. G
Well I do use LineIn() on about 305,000 lines in the files.

That in itself does not seem to be an issue. However, I find that I
can often get get much better performance if I pull in the entire file
with charin() and use pos and substr to extract the individual lines.

Steven

[Mr. G]

On Wed, 4 Jan 2012 03:46:53 UTC, "Steven Levine"

Post by Steven Levine
Hi,

Post by Mr. G
Well I do use LineIn() on about 305,000 lines in the files.

That in itself does not seem to be an issue. However, I find that I
can often get get much better performance if I pull in the entire file
with charin() and use pos and substr to extract the individual lines.
Steven

Don't know if I would know how to do that to acomplish the
results I'm after.

[Mr. G]

On Tue, 3 Jan 2012 18:55:38 UTC, "Steven Levine"

Post by Steven Levine
Hi,

Post by Mr. G
Open items = firefox - 2 or 3 folders - 2 instances of AE text editor.
I tried it after closing FF, same results.

I decided to look at this a bit more . It turns out we have a
matching .sym file for this orexx.dll build which makes analysis a lot
easier.
The trap is caused by something going wrong in the shared memory heap
logic. My guess that it is file related is probably not correct. For
reasons yet unknown 0x12000000, which is supposed to point to a block
in the shared heap, is not accessible. We both fail for the same
address, which may mean something.
Next time this occurs here, I'll capture a process dump and see what
it reveals.

Post by Mr. G
only one at a time. Was careful to close each file before opening
the next, so I think I'm safe there. Stems aren't large (15 elements),
but there are about 200 of them. Is that the issue?

Could be, although I suspect memory corruption of some sort. The
reason closing VIO sessions resolves the issue is because eventually
rexx.dll will unload and the its presumable corrupted shared memory
heap will be released.
I'll know more once I see what the headers of valid heap blocks look
like.
Steven

Thanks, I'll stay tuned. The thing that puzzles me most, is
the fact I can open one cmd line and run scripts all day on it.
Close the cmd line, open a new cmd line, try to run a rexx script,
and the fault occurs. Even the eCS supplied calculator won't run.

BTW, in my haste, I gave misinformation. My stems are compound,
not single, so the total number of elements at any one time is
around 6000 or 9000 depending on which script I'm running.
I loop through this 12 times, with new values each loop.

[A.D. Fundum]

Post by Mr. G
Close the cmd line, open a new cmd line, try to run a rexx
script, and the fault occurs. Even the eCS supplied
calculator won't run.

Even a "/* NOP.CMD */" should fail, using this interpreter in this
situation.

Post by Mr. G
BTW, in my haste, I gave misinformation. My stems are
compound

Like reducing the numer of LineIn()s, reducing the size of the data
may also help. Albeit compound variables are Classic, I don't have an
app which reads a few small lines of data and creates a lot of
compound varaibales. It should be reprocucable: read files of 10 MB
(and close the CMD.EXE session, just like you mentioned). If it fails
after e.g. 20 MB, try creating a single compound variable holding 20
MB of data as a starting point:

DO x=1 TO 30
DO y=1 TO 1024
DO z=1 TO 1024
var.x.y.z='@'
END z
END y
END x
'@EXIT'

If that fails too, your variables are causing the same problem. If
not. the memory (type) is used differently. IOW, not everyhing is
guaranteed to use the limited shared memory. But finding this out
doesn't help you, the ORexx interpreter remains broken and its source
isn't available.


--

[Mr. G]

Post by A.D. Fundum

Post by Mr. G
Close the cmd line, open a new cmd line, try to run a rexx
script, and the fault occurs. Even the eCS supplied
calculator won't run.

Even a "/* NOP.CMD */" should fail, using this interpreter in this
situation.

Post by Mr. G
BTW, in my haste, I gave misinformation. My stems are
compound

Like reducing the numer of LineIn()s, reducing the size of the data
may also help. Albeit compound variables are Classic, I don't have an
app which reads a few small lines of data and creates a lot of
compound varaibales. It should be reprocucable: read files of 10 MB
(and close the CMD.EXE session, just like you mentioned). If it fails
after e.g. 20 MB, try creating a single compound variable holding 20
DO x=1 TO 30
DO y=1 TO 1024
DO z=1 TO 1024
END z
END y
END x

I sort of messed up here. Some of my scripts it's easier to
use stems, others it's easier to use an ORexx array. In this
case, I think I should have used the arrays, but I'm too
lazy to rewrite it. Guess I had tail on my mind that day :-)

Post by A.D. Fundum
If that fails too, your variables are causing the same problem. If
not. the memory (type) is used differently. IOW, not everyhing is
guaranteed to use the limited shared memory. But finding this out
doesn't help you, the ORexx interpreter remains broken and its source
isn't available.

[Steven Levine]

On Tue, 3 Jan 2012 22:55:44 UTC, "Mr. G" <***@yahoo.com> wrote:

Hi,

Post by Mr. G
Thanks, I'll stay tuned.

We had a chance to today. Something I did triggered the exception.
Unfortunately, I was busy with other tasks and managed to fumble
finger the dump setup which resulting in a dump file that we missing
what I really wanted to look at. Oh well, there will be a next time.

Post by Mr. G
The thing that puzzles me most, is
the fact I can open one cmd line and run scripts all day on it.
Close the cmd line, open a new cmd line, try to run a rexx script,
and the fault occurs. Even the eCS supplied calculator won't run.

Like most everything else, it will be obvious why if I spend enough
time on it. I typically have multiple VIO sessions running and VIO
session came and go all the time and get launch by a number of
different techniques.

Post by Mr. G
BTW, in my haste, I gave misinformation. My stems are compound,
not single, so the total number of elements at any one time is
around 6000 or 9000 depending on which script I'm running.
I loop through this 12 times, with new values each loop.

I don't consider this a large data set. I reasonably often do things
like suck in 50K lines of text for one sort of processing or another.
I typically use to Perl for anything larger because while stem
variables indexing is convenient, it is not not particularly
efficient. For items counts of this order of magnitide, Perl hashes
are typically an order of magnitude faster and the system load is much
less.

Steven

[Mr. G]

On Wed, 4 Jan 2012 04:01:55 UTC, "Steven Levine"

Post by Steven Levine
Hi,

Post by Mr. G
Thanks, I'll stay tuned.

We had a chance to today. Something I did triggered the exception.
Unfortunately, I was busy with other tasks and managed to fumble
finger the dump setup which resulting in a dump file that we missing
what I really wanted to look at. Oh well, there will be a next time.

Post by Mr. G
The thing that puzzles me most, is
the fact I can open one cmd line and run scripts all day on it.
Close the cmd line, open a new cmd line, try to run a rexx script,
and the fault occurs. Even the eCS supplied calculator won't run.

Like most everything else, it will be obvious why if I spend enough
time on it. I typically have multiple VIO sessions running and VIO
session came and go all the time and get launch by a number of
different techniques.

Post by Mr. G
BTW, in my haste, I gave misinformation. My stems are compound,
not single, so the total number of elements at any one time is
around 6000 or 9000 depending on which script I'm running.
I loop through this 12 times, with new values each loop.

I don't consider this a large data set. I reasonably often do things
like suck in 50K lines of text for one sort of processing or another.
I typically use to Perl for anything larger because while stem
variables indexing is convenient, it is not not particularly
efficient. For items counts of this order of magnitide, Perl hashes
are typically an order of magnitude faster and the system load is much
less.
Steven

I never learned perl or anything else for that matter.
I don't know if this old dog is ready to learn new tricks
or even wants to.
I know performance could be faster. As it stands now,
my script completes in less than 20 seconds and it
could probably be done in less than 5, but I'm not
really concerned with the difference.

[Shmuel (Seymour J.) Metz]

Post by Mr. G
I never learned perl or anything else for that matter.
I don't know if this old dog is ready to learn new tricks or even
wants to.
I know performance could be faster.

I use Perl, and the reasons have nothing to do with performance or
with bugs in OREXX. Perl is better at parsing data and CPAN has a lot
of useful modules for which no Rexx equivalent is available.

OTOH, I find Rexx code to be far easier to read and maintain in its
area of applicability.

[A.D. Fundum]

Post by Shmuel (Seymour J.) Metz
I use Perl

I.e. a right tool for a job, respecting limited knowledge. The ORexx
interpreter isn't good at processing a lot of file-I/O, because of the
"discovered" bug. Not to mention file-I/O speed, albeit a single
CharIn(file,1,filesize) and PARSE'ing the data ought to be faster.
That's why I recommended Regina (or SysFileSearch(), or ...), at least
for the 305k lines-processing part of the job.


--

[A.D. Fundum]

Post by Mr. G
Open items = firefox - 2 or 3 folders - 2 instances of AE text

editor.

Irrelevant.

Post by Mr. G

Post by Steven Levine
Is it possible you recently modified a script that uses lots of
files or large stems?

The number of files and number of stems is irrelevant. The (internal)
use of memory matters. File I/O functions always use a lot of unfreed
memory internally. Always. Avoid excessive file I/O, avoid excessive
use of memory. A possible way to avoid it as good as possible is to
write a data preprocessor uing another language. Don't look at other
apps, it's bogus and waisting your time.


--

[Mr. G]

Post by Mr. G

Post by Mr. G
Open items = firefox - 2 or 3 folders - 2 instances of AE text

editor.
Irrelevant.

Post by Mr. G

Post by Steven Levine
Is it possible you recently modified a script that uses lots of
files or large stems?

The number of files and number of stems is irrelevant. The (internal)
use of memory matters. File I/O functions always use a lot of unfreed
memory internally. Always. Avoid excessive file I/O, avoid excessive
use of memory. A possible way to avoid it as good as possible is to
write a data preprocessor uing another language. Don't look at other
apps, it's bogus and waisting your time.

"A possible way to avoid it as good as possible is to
write a data preprocessor uing another language."

At my skill level, there are two chances of that happening.
Slim and none.

[A.D. Fundum]

Post by Mr. G

Post by Mr. G
"A possible way to avoid it as good as possible is to
write a data preprocessor uing another language."

At my skill level, there are two chances of that happening.
Slim and none.

Understood. Sometimes tools like GREP can be used to reduce the number
of lines. And as mentioned earlier, you may be able to use Regina
(v3.6) to execute the apps that cause the problem. You may even write
a preprocessor using Regina Rexx, and process the data with IBM's
ORexx interpreter.

With a preprocessor, I mean an app/tool which reduces the size of the
data that has to be processed. If e.g. you are scanning 305k lines to
find 3 lines containing a specific error message, and you cannot use
SysFileSearch(), a preprocessor not using the shared memory reads the
305k lines and stores the 3 lines in a tiny file.


--

[Mr. G]

Post by A.D. Fundum

Post by Mr. G

Post by Mr. G
"A possible way to avoid it as good as possible is to
write a data preprocessor uing another language."

At my skill level, there are two chances of that happening.
Slim and none.

Understood. Sometimes tools like GREP can be used to reduce the number
of lines. And as mentioned earlier, you may be able to use Regina
(v3.6) to execute the apps that cause the problem. You may even write
a preprocessor using Regina Rexx, and process the data with IBM's
ORexx interpreter.
With a preprocessor, I mean an app/tool which reduces the size of the
data that has to be processed. If e.g. you are scanning 305k lines to
find 3 lines containing a specific error message, and you cannot use
SysFileSearch(), a preprocessor not using the shared memory reads the
305k lines and stores the 3 lines in a tiny file.

As stated earlier, every piece of data is used. Basically,
a line is read in, parsed into variables, processed, counted,
then move on to the next line. When all lines are processed
and counted, then percentages are calculated from totals.
It really should be fairly simple number crunching. To simplify
things, I generated the data files to contain nothing but intergers.

[A.D. Fundum]

Post by Mr. G
As stated earlier, every piece of data is used.

Irrelevant, regarding a preprocessor.

Post by Mr. G
then percentages are calculated from totals.

So if it's about the percentages, write a preprocessor in another
language producing it. You are NOT using/storing all data, isn't it?

One of my preprocessors also use all data (duh), crunches the number
and produces the stats. Then ORexx just processes those stats
(sorting, formatting, whatever), or summarized data. I want to know
the average age of women, I don't care if Wilma at line 304,999 is 37
years old.

Instead of adding conditions and assumptions, you'ld be better of
posting a piece of code. But I'm not going to look at it.


--

[Marty]

Post by Mr. G
On Tue, 3 Jan 2012 07:04:55 UTC, "Steven Levine"

Post by Steven Levine
If so, I get this exception now and then. It's a resource issue which
can be resolved with minimal fuss by closing all the open VIO session
windows. I've always suspected it's related to leaked file handles,
but I've never confirmed this.

Open items = firefox - 2 or 3 folders - 2 instances of AE text editor.
I tried it after closing FF, same results.

If any of those are launched via script (Firefox?) then there might
still be an attached VIO session. The key is that you need REXX.DLL to
become unreferenced so that it can unload itself and the system can free
any leaked resources. I agree with Steven on this and have seen it from
time to time myself. Sometimes my code's fault. Sometimes not. Parts
of the multimedia subsystem in REXX classic were actually sloppy enough
to trigger this issue after only a few invocations.

PS: Happy New Year, folks!

[John Small]

Post by Mr. G
On Mon, 2 Jan 2012 22:45:24 UTC, Andreas Schnellbacher

Post by Andreas Schnellbacher

Post by A.D. Fundum

I run rexx programs maybe 15-20 times, then no rexx programs will
run after that. cmd.exe will open on its own but will close if I
try to run another rexx program.

Try reseting the WPS instead of a reboot. Most likely the Rexx
interpreter is running out of shared memory.

It sounds as if you've switched to Object REXX. The outdated OS/2
implementation that comes with W4.x is full of bugs, so everyone
recommends to use the Classic REXX version instead, what is the
default selection for any OS/2 and eCS installation. Object REXX
for OS/2 was just (and unfortunately is still) in an alpha state.

Thing is, I take advantage of Object Rexx functions
which are not available in Classic.

Which functions would those be?

I ask because there were many functions added to Classic REXX's
REXXUTIL.DLL in some fixpak long ago. These added functions were not
however added to the documenhtation for Classic REXX. So It appears
that they are not available.

Lomg ago I set up my system to use Classic REXX with Object REXX's
help file. While I do have to weed through the object-oriented bits of
the help, I at least get the documentation for the newer REXXUTIL
functions which I use frequently.

Run EXEHDR against REXXUTIL.DLL to see if the functions you want are
there.

[A.D. Fundum]

Post by John Small

Post by Mr. G
Thing is, I take advantage of Object Rexx functions
which are not available in Classic.

Which functions would those be?

Date() supports more than one argument.

Post by John Small
I ask because there were many functions added to Classic
REXX's REXXUTIL.DLL in some fixpak long ago.

Please note mentioning other DLLs isn't an option, for one because
there's no "DLL manager" which automagically downloads and installs
trusted language additions. It's just an example, this isn't about
REXXDATE.DLL.


--

[Mr. G]

Post by John Small

Post by Mr. G
On Mon, 2 Jan 2012 22:45:24 UTC, Andreas Schnellbacher

Post by Andreas Schnellbacher

Post by A.D. Fundum

I run rexx programs maybe 15-20 times, then no rexx programs will
run after that. cmd.exe will open on its own but will close if I
try to run another rexx program.

Try reseting the WPS instead of a reboot. Most likely the Rexx
interpreter is running out of shared memory.

It sounds as if you've switched to Object REXX. The outdated OS/2
implementation that comes with W4.x is full of bugs, so everyone
recommends to use the Classic REXX version instead, what is the
default selection for any OS/2 and eCS installation. Object REXX
for OS/2 was just (and unfortunately is still) in an alpha state.

Thing is, I take advantage of Object Rexx functions
which are not available in Classic.

Which functions would those be?
I ask because there were many functions added to Classic REXX's
REXXUTIL.DLL in some fixpak long ago. These added functions were not
however added to the documenhtation for Classic REXX. So It appears
that they are not available.
Lomg ago I set up my system to use Classic REXX with Object REXX's
help file. While I do have to weed through the object-oriented bits of
the help, I at least get the documentation for the newer REXXUTIL
functions which I use frequently.
Run EXEHDR against REXXUTIL.DLL to see if the functions you want are
there.

I was referring to built in functions such as ChangeStr, CountStr,
Use, which are not in Classic.

Are you aware there are functions in RexxUtil that are not
documented in the ObjRexx help file. eCS includes them
in a text file, while Alex Taylor put them into .inf format for
everyone.

I guess that answers your question. Yes, I do have
documentation for all RexxUtil functions.

[A.D. Fundum]

Post by Mr. G

Post by John Small

Post by Mr. G
Thing is, I take advantage of Object Rexx functions
which are not available in Classic.

Which functions would those be?

I was referring to built in functions such as ChangeStr,
CountStr, Use, which are not in Classic.

FTR and to be fair: functions, i.e. not "USE", can be added to Rexx as
an external (!) function, because the function ChangeStr() can be
written using Classic Rexx. It doesn't add any new features to the
language, it's a macro.


--

[Mr. G]

Post by A.D. Fundum

Post by Mr. G

Post by John Small

Post by Mr. G
Thing is, I take advantage of Object Rexx functions
which are not available in Classic.

Which functions would those be?

I was referring to built in functions such as ChangeStr,
CountStr, Use, which are not in Classic.

FTR and to be fair: functions, i.e. not "USE", can be added to Rexx as
an external (!) function, because the function ChangeStr() can be
written using Classic Rexx. It doesn't add any new features to the
language, it's a macro.

Better to have someone else write the function properly,
then to have me fumble around trying to write it and
screw it up.

[A.D. Fundum]

Post by Mr. G

the function ChangeStr() can be written using Classic Rexx.
It doesn't add any new features to the language, it's a macro.

Better to have someone else write the function

http://groups.google.com, "change xedit author:cowlishaw"

If it doesn't already do exactly what you want, it may at least
inspire a beginner. Nevertheless using Regina, with its ChangeStr()
BIF, for this data processing step may be easier.


--

[A.D. Fundum]

Post by Mr. G
Thing is, I take advantage of Object Rexx functions
which are not available in Classic.

Just to mention an example: Date(), supporting more than CRexx' number
of arguments.

Post by Mr. G
Been running Object Rexx for years on my OS/2
MCP2 partition without this problem.

The number of years is irrelevant, unlike (internal) memory usage.
There's no version number of your magic version. ISTR avoidig the use
of "data" doesn't even matter:

/* MAY_FAIL.CMD */
largefile='C:\50MB.ZIP'
mb=1024*1024
part=0
DO WHILE Chars(largefile)>0
part=part+1
partname='50MB.'||Right('00'||part,3)
data=CharIn(largefile,,mb)
CALL CharOut partname,data
CALL CharOut partname
END
CALL CharOut largefile

If this works and used all availablememory, running the next Rexx
script will look like executing a CMD.EXE "EXIT". A reboot or WPS
reset frees te memeory again.


--

[Mr. G]

Post by A.D. Fundum

Post by Mr. G
Thing is, I take advantage of Object Rexx functions
which are not available in Classic.

Just to mention an example: Date(), supporting more than CRexx' number
of arguments.

Post by Mr. G
Been running Object Rexx for years on my OS/2
MCP2 partition without this problem.

The number of years is irrelevant, unlike (internal) memory usage.
There's no version number of your magic version. ISTR avoidig the use
/* MAY_FAIL.CMD */
largefile='C:\50MB.ZIP'
mb=1024*1024
part=0
DO WHILE Chars(largefile)>0
part=part+1
partname='50MB.'||Right('00'||part,3)
data=CharIn(largefile,,mb)
CALL CharOut partname,data
CALL CharOut partname
END
CALL CharOut largefile
If this works and used all availablememory, running the next Rexx
script will look like executing a CMD.EXE "EXIT". A reboot or WPS
reset frees te memeory again.

The puzzling thing is, I can run the script 50-100 times
on the same instance of cmd.exe successfully, but running
it 15-20 times, closing cmd.exe then start a new instance
of cmd.exe and no script will run.
If I'm using all available memory after 15-20 runs, then I
shouldn't be able to run 50-100 times on one instance of
cmd.exe It should fail after the first 15-20 runs.

[A.D. Fundum]

Post by Mr. G
If I'm using all available memory after 15-20 runs, then
I shouldn't be able to run 50-100 times on one instance
of cmd.exe It should fail after the first 15-20 runs.

Unless it's reusing memory in the same CMD.EXE session, but it doesn't
free/release the memory when CMD.EXE is closed. Please note I haven't
investigated this, other people already have done it. It's a known
problem, no matter what the cause it. There's no real ORexx-based
solution, othar than trying to avoid it as much as possible.


--

[A.D. Fundum]

everyone recommends to use the Classic REXX version instead

No, for example because of the syntax checking and extended BIFs (not
the silly OO ones).

what is the default selection for any OS/2 and eCS installation.

That's not a Quality Reward. Instead it's guaranteed to be fully
compatible with all former OS/2 Rexx code, e.g. including the former
OS2ENVIRONMENT. OS/2's QBASIC.EXE doesn't mean the QBASIC is the best
BASIC interpreter.

FWIW and FTR: some WPI archives will fail to install with ORexx, for
example GenMac, and WPI doesn't detect the error. If you want to see a
failing ORexx interpreter, use it to split a large file in smaller
parts. No need to run some apps 15-20 times. There's Regina too,
albeit OORexx killed both Regina and ORexx for OS/2.


--

[Mr. G]

Post by A.D. Fundum

everyone recommends to use the Classic REXX version instead

No, for example because of the syntax checking and extended BIFs (not
the silly OO ones).

what is the default selection for any OS/2 and eCS installation.

That's not a Quality Reward. Instead it's guaranteed to be fully
compatible with all former OS/2 Rexx code, e.g. including the former
OS2ENVIRONMENT. OS/2's QBASIC.EXE doesn't mean the QBASIC is the best
BASIC interpreter.
FWIW and FTR: some WPI archives will fail to install with ORexx, for
example GenMac, and WPI doesn't detect the error. If you want to see a
failing ORexx interpreter, use it to split a large file in smaller
parts. No need to run some apps 15-20 times. There's Regina too,
albeit OORexx killed both Regina and ORexx for OS/2.

ooRexx may have killed Regina for OS/2, but would it be any
different running an old version Regina opposed to an OS/2
Rexx that hasn't been updated in over a decade?

[A.D. Fundum]

Post by Mr. G
ooRexx may have killed Regina for OS/2

Well, ISTR most Regina developments (for any OS) were stopped by Mark
Hessling (http://www.rexx.org), because now there's ooRexx (certainly
not for any OS supported by Regina).

Post by Mr. G
but would it be any different running an old version Regina

It's latest release for OS/2 is v3.6. Dated the 31th of december 2011,
i.e. a few days ago. So why use an "old version", if you want to use
Regina for some projects?

Post by Mr. G
opposed to an OS/2 Rexx that hasn't been updated in over a decade?

On its own the far more modern Regina is the best Classic Rexx
interpreter for OS/2, albeit there's no such thing as "the" Classic
Rexx programming language.

The answer to your question is yes, of course. There's "any
difference". Not everybody has Regina installed, while it's likely
IBM's Rexx is installed and embedded. The unupdatable IBM interpreter
isn't ANSI compliant, and it's far older than the updatable Regina.
Besides that, I don't think Regina is based on the IBM Rexx
interpreter for OS/2.

IOW: if you're the only user of your Rexx code which is likely to
crash due to this shared memory-related bug, any Regina/2 may be a
better Classic Rexx-based option than trying to avoid the situation.
But if you're going to distribute a typical INSTALL.CMD, don't write
it using Regina's special variables. If anybody is going to use
Regina/2, I don't know why you should use an old version.

If Regina/2 has to execute old IBM Rexx code without any chance,
chances are bugs have to be added to some mode of Regina/2. FTR:
Regina is the best implementation of the only Rexx standard (I guess
that'll be "ANSI X3J18-199X"). And, e.g., its Date() BIF supports 3
arguments, just like IBM'sORexx interpreter. So it's better, newer and
changable, but there's the IBM Rexx/2 legacy everybody's using. If
ORexx didn't execute most Classic Rexx code, I wouldn't be using it.
So Regina/2 already is a serious option, as long as you control the
system it's running on. Use IBM's ORexx for INSTALL.CMDs, and use
Regina for (parts of) apps with e.g. a lot of file-I/O. It's just an
option, easier than fixing or porting a silly OO interpreter that
never truely had OS/2 in mind (the selfish developers will be nice to
you, but essentially the answer is "no").


--

[Mr. G]

Post by A.D. Fundum

Post by Mr. G
ooRexx may have killed Regina for OS/2

Well, ISTR most Regina developments (for any OS) were stopped by Mark
Hessling (http://www.rexx.org), because now there's ooRexx (certainly
not for any OS supported by Regina).

Post by Mr. G
but would it be any different running an old version Regina

It's latest release for OS/2 is v3.6. Dated the 31th of december 2011,
i.e. a few days ago. So why use an "old version", if you want to use
Regina for some projects?

My mistake. When you said ooRexx killed Regina, that gave me the
impression Regina was no longer updated.

Post by A.D. Fundum

Post by Mr. G
opposed to an OS/2 Rexx that hasn't been updated in over a decade?

On its own the far more modern Regina is the best Classic Rexx
interpreter for OS/2, albeit there's no such thing as "the" Classic
Rexx programming language.
The answer to your question is yes, of course. There's "any
difference". Not everybody has Regina installed, while it's likely
IBM's Rexx is installed and embedded. The unupdatable IBM interpreter
isn't ANSI compliant, and it's far older than the updatable Regina.
Besides that, I don't think Regina is based on the IBM Rexx
interpreter for OS/2.
IOW: if you're the only user of your Rexx code which is likely to
crash due to this shared memory-related bug, any Regina/2 may be a
better Classic Rexx-based option than trying to avoid the situation.
But if you're going to distribute a typical INSTALL.CMD, don't write
it using Regina's special variables. If anybody is going to use
Regina/2, I don't know why you should use an old version.
If Regina/2 has to execute old IBM Rexx code without any chance,
Regina is the best implementation of the only Rexx standard (I guess
that'll be "ANSI X3J18-199X"). And, e.g., its Date() BIF supports 3
arguments, just like IBM'sORexx interpreter. So it's better, newer and
changable, but there's the IBM Rexx/2 legacy everybody's using. If
ORexx didn't execute most Classic Rexx code, I wouldn't be using it.
So Regina/2 already is a serious option, as long as you control the
system it's running on. Use IBM's ORexx for INSTALL.CMDs, and use
Regina for (parts of) apps with e.g. a lot of file-I/O. It's just an
option, easier than fixing or porting a silly OO interpreter that
never truely had OS/2 in mind (the selfish developers will be nice to
you, but essentially the answer is "no").

When one of the ooRexx developers was trying to push ooRexx
even though he knew I was using OS/2, I asked where the OS/2
version was then answered my own question by stating it didn't
exist. His reply obviously showed he took exception to my
statement, but he did say that if OS/2 was still a major
platform.....well, last time I looked, technically by the numbers,
Linux isn't a major platform either, yet there is an ooRexx for Linux.

[Shmuel (Seymour J.) Metz]

Post by A.D. Fundum
And, e.g., its Date() BIF supports 3
arguments, just like IBM'sORexx interpreter.

Isn't that part of ANSI compliance?