java.lang.String cannot be cast to netrexx.lang.Rexx

[Jeff Hennick-3]

After more testing it gets stranger.

With all the trace and say lines commented out, it still gives the wrong result.  With the addition of a say '' line anywhere in the main loop -- before or after the peekto() --, it works correctly, except for the blank lines it puts out, of course.

===========

This concern is still with us, and it has become weirder.

First, René, putting in the toString made the problem go away, and I was able to continue working.  Thank you.

When I went back to the previous stage, CHOP, it certainly appears that its output is type Rexx.  Its output is either the variable outl or rest, both of which come from parse line outl =(p) rest .  Why the overlay stage thinks it is an object that needs to be converted to string and then to Rexx still puzzles me.

But it worked.

Now today I'm getting a new weirdness.  I have these lines

--          line=Rexx peekto().toString()    <-- is the line I had that has been working, when it stopped -- after working elsewhere --, I broke it into 3 lines for debugging
--trace results
          linea = peekto()
--say linea
trace off
          lines=linea.toString()
--say lines
          line=Rexx lines
--say line

as it is above I get the wrong result later on.  If I remove the "--" from either the trace OR ANY of the says, I get the right result.  The trace results does not need to be right before the line in question, it can be way earlier.  The trace off can be way later.  When traced, it is right.

What is different if it is being traced?  And how can a say, several lines later, change its behavior?

Any insight to keep me from going mad would be gratefully appreciated.  Or a suggested work around.  Remember, in every other stage it is a simple line = peekto() that works.

Thanks.

On 5/5/2020 4:55 PM, René Jansen wrote:

yes, it can convert a String. For an Object, it is different; but always try the .toString method on an Object, it might do what you want.

Remember we did convert a lot of these stages to provide output as type Rexx - because no-one used it for Java and it was much too complicated to use from NetRexx, with a ‘rexx’ interspersed here and there (but not where one would expect it) - so it could not credibly look like CMS Pipelines  - which I think it does now a lot more.

René.

On 5 May 2020, at 21:16, Jeff Hennick <[hidden email]> wrote:

René,

Yes, thanks.  That does work.

I will take a look at CHOP and its output type.

But NetRexx should never object to converting a Java String (not Object) to a Rexx, should it?  It should convert it quietly and automatically, and to not give any way to do it "manually," either?

On 5/5/2020 2:27 PM, René Jansen wrote:

Jeff,

pipe (ctb)

 literal the left/the right |

 c: chop before / |

 o1: rexx bad |

 console ?

 c: |

 spec 2-* 1.50 right |

o1:

Note the rexx before the bad.

We probably forgot to treat the chop stage to only return Rexx.

René.

On 5 May 2020, at 20:20, Jeff Hennick <[hidden email]> wrote:

pipe (ctb) literal the left/the right | c: chop before / | o1: bad | console ? c: | spec 2-* 1.50 right | o1:

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ColinK]

Hi Jeff

I am trying to replicate your problem and so I created ctb.njp and bad.nrx (based on an earlier note in this thread).  I could not get ctb.njp to compile as it complained about the filter "spec"

Z:\NetRexx-3.08-GA\bin>pipc ctb
pipe (ctb ) literal the left/the right | c: chop before / | o1:  bad | console ? c: | spec 2-* 1.50 right | o1:
  76 +++    _s_5 = spec()
     +++           ^^^^
     +++ Error: The method 'spec()' cannot be found in class 'ctb' or a superclass

I changed "spec" to "specs" and then the compile worked but I didn't get the cast exception - it went for a loop instead.

Z:\NetRexx-3.08-GA\bin>pipc ctb
pipe (ctb ) literal the left/the right | c: chop before / | o1:  bad | console ? c: | specs 2-* 1.50 right | o1:

Z:\NetRexx-3.08-GA\bin>java ctb

<...tight loop...>
<...press Ctrl-c...>

Z:\NetRexx-3.08-GA\bin>

Is this the following the code I should be using to replicate the problem?  bad doesn't output anything nor does it do a readto() which may imply it is looping on peekto.

Z:\NetRexx-3.08-GA\bin>type bad.nrx
import org.netrexx.njpipes.pipes.

class bad extends stage

method run()
  loop forever
    linePa = Rexx peekto()
  catch StageError
  end
  rc=mrc()
  exit(rc*(rc<>12))


Z:\NetRexx-3.08-GA\bin>type ctb.njp
 pipe (ctb)

 literal the left/the right |
 c: chop before / |
 o1:  bad |
 console ?
 c: |
 specs 2-* 1.50 right |
o1:

Thanks
Colin

On 2020-05-11 19:10, Jeff Hennick wrote:

After more testing it gets stranger.

With all the trace and say lines commented out, it still gives the wrong result.  With the addition of a say '' line anywhere in the main loop -- before or after the peekto() --, it works correctly, except for the blank lines it puts out, of course.

===========

This concern is still with us, and it has become weirder.

First, René, putting in the toString made the problem go away, and I was able to continue working.  Thank you.

When I went back to the previous stage, CHOP, it certainly appears that its output is type Rexx.  Its output is either the variable outl or rest, both of which come from parse line outl =(p) rest .  Why the overlay stage thinks it is an object that needs to be converted to string and then to Rexx still puzzles me.

But it worked.

Now today I'm getting a new weirdness.  I have these lines

--          line=Rexx peekto().toString()    <-- is the line I had that has been working, when it stopped -- after working elsewhere --, I broke it into 3 lines for debugging
--trace results
          linea = peekto()
--say linea
trace off
          lines=linea.toString()
--say lines
          line=Rexx lines
--say line

as it is above I get the wrong result later on.  If I remove the "--" from either the trace OR ANY of the says, I get the right result.  The trace results does not need to be right before the line in question, it can be way earlier.  The trace off can be way later.  When traced, it is right.

What is different if it is being traced?  And how can a say, several lines later, change its behavior?

Any insight to keep me from going mad would be gratefully appreciated.  Or a suggested work around.  Remember, in every other stage it is a simple line = peekto() that works.

Thanks.

On 5/5/2020 4:55 PM, René Jansen wrote:

yes, it can convert a String. For an Object, it is different; but always try the .toString method on an Object, it might do what you want.

Remember we did convert a lot of these stages to provide output as type Rexx - because no-one used it for Java and it was much too complicated to use from NetRexx, with a ‘rexx’ interspersed here and there (but not where one would expect it) - so it could not credibly look like CMS Pipelines  - which I think it does now a lot more.

René.

On 5 May 2020, at 21:16, Jeff Hennick <[hidden email]> wrote:

René,

Yes, thanks.  That does work.

I will take a look at CHOP and its output type.

But NetRexx should never object to converting a Java String (not Object) to a Rexx, should it?  It should convert it quietly and automatically, and to not give any way to do it "manually," either?

On 5/5/2020 2:27 PM, René Jansen wrote:

Jeff,

pipe (ctb)

 literal the left/the right |

 c: chop before / |

 o1: rexx bad |

 console ?

 c: |

 spec 2-* 1.50 right |

o1:

Note the rexx before the bad.

We probably forgot to treat the chop stage to only return Rexx.

René.

On 5 May 2020, at 20:20, Jeff Hennick <[hidden email]> wrote:

pipe (ctb) literal the left/the right | c: chop before / | o1: bad | console ? c: | spec 2-* 1.50 right | o1:

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

Hi Colin,

the spec/specs problem will be gone in 3.09.

René.

On 12 May 2020, at 07:41, ColinK <[hidden email]> wrote:

Hi Jeff

I am trying to replicate your problem and so I created ctb.njp and bad.nrx (based on an earlier note in this thread).  I could not get ctb.njp to compile as it complained about the filter "spec"

Z:\NetRexx-3.08-GA\bin>pipc ctb
pipe (ctb ) literal the left/the right | c: chop before / | o1:  bad | console ? c: | spec 2-* 1.50 right | o1:
  76 +++    _s_5 = spec()
     +++           ^^^^
     +++ Error: The method 'spec()' cannot be found in class 'ctb' or a superclass

I changed "spec" to "specs" and then the compile worked but I didn't get the cast exception - it went for a loop instead.

Z:\NetRexx-3.08-GA\bin>pipc ctb
pipe (ctb ) literal the left/the right | c: chop before / | o1:  bad | console ? c: | specs 2-* 1.50 right | o1:

Z:\NetRexx-3.08-GA\bin>java ctb

<...tight loop...>
<...press Ctrl-c...>

Z:\NetRexx-3.08-GA\bin>

Is this the following the code I should be using to replicate the problem?  bad doesn't output anything nor does it do a readto() which may imply it is looping on peekto.

Z:\NetRexx-3.08-GA\bin>type bad.nrx
import org.netrexx.njpipes.pipes.

class bad extends stage

method run()
  loop forever
    linePa = Rexx peekto()
  catch StageError
  end
  rc=mrc()
  exit(rc*(rc<>12))


Z:\NetRexx-3.08-GA\bin>type ctb.njp
 pipe (ctb)

 literal the left/the right |
 c: chop before / |
 o1:  bad |
 console ?
 c: |
 specs 2-* 1.50 right |
o1:

Thanks
Colin

On 2020-05-11 19:10, Jeff Hennick wrote:

After more testing it gets stranger.

With all the trace and say lines commented out, it still gives the wrong result.  With the addition of a say '' line anywhere in the main loop -- before or after the peekto() --, it works correctly, except for the blank lines it puts out, of course.

===========

This concern is still with us, and it has become weirder.

First, René, putting in the toString made the problem go away, and I was able to continue working.  Thank you.

When I went back to the previous stage, CHOP, it certainly appears that its output is type Rexx.  Its output is either the variable outl or rest, both of which come from parse line outl =(p) rest .  Why the overlay stage thinks it is an object that needs to be converted to string and then to Rexx still puzzles me.

But it worked.

Now today I'm getting a new weirdness.  I have these lines

--          line=Rexx peekto().toString()    <-- is the line I had that has been working, when it stopped -- after working elsewhere --, I broke it into 3 lines for debugging
--trace results
          linea = peekto()
--say linea
trace off
          lines=linea.toString()
--say lines
          line=Rexx lines
--say line

as it is above I get the wrong result later on.  If I remove the "--" from either the trace OR ANY of the says, I get the right result.  The trace results does not need to be right before the line in question, it can be way earlier.  The trace off can be way later.  When traced, it is right.

What is different if it is being traced?  And how can a say, several lines later, change its behavior?

Any insight to keep me from going mad would be gratefully appreciated.  Or a suggested work around.  Remember, in every other stage it is a simple line = peekto() that works.

Thanks.

On 5/5/2020 4:55 PM, René Jansen wrote:

yes, it can convert a String. For an Object, it is different; but always try the .toString method on an Object, it might do what you want.

Remember we did convert a lot of these stages to provide output as type Rexx - because no-one used it for Java and it was much too complicated to use from NetRexx, with a ‘rexx’ interspersed here and there (but not where one would expect it) - so it could not credibly look like CMS Pipelines  - which I think it does now a lot more.

René.

On 5 May 2020, at 21:16, Jeff Hennick <[hidden email]> wrote:

René,

Yes, thanks.  That does work.

I will take a look at CHOP and its output type.

But NetRexx should never object to converting a Java String (not Object) to a Rexx, should it?  It should convert it quietly and automatically, and to not give any way to do it "manually," either?

On 5/5/2020 2:27 PM, René Jansen wrote:

Jeff,

pipe (ctb)

 literal the left/the right |

 c: chop before / |

 o1: rexx bad |

 console ?

 c: |

 spec 2-* 1.50 right |

o1:

Note the rexx before the bad.

We probably forgot to treat the chop stage to only return Rexx.

René.

On 5 May 2020, at 20:20, Jeff Hennick <[hidden email]> wrote:

pipe (ctb) literal the left/the right | c: chop before / | o1: bad | console ? c: | spec 2-* 1.50 right | o1:

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Jeff Hennick-3]

Progress (?) Report:  I am still getting flaky results.  For example, when the code is in file/stage named "bad," it is repeatably working.  Copying that code into a file/stage named "overlay_a" (changing only the class name) it is repeatedly not; there it needs at least one say instruction to be active in order to work; then it works repeatably.

My latest try is to replace the normal single peekto() statement with a "2 tries out of 3" segment:

          linea = peekto()
          lineb = peekto()
          if linea <> lineb then do
            linec = peekto()
            if linec <> linea then do
              if linec <> lineb then -- All 3 are different!
                Emsg(99, "Error in peekto():\n"linea";\n"lineb";\n"linec)
              else
                linea = lineb -- b & c agree, but differ from a
            end
          end

After this, I go into that object to string to rexx routine using linea.

This is while I am trying to "enhance" our stage over the CMS version, so I think I'll just revert it back down and call it a day.

Another anomaly I have had and not reported here is that sometimes selectInput(0) does not work (reports it is out of data, when there is more).  My workaround for that is to try it a second time like this code:

      do
        selectInput(pick)
      catch StageError
        do
          selectInput(pick)
        catch StageError
          rc = rc()
          leave
        end
      end

That seems to be working.

[Is it possible that a NetRexx program can be cursed?  It is "hex code" in a sense.  :-)   This stage, overlay, is the only one that has given this much odd trouble; the troubles with other stages have been of my own making.]

On 5/12/2020 1:21 PM, René Jansen wrote:

Hi Colin,

the spec/specs problem will be gone in 3.09.

René.

On 12 May 2020, at 07:41, ColinK <[hidden email]> wrote:

Hi Jeff

I am trying to replicate your problem and so I created ctb.njp and bad.nrx (based on an earlier note in this thread).  I could not get ctb.njp to compile as it complained about the filter "spec"

Z:\NetRexx-3.08-GA\bin>pipc ctb
pipe (ctb ) literal the left/the right | c: chop before / | o1:  bad | console ? c: | spec 2-* 1.50 right | o1:
  76 +++    _s_5 = spec()
     +++           ^^^^
     +++ Error: The method 'spec()' cannot be found in class 'ctb' or a superclass

I changed "spec" to "specs" and then the compile worked but I didn't get the cast exception - it went for a loop instead.

Z:\NetRexx-3.08-GA\bin>pipc ctb
pipe (ctb ) literal the left/the right | c: chop before / | o1:  bad | console ? c: | specs 2-* 1.50 right | o1:

Z:\NetRexx-3.08-GA\bin>java ctb

<...tight loop...>
<...press Ctrl-c...>

Z:\NetRexx-3.08-GA\bin>

Is this the following the code I should be using to replicate the problem?  bad doesn't output anything nor does it do a readto() which may imply it is looping on peekto.

Z:\NetRexx-3.08-GA\bin>type bad.nrx
import org.netrexx.njpipes.pipes.

class bad extends stage

method run()
  loop forever
    linePa = Rexx peekto()
  catch StageError
  end
  rc=mrc()
  exit(rc*(rc<>12))


Z:\NetRexx-3.08-GA\bin>type ctb.njp
 pipe (ctb)

 literal the left/the right |
 c: chop before / |
 o1:  bad |
 console ?
 c: |
 specs 2-* 1.50 right |
o1:

Thanks
Colin

On 2020-05-11 19:10, Jeff Hennick wrote:

After more testing it gets stranger.

With all the trace and say lines commented out, it still gives the wrong result.  With the addition of a say '' line anywhere in the main loop -- before or after the peekto() --, it works correctly, except for the blank lines it puts out, of course.

===========

This concern is still with us, and it has become weirder.

First, René, putting in the toString made the problem go away, and I was able to continue working.  Thank you.

When I went back to the previous stage, CHOP, it certainly appears that its output is type Rexx.  Its output is either the variable outl or rest, both of which come from parse line outl =(p) rest .  Why the overlay stage thinks it is an object that needs to be converted to string and then to Rexx still puzzles me.

But it worked.

Now today I'm getting a new weirdness.  I have these lines

--          line=Rexx peekto().toString()    <-- is the line I had that has been working, when it stopped -- after working elsewhere --, I broke it into 3 lines for debugging
--trace results
          linea = peekto()
--say linea
trace off
          lines=linea.toString()
--say lines
          line=Rexx lines
--say line

as it is above I get the wrong result later on.  If I remove the "--" from either the trace OR ANY of the says, I get the right result.  The trace results does not need to be right before the line in question, it can be way earlier.  The trace off can be way later.  When traced, it is right.

What is different if it is being traced?  And how can a say, several lines later, change its behavior?

Any insight to keep me from going mad would be gratefully appreciated.  Or a suggested work around.  Remember, in every other stage it is a simple line = peekto() that works.

Thanks.

On 5/5/2020 4:55 PM, René Jansen wrote:

yes, it can convert a String. For an Object, it is different; but always try the .toString method on an Object, it might do what you want.

Remember we did convert a lot of these stages to provide output as type Rexx - because no-one used it for Java and it was much too complicated to use from NetRexx, with a ‘rexx’ interspersed here and there (but not where one would expect it) - so it could not credibly look like CMS Pipelines  - which I think it does now a lot more.

René.

On 5 May 2020, at 21:16, Jeff Hennick <[hidden email]> wrote:

René,

Yes, thanks.  That does work.

I will take a look at CHOP and its output type.

But NetRexx should never object to converting a Java String (not Object) to a Rexx, should it?  It should convert it quietly and automatically, and to not give any way to do it "manually," either?

On 5/5/2020 2:27 PM, René Jansen wrote:

Jeff,

pipe (ctb)

 literal the left/the right |

 c: chop before / |

 o1: rexx bad |

 console ?

 c: |

 spec 2-* 1.50 right |

o1:

Note the rexx before the bad.

We probably forgot to treat the chop stage to only return Rexx.

René.

On 5 May 2020, at 20:20, Jeff Hennick <[hidden email]> wrote:

pipe (ctb) literal the left/the right | c: chop before / | o1: bad | console ? c: | spec 2-* 1.50 right | o1:

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Jason Martin]

None of this may help you. Just me looking at the thread.

I noticed "options binary" in first message.

NRL manual page 107

binary All classes in this program will be binary (see page 71)
classes:ea.. In binary classes,
literals are assigned binary (primitive) or native string types, rather
than NetRexx
types, and native binary operations are used to implement operators
where appropri-
ate, as described in ”Binary values and operations” (see page 165) . In
classes that
are not binary, terms in expressions are converted to the NetRexx string
type, Rexx,
before use by operators.


Also, do you use or can you use the -crossref option with pipes?

bad.crossref

--- Variables for class bad ---
linePa Rexx v 9=
rc     int  v 12= 13 13

ctb.crossref

--- Variables for class ctb ---
_s_1 stage    p 14 26 49= 50 60 67 76
_s_2 stage    p 15 27 51= 52 61 67 68 70 77
_s_3 stage    p 16 28 53= 54 62 68 69 71 75
_s_4 stage    p 17 29 55= 56 63 69 74
_s_5 stage    p 18 30 57= 58 64 70 71 80
a    Object   a 20= 21
a    Object   a 32= 38 40
a    Object   a 45 46
a    String[] a 86 87
e    ctb      v 35= 37 38 40= 42 43
p    ctb      v 87= 88 89 89 89 90
pool Stack    s 11= 34 35 82 83

--- Variables for class ctb_specs_5 ---
data Rexx    v 115= 116
eofc Rexx    v 98= 107 107= 109
eoff Rexx    v 97= 107 108=
l0   Rexx    v 103= 113= 115
outp Rexx    v 96= 110 110 116 116= 117 118=
rc   int     v 106= 122= 125= 127 127
read boolean v 99= 100 101= 104=



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Jeff Hennick-3]

Jason,

Thank you for taking the time to help.

The Binary option is a good catch.  It is (now "was") there as a carryover from 20+ years ago.  I picked up the work still with debugging say instructions.  I should have de-Binaried it immediately, but having started at the top, did not know for sure it was not required, and I never went back up there to remove it -- my bad.

Unfortunately, when I do remove Binary, it still needs the say instruction to produce the correct output.  I have reduced it to  say " \-" which produces an invisible null output without even an end-of-line.  With that in it works, without it, it does not.

And the tip on crossref: again thanks.  It has been years since I have thought of it.  Yes it can be used with pipe stages, since it is only a compile time thing that has no effect on the class file.

In looking over the list of compile options, one I have never played with looks interesting: Format, to give a "readable" Java file.  In the morning, I'll try my hand at reading Java (it has been a long time since I had even a beginners knowledge of it) and compare the two files, with and without the say instruction.  Thanks for pointing me toward that.

This whole project is mostly the equivalent of amateur painting for me.  It is unlikely that anyone will ever get any value out of it.  But with the current virus imposed stay at home, it is more interesting than other things I could do.

On 5/12/2020 7:56 PM, Jason Martin wrote:

None of this may help you. Just me looking at the thread.

I noticed "options binary" in first message.

NRL manual page 107

binary All classes in this program will be binary (see page 71) classes:ea.. In binary classes,
literals are assigned binary (primitive) or native string types, rather than NetRexx
types, and native binary operations are used to implement operators where appropri-
ate, as described in ”Binary values and operations” (see page 165) . In classes that
are not binary, terms in expressions are converted to the NetRexx string type, Rexx,
before use by operators.


Also, do you use or can you use the -crossref option with pipes?

bad.crossref

--- Variables for class bad ---
linePa Rexx v 9=
rc     int  v 12= 13 13

ctb.crossref

--- Variables for class ctb ---
_s_1 stage    p 14 26 49= 50 60 67 76
_s_2 stage    p 15 27 51= 52 61 67 68 70 77
_s_3 stage    p 16 28 53= 54 62 68 69 71 75
_s_4 stage    p 17 29 55= 56 63 69 74
_s_5 stage    p 18 30 57= 58 64 70 71 80
a    Object   a 20= 21
a    Object   a 32= 38 40
a    Object   a 45 46
a    String[] a 86 87
e    ctb      v 35= 37 38 40= 42 43
p    ctb      v 87= 88 89 89 89 90
pool Stack    s 11= 34 35 82 83

--- Variables for class ctb_specs_5 ---
data Rexx    v 115= 116
eofc Rexx    v 98= 107 107= 109
eoff Rexx    v 97= 107 108=
l0   Rexx    v 103= 113= 115
outp Rexx    v 96= 110 110 116 116= 117 118=
rc   int     v 106= 122= 125= 127 127
read boolean v 99= 100 101= 104=



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

Hi Jeff,

well, I slightly disagree about the ‘amateur painting’. I use it heavily for work; look at my current shell statistics:

➜  netrexx-code git:(master) ✗ zsh_stats

     1 1130  11.2148%     pipe

     2 1059  10.5101%     cd

     3 751   7.45335%     git

     4 581   5.76618%     emacs

     5 472   4.6844%      ssh

     6 398   3.94998%     ll

     7 381   3.78126%     ls

     8 359   3.56292%     rm

     9 293   2.9079%      docker

    10 256   2.54069%     cat

    11 252   2.50099%     make

    12 168   1.66733%     pipc

    13 165   1.63755%     nrc

    14 156   1.54823%     exit

    15 154   1.52838%     gst

    16 149   1.47876%     rexx

    17 148   1.46884%     sudo

    18 138   1.36959%     brexx

    19 134   1.32989%     mv

    20 130   1.29019%     cp

It is very usable for the repetitive, but always slightly different work with files and directories that I do for the library on Aruba; for most tasks even scripting it in NetRexx would take more time. I find myself now also writing NetRexx with Pipelines integrated like I would do on CMS. I am thinking about modifying org.netrexx.process.NetRexxC to automatically send source to the pipes compiler when it ends in .njp - scanning for pipes would be the next step.

The fact that not very many people know CMS Pipelines and even less its NetRexx version is sad, but I am not particularly worried about that. When the compiler supports Java 9 we need to make some propaganda about it.

best regards,

René.

 

On 13 May 2020, at 05:26, Jeff Hennick <[hidden email]> wrote:

This whole project is mostly the equivalent of amateur painting for me.  It is unlikely that anyone will ever get any value out of it.  But with the current virus imposed stay at home, it is more interesting than other things I could do.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

it is like with voodoo (or bruha, as we call it here): it works, but only when the victim believes in it.

So I don’t believe in that, thus what I always do with this class of problem is to:

say x.getClass().getName()

where x, the unknown, is your variable under suspicion of supernatural influences. It tells you its class, and mostly (only then) I see the error of my ways, and what the compiler thought it should do.

best regards,

René.

On 12 May 2020, at 19:59, Jeff Hennick <[hidden email]> wrote:

[Is it possible that a NetRexx program can be cursed?  It is "hex code" in a sense.  :-)   This stage, overlay, is the only one that has given this much odd trouble; the troubles with other stages have been of my own making.]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Jeff Hennick-3]

Thank you.

In this case, as soon as I put in either a say or trace, the problem goes away.  I'll be trying the format option to try and find some clue in the Java code.

On 5/13/2020 6:19 AM, René Jansen wrote:

it is like with voodoo (or bruha, as we call it here): it works, but only when the victim believes in it.

So I don’t believe in that, thus what I always do with this class of problem is to:

say x.getClass().getName()

where x, the unknown, is your variable under suspicion of supernatural influences. It tells you its class, and mostly (only then) I see the error of my ways, and what the compiler thought it should do.

best regards,

René.

On 12 May 2020, at 19:59, Jeff Hennick <[hidden email]> wrote:

[Is it possible that a NetRexx program can be cursed?  It is "hex code" in a sense.  :-)   This stage, overlay, is the only one that has given this much odd trouble; the troubles with other stages have been of my own making.]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Jeff Hennick-3]

The voodoo continues. 

The following is with no change in the source files, you see all the action.  "overlay_a" is the stage under test, "ct" is the test pipe calling the stage.  (In this test, "xyz" is coming in on the primary stream, "1 34  789" is on the secondary to be laid over, with an expected result of "1y34  789".  These are the second and last records in the pipe to be processed; the first set were done right.)

PS C:\Users\Jeff\documents\pipe tests> pipc overlay_a -keepasjava -replace PS C:\Users\Jeff\documents\pipe tests> java ct # 2 2 records hold **FAIL** at rec 2 col 1. More: Actual: xyz Expected: 1y34 789 RC=4 PS C:\Users\Jeff\documents\pipe tests> pipc overlay_a PS C:\Users\Jeff\documents\pipe tests> java ct # 2 2 records hold *OK* RC=4 PS C:\Users\Jeff\documents\pipe tests>

The only change is in keeping the Java file.  And the results.

This version has a say " \-" statement active. It tests OK with normal compilation.  When I ask for the Java file to be kept, it FAILs.  Exact same source file.

At another time I compiled it, keeping the Java file, with the say, and then with the say commented out.  With the say it worked, without it, it failed.

The only differences in the java files were the time in the first line and a  netrexx.lang.RexxIO.Say(" \000");  line which was in the right place in the logic.

At this time, I plan to take the pins out of the doll, leave the null "say" in, declare victory, publish that version, hope for the best, and go on.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

Hi Jeff,

if you check it in I’ll try an exorcism.

René.

On 13 May 2020, at 17:22, Jeff Hennick <[hidden email]> wrote:

The voodoo continues. 

The following is with no change in the source files, you see all the action.  "overlay_a" is the stage under test, "ct" is the test pipe calling the stage.  (In this test, "xyz" is coming in on the primary stream, "1 34  789" is on the secondary to be laid over, with an expected result of "1y34  789".  These are the second and last records in the pipe to be processed; the first set were done right.)

PS C:\Users\Jeff\documents\pipe tests> pipc overlay_a -keepasjava -replace PS C:\Users\Jeff\documents\pipe tests> java ct # 2 2 records hold **FAIL** at rec 2 col 1. More: Actual: xyz Expected: 1y34 789 RC=4 PS C:\Users\Jeff\documents\pipe tests> pipc overlay_a PS C:\Users\Jeff\documents\pipe tests> java ct # 2 2 records hold *OK* RC=4 PS C:\Users\Jeff\documents\pipe tests>

The only change is in keeping the Java file.  And the results.

This version has a say " \-" statement active. It tests OK with normal compilation.  When I ask for the Java file to be kept, it FAILs.  Exact same source file.

At another time I compiled it, keeping the Java file, with the say, and then with the say commented out.  With the say it worked, without it, it failed.

The only differences in the java files were the time in the first line and a  netrexx.lang.RexxIO.Say(" \000");  line which was in the right place in the logic.

At this time, I plan to take the pins out of the doll, leave the null "say" in, declare victory, publish that version, hope for the best, and go on.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Jeff & Rene,

it's so nice to see Your conversation on this problem. Sorry I cannot help. But an EXORCISM of Rene is, frankly speaking, a quite new ATTITUDE of our beloved President.

GOOD LUCK, both, and stay HEALTHY in this Corona times !

Thomas.

=======================================================================================================

Am 13.05.2020 um 19:05 schrieb René Jansen:

Hi Jeff,

if you check it in I’ll try an exorcism.

René.

On 13 May 2020, at 17:22, Jeff Hennick <[hidden email]> wrote:

The voodoo continues. 

The following is with no change in the source files, you see all the action.  "overlay_a" is the stage under test, "ct" is the test pipe calling the stage.  (In this test, "xyz" is coming in on the primary stream, "1 34  789" is on the secondary to be laid over, with an expected result of "1y34  789".  These are the second and last records in the pipe to be processed; the first set were done right.)

PS C:\Users\Jeff\documents\pipe tests> pipc overlay_a -keepasjava -replace PS C:\Users\Jeff\documents\pipe tests> java ct # 2 2 records hold **FAIL** at rec 2 col 1. More: Actual: xyz Expected: 1y34 789 RC=4 PS C:\Users\Jeff\documents\pipe tests> pipc overlay_a PS C:\Users\Jeff\documents\pipe tests> java ct # 2 2 records hold *OK* RC=4 PS C:\Users\Jeff\documents\pipe tests>

The only change is in keeping the Java file.  And the results.

This version has a say " \-" statement active. It tests OK with normal compilation.  When I ask for the Java file to be kept, it FAILs.  Exact same source file.

At another time I compiled it, keeping the Java file, with the say, and then with the say commented out.  With the say it worked, without it, it failed.

The only differences in the java files were the time in the first line and a  netrexx.lang.RexxIO.Say(" \000");  line which was in the right place in the logic.

At this time, I plan to take the pins out of the doll, leave the null "say" in, declare victory, publish that version, hope for the best, and go on.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Virus-free. www.avg.com

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Jeff Hennick-3]

A currently stable (I think) version has been checked in.  I have sent documentation of its enhanced options to the pipes list.

On 5/13/2020 1:05 PM, René Jansen wrote:

Hi Jeff,

if you check it in I’ll try an exorcism.

René.

On 13 May 2020, at 17:22, Jeff Hennick <[hidden email]> wrote:

The voodoo continues. 

The following is with no change in the source files, you see all the action.  "overlay_a" is the stage under test, "ct" is the test pipe calling the stage.  (In this test, "xyz" is coming in on the primary stream, "1 34  789" is on the secondary to be laid over, with an expected result of "1y34  789".  These are the second and last records in the pipe to be processed; the first set were done right.)

PS C:\Users\Jeff\documents\pipe tests> pipc overlay_a -keepasjava -replace PS C:\Users\Jeff\documents\pipe tests> java ct # 2 2 records hold **FAIL** at rec 2 col 1. More: Actual: xyz Expected: 1y34 789 RC=4 PS C:\Users\Jeff\documents\pipe tests> pipc overlay_a PS C:\Users\Jeff\documents\pipe tests> java ct # 2 2 records hold *OK* RC=4 PS C:\Users\Jeff\documents\pipe tests>

The only change is in keeping the Java file.  And the results.

This version has a say " \-" statement active. It tests OK with normal compilation.  When I ask for the Java file to be kept, it FAILs.  Exact same source file.

At another time I compiled it, keeping the Java file, with the say, and then with the say commented out.  With the say it worked, without it, it failed.

The only differences in the java files were the time in the first line and a  netrexx.lang.RexxIO.Say(" \000");  line which was in the right place in the logic.

At this time, I plan to take the pins out of the doll, leave the null "say" in, declare victory, publish that version, hope for the best, and go on.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ColinK]

Hi Jeff

I agree with Rene.  Pipes are NetRexx's secret super power!  The things one can quickly pull together with pipes is incredible! 

Cheers
Colin

On 2020-05-13 02:50, René Jansen wrote:

Hi Jeff,

well, I slightly disagree about the ‘amateur painting’. I use it heavily for work; look at my current shell statistics:

➜  netrexx-code git:(master) ✗ zsh_stats

     1 1130  11.2148%     pipe

     2 1059  10.5101%     cd

     3 751   7.45335%     git

     4 581   5.76618%     emacs

     5 472   4.6844%      ssh

     6 398   3.94998%     ll

     7 381   3.78126%     ls

     8 359   3.56292%     rm

     9 293   2.9079%      docker

    10 256   2.54069%     cat

    11 252   2.50099%     make

    12 168   1.66733%     pipc

    13 165   1.63755%     nrc

    14 156   1.54823%     exit

    15 154   1.52838%     gst

    16 149   1.47876%     rexx

    17 148   1.46884%     sudo

    18 138   1.36959%     brexx

    19 134   1.32989%     mv

    20 130   1.29019%     cp

It is very usable for the repetitive, but always slightly different work with files and directories that I do for the library on Aruba; for most tasks even scripting it in NetRexx would take more time. I find myself now also writing NetRexx with Pipelines integrated like I would do on CMS. I am thinking about modifying org.netrexx.process.NetRexxC to automatically send source to the pipes compiler when it ends in .njp - scanning for pipes would be the next step.

The fact that not very many people know CMS Pipelines and even less its NetRexx version is sad, but I am not particularly worried about that. When the compiler supports Java 9 we need to make some propaganda about it.

best regards,

René.

 

On 13 May 2020, at 05:26, Jeff Hennick <[hidden email]> wrote:

This whole project is mostly the equivalent of amateur painting for me.  It is unlikely that anyone will ever get any value out of it.  But with the current virus imposed stay at home, it is more interesting than other things I could do.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/