Menu
▾
▴
netrexx-pipelines
You can subscribe to this list here.
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(1) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2020 |
Jan
|
Feb
|
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(7) |
Jul
(10) |
Aug
(9) |
Sep
(9) |
Oct
(1) |
Nov
(3) |
Dec
(5) |
| 2021 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(3) |
Oct
(9) |
Nov
(1) |
Dec
(14) |
| 2022 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(165) |
Jul
(8) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(5) |
| 2023 |
Jan
(19) |
Feb
(14) |
Mar
(2) |
Apr
(3) |
May
|
Jun
(2) |
Jul
(10) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
(10) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: J L. T. <jlt...@ma...> - 2022-07-08 20:08:03
|
René, Interestingly, I see that putting the stream separator on a separate line (to make the boundary between streams more obvious) also causes the compile to fail (see attached): | $ pipc ltree1.njp | pipe (ltree1_ltree1 end ?) literal tree -pugsD arg(string 'paths'} | command | s: drop last 2 | a: split at [ | c: fanin 2 1 3 | t: faninany | console | 13 +++ ? -- Display the results. | | +++ ^ | +++ Error: Unexpected character found in source: '?' (hexadecimal encoding: 003F) | @15:03:45,leslie@pinto rc=2 Leslie On 2022-06-29 11:02:39 J Leslie Turriff wrote: > On 2022-06-27 14:35:31 René Jansen wrote: > > Hi Leslie, > > > > I was looking into this problem but could not reproduce: > > > > pipe (orx_downloads) > > literal curl > > https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/ > > > > | command > > | split > > | locate +href="https://sourceforge.net/projects/oorexx/files+ > > | nlocate /readme.md/ specs 7-* 1 > > | reverse > > | specs 2-* 1 > > | reverse > > | o: fanout > > | specs 77-* 1 > > | reverse > > | specs 10-* 1 > > | reverse > > | b: juxtapose > > | sort desc > > | specs /[/ 1 1-5 nw 7-11 nw 13-* nw /)/ nw > > | change /href/ /] (href/ > > | cons ? o: > > | insert / / > > > > b: > > > > > > ➜ test git:(master) ✗ pipc oorexx_downloads.njp > > pipe (orx_downloads ) literal curl > > https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/ | command > > | split | locate +href="https://sourceforge.net/projects/oorexx/files+ | > > nlocate /readme.md/ specs 7-* 1 | reverse | specs 2-* 1 | reverse | o: > > fanout | specs 77-* 1 | reverse | specs 10-* 1 | reverse | b: juxtapose | > > sort desc | specs /[/ 1 1-5 nw 7-11 nw 13-* nw /)/ nw | change /href/ /] > > (href/ | cons ? o: | insert / / > > > > (And I verified the classes were generated). > > > > Do you have the source file for the original issue somewhere? > > > > Best regards, > > > > René. > > The last time I tried to review it I couldn't find it, butI will look > again. > > Leslie -- |
|
From: J L. T. <jlt...@ma...> - 2022-07-08 19:28:03
|
René, Sorry for the delay in replying to you. Attached is ltree1.njp, which was where I encountered the problem. The first variant of the pipeline (the uncommented one) compiles, but fails with a stall; compilation of the second variant fails at the first occurrance of the s: label with the message | $ pipc ltree1.njp | pipe (ltree1_ltree1 end ?) literal tree -pugsD arg(string 'paths'} | 31 +++ | s: drop last 2 | -- Reattach summary lines later. | +++ ^ | +++ Error: Unexpected character found in source: ':' (hexadecimal encoding: 003A) | @14:17:33,leslie@pinto rc=2 Leslie On 2022-06-29 11:02:39 J Leslie Turriff wrote: > On 2022-06-27 14:35:31 René Jansen wrote: > > Hi Leslie, > > > > I was looking into this problem but could not reproduce: > > > > pipe (orx_downloads) > > literal curl > > https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/ > > > > | command > > | split > > | locate +href="https://sourceforge.net/projects/oorexx/files+ > > | nlocate /readme.md/ specs 7-* 1 > > | reverse > > | specs 2-* 1 > > | reverse > > | o: fanout > > | specs 77-* 1 > > | reverse > > | specs 10-* 1 > > | reverse > > | b: juxtapose > > | sort desc > > | specs /[/ 1 1-5 nw 7-11 nw 13-* nw /)/ nw > > | change /href/ /] (href/ > > | cons ? o: > > | insert / / > > > > b: > > > > > > ➜ test git:(master) ✗ pipc oorexx_downloads.njp > > pipe (orx_downloads ) literal curl > > https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/ | command > > | split | locate +href="https://sourceforge.net/projects/oorexx/files+ | > > nlocate /readme.md/ specs 7-* 1 | reverse | specs 2-* 1 | reverse | o: > > fanout | specs 77-* 1 | reverse | specs 10-* 1 | reverse | b: juxtapose | > > sort desc | specs /[/ 1 1-5 nw 7-11 nw 13-* nw /)/ nw | change /href/ /] > > (href/ | cons ? o: | insert / / > > > > (And I verified the classes were generated). > > > > Do you have the source file for the original issue somewhere? > > > > Best regards, > > > > René. > > The last time I tried to review it I couldn't find it, butI will look > again. > > Leslie -- |
|
From: <hp...@we...> - 2022-07-06 04:11:14
|
Jeff! i) Seems I was not clear enough last time: I don't like private mails about subjects publicly debated on a mailing list. Jeff, René, all who helped, ii) I quit. Why? After a soundly test of NetRexx Pipelines I conclude: it's not what I hoped it could be since it is advertised with "Implements CMS Pipelines". IMO no, not yet. To be fair I must mention that I tried to run it from ooRexx, what inflicts additional problems. Mainly it's the need to wrap calls in 'Address "" ... with input ... output ...', what is a distinct limitation to one input sources only and one output sink (and one error output). Next problem is ooRexx 5.oo _Beta_ -- it /seems/ to me not stable. At least I did not give up too soon, I finished a little routine. Some of the OS/2 Pipelines I had to convert completely to REXX, some pipes I had to simplify or split in two parts -- in short, together with the a. m. restrictions I had to rewrite every pipe, and therefore also to test and debug it. I did not try to migrate ooRexx to NetRexx, so I can not estimate if NR Pipelines perform better directly with NetRexx. Am 05.07.2022 um 16:58 schrieb Jeff Hennick: > [...] tl;dr. Best, M. |
|
From: <hp...@we...> - 2022-07-05 12:30:35
|
Jeff! Am 05.07.2022 um 02:42 schrieb Jeff Hennick: > The complicated *SPECs* stage has complicated, and I find in places > contradictory, documentation in the IBM publications. So you did report to IBM the contradictions you found, I assume. > I am going into detail here, but the problem as I see it, is misreading the > description of an /input-source/ format (right justified for *NUMBER*) for an > /output placement/ (truncated on the right to the specified field width by default). Your detailed documentation of all relevant descriptions about specs' recno/number placement shows clearly, if you copy CMS Pipelines you have to observe _all_ references in IBM's manuals. In contrast, for me the "right justified" in Chapter 23 was enough to doubt your hint "without documenting it" within note #7 for the specs stage deviants from the "exemplar". > The _User's Guide and Reference Version 7 Revision 1_ would seem to be the most > current. I skip all details which are _not_ self-contradictory for me. > [...] > In the */spec /Tutorial* on page 174 we have the example of all this coming > together in > > Figure 285. Number and Literal > > specs number 1.5 left /*/ next > > with > > input record > output record > First record 1 * > Second record 2 * > > *it is my contention that this is not in agreement with the Reference. Why is > it taking the last 5 characters of 10 input and not the first ones? Apparently > it is only NUMBER/RECNO that exhibits this behavior.* Honestly, considering all the details you mentioned before, I was astonished. It smells as if blanks are stripped before placement. Then, scrolling back from page 174 to 173, last paragraph, second to last phrase: "When you use a placement option, the input field is stripped of blanks before it is placed." -- No comment. > Your other comments, I agree with totally. One was not a comment but a query: where to find the documentation (part/chapter/page) of NetRexx Pipelines specs stage placement defaults, alleged in note #7 for specs in upcoming revision of the list of differences to the role model. > [...] > I mention the Author's Edition only because someone, you-?-, brought it into the > discussion. I consider it outdated and depreciated. Agreed, it definitely is dated. Without access to an up-to-date z/VM it's the one corresponding to the youngest "field-test" distribution at http://vm.marist.edu/%7Epipeline/ I may use. Thus, it would be sufficing if NetRexx Pipelines complies with that release -- at least for me ;) Best, M. |
|
From: Jeff H. <Je...@Je...> - 2022-07-05 00:42:17
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Mike,</p>
<p>Thank you, as always, for the time and comments.</p>
<p>The complicated <b>SPECs</b> stage has complicated, and I find
in places contradictory, documentation in the IBM publications.</p>
<p>I am going into detail here, but the problem as I see it, is
misreading the description of an <i>input-source</i> format
(right justified for <b>NUMBER</b>) for an <i>output placement</i>
(truncated on the right to the specified field width by default).<br>
</p>
<p>The <u>User's Guide and Reference Version 7 Revision 1</u> would
seem to be the most current.<br>
</p>
<p>On the <b>NUMBER/RECNO</b> option's placement, you refer to page
573. This section says on page 571, "This article contains but an
overview of spec. Refer to Chapter 16, “spec Tutorial” on
page 166 and Chapter 24, “spec Reference” on page 719."</p>
<p>That overview says "NUMBER ... describes a
10-byte input field ..., right
aligned with leading blanks (no leading zeros)." Later in the
overview, page 574, is "Placement of data in the output field:
When an output range is specified without a placement option, the
input field after conversion is aligned on the left (possibly with
leading
blank characters), <b>truncated or padded on the right</b> [bold
added] with pad characters." Neither indicates the <u>output</u>
position for NUMBER is an exception.</p>
<p>In the <b><i>spec </i></b><b>Reference</b> on page 722, in
general, "Arithmetic is done in signed decimal floating point with
thirty-one significant digits." On page 729 is the reference for
the <b>NUMBER</b> option. Note that it is just one of many input
sources, and available for any of the conversion and output
options. "The record number is computed in decimal arithmetic
with up to fifteen significant digits. ... The number is aligned
to the right
with a drifting minus sign.
The implied field length is ten characters. ... <b>Notes: </b>1.
NUMBER is a convenience; the same result can be obtained by
incrementing a counter." With no indication of special <u>output</u>
formatting.</p>
<p>At this point we have a 10 character string with the digits right
justified, padded on the left with blanks, just as though it had
been read as such from the input record.<br>
</p>
<p>On page 734 we get to <b>Output Placement</b>. There is nothing
specific for the <b>NUMBER/RECNO</b> input source that I can
find. We can place those 10 characters where we want in the
output record. The confusion/problem comes when that position is
specified as a <i>range </i>(or a width on<i> </i><b>NEXTWORD</b>),
with a field length <u>less than 10</u>. In that case page 735
says "<i>range </i>Specify the extent of the output field. If
the field length is different
from the size of the data to be stored, the data are padded with
the pad character or <b>truncated on the right </b>[bold added],
unless a placement option is
specified." No exceptions are noted.</p>
<p>In the <b><i>spec </i>Tutorial</b> on page 174 we have the
example of all this coming together in <br>
</p>
<blockquote>
<p>Figure 285. Number and Literal <br>
</p>
<p>specs
number 1.5 left /*/ next <br>
</p>
<p>with <br>
</p>
</blockquote>
<blockquote>
<table width="323" height="88" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td valign="top">input record<br>
</td>
<td valign="top">output record<br>
</td>
</tr>
<tr>
<td valign="top">First record</td>
<td valign="top"><font face="monospace">1 *</font></td>
</tr>
<tr>
<td valign="top">Second record</td>
<td valign="top"><font face="monospace">2 *</font></td>
</tr>
</tbody>
</table>
</blockquote>
<p><b>it is my contention that this is not in agreement with the
Reference. Why is it taking the last 5 characters of 10 input
and not the first ones? Apparently it is only NUMBER/RECNO that
exhibits this behavior.</b></p>
<p>Your other comments, I agree with totally. I agree that this
behavior, if documented, would be "most wise" (also considerably
harder it implement, I think, since the output placement has to be
informed that this string of characters came from NUMBER/RECNO and
hasn't been converted since). <br>
</p>
<p>The 3.11 is a typo on my part, not updating it. To be fixed.<br>
</p>
<p>I mention the Author's Edition only because someone, you-?-,
brought it into the discussion. I consider it outdated and
depreciated.</p>
<p>Jeff<br>
</p>
<div class="moz-cite-prefix">On 7/4/2022 4:31 PM, <a class="moz-txt-link-abbreviated" href="mailto:hp...@we...">hp...@we...</a>
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2bb...@we...">Hello Jeff!
<br>
<br>
Thank you for the announce of innovations.
<br>
Just one...two questions.
<br>
<br>
Am 04.07.2022 um 16:58 schrieb Jeff Hennick:
<br>
<blockquote type="cite">[...]
<br>
*SPECs*' left/right position of the *recno*:
<br>
(7) CMS Pipelines, without documenting it, ...
<br>
</blockquote>
<br>
Without documenting it? In CMS/TSO Pipelines Author’s Edition,
<br>
p. 557 (585 of the PDF), paragraph beginning with /The record
number/
<br>
I find "right aligned".
<br>
<br>
Since you stated some days ago
<br>
<br>
<blockquote type="cite">I have been referencing z/VM CMS Pipelines
User’s Guide
<br>
and Reference *Version 7 Release 1*. I suggest NOT using the
Author's Edition
<br>
as a reference, although as a general User's Guide it is very
useful.
<br>
</blockquote>
<br>
I looked for the z/VM 7.1 CMS Pipelines USR GDE & REF MNL and
<br>
found it accessible for free. About 'specs' positioning recno it
<br>
says: "right aligned" (p. 573, p. 601 of the PDF). For me this is
<br>
/documenting/ enough.
<br>
<br>
<blockquote type="cite"> ... places this right by default
<br>
</blockquote>
<br>
IMO, everything else is pretty unwise.
<br>
<br>
<blockquote type="cite"> NetRexx Pipelines follows the
documentation and places this left by default.
<br>
</blockquote>
<br>
Which documentation? That of NetRexx Pipelines of course, Guide
<br>
and Reference I assume, ISBN 978-90-819090-3-7. Would you please
<br>
be so kind and give out where exactly the default placement to the
<br>
left is documented, part/chapter/page.
<br>
<br>
<blockquote type="cite">This version is available from SourceForge
at
<br>
<a class="moz-txt-link-freetext" href="https://sourceforge.net/p/netrexx/code/ci/master/tree/documentation/njpipes/Pipeline%20Stages.html">https://sourceforge.net/p/netrexx/code/ci/master/tree/documentation/njpipes/Pipeline%20Stages.html</a>
<br>
</blockquote>
<br>
First two lines show
<br>
<br>
<blockquote type="cite">Stages Built Into
<br>
NetRexx Pipelines 3.11
<br>
</blockquote>
<br>
while version 4.03-GA of NetRexx Pipelines Guide and Reference
<br>
shows on p. 36 (p. 42 of the PDF)
<br>
<br>
<blockquote type="cite">Stages Built Into
<br>
NetRexx Pipelines 4.02
<br>
</blockquote>
<br>
BTW, you suggest _not_ to use the Author's Edition as a reference,
<br>
for not more than a general User's Guide, so general users using
<br>
the (dated) author's edition might be puzzled every now and then
<br>
finding deviations in NetRexx Pipelines.
<br>
<br>
Best,
<br>
M.
<br>
<br>
<br>
_______________________________________________
<br>
netrexx-pipelines mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:net...@li...">net...@li...</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines">https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines</a>
<br>
</blockquote>
</body>
</html>
|
|
From: <hp...@we...> - 2022-07-04 20:31:17
|
Hello Jeff! Thank you for the announce of innovations. Just one...two questions. Am 04.07.2022 um 16:58 schrieb Jeff Hennick: > [...] > *SPECs*' left/right position of the *recno*: > (7) CMS Pipelines, without documenting it, ... Without documenting it? In CMS/TSO Pipelines Author’s Edition, p. 557 (585 of the PDF), paragraph beginning with /The record number/ I find "right aligned". Since you stated some days ago > I have been referencing z/VM CMS Pipelines User’s Guide > and Reference *Version 7 Release 1*. I suggest NOT using the Author's Edition > as a reference, although as a general User's Guide it is very useful. I looked for the z/VM 7.1 CMS Pipelines USR GDE & REF MNL and found it accessible for free. About 'specs' positioning recno it says: "right aligned" (p. 573, p. 601 of the PDF). For me this is /documenting/ enough. > ... places this right by default IMO, everything else is pretty unwise. > NetRexx Pipelines follows the documentation and places this left by default. Which documentation? That of NetRexx Pipelines of course, Guide and Reference I assume, ISBN 978-90-819090-3-7. Would you please be so kind and give out where exactly the default placement to the left is documented, part/chapter/page. > This version is available from SourceForge at > https://sourceforge.net/p/netrexx/code/ci/master/tree/documentation/njpipes/Pipeline%20Stages.html First two lines show > Stages Built Into > NetRexx Pipelines 3.11 while version 4.03-GA of NetRexx Pipelines Guide and Reference shows on p. 36 (p. 42 of the PDF) > Stages Built Into > NetRexx Pipelines 4.02 BTW, you suggest _not_ to use the Author's Edition as a reference, for not more than a general User's Guide, so general users using the (dated) author's edition might be puzzled every now and then finding deviations in NetRexx Pipelines. Best, M. |
|
From: Jeff H. <Je...@Je...> - 2022-07-04 14:59:11
|
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I have submitted, for the next release, updated Stages
documentation. This is prompted by discussion on this list.
Thank you Mike, Leslie, and Rob.<br>
</p>
<p>This includes <br>
</p>
<ul>
<li>adding the abbreviations for <b>Locate</b></li>
<li>notation of the discrepancy in the IBM
documentation/implementation in <b>SPECs</b>' left/right
position of the <b>recno</b>: <br>
(7) <span class="cmsonly">CMS Pipelines, without documenting
it, places this right by default</span> <span class="njponly">NetRexx
Pipelines follows the documentation and places this left by
default</span>. Specify the alignment you want to override
these defaults. </li>
<li>clean up of the options for <b>XLATE/TRANSlate</b></li>
<li>correct the multiple <i>inputRange</i>s grouping brackets</li>
<li>adding some other stage name abbreviations</li>
</ul>
<p>This version is available from SourceForge at
<a class="moz-txt-link-freetext" href="https://sourceforge.net/p/netrexx/code/ci/master/tree/documentation/njpipes/Pipeline%20Stages.html">https://sourceforge.net/p/netrexx/code/ci/master/tree/documentation/njpipes/Pipeline%20Stages.html</a></p>
<p>I expect more changes to this and some stage programs before the
next general release. (I just spotted 2 typos.)<br>
</p>
<p>Jeff<br>
</p>
</body>
</html>
|
|
From: <hp...@we...> - 2022-07-01 17:11:58
|
Hello René! To keep my promise I now published my first successful migration from OS/2 to NetRexx Pipelines. Since this list impedes ZIP attachments you find it here: https://forum.hp41.org/viewtopic.php?f=13&t=372#p1892 It is the fruit of all the kind help I received from this list. Thank you. The resulting files work flawlessly in V41, https://hp.giesselink.com/v41.htm Well, it's still work in progress, since I am able to pack .class files to a .jar, but found no description yet how to run pipelines in the .jar file. Is there an example somewhere? > Am 29.06.2022 um 18:37 schrieb René Jansen: >> I mostly compile the stages with ’trace results’ and see what >> flows. In the new 4.04 you can even use Marc’s ’trace interactive’. I tried, but neither 'trace result' nor 'trace interactive' show something like "data flow", it compiles and runs as without this line: > /* MkR_9b.njp: show prgms in 4 colums side by side */ > > trace results > > pipe (MkR_9b sep ! end ?) cons!x: strfrlab /nixbix/!drop ! > a: lookup *-* w1-2 master ! > spec w3-* 1 ! > b: locate 1 /'/ ! > change 1 x27 x22 ! > insert x22 after ! > insert /XROM / ! > c: faninany ! > spec pad 0 recno 1.4 r *-* nw ! > change x20FA4C424C xFA4C424C ! > d: take 9!spec 3-* 1 ! > e: faninany!pad 20!snake 4!chop 79 ! > literal!term > ?x:!a:!c:?b:!c: > ?d:! > strip leading str /0/!e: === I found some more errors in NetRexx Pipelines: spec fails badly > literal MOD1!pad 5 00!spec *-* c2x 1!term returns : 4D4F44310 expected: 4D4F443100 === diskr fails (IMO) 'FA'x in file is converted to 'FFFD'x in NetRexx Pipeline. In cmd window 'FA'x shows as · (cdot) while 'FFFD'x as "?" === change error > ... '! change x20FFFD4C424C xFA4C424C', does not alter the given sequence whilst actually present in data. === stage ending not propagated in time > ... > '!d: take 9!spec 3-* 1', > '!e: fanin' clmsho '!chop 79!term', > '?d:', > '!copy', > '! strip leading str /0/!e:' > ... To prevent a stall I had either to insert a copy stage as shown or change fanin to faninany. Theoretically unnecessarily. Totally. (After nine records take changes operation but the information about that should also propagate forward to Fanin so it will switch to next stream.) === snake fails Try: > literal!dup 8!spec recno 1!pad 20!snake 4!term' > literal!dup 8!spec recno 1!pad 27!snake 3!term' === Nasty surprise in ooRexx (at leat for me) I had do learn that it makes a big difference > in. = xrom. or > in. = xrom.~copy In first case, altering in. also modifies xrom. (Who needs this?) === RC=4, alas not found why. > ... > d: take 9!spec 3-* 1 ! > e: fanin!pad 27!snake 3!chop 79 ! > literal!term > ?x:!a:!c:?b:!c: > ?d:! > copy ! -- ... it is what it is: NetRexx Pipelines > strip leading str /0/!e: works with 8 records arriving at d:, while it fails with > ... e: fanin!pad 20!snake 4 ... Here I hoped 'trace interactive' could shed some light onto the dark matter behind the scenes. === Next steps? Yep, why not migrate this little toy from ooRexx to NetRexx? a) would it be possible and b) would there be a gain in execution speed? Currently, using pre-compiled pipes, it is not overwhelming fast, but "within the realms of bearable". Best, M. |
|
From: <hp...@we...> - 2022-06-29 22:59:18
|
Hello René!
Am 29.06.2022 um 18:37 schrieb René Jansen:
> I mostly compile the stages with ’trace results’ and see what flows. In the new 4.04 you can even use Marc’s ’trace interactive’.
Thank you for this hint. Sorry, I did not test it yet. Nonetheless
I achieved at last the first binary output of my converter. I'll
publish it when all works as desired (have to remove also all
holdover from OS/2 Pipelines).
There are several severe errors in Specs stage, also in few
others. As long as your "Pipelines Guide and Reference" shows in
chapter 8 'For a complete description we refer to the IBM
Pipelines documentation' I will regard all disparities as errors.
Even without reference to the role model, some bugs just thwart
the use of NetRexx Pipelines. For example, I was not able to write
a binary file.
What I found today:
i) reverse fails and/or specs fails
I'd expect same results from either
> ... !spec pad 0 w1 d2x 1.4 r!spec 3.2 1 1.2 n
and
> ... !spec pad 00 w1 d2c 1.2 r!reverse!spec pad 0 *-* c2x 1.4 r
with input 0..1023
===
ii) specs fails
> .. literal 0010001110000000000000010000000000000110!spec w1 b2c 1!spec pad 0 *-* c2x 1.10 r
returns:
0002380106
===
iii) specs fails
> Address '' ripe '"(MkR_x sep !) literal 410042!',
> 'spec w1 x2c 1!reverse!spec *-* c2x 1!term'
returns: 42041
expected: 420041
===
iv) probably a problem of ooRexx:
> Address ... with output use (f)
with "..." a nice NetRexx pipeline
circumvents filing binary files.
'0A'x is interpretet as linened,
'80'x and above is changed to "?"
===
Therefore I had to do some annoying post-processing in Rexx:
Without Vchar stage I'm forced to do it binary...
> jfg = 'spec pad 0 w1 d2x 13.4 r read w1 d2x 9.4 r read w1 d2x 5.4 r read w1 d2x 1.4 r',
> '!spec *-* x2b 1!fblock 16!spec 7.10 1!join 3!spec pad 0 w1 b2x 1.10 r'
> f = .stream~new(modid || '.ROM')
> if f~open("W REP BI REC 5120") \== "READY:" then exit,
> RxMessageBox('Could not open file for writing ROM list,',
> 'procedure ends.', , 'OK', 'STOP')
> Address '' ripe '"(MkR_8 sep !) cons!' jfg '!term',
> with input stem rom. output stem bin.
> do i = 1 to bin.0; f~CharOut(reverse(x2c(bin.i))); end
(Stem rom. contains 4096 decimal values in the range 0..1023)
I find it pretty disgraceful writing data prepared with a pipeline
using a loop in Rexx.
Best,
M.
|
|
From: <hp...@we...> - 2022-06-29 22:59:17
|
Pipelines on youngest z/VM has more stuff in storage than the Marist edition (which nonetheless is pretty useful for the hobbyist piper.) Best, M. Am 29.06.2022 um 18:32 schrieb René Jansen: > I think the point of this Author’s Edition was that it documented all the new developments since Pipelines on z/VM was frozen. Only with z/VM 6.04 a new level was introduced that contained all of the stages that only were usable from the downloaded Marist edition. Rob van der Heij has worked very hard to get it up to date again. > > René. > > >> On 29 Jun 2022, at 17:37, J Leslie Turriff <jlt...@ma...> wrote: >> >> When I last had access to a VM/CMS system there were many stages documented in the >> Author's Edition that were not covered in the CMS Pipelines Reference. Maybe that has >> changed since then? >> >> Leslie |
|
From: Jeff H. <Je...@Je...> - 2022-06-29 17:06:22
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>The NetRexx Pipelines documentation does both. <br>
</p>
<p><img src="cid:par...@Je..." alt=""></p>
<p>The left shows the command and all aliases. The RRT uses UPPER
case for the required part and lower case for optional, full,
parts, following the Rexx convention.<br>
</p>
Also, the same information is duplicated under both <b>xlate</b>
and <b>translate</b> in their respective alphabetical locations.
So if you are trying to read an existing pipe that has a <b>translate</b>
stage it is easy to find. The IBM publication sometimes buries that
information in a footnote.
<p>As a further service, this alias information is extended to
stages that are CMS only:</p>
<p><img src="cid:par...@Je..." alt=""></p>
<p>Our "big problem" is using text rather than fancy illustrations
so the solid triangles are not exactly a character wide and the
back-and-down arrows don't quite meet up. Terrible!</p>
<p>The underlined parts, online, are links to popups that expand on
the definition of it, in this case, what an xrange is.</p>
<p>Jeff<br>
</p>
<div class="moz-cite-prefix">On 6/29/2022 11:42 AM, J Leslie Turriff
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:202...@ma...">
<pre class="moz-quote-pre" wrap=""> I think that part of the reason that the abbreviations are not well documented is that
the railroad track syntax diagram convention is to show the command name (here the stage
name) in all caps. This of course obscures the available abbreviations of stage names.
It would be very helpful if the title of each section that described a stage showed the
stage name in the expected abbreviation form; that way, just looking at the ToC would
make them obvious.
I don't expect to see any such change making it into the mainframe documentation,
though.)
Leslie
On 2022-06-25 20:43:15 Jeff Hennick wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">It looks like the manual is wrong here, too.
My vote is for NetRexx Pipelines to use the abbreviations, as does the
XEDIT model, and document the discrepancy. Jeff
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
--
Operating System: Linux
Distribution: openSUSE Leap 15.4 x86_64
java version "18" 2022-03-22
NetRexx portable processor 4.03-GA build 260-20220503-1730
_______________________________________________
netrexx-pipelines mailing list
<a class="moz-txt-link-abbreviated" href="mailto:net...@li...">net...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines">https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines</a>
</pre>
</blockquote>
</body>
</html> |
|
From: René J. <rvj...@xs...> - 2022-06-29 16:37:49
|
I mostly compile the stages with ’trace results’ and see what flows. In the new 4.04 you can even use Marc’s ’trace interactive’. René. > On 29 Jun 2022, at 06:11, hp...@we... wrote: > > > After all the kind support I received from this list I still have > questions. How may I see the data in the pipeline? Option 'debug > 63' does not show it. On CMS there was a PipeDemo program what > enabled to 'single-step' a pipe's data flow. Does something > similar exist here too? |
|
From: René J. <rvj...@xs...> - 2022-06-29 16:32:21
|
I think the point of this Author’s Edition was that it documented all the new developments since Pipelines on z/VM was frozen. Only with z/VM 6.04 a new level was introduced that contained all of the stages that only were usable from the downloaded Marist edition. Rob van der Heij has worked very hard to get it up to date again. René. > On 29 Jun 2022, at 17:37, J Leslie Turriff <jlt...@ma...> wrote: > > When I last had access to a VM/CMS system there were many stages documented in the > Author's Edition that were not covered in the CMS Pipelines Reference. Maybe that has > changed since then? > > Leslie > > On 2022-06-26 06:46:00 Jeff Hennick wrote: >> On 6/25/2022 11:33 PM, hp...@we... wrote: >> >> >> Sure, 'the Book' (author's edition) "does not exactly reflect" >> what's up. In addition, pipe ahelp L shows help for LDRTBLS, not >> for Locate. In contrast, help pipe L works as expected. >> >> I suppose for that you have clear rules of precedence when cloning >> the role model. >> >> /M. >> >> >> Unfortunately, CMS/TSO Pipelines Author’s Edition 1.1.12 does not say >> which Level of Pipelines it documents. It says it applies to Version 1 and >> everything above! It does say that the examples were all run at Level >> "CMS/TSO Pipelines, 5654-030/5655-A17 level 110C0006." Which is not very >> helpful to me. It does reference publication SC24-6077, which is z/VM IBM >> CMS Pipelines User’s Guide version 5 release 2. I have been referencing >> z/VM CMS Pipelines User’s Guide and Reference Version 7 Release 1. I >> suggest NOT using the Author's Edition as a reference, although as a >> general User's Guide it is very useful. Jeff > > -- > > > > _______________________________________________ > netrexx-pipelines mailing list > net...@li... > https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines |
|
From: René J. <rvj...@xs...> - 2022-06-29 16:28:30
|
He is from Danmark so I expect he would live in that language environment. René. > On 29 Jun 2022, at 17:53, J Leslie Turriff <jlt...@ma...> wrote: > > I may be wrong, but I believe that the Pipelines author, John Hartmann, is located in > Belgium? > > Leslie > > On 2022-06-27 18:46:31 hp...@we... wrote: >>> Is there a good reason that "500 EBCDIC Belgium, Canada, >>> Switzerland, International Latin-1. International number 5. This is >>> the base codepage for xlate." rather than say, "285 EBCDIC United >>> Kingdom." or "37 EBCDIC United States, Canada, Netherlands, Portugal, >>> Brazil, Australia, New Zealand." and how should I decide between that and >>> "274 EBCDIC Belgium." if I am really interested in Belgium? >> >> Your are interested in Belgium? No, if you exchange files with a >> VM system located in Belgium (and which is running on CP 274) you >> are interested to see as much as possible on your PC screen as >> would be visible on the mainframe terminal "chez les belges". >> And vv too. > > -- > Operating System: Linux > Distribution: openSUSE Leap 15.4 x86_64 > java version "18" 2022-03-22 > NetRexx portable processor 4.03-GA build 260-20220503-1730 > > > _______________________________________________ > netrexx-pipelines mailing list > net...@li... > https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines |
|
From: J L. T. <jlt...@ma...> - 2022-06-29 16:02:55
|
On 2022-06-27 14:35:31 René Jansen wrote: > Hi Leslie, > > I was looking into this problem but could not reproduce: > > pipe (orx_downloads) > literal curl > https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/ > > | command > | split > | locate +href="https://sourceforge.net/projects/oorexx/files+ > | nlocate /readme.md/ specs 7-* 1 > | reverse > | specs 2-* 1 > | reverse > | o: fanout > | specs 77-* 1 > | reverse > | specs 10-* 1 > | reverse > | b: juxtapose > | sort desc > | specs /[/ 1 1-5 nw 7-11 nw 13-* nw /)/ nw > | change /href/ /] (href/ > | cons ? o: > | insert / / > > b: > > > ➜ test git:(master) ✗ pipc oorexx_downloads.njp > pipe (orx_downloads ) literal curl > https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/ | command | > split | locate +href="https://sourceforge.net/projects/oorexx/files+ | > nlocate /readme.md/ specs 7-* 1 | reverse | specs 2-* 1 | reverse | o: > fanout | specs 77-* 1 | reverse | specs 10-* 1 | reverse | b: juxtapose | > sort desc | specs /[/ 1 1-5 nw 7-11 nw 13-* nw /)/ nw | change /href/ /] > (href/ | cons ? o: | insert / / > > (And I verified the classes were generated). > > Do you have the source file for the original issue somewhere? > > Best regards, > > René. The last time I tried to review it I couldn't find it, butI will look again. Leslie -- |
|
From: J L. T. <jlt...@ma...> - 2022-06-29 15:54:03
|
I may be wrong, but I believe that the Pipelines author, John Hartmann, is located in Belgium? Leslie On 2022-06-27 18:46:31 hp...@we... wrote: > > Is there a good reason that "500 EBCDIC Belgium, Canada, > > Switzerland, International Latin-1. International number 5. This is > > the base codepage for xlate." rather than say, "285 EBCDIC United > > Kingdom." or "37 EBCDIC United States, Canada, Netherlands, Portugal, > > Brazil, Australia, New Zealand." and how should I decide between that and > > "274 EBCDIC Belgium." if I am really interested in Belgium? > > Your are interested in Belgium? No, if you exchange files with a > VM system located in Belgium (and which is running on CP 274) you > are interested to see as much as possible on your PC screen as > would be visible on the mainframe terminal "chez les belges". > And vv too. -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 java version "18" 2022-03-22 NetRexx portable processor 4.03-GA build 260-20220503-1730 |
|
From: J L. T. <jlt...@ma...> - 2022-06-29 15:42:38
|
I think that part of the reason that the abbreviations are not well documented is that the railroad track syntax diagram convention is to show the command name (here the stage name) in all caps. This of course obscures the available abbreviations of stage names. It would be very helpful if the title of each section that described a stage showed the stage name in the expected abbreviation form; that way, just looking at the ToC would make them obvious. I don't expect to see any such change making it into the mainframe documentation, though.) Leslie On 2022-06-25 20:43:15 Jeff Hennick wrote: > It looks like the manual is wrong here, too. > My vote is for NetRexx Pipelines to use the abbreviations, as does the > XEDIT model, and document the discrepancy. Jeff -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 java version "18" 2022-03-22 NetRexx portable processor 4.03-GA build 260-20220503-1730 |
|
From: J L. T. <jlt...@ma...> - 2022-06-29 15:37:25
|
When I last had access to a VM/CMS system there were many stages documented in the Author's Edition that were not covered in the CMS Pipelines Reference. Maybe that has changed since then? Leslie On 2022-06-26 06:46:00 Jeff Hennick wrote: > On 6/25/2022 11:33 PM, hp...@we... wrote: > > > Sure, 'the Book' (author's edition) "does not exactly reflect" > what's up. In addition, pipe ahelp L shows help for LDRTBLS, not > for Locate. In contrast, help pipe L works as expected. > > I suppose for that you have clear rules of precedence when cloning > the role model. > > /M. > > > Unfortunately, CMS/TSO Pipelines Author’s Edition 1.1.12 does not say > which Level of Pipelines it documents. It says it applies to Version 1 and > everything above! It does say that the examples were all run at Level > "CMS/TSO Pipelines, 5654-030/5655-A17 level 110C0006." Which is not very > helpful to me. It does reference publication SC24-6077, which is z/VM IBM > CMS Pipelines User’s Guide version 5 release 2. I have been referencing > z/VM CMS Pipelines User’s Guide and Reference Version 7 Release 1. I > suggest NOT using the Author's Edition as a reference, although as a > general User's Guide it is very useful. Jeff -- |
|
From: <hp...@we...> - 2022-06-29 04:19:12
|
Hi all! Until the Xlate stage will be fixed in some future release of NetRexx Pipelines I'll use plain Rexx instead. So the problem is bypassed and I am about to debug the last two pipelines of my program, converting the "human readable" result (which is entirely the same as from OS/2 Pipelines) in two binary formats. My first 'whole program'-migration to NetRexx Pipelines is almost done. After all the kind support I received from this list I still have questions. How may I see the data in the pipeline? Option 'debug 63' does not show it. On CMS there was a PipeDemo program what enabled to 'single-step' a pipe's data flow. Does something similar exist here too? I started testing by "slicing" my pipe to single stages I run in a "executor" like this > Address '' ripe '"(MkR_x sep !)' jfg '!take 11!term', > with input stem rom. and variable jfg containing piecewise my pipe. First run: > jfg = 'cons!spec w1 d2x 1.4 r' results: > 6 > 40 > 0 > 8E > 200 > F5 > 208 > 69 > 200 > EB > 20E what differs from the role model. So I have to set > jfg = 'cons!spec pad 0 w1 d2x 1.4 r' results: > 0006 > 0040 > 0000 > 008E > 0200 > 00F5 > 0208 > 0069 > 0200 > 00EB > 020E -- what I do expect without pad 0. I regard this discrepancy as an error. Next > jfg = 'cons!spec pad 0 w1 d2x 1.4 r!spec w1 x2c 1!spec *-* c2x 1' is to convert from hex to character and back again to check if x2c worked... > 06 > 040 -- woot? > 00 > 08E > 20 -- was 0200 > 0F5 > 28 -- was 0208 > 069 > 20 > 0EB > 2E -- now I'm lost. For me this looks like a big mess, and to achieve the binary format there are several more Specs to follow. The goal is to "pack" four 10-bit words to 5 bytes. What would be the best way in NetRexx Pipelines without Vchar stage? Is this again doable only in Rexx? All useful ideas welcome M. |
|
From: René J. <rvj...@xs...> - 2022-06-28 22:53:14
|
[intentionally cross-posted] Dear RexxLA members, The 33rd International Rexx Language Symposium (2022) will be on September 12-14, with an optional programme on the preceding Sunday. Like last year, the symposium will be online and conducted via zoom. Also like last year, the schedule will be adapted to the time zones in the US and Europe. (For other geographies we might re-run some of the presentations - it is our firm intention to have some of the presentations available on video this year). The International Rexx Language Symposium is a yearly event where Rexx users, irrespective of implementations and language variants, can meet and mingle. The programme committee which judges the presentation proposals consists of the President and the Vice President of RexxLA - that is myself and Terry Fuller. Please send in your presentation proposals! The separate Call For Papers (CFP) will shine more light on this process and its requirements. Apart from the presentations (which are readable from the RexxLA.org <http://rexxla.org/> website right after the presentations takes place, and which are often used a reference material), this yearly symposium is also a great opportunity to meet your fellow Rexx users, the implementors of the various variants, and - if we are lucky - a Q&A Session with the Father of Rexx himself, IBM Fellow Michael Cowlishaw. This year there will be even more Q&A sessions, and social events where we leave the session and its microphones and cameras open - and we will even experiment with parallel- and breakout sessions (if we understand how to do these in Zoom in time). There will be presentations on Classic (including mainframe) Rexx on TSO (ISPF) and CMS, Regina Rexx, NetRexx for the JVM world, and Open Object Rexx. Also, new implementations will be discussed. Hope to see you all! Best regards, René Jansen, President, Rexx Language Association. |
|
From: <hp...@we...> - 2022-06-28 17:46:35
|
Hi! A fundamental question: will NetRexx Pipelines stages not prepared to deal with higher numbered connections report such attempts with an error message? Why I ask such things? Well, it could help to avoid the need for long debugging. Triggered by the exchange of views about Xlate, I took a look at https://sourceforge.net/p/netrexx/code/ci/master/tree/src/org/netrexx/njpipes/stages/xlate.nrx to find the hint: > -- not implemented: > -- WS word separator > -- translate table via input file (I assume, the term 'input file' could be the single record on the secondary input stream.) The NetRexx Pipelines Guide and Reference does not document this difference to the role model. Therefore an error message would have helped to avoid my futile effort at first try. /M. Am 27.06.2022 um 22:39 schrieb ((me, myself and I)): > Hi René! > > Am 27.06.2022 um 17:00 schrieb René Jansen: >> [...] >> That it works for you does not means it is not going to be fixed. > > Yes please, the 256 bytes of the transliteration table takes some > 16 funny lines of code where a single line would be enough. > > /M. > > > _______________________________________________ > netrexx-pipelines mailing list > net...@li... > https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines |
|
From: <hp...@we...> - 2022-06-28 17:46:35
|
Am 27.06.2022 um 18:47 schrieb Jeff Hennick: > Also, mentioned only in passing in a footnote is "E2A". [The xlate.nrx > internal documentation says E2A (EBCDIC to ASCII) and A2E (ASCII to EBCDIC) > are options instead of UPper and LOWer in NetRexx Pipelines. ] ) In author's edition E2A and A2E are documented in note #1. > For compatibility with the past, xlate A2E is equivalent to xlate from 819. xlate E2A > is equivalent to xlate to 819. Next phrase of the note is redundant, theoretically. But many like to read what they already know. It's nice to see that NetRexx Pipelines takes care about history and copies also the role model's ancient capabilities. Best, M. |
|
From: Jeff H. <Je...@Je...> - 2022-06-28 16:11:22
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Mike and René,</p>
<p>Again I disclaim knowing the workings of the XLATE stage. I am
interested in getting the published documentation as accurate as I
can.</p>
<p>This is my current understanding, not withstanding any current
bugs in the NetRexx version. It would be in the next release. <br>
</p>
<p>The inputRanges has been fixed, and the default-table and notes
redone.<br>
</p>
<p><img src="cid:par...@Je..." alt=""></p>
<p>I ask your corrections, additions, comments, ideas, etc. In
particular, am I too strong in those notes? Thank you.</p>
<p>Jeff<br>
</p>
<br>
</body>
</html> |
|
From: <hp...@we...> - 2022-06-28 14:58:15
|
Hello René! Am 27.06.2022 um 17:00 schrieb René Jansen: > That is good news. Sorry, that was yesterday. Today I have to withdraw my statement Xlate would work with a table on secondary stream. It does not. My error was, by chance the numbers and the blank don't need to be transliterated, therefore at a too quick, first glance the output looked ok. By comparing the complete 4k output file, a ROM for the HP41, prepared using NetRexx Pipelines against the result obtained by using OS/2 Pipelines, the only difference are the four letters within 'C PPC 1981', the rest is identical. Digging for the reason of this slight discrepancy I found several errors or deviations from the role model (as I know it): i) Stage Xrange fails. Example: PIPE (sep !) xrange 00-ff ! ... Expected output: one record of 256 characters from '00'x to 'FF'x. Question: the manual states "NetRexx uses UTF-16 (ASCII) and CMS uses EBCDIC" -- is this hint related to the arguments of Xrange or its output? ii) Specs documentation error Specs conversion d2x is tagged with "(4) NetRexx Pipelines only. Not yet implemented in CMS" iii) Specs fails without output placement In contrast to the role model, where following works > pipe literal 1!spec w1 d2x!term NetRexx insists on ...!spec w1 d2x 1!... Yes, I know, this looks like a littleness, but it reminds me the story about changing 'trace i' in paragraph "Dealing with reality" of Michael Cowlishaw's "The REXX Language". iv) Specs output differs from role model On CMS: > pipe literal 1!spec w1 d2x!term > 00000001 > Ready; Result from NetRexx Pipelines is somewhat shorter. v) Specs x2c works varying First: what is a character in regard to Pipelines? While analysing all input to failing Xlate I checked the transliteration table: > address '' ripe '"(MkR_5 sep !) literal', > '3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A', > '3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A', > '202122232425262728292A2B2C2D2E2F', > '303132333435363738393A3B3C3D3E3F', > '000102030405060708090A0B0C0D0E0F', > '101112131415161718191A1B1C1D1E1F', > '404142434445463A3A3A3A3A3A3A3A3A', > '3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A', > '3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A', > '3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A', > '3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A', > '3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A', > '3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A', > '3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A', > '3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A', > '3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A!space 0!spec *-* x2c 1!', > 'fblock 16!spec *-* c2x 1!term' ... what is nothing but a simple conversion to characters and back again to hex for the display. Result is: > 3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A > 3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A > 202122232425262728292A2B2C2D2E2F > 303132333435363738393A3B3C3D3E3F > 0123456789ABCDEF > 101112131415161718191A1B1C1D1E1F > 404142434445463A3A3A3A3A3A3A3A3A > 3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A > 3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A > 3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A > 3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A > 3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A > 3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A > 3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A > 3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A > 3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A3A Have fun... ;) vi) Specs strips output unasked > address '' ripe '"(MkR_5 sep !) literal', > '000102030405060708090A0B0C0D0E0F!space 0!spec *-* x2c 1!', > 'fblock 1!spec 1 c2x 1!fblock 32!term' returns: 0123456789ABCDEF instead of 000102030405060708090A0B0C0D0E0F To cure this I had to code: > ... fblock 1!spec pad 0 1 c2x 1.2 r!fblock 32!term vii) Xlate ignores a transliteration table on secondary input stream. Since Xrange 00-ff fails I had to put it this way: > address '' ripe '"(MkR_5 sep ! end ?) literal', > '000102030405060708090A0B0C0D0E0F', > '101112131415161718191A1B1C1D1E1F', > '202122232425262728292A2B2C2D2E2F', > '303132333435363738393A3B3C3D3E3F', > '404142434445464748494A4B4C4D4E4F', > '505152535455565758595A5B5C5D5E5F', > '606162636465666768696A6B6C6D6E6F', > '707172737475767778797A7B7C7D7E7F', > '808182838485868788898A8B8C8D8E8F', > '909192939495969798999A9B9C9D9E9F', > 'A0A1A2A3A4A5A6A7A8A9AAABACADAEAF', > 'B0B1B2B3B4B5B6B7B8B9BABBBCBDBEBF', > 'C0C1C2C3C4C5C6C7C8C9CACBCCCDCECF', > 'D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF', > 'E0E1E2E3E4E5E6E7E8E9EAEBECEDEEEF', > 'F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF!space 0!spec *-* x2c 1!', > 'a: xlate *-*!fblock 1!spec pad 0 1 c2x 1.2 r!fblock 32!term', > '? literal FF!dup 255!join *!spec *-* x2c 1!a:' Result: > 000102030405060708090A0B0C0D0E0F > 101112131415161718191A1B1C1D1E1F > 202122232425262728292A2B2C2D2E2F > 303132333435363738393A3B3C3D3E3F > 404142434445464748494A4B4C4D4E4F > 505152535455565758595A5B5C5D5E5F > 604142434445464748494A4B4C4D4E4F > 505152535455565758595A7B7C7D7E7F > 808182838485868788898A8B8C8D8E8F > 909192939495969798999A9B9C9D9E9F > A0A1A2A3A4A5A6A7A8A9AAABACADAEAF > B0B1B2B3B49CB6B7B8B9BABBBCBDBEBF > C0C1C2C3C4C5C6C7C8C9CACBCCCDCECF > D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF > C0C1C2C3C4C5C6C7C8C9CACBCCCDCECF > D0D1D2D3D4D5D6F7D8D9DADBDCDDDE78 Expected result would be 16 rows of 32 'F'. viii) Address documentation error This is related to ooRexx, but maybe someone here is also interested: > address '' ripe '"(MkR_6 sep !) cons!', > 'spec recno from 61440 d2x 1.4 r pad 0 w1 d2x nw.3 r!cons', > with input stem rom. output REPLACE USING (f) > Error 98.997: REPLACE or APPEND cannot be specified with a Stream object USING target. This can not be educed from the RRT diagram. BTW, I used keyword USING since STREAM (what IMO would be more 'natural' when using a stream object) failed with: > Error 98.920: Unable to open file "D:\...\C PPC 1981.hpmclist.txt" for writing; open result was "ERROR:13". No explanation found for "ERROR:13". ix) default REPLACE does in fact APPEND > address '' ripe '"(MkR_6 sep !) cons!', > 'spec recno from 61440 d2x 1.4 r pad 0 w1 d2x nw.3 r!cons', > with input stem rom. output USING (f) Result: output appended to previously written file. Expected result: overwrite previously written file. Best, M. |
|
From: <hp...@we...> - 2022-06-27 23:49:00
|
Jeff! Am 27.06.2022 um 18:47 schrieb Jeff Hennick: > First let me make clear that I am not an XLATE "expert." Nor am I! My degree is /MD/, "master of disaster" ;) Honestly, I try to use NetRexx Pipelines as described in 'Pipelines Guide and Reference', ISBN 978-90-819090-3-7, where I read in chapter 8: > For a complete description we refer to the IBM Pipelines documentation. Which one exactly? Ok, in that case my choice is the author's edition from 1846, ah... sorry, no, July 2010. Normally, "papers" older than 6 years are ignored, alas, it's the youngest I have. But! typically IBM does not change suitable systems too fast. This is why, also together with the explicit promise of NetRexx Pipelines "Implements CMS Pipelines" (w/o restrictions, no footnotes, no "see working examples" addition), I assume it as highly likely that the Xlate stage probably still might work as described once upon a time by John. No, I'm for sure not an expert, I try my first steps with NetRexx Pipelines (called from ooRexx), so somehow I am a student who has no time and no reason yet to distrust the description. > I did not write the > XLATE stage for NetRexx, René did a long time ago, it has a copyright date of > 1998. I did add the input range handling, back then too. I am not interested who done it, I rather prefer Pipes that WAD (work as designed). > I know little of what the XLATE stage is supposed to do or how it does it. Is this a test if I dare to give the fitting reply? > I > have used it for case conversion, and wrote 8 simple verification tests ( > xlate_tests01.njp ). Nice. But why didn't you test _all_ features which are described in the manual? > As for the published NetRexx documentation for it, I am responsible, bearing in > mind the above. You ask for pity? -- Hmm..., it was for sure not my intention to push you into such a situation. Maybe I took this "Implements CMS Pipelines" too serious, maybe same time you desired to keep your promise. Maybe both intentions are too demanding. Maybe I should only report errors without much ado. > Mostly I copied it from the IBM publication. You copied also the error in the RRT diagram regarding how to define more than one input range. > I stand ready to > improve it in any way I can. Here is a special Thank You on this point. I just > looked at the xlate.nrx source code and see some different and additional > documentation there. I will work at consolidating all these for the next release. > > Also welcomed would be any additional verification tests. I will report all findings from doing, but no extra beta-testing. > Especially any showing > erroneous results from the current version. For these, I would need three > pieces of information: > > 1. the test XLATE stage > 2. test input data; in the case of this stage, only a single line would be > needed but multiples to show different points can be used > 3. the expected output (for each input line); and if currently a failure, I'd > like that output too All requested information is included in https://github.com/RexxLA/NetRexx/issues/30 but it should be split, there are two issues for different stages. BTW, the reported error has nothing to do with codepages. > More comments interspersed below. > [...] > Great. There is also a possible hint in IBM's Note "4. Use a cascade of xlate > stages to perform stepwise translation." and that you might be able to generate > your external table that way. But it is beyond me. That note #4 is for the really challenging cases. >> ii) [...] >> Marked as not yet in Pipes for NetRexx are 'OUTput' and 'TO/FROM >> CODEPAGE n', but not 'INput'. For CMS input and output options of >> the XLATE stage are related to the input and output settings. >> Question: what is under Windows the corresponding parallel of CMS >> input setting? > > Sorry, I have no idea of what INput and OUTput are supposed to do or what they > might be related to in any system. I can find no further reference to them in > either IBM documentation. But according your documentation, INput is part of NetRexx Pipelnes' Xlate stage while OUTput isn't. > (I find the XLATE IBM documentation to be harder to understand than most. > For example, I have no idea of the use of all those Codepages, or why one > would use them here other than that one can go FROM one TO another. But why, Why does CMS/TSO Pipelines offer a selected subset of codepages? > and how one goes from a language with umlauts to one with tildes is a > mystery to me. Is there an example that does so? Or is this your guesswork someone could do this? > Is there a good reason that "500 EBCDIC Belgium, Canada, > Switzerland, International Latin-1. International number 5. This is the base > codepage for xlate." rather than say, "285 EBCDIC United Kingdom." or "37 > EBCDIC United States, Canada, Netherlands, Portugal, Brazil, Australia, New > Zealand." and how should I decide between that and "274 EBCDIC Belgium." if > I am really interested in Belgium? Your are interested in Belgium? No, if you exchange files with a VM system located in Belgium (and which is running on CP 274) you are interested to see as much as possible on your PC screen as would be visible on the mainframe terminal "chez les belges". And vv too. > Also, mentioned only in passing in a footnote is "E2A". [The xlate.nrx > internal documentation says E2A (EBCDIC to ASCII) and A2E (ASCII to EBCDIC) > are options instead of UPper and LOWer in NetRexx Pipelines. ] ) Please keep in mind: > A language needs to be adaptable because it certainly will be used for > applications not foreseen by the designer. (M. COWLISHAW) Thus, even if you "have no idea of the use of all those Codepages", they may be useful for somebody else. Best, M. |
