Re: [Oorexx-devel] Possible Documentation Change
Had a closer look at the RxSock.pdf. Definitely looks good. The notes are a bit prominent, perhaps, given they are mostly like this one: SockSendTo() interfaces with the C function sendto()." Mike -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Possible Documentation Change
Personally I don't like the font used in the text parts and the lack of page-breaks. Also the class object "pictures" is to low-res compared to the running text. Maybe I have read to many IBM manuals, that has an easy reading font and mostly, page-breaks at a suitable place. /hex - Ursprungligt Meddelande: Från: David Ashley Till: Open Object Rexx Developer Mailing List Kopia: Datum: tisdag, 07 augusti 2012 23:02 Ämne: Re: [Oorexx-devel] Possible Documentation Change I have refreshed the documents on the Build Server. I created a new brand so now the doc references the correct license. I think this is pretty close to as finished as I can make it. As to the formatting issues, the Publican system uses CSS formatting. As you may or may not know CSS is very weak in formatting multi-page output for PDF documents. This because it primary use is for HTML pages which have no multi-page concerns. The result can be some odd page breaks in your PDF outout. There is not much you can do about this and anything you do will probably make the situation worse either now or in the future. But for the most part we can live with these issues as long as the content does not go missing completely. David Ashley On Tue, 2012-08-07 at 20:41 +0100, Jeremy Nicoll - ml sourceforge wrote: > David Ashley wrote: > > > The document looks outstanding! > > It's certainly polished, in places. I just looked at some pages at random > though and found one problem, where the shaded box around a syntax diagram > straddles a page break - for 5.18 SockRecv at the foot of page 24. > > Similarly (though not as bad) see "7.2.16 state" at the foot of p55. > > And at the foot of p36 there's a "where" that's not connected with the text > it introduces. > > > I've never used XML or DocBook, but did long ago use IBM's DCF/Script > package, writing macros for quite complex 3-pass processing of documents > (where the macros did different things on different passes). Script had > control words (dot commands) for bracketing sections of text that should not > be broken up, and others eg to force a page break if there was insufficient > space at the foot of one page to start a new section of a document. (These > things only got used if one wrote macros that issued them with appropriate > arguments in appropriate places.) > > The output from this system looks a lot like it's created nice looking text > but just poured it onto a series of pages without taking page-breaks into > account. > > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] [Ibm-netrexx] ASCII or EBCDIC?
René, Go ahead and give me all the good news, as I have determined that I'm NOT the guy to port ooRexx to z/os. While z/os USS is true to the letter of the law where Unix is concerned, it is not true to the spirit of the law. It doesn't contain all of the programs and utilities that one would reasonably expect Unix to have. Perhaps someday in the near future this will all change, but until it does, I think NetRexx is where IBM obviously wants REXX to go. I have learned through many years of banging my head against the wall not to buck IBM. They are just too big and powerful, and the hold the scimitar of death over my head. Earl On Aug 8, 2012, at 7:57 AM, rvjansen wrote: > On z/OS the translation is automatic, and done by the Java runtime. EBCDIC > ends up as the right Java types as char (16 bit Unicode) and String. When > doing multiplatform development over ASCII and EBCDIC environments, one > should refrain from doing things as assuming the numerical value and sequence > of characters - this will fail; but keep to Rexx, String and char and > everything works. > > Spreading the answers over several emails because I don't want to discourage > you from porting ooRexx to z/OS with too much good news at once ... > > best regards, > > René. > > > > On 2012-08-08 13:51, rvjansen wrote: >> But do note, that while it is Unicode, to send actual Unicode into >> program files as program source, there is an option -utf8 for the >> translator. >> >> I opened an issue to make this the default, but am not aware of all >> consequences of this and receive not enough feedback to put that into >> 3.01. >> >> best regards, >> >> René. >> >> >> On 2012-08-08 13:46, Earl Hodil wrote: >>> What character set does NetRexx work in: ASCII or EBCDIC? >>> >>> >>> Second question: Does NetRexx handle character set conversions >>> automatically? >>> >>> >>> Thanks to whomever answers! >>> >>> Earl Hodil >>> >>> ___ >>> Ibm-netrexx mailing list >>> ibm-netr...@hursley.ibm.com >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> >> ___ >> Ibm-netrexx mailing list >> ibm-netr...@hursley.ibm.com >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > ___ > Ibm-netrexx mailing list > ibm-netr...@hursley.ibm.com > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] [Ibm-netrexx] ASCII or EBCDIC?
'For what it's worth' .. the *binary* .class files of the NetRexx compiler/interpreter worked first time when copied across to (EBCDIC) VM. And 'Hello World' complied (and the result was readable) :-). I found that to be a compelling example that 'write once, run anywhere' really could be real, at least for text/console-based applications. Mike -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] [Ibm-netrexx] ASCII or EBCDIC?
[thanks for moving the thread to ooRexx as far as ooRexx is concerned] Earl, in my opinion, IBM does not have an opinion on this. NetRexx was briefly a part of VM but not anymore I heard. Apart from Mark Cathcart and a small band of others nobody really went deep into the use of NetRexx on z/OS. It opted for not adding the stream I/O library in an easy way to Rexx (but we have opened channels to the dev team last symposium with the help of Virgil) and seemingly stabilize it on TSO (but this is not true, they are doing a lot of work - we saw the logs). It would be great if ooRexx was available on z/OS; IBM is not going to do it; RexxLA (the ooRexx development team) has the source. It would be great for Rexx, and great for RexxLA. When I ported ooRexx 3 first to MacOSX, I was in the same position (autoconf, automake out of date. gcc slighlty older than needed) and had to distill a makefile out of something that nearly worked on Linux (could not link with the C runtime I had at the time). With the help of Mark Hessling, David and Rick, eventually I came to something that worked, but failing mysterously for some builds. Turned out that ooRexx 3 used System-V IPC mechanisms (shared memory) that needed adjustment, and that support for these API's was very shaky in early versions of MacOSX. This was subsequently fixed in ooRexx 4, which uses the IP stack for its IPC in the RXAPI daemon module. I only want to say here: the build environment and the makefile is a hurdle that can be overcome, and the shared memory issue is removed. It would be mighty interesting to see how far we can come with a z/OS ooRexx build. Terry is also looking into it, and if we combine forces and engage the development team we might go far. I sincerely do not think IBM (if seen as one entity) has any opinion on this, except for being happy if its customes are happy, much less that it is steering the Rexx family somewhere. I know a lot of customers who would be very happy to take the next step with ooRexx if it also would work on the Big Iron. best regards, René. On 2012-08-08 14:12, Earl Hodil wrote: > René, > > Go ahead and give me all the good news, as I have determined that I'm > NOT the guy to port ooRexx to z/os. While z/os USS is true to the > letter of the law where Unix is concerned, it is not true to the > spirit of the law. It doesn't contain all of the programs and > utilities that one would reasonably expect Unix to have. Perhaps > someday in the near future this will all change, but until it does, I > think NetRexx is where IBM obviously wants REXX to go. > > I have learned through many years of banging my head against the wall > not to buck IBM. They are just too big and powerful, and the hold the > scimitar of death over my head. > > Earl > > On Aug 8, 2012, at 7:57 AM, rvjansen wrote: > >> On z/OS the translation is automatic, and done by the Java runtime. >> EBCDIC ends up as the right Java types as char (16 bit Unicode) and >> String. When doing multiplatform development over ASCII and EBCDIC >> environments, one should refrain from doing things as assuming the >> numerical value and sequence of characters - this will fail; but keep >> to Rexx, String and char and everything works. >> >> Spreading the answers over several emails because I don't want to >> discourage you from porting ooRexx to z/OS with too much good news at >> once ... >> >> best regards, >> >> René. >> >> >> >> On 2012-08-08 13:51, rvjansen wrote: >>> But do note, that while it is Unicode, to send actual Unicode into >>> program files as program source, there is an option -utf8 for the >>> translator. >>> >>> I opened an issue to make this the default, but am not aware of all >>> consequences of this and receive not enough feedback to put that >>> into >>> 3.01. >>> >>> best regards, >>> >>> René. >>> >>> >>> On 2012-08-08 13:46, Earl Hodil wrote: What character set does NetRexx work in: ASCII or EBCDIC? Second question: Does NetRexx handle character set conversions automatically? Thanks to whomever answers! Earl Hodil ___ Ibm-netrexx mailing list ibm-netr...@hursley.ibm.com Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >>> ___ >>> Ibm-netrexx mailing list >>> ibm-netr...@hursley.ibm.com >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> >> ___ >> Ibm-netrexx mailing list >> ibm-netr...@hursley.ibm.com >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security
Re: [Oorexx-devel] [Ibm-netrexx] ASCII or EBCDIC?
I too would be happy to see ooRexx on MVS, I'm just not the person to do it. Yes, I have access to a z/os system, but NO, I do not have the expertise to do it. Surely someone else has access to a z/os system. What about Mr. REXX himself, Mike Cowlishaw? He's an IBM fellow. I'm sure he could persuade IBM to give him his own zPDT system, if he asked (not that it would be required. A TSO ID on a time-sharing system would suffice). Earl On Aug 8, 2012, at 8:35 AM, rvjansen wrote: > [thanks for moving the thread to ooRexx as far as ooRexx is concerned] > > Earl, > > in my opinion, IBM does not have an opinion on this. NetRexx was > briefly a part of VM but not anymore I heard. Apart from Mark Cathcart > and a small band of others nobody really went deep into the use of > NetRexx on z/OS. It opted for not adding the stream I/O library in an > easy way to Rexx (but we have opened channels to the dev team last > symposium with the help of Virgil) and seemingly stabilize it on TSO > (but this is not true, they are doing a lot of work - we saw the logs). > > It would be great if ooRexx was available on z/OS; IBM is not going to > do it; RexxLA (the ooRexx development team) has the source. It would be > great for Rexx, and great for RexxLA. > > When I ported ooRexx 3 first to MacOSX, I was in the same position > (autoconf, automake out of date. gcc slighlty older than needed) and had > to distill a makefile out of something that nearly worked on Linux > (could not link with the C runtime I had at the time). With the help of > Mark Hessling, David and Rick, eventually I came to something that > worked, but failing mysterously for some builds. Turned out that ooRexx > 3 used System-V IPC mechanisms (shared memory) that needed adjustment, > and that support for these API's was very shaky in early versions of > MacOSX. This was subsequently fixed in ooRexx 4, which uses the IP stack > for its IPC in the RXAPI daemon module. > > I only want to say here: the build environment and the makefile is a > hurdle that can be overcome, and the shared memory issue is removed. It > would be mighty interesting to see how far we can come with a z/OS > ooRexx build. Terry is also looking into it, and if we combine forces > and engage the development team we might go far. > > I sincerely do not think IBM (if seen as one entity) has any opinion on > this, except for being happy if its customes are happy, much less that > it is steering the Rexx family somewhere. I know a lot of customers who > would be very happy to take the next step with ooRexx if it also would > work on the Big Iron. > > best regards, > > René. > > On 2012-08-08 14:12, Earl Hodil wrote: >> René, >> >> Go ahead and give me all the good news, as I have determined that I'm >> NOT the guy to port ooRexx to z/os. While z/os USS is true to the >> letter of the law where Unix is concerned, it is not true to the >> spirit of the law. It doesn't contain all of the programs and >> utilities that one would reasonably expect Unix to have. Perhaps >> someday in the near future this will all change, but until it does, I >> think NetRexx is where IBM obviously wants REXX to go. >> >> I have learned through many years of banging my head against the wall >> not to buck IBM. They are just too big and powerful, and the hold the >> scimitar of death over my head. >> >> Earl >> >> On Aug 8, 2012, at 7:57 AM, rvjansen wrote: >> >>> On z/OS the translation is automatic, and done by the Java runtime. >>> EBCDIC ends up as the right Java types as char (16 bit Unicode) and >>> String. When doing multiplatform development over ASCII and EBCDIC >>> environments, one should refrain from doing things as assuming the >>> numerical value and sequence of characters - this will fail; but keep >>> to Rexx, String and char and everything works. >>> >>> Spreading the answers over several emails because I don't want to >>> discourage you from porting ooRexx to z/OS with too much good news at >>> once ... >>> >>> best regards, >>> >>> René. >>> >>> >>> >>> On 2012-08-08 13:51, rvjansen wrote: But do note, that while it is Unicode, to send actual Unicode into program files as program source, there is an option -utf8 for the translator. I opened an issue to make this the default, but am not aware of all consequences of this and receive not enough feedback to put that into 3.01. best regards, René. On 2012-08-08 13:46, Earl Hodil wrote: > What character set does NetRexx work in: ASCII or EBCDIC? > > > Second question: Does NetRexx handle character set conversions > automatically? > > > Thanks to whomever answers! > > Earl Hodil > > ___ > Ibm-netrexx mailing list > ibm-netr...@hursley.ibm.com > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>
Re: [Oorexx-devel] [Ibm-netrexx] ASCII or EBCDIC?
> I too would be happy to see ooRexx on MVS, I'm just not the > person to do it. Yes, I have access to a z/os system, but NO, > I do not have the expertise to do it. Surely someone else has > access to a z/os system. What about Mr. REXX himself, Mike > Cowlishaw? He's an IBM fellow. Umm, a *retired* IBM Fellow. That means I don't even have my IBM e-mail address anymore ... > I'm sure he could persuade IBM > to give him his own zPDT system, if he asked (not that it > would be required. A TSO ID on a time-sharing system would suffice). Wouldn't be much use to me or to Rexx, to be honest. Last time I used z/OS it was called MFT ... :-) Mike -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Error in Doc Build?
I just downloaded oodGuide.pdf from http://build.oorexx.org/builds/docs/8164/. When I looked at it (using Adobe Reader X vsn 10.1.3), I got this Adobe error for pages 26 and 27 (neither of which displayed): "There was an error processing a page. There was a problem reading this document. (109)" The previous build did not have this error, nor were there any changes in the XML files. I checked buildrpt.txt, but couldn't see anything obvious. Was there a change of some sort in the build? -- Oliver Sims (PS: Btw, my name on the front page of oodGuide should have only a single "m".) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Possible Documentation Change
The doc looks really good. Only one thing I'd suggest, and that is that the "body text" might be better in a serifed font. In my IBM career, I spent a short time in OP, and their received wisdom was that a serifed font is 10% easier to read than a sans-serif one. Personally, I agree, but that might just be me... Oliver Sims -Original Message- From: David Ashley [mailto:w.david.ash...@gmail.com] Sent: 07 August 2012 18:34 To: ooRexxDevel Subject: [Oorexx-devel] Possible Documentation Change All - After over a year of struggle and tries, I finally got the Publican system to compile one of our documents, The output is simply too good to be true. The document looks outstanding! You can find the document on the Build Server at release_candidates/rxsock.pdf. There are some problems with this document. 1. I used the "common" brand in compiling the document. This refers to the Creative Commons license so you will see that referenced in the document. We will need to create our own brand to refer to the CPL. 2. Not all the content from the original document is there. That was just me being lazy. 3. Some of the images are not showing up. I need to look into that. If you are interested in what Publican is and how it relates to Docbook refer to https://fedorahosted.org/publican/. Please let me know what you think. David Ashley ooRexx Team -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Error in Doc Build?
On Wed, Aug 8, 2012 at 7:52 AM, Oliver Sims wrote: > I just downloaded oodGuide.pdf from > http://build.oorexx.org/builds/docs/8164/. When I looked at it (using Adobe > Reader X vsn 10.1.3), I got this Adobe error for pages 26 and 27 (neither of > which displayed): > > "There was an error processing a page. There was a problem reading this > document. (109)" It works fine for me. It is likely that it somehow got corrupted during your download. I'd try to download a fresh copy. > (PS: Btw, my name on the front page of oodGuide should have only a single > "m".) Sorry, a typo on my part while you were out of town. You can fix it yourself, after all you're a committer.Go to the legalstuff.xml file in the ooguide directory, fix the typo, commit. (Line 69) -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Error in Doc Build?
Another download didn't work either. But another another did. Many thanks. Ref name - many thx - techies never look at "legal stuff" (and sometimes suffer consequences)... -- Oliver Sims -Original Message- From: Mark Miesfeld [mailto:miesf...@gmail.com] Sent: 08 August 2012 14:52 To: Open Object Rexx Developer Mailing List Subject: Re: [Oorexx-devel] Error in Doc Build? On Wed, Aug 8, 2012 at 7:52 AM, Oliver Sims wrote: > I just downloaded oodGuide.pdf from > http://build.oorexx.org/builds/docs/8164/. When I looked at it (using > Adobe Reader X vsn 10.1.3), I got this Adobe error for pages 26 and 27 > (neither of which displayed): > > "There was an error processing a page. There was a problem reading > this document. (109)" It works fine for me. It is likely that it somehow got corrupted during your download. I'd try to download a fresh copy. > (PS: Btw, my name on the front page of oodGuide should have only a > single > "m".) Sorry, a typo on my part while you were out of town. You can fix it yourself, after all you're a committer.Go to the legalstuff.xml file in the ooguide directory, fix the typo, commit. (Line 69) -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Status of REXX at IBM
I would like to move this conversation to the REXXLA list. Just what is the status of REXX at IBM? Does REXXLA have an official IBM contact? As a developer of a REXX-related product, I have to justify my existence every year. And when we tell IBM that we are working on a REXX product, we get a big yawn. They want to know how we're going to help them sell some IBM key technology or application, and quite frankly we get the impression that REXX ain't it. Of course, they haven't cut us off yet; so I guess that's something. Earl Hodil Open Software Technologies On Aug 8, 2012, at 9:26 AM, Mike Cowlishaw wrote: > >> I too would be happy to see ooRexx on MVS, I'm just not the >> person to do it. Yes, I have access to a z/os system, but NO, >> I do not have the expertise to do it. Surely someone else has >> access to a z/os system. What about Mr. REXX himself, Mike >> Cowlishaw? He's an IBM fellow. > > Umm, a *retired* IBM Fellow. That means I don't even have my IBM e-mail > address > anymore ... > >> I'm sure he could persuade IBM >> to give him his own zPDT system, if he asked (not that it >> would be required. A TSO ID on a time-sharing system would suffice). > > Wouldn't be much use to me or to Rexx, to be honest. Last time I used z/OS it > was called MFT ... :-) > > Mike > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] "New" SYSFILETREE order of returned values
This is on win7 64bit and oorexx 4.2.0 8149. Using the new SYSFILETREE , maybe it also applies to the "old" SYSFILETREE!, I have a question. In what order is the result returned in the steam ? Reading a windows path, it seems the result is returned in alphabetic order, but reading a networkpath (UNC path) I can't figure out in what order the result is returned. Using this: call SysFileTree "\\mypath\*.*", "file", "LB", "**-**" the result seems to be returned in a arbitrary order. \\mypath is a linuxmachine /hex-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] "New" SYSFILETREE order of returned values
On Wed, Aug 8, 2012 at 11:07 AM, hakan wrote: > This is on win7 64bit and oorexx 4.2.0 8149. > Using the new SYSFILETREE , maybe it also applies to the "old" SYSFILETREE!, > I have a question. There is nothing in the reworked code that would change this from the previous version. > In what order is the result returned in the steam ? > Reading a windows path, it seems the result is returned in alphabetic order, > but reading a networkpath (UNC path) I can't figure out in what order the > result is returned. > Using this: > call SysFileTree "\\mypath\*.*", "file", "LB", "**-**" > the result seems to be returned in a arbitrary order. > \\mypath is a linuxmachine SysFileTree does nothing to change the order of the files returned by the Windows API. It uses the Windows APIs, FindFirstFile() / FindNextFile(). Whatever order these APIs return the found files in, will be the order in the stem. This is dictated by the operating system, there are no options to pass into the APIs to change the order. Note that I would be careful about using UNC path names for SysFileTree(). There is nothing in the docs saying UNC path names are acceptable. And there is nothing in the original IBM code that points to any consideration being given to the possibility of UNC path names being used. I'm not saying it won't work, and maybe there is no problem. I'm just saying it doesn't look like any thought was given to that possibility. I didn't dig into that possibility while going through the code either. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] "New" SYSFILETREE order of returned values
Ok, I see I haven't tried the "old" sysfiletree with UNC path so have no clue if it differs in result returned, probably not. The "new" sysfiletree seems to work with UNC path's from Win7 anyhow and the returned values is in arbitrary order, the same arbitrary order is returned if the the path is on a mapped network drive (drive letter), but looking at the same path/drive letter in windowsexplorer shows files in alphabetic order, maybe they are sorted before display! Maybe a note in the manual about this can be useful, if this behaviour is confirmed by others/testing. /hex - Ursprungligt Meddelande: Från: Mark Miesfeld Till: hexi...@users.sourceforge.net, Open Object Rexx Developer Mailing List Kopia: Datum: onsdag, 08 augusti 2012 20:47 Ämne: Re: [Oorexx-devel] "New" SYSFILETREE order of returned values On Wed, Aug 8, 2012 at 11:07 AM, hakan wrote: > This is on win7 64bit and oorexx 4.2.0 8149. > Using the new SYSFILETREE , maybe it also applies to the "old" SYSFILETREE!, > I have a question. There is nothing in the reworked code that would change this from the previous version. > In what order is the result returned in the steam ? > Reading a windows path, it seems the result is returned in alphabetic order, > but reading a networkpath (UNC path) I can't figure out in what order the > result is returned. > Using this: > call SysFileTree "\\mypath\*.*", "file", "LB", "**-**" > the result seems to be returned in a arbitrary order. > \\mypath is a linuxmachine SysFileTree does nothing to change the order of the files returned by the Windows API. It uses the Windows APIs, FindFirstFile() / FindNextFile(). Whatever order these APIs return the found files in, will be the order in the stem. This is dictated by the operating system, there are no options to pass into the APIs to change the order. Note that I would be careful about using UNC path names for SysFileTree(). There is nothing in the docs saying UNC path names are acceptable. And there is nothing in the original IBM code that points to any consideration being given to the possibility of UNC path names being used. I'm not saying it won't work, and maybe there is no problem. I'm just saying it doesn't look like any thought was given to that possibility. I didn't dig into that possibility while going through the code either. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] "New" SYSFILETREE order of returned values
I noticed this issue with a samba share. If you try doing a 'dir' from the command line, my guess would be you would get the same results. My search lead me to this fix: http://www.samba.org/samba/docs/man/manpages-3/vfs_dirsort.8.html -- Brandon Cherry On 8/8/2012 3:10 PM, hakan wrote: > Ok, I see > I haven't tried the "old" sysfiletree with UNC path so have no clue if it > differs in result returned, probably not. > The "new" sysfiletree seems to work with UNC path's from Win7 anyhow and the > returned values is in arbitrary order, the same arbitrary order is returned > if the the path is on a mapped network drive (drive letter), but looking at > the same path/drive letter in windowsexplorer shows files in alphabetic > order, maybe they are sorted before display! > > Maybe a note in the manual about this can be useful, if this behaviour is > confirmed by others/testing. > /hex -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Speaking of SysFileTree in trunk ...
I was going to bring this up, but probabaly after I had done some more testing. However since /hex just brought up SysFileTree, I'll do it now. I had wanted to include the new SysFileTree code in 4.1.2 because it definitely fixes some reproducible bugs in Linux. In Windows, I gave a version to Jerry, the submitter of the Windows bug, a version of ooRexx that had SysFileTreeB() and SysFileTree(). He tested it for a week and was able to reproduce the bug using SysFileTree 4 times in a week of testing, and never using SysFileTreeB(). Not conclusive, but an indication that the new code might fix the Windows bug. I myself tested a lot that the newer version produces the same results as the old version. However, on Friday I discovered what I thought might be a memory leak on Windows. So I won't put it in 4.1.2, but the new version does exist in trunk. What I did was put a simple routine that does a SysFileTree search for all files on my system in an endless loop. The returned stem from 1 iteration holds about 300,000 file names in the long format. On a Windows 64-bit system, memory used by rexx.exe keeps increasing until at 98% of total memory had to kill it. I have 4 GB of memory and the Rexx process used up to about 3,500 MB of it before I killed it. Since in the new version, there is the possibility of a lot more dynamically allocated memory, I first thought I had a memory leak But, these facts make me wonder if it might be something else: Running the exact same source code and same test on a Windows 32-bit machine. Memory used by the Rexx process rose to about 2400 MB and then stayed there. The system also has 4 GB of memory. I ran the test program for 48 hours and then quit because the memory had stayed steady for about 46 hours. Whereas on the 64-bit system, memory maxed out after about, I don't know exactly, but about 4 to 7 hours. I have a trial version of Purify that only runs on 32-bit. I ran the test program under it. Running one iteration, Purify report a memory loss of 28 bytes. Running 200 iterations, Purify reported a memory loss of, 28 bytes. Since it is a trial version it doesn't report where the memory loss happened. So the 28 bytes might not have even been allocated in SysFileTree. Originally in the code I was going to raise a condition if a string was longer than the static buffers. I ran that code a lot on the same 64-bit system and a condition was never raised. In the newer version, I replaced all the possible raised condition code with code that dynamically allocates memory. Therefore, in the current code, it seems possible that no dynamic memory is allocated to begin with. Making a memory leak in the new code unlikely to be the culprit. That's my next step, is to put a print out every time memory is allocated, and see if it actually happens. I still have to do that. However it's odd that the same memory problem doesn't happen on a 32-bit system. I wonder if the problem is with the garbage collector on 64-bit? -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Speaking of SysFileTree in trunk ...
There really shouldn't be an difference in the garbage collector on 64-bit vs 32.bit. The code itself is really independent of the size of the objects, but that's not a definitive statement that there might not be something strange going on. You might try rebuilding with _DEBUG and VERBOSE_GC defined. This will dump a lot of GC statistics that might give a clue as to the problem area. Rick On Wed, Aug 8, 2012 at 3:32 PM, Mark Miesfeld wrote: > I was going to bring this up, but probabaly after I had done some more > testing. However since /hex just brought up SysFileTree, I'll do it > now. > > I had wanted to include the new SysFileTree code in 4.1.2 because it > definitely fixes some reproducible bugs in Linux. > > In Windows, I gave a version to Jerry, the submitter of the Windows > bug, a version of ooRexx that had SysFileTreeB() and SysFileTree(). > He tested it for a week and was able to reproduce the bug using > SysFileTree 4 times in a week of testing, and never using > SysFileTreeB(). Not conclusive, but an indication that the new code > might fix the Windows bug. I myself tested a lot that the newer > version produces the same results as the old version. > > However, on Friday I discovered what I thought might be a memory leak > on Windows. So I won't put it in 4.1.2, but the new version does > exist in trunk. > > What I did was put a simple routine that does a SysFileTree search for > all files on my system in an endless loop. The returned stem from 1 > iteration holds about 300,000 file names in the long format. > > On a Windows 64-bit system, memory used by rexx.exe keeps increasing > until at 98% of total memory had to kill it. I have 4 GB of memory > and the Rexx process used up to about 3,500 MB of it before I killed > it. > > Since in the new version, there is the possibility of a lot more > dynamically allocated memory, I first thought I had a memory leak > > But, these facts make me wonder if it might be something else: > > Running the exact same source code and same test on a Windows 32-bit > machine. Memory used by the Rexx process rose to about 2400 MB and > then stayed there. The system also has 4 GB of memory. I ran the > test program for 48 hours and then quit because the memory had stayed > steady for about 46 hours. Whereas on the 64-bit system, memory maxed > out after about, I don't know exactly, but about 4 to 7 hours. > > I have a trial version of Purify that only runs on 32-bit. I ran the > test program under it. Running one iteration, Purify report a memory > loss of 28 bytes. Running 200 iterations, Purify reported a memory > loss of, 28 bytes. Since it is a trial version it doesn't report > where the memory loss happened. So the 28 bytes might not have even > been allocated in SysFileTree. > > Originally in the code I was going to raise a condition if a string > was longer than the static buffers. I ran that code a lot on the same > 64-bit system and a condition was never raised. In the newer version, > I replaced all the possible raised condition code with code that > dynamically allocates memory. > > Therefore, in the current code, it seems possible that no dynamic > memory is allocated to begin with. Making a memory leak in the new > code unlikely to be the culprit. That's my next step, is to put a > print out every time memory is allocated, and see if it actually > happens. I still have to do that. > > However it's odd that the same memory problem doesn't happen on a > 32-bit system. I wonder if the problem is with the garbage collector > on 64-bit? > > -- > Mark Miesfeld > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Speaking of SysFileTree in trunk ...
Thanks Rick. I meant to ask you about any debugging flags. -- Mark Miesfeld On Wed, Aug 8, 2012 at 12:48 PM, Rick McGuire wrote: > There really shouldn't be an difference in the garbage collector on 64-bit > vs 32.bit. The code itself is really independent of the size of the > objects, but that's not a definitive statement that there might not be > something strange going on. > > You might try rebuilding with _DEBUG and VERBOSE_GC defined. This will dump > a lot of GC statistics that might give a clue as to the problem area. > > Rick > > On Wed, Aug 8, 2012 at 3:32 PM, Mark Miesfeld wrote: >> >> I was going to bring this up, but probabaly after I had done some more >> testing. However since /hex just brought up SysFileTree, I'll do it >> now. >> >> I had wanted to include the new SysFileTree code in 4.1.2 because it >> definitely fixes some reproducible bugs in Linux. >> >> In Windows, I gave a version to Jerry, the submitter of the Windows >> bug, a version of ooRexx that had SysFileTreeB() and SysFileTree(). >> He tested it for a week and was able to reproduce the bug using >> SysFileTree 4 times in a week of testing, and never using >> SysFileTreeB(). Not conclusive, but an indication that the new code >> might fix the Windows bug. I myself tested a lot that the newer >> version produces the same results as the old version. >> >> However, on Friday I discovered what I thought might be a memory leak >> on Windows. So I won't put it in 4.1.2, but the new version does >> exist in trunk. >> >> What I did was put a simple routine that does a SysFileTree search for >> all files on my system in an endless loop. The returned stem from 1 >> iteration holds about 300,000 file names in the long format. >> >> On a Windows 64-bit system, memory used by rexx.exe keeps increasing >> until at 98% of total memory had to kill it. I have 4 GB of memory >> and the Rexx process used up to about 3,500 MB of it before I killed >> it. >> >> Since in the new version, there is the possibility of a lot more >> dynamically allocated memory, I first thought I had a memory leak >> >> But, these facts make me wonder if it might be something else: >> >> Running the exact same source code and same test on a Windows 32-bit >> machine. Memory used by the Rexx process rose to about 2400 MB and >> then stayed there. The system also has 4 GB of memory. I ran the >> test program for 48 hours and then quit because the memory had stayed >> steady for about 46 hours. Whereas on the 64-bit system, memory maxed >> out after about, I don't know exactly, but about 4 to 7 hours. >> >> I have a trial version of Purify that only runs on 32-bit. I ran the >> test program under it. Running one iteration, Purify report a memory >> loss of 28 bytes. Running 200 iterations, Purify reported a memory >> loss of, 28 bytes. Since it is a trial version it doesn't report >> where the memory loss happened. So the 28 bytes might not have even >> been allocated in SysFileTree. >> >> Originally in the code I was going to raise a condition if a string >> was longer than the static buffers. I ran that code a lot on the same >> 64-bit system and a condition was never raised. In the newer version, >> I replaced all the possible raised condition code with code that >> dynamically allocates memory. >> >> Therefore, in the current code, it seems possible that no dynamic >> memory is allocated to begin with. Making a memory leak in the new >> code unlikely to be the culprit. That's my next step, is to put a >> print out every time memory is allocated, and see if it actually >> happens. I still have to do that. >> >> However it's odd that the same memory problem doesn't happen on a >> 32-bit system. I wonder if the problem is with the garbage collector >> on 64-bit? >> >> -- >> Mark Miesfeld >> >> >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ___ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-d
Re: [Oorexx-devel] "New" SYSFILETREE order of returned values
Brandon is correct. tried dir \\mypath and got the same arbitrary order. I think this should be mentioned in the manual. /hex - Ursprungligt Meddelande: Från: Brandon Cherry Till: Open Object Rexx Developer Mailing List Kopia: Datum: onsdag, 08 augusti 2012 21:22 Ämne: Re: [Oorexx-devel] "New" SYSFILETREE order of returned values I noticed this issue with a samba share. If you try doing a 'dir' from the command line, my guess would be you would get the same results. My search lead me to this fix: http://www.samba.org/samba/docs/man/manpages-3/vfs_dirsort.8.html -- Brandon Cherry On 8/8/2012 3:10 PM, hakan wrote: > Ok, I see > I haven't tried the "old" sysfiletree with UNC path so have no clue if it > differs in result returned, probably not. > The "new" sysfiletree seems to work with UNC path's from Win7 anyhow and the > returned values is in arbitrary order, the same arbitrary order is returned > if the the path is on a mapped network drive (drive letter), but looking at > the same path/drive letter in windowsexplorer shows files in alphabetic > order, maybe they are sorted before display! > > Maybe a note in the manual about this can be useful, if this behaviour is > confirmed by others/testing. > /hex -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Status of REXX at IBM
As an IBMer what I am about to say is my own opinion and does not represent any official or unofficial direction from IBM. Essentially Rexx is dead at IBM. There are no development or maintenance plans of any kind. And good luck getting any bug fixes. When IBM open sourced ooRexx in 2004 it was the last Rexx development that was going on at IBM. And they just dumped in the lap of RexxLA. RexxLA has no contract of any kind with IBM and all there ever was between the two parties was a gentleman's agreement. The Rexx language is not seen as strategic at IBM. And therefore it gets no respect or resources. Like any other software company IBM only deals in what is "cool"at the time no matter whether that stuff actually works or delivers cost savings to the customer. It is all very sad. David Ashley On Wed, 2012-08-08 at 13:28 -0400, Earl Hodil wrote: > I would like to move this conversation to the REXXLA list. > > Just what is the status of REXX at IBM? Does REXXLA have an official IBM > contact? > > As a developer of a REXX-related product, I have to justify my existence > every year. And when we tell IBM that we are working on a REXX product, we > get a big yawn. They want to know how we're going to help them sell some IBM > key technology or application, and quite frankly we get the impression that > REXX ain't it. > > Of course, they haven't cut us off yet; so I guess that's something. > > Earl Hodil > Open Software Technologies > > > On Aug 8, 2012, at 9:26 AM, Mike Cowlishaw wrote: > > > > >> I too would be happy to see ooRexx on MVS, I'm just not the > >> person to do it. Yes, I have access to a z/os system, but NO, > >> I do not have the expertise to do it. Surely someone else has > >> access to a z/os system. What about Mr. REXX himself, Mike > >> Cowlishaw? He's an IBM fellow. > > > > Umm, a *retired* IBM Fellow. That means I don't even have my IBM e-mail > > address > > anymore ... > > > >> I'm sure he could persuade IBM > >> to give him his own zPDT system, if he asked (not that it > >> would be required. A TSO ID on a time-sharing system would suffice). > > > > Wouldn't be much use to me or to Rexx, to be honest. Last time I used z/OS > > it > > was called MFT ... :-) > > > > Mike > > > > > > -- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ___ > > Oorexx-devel mailing list > > Oorexx-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] [Ibm-netrexx] ASCII or EBCDIC?
** Reply to message from Earl Hodil on Wed, 8 Aug 2012 09:03:48 -0400 I'm still working on porting ooRexx to zOS (evenutally both to USS and TSO). (took off the last week, but back in town now and picking up the threads...) taf > would be happy to see ooRexx on MVS, I'm just not the person to do it. Yes, I > have access to a z/os system, but NO, I do not have the expertise to do it. > Surely someone else has access to a z/os system. What about Mr. REXX himself, > Mike Cowlishaw? He's an IBM fellow. I'm sure he could persuade IBM to give him > his own zPDT system, if he asked (not that it would be required. A TSO ID on a > time-sharing system would suffice). > > Earl > > > On A -- Regards, taf -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] More on memory problem, SysFileTree, etc..
Okay, I put print outs in the SysFile tree code and in the loop test
it turns out it is not dynamically allocating memory when running in a
loop. Well, it does allocate 2 buffers but frees them each time.
But, it turns out I wasn't comparing apples to orange running on
64-bit and 32-bit. It seems the memory problem is not in
SysFileTree() but in another portion of the code.
When I first ran the loop test on 64-bit Windows, the test program has
this code in it, (that I removed when I ran it on 32-bit Windows.)
do i=1 to f.0
if \var("f.i")
then do
sw = 1
say "Stem variable f."i "has not been assigned a value."
end
end
The bottom line is, if I take that code out of the base program, when
I run the endless loop of SysFileTree() memory use climbs to around
204,000 MB and then holds steady. If I put that code back in, then
Rexx memory usage keeps climbing, until all usable memory is consumed.
Rick - I'm going to open a tracker item for this so I can attach the
exact Rexx programs I was using. I'll put the details in the tracker
and you can look at it if you have time.
--
Mark Miesfeld
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Status of REXX at IBM
Hi David,
as I tried to say, it is not so bleak. The Rexx TSO team has a healthy list of
issues to work through and we might even get the Stream-I/O library on it.
I do share your opinion that there is nobody in the higher ups at IBM that sees
Rexx as the strategic language it is - in other contexts I already stated my
opinion that there is much more Rexx than there is visible, because most of it
is under the radar of management, due to its position as a language to program
in if you are not allowed to program - the systems staff dilemma. Myself, I am
much more at ease supporting something that has grass roots support and is
loved by its community than some language mandated by the top of a large
company - those positions don't last long (Rexx once was once SAA procedures
language, and went down with SAA before it went down with OS/2 - and it still
survives - did you hear of AD/Cycle Prolog lately?) - while the open source
status guarantees continuity.
RexxLA has two official contracts with IBM, concerning the open sourcing of
Object Rexx and NetRexx, that are legally binding. RexxLA has an obligation to
support the users of the language to the best of its ability. For this reason,
part of the OSSC process was the delivery of an open source proposal ("for
sponsorship of the transition of [Object,Net]Rexx to an open source project")
and a Project Charter.
ooRexx might have been dumped in our lap (although I remember myself emailing
Manfred Schweizer regularly with pleas to let it go, and set it free already)
but the Open Sourcing of NetRexx was no walk in the park, as the extended
2007-2011 time period has shown. Among the things I agreed with IBM:
"The objectives of RexxLA are well aligned with those of IBM and also include
some goals that might be difficult to achieve within the commercial product
development environment. These include:
§ To promote the use of NetRexx across all platforms that have a JVM available
§ To promote Rexx as a first-class language within the open source community
§ To provide IBM with a known and reliable set of experts to lead the open
source project
§ To provide a smooth migration path for IBM’s current NetRexx user base on
existing platforms to the open source product
§ To ensure that NetRexx code is maintained at the highest levels of quality
consistent with commercial products
§ To provide direction for the project which is consistent with the needs of
the NetRexx community
§ To enhance and extend NetRexx to stay abreast of developments in the Java
platform"
This is at least the text that the product owner at IBM, after Mike left to
enjoy his new pensioned state, agreed to. I needed to supply a list of 8 people
who are qualified to support development of the product.
I do not have the Object Rexx document close at hand, but the NetRexx one is
based on that. It states clearly that IBM expects us to do the work to keep
Rexx in a high standing.
Of course there have been terrible disappointments over the last decades, with
the slow death of SOM, OpenDoc, Workplace OS (OS/2) and the failure to include
Object Rexx in AIX and NetRexx in the products that support Java as low points.
I tend to not look to the past (as historian, I know there is no future in it)
but I try to look ahead, as RexxLA does.
Check out this: I had, after finding a way to write the raspbian image to an SD
card, Classic Rexx (Regina), and NetRexx installed within 20 minutes. They run
flawlessly. Regina is already mentioned in the Raspberry Pi documentation site.
Someone (well, ok, me, if no-one beats me to it) will compile ooRexx soon, and
have it in the package repository.
With a list price of $25 (plus an SD card, and optionally some cables and a
monitor) there is no reason not to try Linux and Rexx. If we try to publish
some feats, I think we can get more attention than we ever had. RexxLA can sell
ready-to-run cards with everything installed.
best regards,
René.
On 8 aug. 2012, at 22:20, David Ashley wrote:
> As an IBMer what I am about to say is my own opinion and does not
> represent any official or unofficial direction from IBM.
>
> Essentially Rexx is dead at IBM. There are no development or maintenance
> plans of any kind. And good luck getting any bug fixes. When IBM open
> sourced ooRexx in 2004 it was the last Rexx development that was going
> on at IBM. And they just dumped in the lap of RexxLA. RexxLA has no
> contract of any kind with IBM and all there ever was between the two
> parties was a gentleman's agreement.
>
> The Rexx language is not seen as strategic at IBM. And therefore it gets
> no respect or resources. Like any other software company IBM only deals
> in what is "cool"at the time no matter whether that stuff actually works
> or delivers cost savings to the customer.
>
> It is all very sad.
>
> David Ashley
>
> On Wed, 2012-08-08 at 13:28 -0400, Earl Hodil wrote:
>> I would like to move this conversation
Re: [Oorexx-devel] More on memory problem, SysFileTree, etc..
Am I correct in assuming this loop never wrote out any lines? I've been
trying to recreate this with a simple sample, but the memory size looks
dead stable so far.
Rick
On Wed, Aug 8, 2012 at 5:10 PM, Mark Miesfeld wrote:
> Okay, I put print outs in the SysFile tree code and in the loop test
> it turns out it is not dynamically allocating memory when running in a
> loop. Well, it does allocate 2 buffers but frees them each time.
>
> But, it turns out I wasn't comparing apples to orange running on
> 64-bit and 32-bit. It seems the memory problem is not in
> SysFileTree() but in another portion of the code.
>
> When I first ran the loop test on 64-bit Windows, the test program has
> this code in it, (that I removed when I ran it on 32-bit Windows.)
>
> do i=1 to f.0
> if \var("f.i")
> then do
> sw = 1
> say "Stem variable f."i "has not been assigned a value."
> end
> end
>
> The bottom line is, if I take that code out of the base program, when
> I run the endless loop of SysFileTree() memory use climbs to around
> 204,000 MB and then holds steady. If I put that code back in, then
> Rexx memory usage keeps climbing, until all usable memory is consumed.
>
> Rick - I'm going to open a tracker item for this so I can attach the
> exact Rexx programs I was using. I'll put the details in the tracker
> and you can look at it if you have time.
>
> --
> Mark Miesfeld
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] More on memory problem, SysFileTree, etc..
On Wed, Aug 8, 2012 at 2:28 PM, Rick McGuire wrote: > Am I correct in assuming this loop never wrote out any lines? I've been > trying to recreate this with a simple sample, but the memory size looks dead > stable so far. Sort of. The loop didn't write out any lines. A few lines were written out in the overall program. I attached the complete programs I'm using to a tracker item. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] More on memory problem, SysFileTree, etc..
Mark, I'm seeing the same growth with both versions and it looks like it is a classic memory fragmentation problem. An external call context keeps a hashtable of all object references it hands out to external functions like SysFileTree that protects those objects from garbage collection. Because SysFileTree is creating so many objects, this table gets very, very large (needing a 19Mb block of storage). What is happening is the memory manager can't find a sufficiently large block of storage, so it adds that to the memory heap. This memory is then used for other allocations after the hash table is garbage collection, so the next time a table of this size is required again, there's no longer a contiguous block large enough to satisfy the request, so we need to expand again. This basically keeps happening, so the memory grows. The root cause of the problem is the large number of objects SysFileTree is creating in a single call. All of those objects need to be protected until the call completes...unless, that is SysFileTree says it is ok to stop protecting those objects. This will require a few changes to SysFileTree. For example, there are many lines like this in SysFileTree: c->SetStemArrayElement(treeData->files, treeData->count, c->String(dFoundFile)); This needs to be changed to something like this: RexxString temp = c->String(dFoundFile); c->SetStemArrayElement(treeData->files, treeData->count, temp); c->ReleaseLocalReference(temp); This will keep the local reference table at a reasonable size throughout this process. Rick On Wed, Aug 8, 2012 at 5:33 PM, Mark Miesfeld wrote: > On Wed, Aug 8, 2012 at 2:28 PM, Rick McGuire > wrote: > > > Am I correct in assuming this loop never wrote out any lines? I've been > > trying to recreate this with a simple sample, but the memory size looks > dead > > stable so far. > > Sort of. The loop didn't write out any lines. A few lines were > written out in the overall program. > > I attached the complete programs I'm using to a tracker item. > > -- > Mark Miesfeld > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] More on memory problem, SysFileTree, etc..
On Wed, Aug 8, 2012 at 3:21 PM, Rick McGuire wrote: > I'm seeing the same growth with both versions and it looks like it is a > classic memory fragmentation problem. An external call context keeps a > hashtable of all object references it hands out to external functions like > SysFileTree that protects those objects from garbage collection. Because > SysFileTree is creating so many objects, this table gets very, very large > (needing a 19Mb block of storage). What is happening is the memory manager > can't find a sufficiently large block of storage, so it adds that to the > memory heap. This memory is then used for other allocations after the hash > table is garbage collection, so the next time a table of this size is > required again, there's no longer a contiguous block large enough to satisfy > the request, so we need to expand again. This basically keeps happening, so > the memory grows. > > The root cause of the problem is the large number of objects SysFileTree is > creating in a single call. All of those objects need to be protected until > the call completes...unless, that is SysFileTree says it is ok to stop > protecting those objects. This will require a few changes to SysFileTree. > For example, there are many lines like this in SysFileTree: > > c->SetStemArrayElement(treeData->files, treeData->count, > c->String(dFoundFile)); > > This needs to be changed to something like this: > > > RexxString temp = c->String(dFoundFile); > > c->SetStemArrayElement(treeData->files, treeData->count, temp); > > c->ReleaseLocalReference(temp); > > > This will keep the local reference table at a reasonable size throughout > this process. Okay, thanks for taking a look at it. And thanks for the advice. I'll fix that up. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Status of REXX at IBM
>> ... Rexx once was once SAA procedures language ...
... and this positioning of Rexx was afterwards hailed by some as the
greatest success of the IBM Sales Prevention Department.
-- Oliver
_
From: René Jansen [mailto:rvjan...@xs4all.nl]
Sent: 08 August 2012 21:23
To: Open Object Rexx Developer Mailing List
Subject: Re: [Oorexx-devel] Status of REXX at IBM
Hi David,
as I tried to say, it is not so bleak. The Rexx TSO team has a healthy list
of issues to work through and we might even get the Stream-I/O library on
it.
I do share your opinion that there is nobody in the higher ups at IBM that
sees Rexx as the strategic language it is - in other contexts I already
stated my opinion that there is much more Rexx than there is visible,
because most of it is under the radar of management, due to its position as
a language to program in if you are not allowed to program - the systems
staff dilemma. Myself, I am much more at ease supporting something that has
grass roots support and is loved by its community than some language
mandated by the top of a large company - those positions don't last long
(Rexx once was once SAA procedures language, and went down with SAA before
it went down with OS/2 - and it still survives - did you hear of AD/Cycle
Prolog lately?) - while the open source status guarantees continuity.
RexxLA has two official contracts with IBM, concerning the open sourcing of
Object Rexx and NetRexx, that are legally binding. RexxLA has an obligation
to support the users of the language to the best of its ability. For this
reason, part of the OSSC process was the delivery of an open source proposal
("for sponsorship of the transition of [Object,Net]Rexx to an open source
project") and a Project Charter.
ooRexx might have been dumped in our lap (although I remember myself
emailing Manfred Schweizer regularly with pleas to let it go, and set it
free already) but the Open Sourcing of NetRexx was no walk in the park, as
the extended 2007-2011 time period has shown. Among the things I agreed with
IBM:
"The objectives of RexxLA are well aligned with those of IBM and also
include some goals that might be difficult to achieve within the commercial
product development environment. These include:
§ To promote the use of NetRexx
across all platforms that have a JVM available
§ To promote Rexx as a first-class
language within the open source community
§ To provide IBM with a known and
reliable set of experts to lead the open source project
§ To provide a smooth migration path
for IBMs current NetRexx user base on existing platforms to the open source
product
§ To ensure that NetRexx code is
maintained at the highest levels of quality consistent with commercial
products
§ To provide direction for the
project which is consistent with the needs of the NetRexx community
§ To enhance and extend NetRexx to
stay abreast of developments in the Java platform"
This is at least the text that the product owner at IBM, after Mike left to
enjoy his new pensioned state, agreed to. I needed to supply a list of 8
people who are qualified to support development of the product.
I do not have the Object Rexx document close at hand, but the NetRexx one is
based on that. It states clearly that IBM expects us to do the work to keep
Rexx in a high standing.
Of course there have been terrible disappointments over the last decades,
with the slow death of SOM, OpenDoc, Workplace OS (OS/2) and the failure to
include Object Rexx in AIX and NetRexx in the products that support Java as
low points. I tend to not look to the past (as historian, I know there is no
future in it) but I try to look ahead, as RexxLA does.
Check out this: I had, after finding a way to write the raspbian image to an
SD card, Classic Rexx (Regina), and NetRexx installed within 20 minutes.
They run flawlessly. Regina is already mentioned in the Raspberry Pi
documentation site. Someone (well, ok, me, if no-one beats me to it) will
compile ooRexx soon, and have it in the package repository.
With a list price of $25 (plus an SD card, and optionally some cables and a
monitor) there is no reason not to try Linux and Rexx. If we try to publish
some feats, I think we can get more attention than we ever had. RexxLA can
sell ready-to-run cards with everything installed.
best regards,
René.
On 8 aug. 2012, at 22:20, David Ashley wrote:
As an IBMer what I am about to say is my own opinion and does not
represent any official or unofficial direction from IBM.
Essentially Rexx is dead at IBM. There are no development or maintenance
plans of any kind. And good luck getting any bug fixes. When IBM open
sourced ooRexx in 2004 it was the last Rexx development that was going
on at IBM. And they just dumped in the lap of RexxLA. RexxLA has no
contract of any kind with IBM and all there ever was between the two
parties was a gentleman's agreement.
The Rexx language is not seen as strategic at IBM. And therefore it gets
no respect or r
