# REXX for MVS 3.8J?

 Classic List Threaded
44 messages
123
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## REXX for MVS 3.8J?

 I'm sure this has come up before, but is there a REXX implementation for MVS 3.8J?  I really prefer REXX to CLIST. From my searching around it looks like BREXX may be available, but only under VM/370. I have a lot of time on my hands and a thought I've had is that it may be interesting to try and write an assembler implementation of REXX for use on MVS 3.8J TSO and batch. I know the BREXX code is open source and I know C very well and I know mainframe assembler very well.  I may not really have the skill set to do it, but it might be interesting to try, but I don't want to waste my time if there already is a REXX implementation for these environments that I'm not aware of.
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 --- In [hidden email], "John" wrote: > > I'm sure this has come up before, but is there a REXX implementation for MVS 3.8J? To the best of my knowledge, the answer is no. > I know the BREXX code is open source and I know C very well and I know mainframe assembler very well.  I may not really have the skill set to do it, but it might be interesting to try, but I don't want to waste my time if there already is a REXX implementation for these environments that I'm not aware of. It would be great but I think it's a big project. If you are ready to go, then I wish you the best of luck :-) Yours truly, Rene FERLAND, Montreal
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 In reply to this post by John-796 --- In [hidden email], "John" wrote: > > I'm sure this has come up before, but is there a REXX implementation for MVS 3.8J?  I really prefer REXX to CLIST. > > From my searching around it looks like BREXX may be available, but only under VM/370. > > I have a lot of time on my hands and a thought I've had is that it may be interesting to try and write an assembler implementation of REXX for use on MVS 3.8J TSO and batch. > > I know the BREXX code is open source and I know C very well and I know mainframe assembler very well.  I may not really have the skill set to do it, but it might be interesting to try, but I don't want to waste my time if there already is a REXX implementation for these environments that I'm not aware of. > BREXX (v2.1.8 MVS 1.0 May 24 2010) is implemented as a part of the MVS380 Project, a 31-bit variant of 24-bit MVS/370: Overlay to tk3upd: http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_overlay.zip-or- Full Installation: http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_rtr.zipYahoo Discussion Group: http://tech.groups.yahoo.com/group/hercules-os380If interested, please join us.  I believe there is still much work to do to enhance BREXX's current features, but at least it has been ported to MVS! ScottC P.S. BREXX was installed into MVS/380 from the "SEASIK" compilation from the GCCMVS Project: http://sourceforge.net/projects/gccmvs/files
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Re: REXX for MVS 3.8J?

 In reply to this post by René Ferland On 08/31/2012 04:14 PM, Rene Ferland wrote: > > --- In [hidden email], "John" wrote: >> I'm sure this has come up before, but is there a REXX implementation for MVS 3.8J? > To the best of my knowledge, the answer is no. > >> I know the BREXX code is open source and I know C very well and I know mainframe assembler very well.  I may not really have the skill set to do it, but it might be interesting to try, but I don't want to waste my time if there already is a REXX implementation for these environments that I'm not aware of. > It would be great but I think it's a big project. If you are ready to go, then I wish you the best of luck :-) > > Yours truly, > > Rene FERLAND, Montreal > > I too have thought about this but no time.  Had an idea though which may help.  If on the MVS 380 one had the GCC compiler running, will it output the translated C to assembler?  If so, one could take the assembler output, clean it up, and assemble that on MVS 3.8. Just a thought...  Haven't worked much with C on IBM mainframes. Scott
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 --- In [hidden email], scott wrote: > I too have thought about this but no time.  Had an idea though which may > help.  If on the MVS 380 one had the GCC compiler running, will it > output the translated C to assembler? Yes > If so, one could take the assembler output, clean it up, > and assemble that on MVS 3.8. > > Just a thought...  Haven't worked much with C on IBM mainframes. > > Scott > ScottC
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Re: REXX for MVS 3.8J?

 In reply to this post by scott-21 On 8/31/2012 4:27 PM, scott wrote: > I too have thought about this but no time.  Had an idea though which may > help.  If on the MVS 380 one had the GCC compiler running, will it > output the translated C to assembler?  If so, one could take the > assembler output, clean it up, and assemble that on MVS 3.8. The compiler produces an S2 file containing only assembler code, and no comments (I don't remember whether it copies the original c code as comments). The code is the worst I've ever seen, and for BREXX might take longer to clean up than to write from scratch. Also it's missing any and all IBM specific features (no ADDRESS TSO, no EXECIO, etc.). I had a similar idea to modify the GWBASIC code to add screen addressing and I/O (similar to the original BASIC on PC/DOS), but didn't have enough time to follow through. Gerhard Postpischil Bradford, VT
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 In reply to this post by sccosel-2 My intent would be to rewrite BREXX in mainframe assembler and have it be executable on MVS 3.8J under MVS/370.  I'm hoping I could make the footprint small enough by removing use of the C runtime library. I can see issues related to the ANSI I/O model, but I have some thoughts about how to address those, unfortunately they would be heavily performance degrading - creating copies of files that are opened. --- In [hidden email], "ScottC" wrote: > > --- In [hidden email], "John" wrote: > > > > I'm sure this has come up before, but is there a REXX implementation for MVS 3.8J?  I really prefer REXX to CLIST. > > > > From my searching around it looks like BREXX may be available, but only under VM/370. > > > > I have a lot of time on my hands and a thought I've had is that it may be interesting to try and write an assembler implementation of REXX for use on MVS 3.8J TSO and batch. > > > > I know the BREXX code is open source and I know C very well and I know mainframe assembler very well.  I may not really have the skill set to do it, but it might be interesting to try, but I don't want to waste my time if there already is a REXX implementation for these environments that I'm not aware of. > > > BREXX (v2.1.8 MVS 1.0 May 24 2010) is implemented as a part of the MVS380 Project, a 31-bit variant of 24-bit MVS/370: > > Overlay to tk3upd: > http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_overlay.zip> > -or- Full Installation: > http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_rtr.zip> > Yahoo Discussion Group: > http://tech.groups.yahoo.com/group/hercules-os380> > If interested, please join us.  I believe there is still much work to do to enhance BREXX's current features, but at least it has been ported to MVS! > > ScottC > > P.S. BREXX was installed into MVS/380 from the "SEASIK" compilation from the GCCMVS Project: > http://sourceforge.net/projects/gccmvs/files>
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## RE: Re: REXX for MVS 3.8J?

 > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of John > Sent: 01 September 2012 17:51 > To: [hidden email] > Subject: [H390-MVS] Re: REXX for MVS 3.8J? > > > My intent would be to rewrite BREXX in mainframe assembler > and have it be executable on MVS 3.8J under MVS/370.  I'm > hoping I could make the footprint small enough by removing > use of the C runtime library. > It should run just fine as it is. Looking at the file sizes and load map the C runtime is about 150K loaded. BREXX itself is much bigger about 500K. It also grabs lots of store to parse files. When I tried it on CMS it needed a 2 Meg VM to parse simple files, which is actually more than I expected, but I wouldn't have thought that was much of an issue on MVS. You only need MVS/380 to re-build the GCC compiler > I can see issues related to the ANSI I/O model, but I have > some thoughts about how to address those, unfortunately they > would be heavily performance degrading - creating copies of 1 > files that are opened. > > --- In [hidden email], "ScottC" wrote: > > > > --- In [hidden email], "John" wrote: > > > > > > I'm sure this has come up before, but is there a REXX > implementation > > > for MVS 3.8J?  I really prefer REXX to CLIST. > > > > > > From my searching around it looks like BREXX may be > available, but > > > only under VM/370. > > > > > > I have a lot of time on my hands and a thought I've had > is that it > > > may be interesting to try and write an assembler > implementation of > > > REXX for use on MVS 3.8J TSO and batch. > > > > > > I know the BREXX code is open source and I know C very well and I > > > know mainframe assembler very well.  I may not really > have the skill > > > set to do it, but it might be interesting to try, but I > don't want > > > to waste my time if there already is a REXX > implementation for these > > > environments that I'm not aware of. > > > > > BREXX (v2.1.8 MVS 1.0 May 24 2010) is implemented as a part of the > > MVS380 Project, a 31-bit variant of 24-bit MVS/370: > > > > Overlay to tk3upd: > > > http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_overlay.zi> > p > > > > -or- Full Installation: > > http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_rtr.zip> > > > Yahoo Discussion Group: > > http://tech.groups.yahoo.com/group/hercules-os380> > > > If interested, please join us.  I believe there is still > much work to > > do to enhance BREXX's current features, but at least it has been > > ported to MVS! > > > > ScottC > > > > P.S. BREXX was installed into MVS/380 from the "SEASIK" compilation > > from the GCCMVS Project: > http://sourceforge.net/projects/gccmvs/files> > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > >
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 In reply to this post by John-796 > John wrote: > I'm sure this has come up before, but is there a REXX implementation > for MVS 3.8J?  I really prefer REXX to CLIST.   > From my searching around it looks like BREXX may be available, but > only under VM/370.   > I have a lot of time on my hands and a thought I've had is that it > may be interesting to try and write an assembler implementation of > REXX for use on MVS 3.8J TSO and batch.   > I know the BREXX code is open source and I know C very well and I > know mainframe assembler very well.  I may not really have the skill > set to do it, but it might be interesting to try, but I don't want > to waste my time if there already is a REXX implementation for these > environments that I'm not aware of. >> Gerhard wrote: >> The compiler produces an S2 file containing only assembler code, >> and no comments (I don't remember whether it copies the original >> c code as comments). If you are running a Windows host you can download about 3 items and see what BREXX for MVS looks like.  You could also upload to 3.8j and link but instructions are beyond the scope of this post. Grab : http://sourceforge.net/projects/gccmvs/files/GCCMVS/GCC%203.4.6%20MVS%201.0/gccmvs-3_4_6-1_0-win32.zip/downloadhttp://sourceforge.net/projects/pdos/files/pdpclib/pdpclib%203.10/pdpc310.zip/downloadhttp://sourceforge.net/projects/brexx/files/2.1.8/brexx-2.1.8.tar.gz/downloadUnzip & untar the respective files.  You may need to change permissions on the GCCMVS.exe as on my system it was restored non-executable. In brexx-2.1.8\mvs\stdcomp.bat file, modify the gccmvs line to indicate the path to GCCMVS and path to PDPCLIB. Add '-g -dA' to have the output assembly source, xxx.s files, include the C source line numbers for the respective sections of code.  A separate utility to insert the actual C code into the assembler may exist but I don't know of it. My gccmvs line looks something like: c:\testgcc\gccmvs -g -dA -Os -S -DHAVE_CONFIG_H -I c:\testpdp -I . -I ../inc %1 %2 %3 %4 %5 %6 %7 %8 %9 Phil
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 > halfmeg wrote: Ooops!  Left off the finish and example. > Grab : > http://sourceforge.net/projects/gccmvs/files/GCCMVS/GCC%203.4.6%20MVS%201.0/gccmvs-3_4_6-1_0-win32.zip/download> http://sourceforge.net/projects/pdos/files/pdpclib/pdpclib%203.10/pdpc310.zip/download> http://sourceforge.net/projects/brexx/files/2.1.8/brexx-2.1.8.tar.gz/download  > Unzip & untar the respective files.  You may need to change > permissions on the GCCMVS.exe as on my system it was restored > non-executable.   > In brexx-2.1.8\mvs\stdcomp.bat file, modify the gccmvs line to > indicate the path to GCCMVS and path to PDPCLIB.   > Add '-g -dA' to have the output assembly source, xxx.s files, > include the C source line numbers for the respective sections of > code.  A separate utility to insert the actual C code into the > assembler may exist but I don't know of it.   > My gccmvs line looks something like:   > c:\testgcc\gccmvs -g -dA -Os -S -DHAVE_CONFIG_H -I c:\testpdp -I . -I ../inc %1 %2 %3 %4 %5 %6 %7 %8 %9   > Phil After the change to stdcomp.bat is completed, 'compile' needs to be run in a DOS window from the brexx-2.1.8\mvs directory. Example of BREXX C source from builtin.c 189:            case f_trace: 190-                    i = 0; 191-                    if (_proc[_rx_proc].interactive_trace) 192-                            LSTR(*ARGR)[i++] = '?'; 193-                    switch (_proc[_rx_proc].trace) { 194-                            case all_trace:         LSTR(*ARGR)[i++] = 'A'; break; 195-                            case commands_trace:    LSTR(*ARGR)[i++] = 'C'; break; 196-                            case error_trace:       LSTR(*ARGR)[i++] = 'E'; break; 197-                            case intermediates_trace:LSTR(*ARGR)[i++]= 'I'; break; 198-                            case labels_trace:      LSTR(*ARGR)[i++] = 'L'; break; 199-                            case normal_trace:      LSTR(*ARGR)[i++] = 'N'; break; 200:                            case off_trace:         LSTR(*ARGR)[i++] = 'O'; break; 201-                            case results_trace:     LSTR(*ARGR)[i++] = 'R'; break; 202-                            case scan_trace:        LSTR(*ARGR)[i++] = 'S'; break; 203-                    } 204-                    LTYPE(*ARGR) = LSTRING_TY; 205-                    LLEN(*ARGR)  = i; 206-                    if (exist(1)) TraceSet(ARG1); 207-                    break; is compiled to generate 370 Assembler output with C source line numbers as commented lines: * 190 ../src/builtin.c          SLR   15,15 * 191 ../src/builtin.c          L     6,=V(@RX@PROC)          L     2,0(6)          L     5,=V(@PROC)          L     3,0(5)          MH    2,=H'148'          L     2,144(2,3)          LTR   2,2          BE    L33 * 192 ../src/builtin.c          L     2,4(4)          L     2,0(2)          MVI   0(2),111          LA    15,1(0,0) L33      EQU   * * 193 ../src/builtin.c          L     2,0(6)          L     3,0(5)          MH    2,=H'148'          L     2,140(2,3)          LA    3,16(0,0)          CR    2,3          BE    L39          BH    L44          LA    3,2(0,0)          CR    2,3          BE    L36          BH    L45          LA    3,1(0,0)          CLR   2,3          BE    L35          B     L34 L45      EQU   *          LA    3,4(0,0)          CLR   2,3          BE    L37          LA    3,8(0,0)          CLR   2,3          BE    L38          B     L34 L44      EQU   *          LA    3,64(0,0)          CR    2,3          BE    L41          BH    L46          LA    3,32(0,0)          CLR   2,3          BE    L40          B     L34 L46      EQU   *          LA    3,128(0,0)          CLR   2,3          BE    L42          LA    3,256(0,0)          CLR   2,3          BE    L43          B     L34 L35      EQU   * * 194 ../src/builtin.c          L     2,=V(RXARG)          L     2,4(2)          L     2,0(2)          AR    2,15          MVI   0(2),193          B     L51 L36      EQU   * * 195 ../src/builtin.c          L     2,=V(RXARG)          L     2,4(2)          L     2,0(2)          AR    2,15          MVI   0(2),195          B     L51 L37      EQU   * * 196 ../src/builtin.c          L     2,=V(RXARG)          L     2,4(2)          L     2,0(2)          AR    2,15          MVI   0(2),197          B     L51 L38      EQU   * * 197 ../src/builtin.c          L     2,=V(RXARG)          L     2,4(2)          L     2,0(2)          AR    2,15          MVI   0(2),201          B     L51 L39      EQU   * * 198 ../src/builtin.c          L     2,=V(RXARG)          L     2,4(2)          L     2,0(2)          AR    2,15          MVI   0(2),211          B     L51 L40      EQU   * * 199 ../src/builtin.c          L     2,=V(RXARG)          L     2,4(2)          L     2,0(2)          AR    2,15          MVI   0(2),213          B     L51 L41      EQU   * * 200 ../src/builtin.c          L     2,=V(RXARG)          L     2,4(2)          L     2,0(2)          AR    2,15          MVI   0(2),214          B     L51 L42      EQU   * * 201 ../src/builtin.c          L     2,=V(RXARG)          L     2,4(2)          L     2,0(2)          AR    2,15          MVI   0(2),217          B     L51 L43      EQU   * * 202 ../src/builtin.c          L     2,=V(RXARG)          L     2,4(2)          L     2,0(2)          AR    2,15          MVI   0(2),226 L51      EQU   *          A     15,=F'1' L34      EQU   * * 204 ../src/builtin.c          L     3,=V(RXARG)          L     2,4(3)          MVC   12(2,2),=H'0' * 205 ../src/builtin.c          ST    15,4(2) * 206 ../src/builtin.c          L     2,8(3)          LTR   2,2          BE    L25          ST    2,88(13)          LA    1,88(,13)          L     15,=V(TRACESET)          BALR  14,15 * 207 ../src/builtin.c          B     L25 L48      EQU   * The xxx.s files in the mvs directory can be moved to the mainframe and assembled then linked to see how BREXX actually works on 'real iron' I believe.  I haven't actually done that part as the last tinkering I did with BREXX was the version generated by JCC. The xxx.jcl files give some indication on what needs to be done but they are set up for the compiler to be on the mainframe which isn't the case for this quick look at the generated code without having to install mucho overhead just to see some source. Phil
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 In reply to this post by scott-21 --- In [hidden email], scott wrote: > > On 08/31/2012 04:14 PM, Rene Ferland wrote: > > > > --- In [hidden email], "John" wrote: > >> I'm sure this has come up before, but is there a REXX implementation for MVS 3.8J? > > To the best of my knowledge, the answer is no. > > > >> I know the BREXX code is open source and I know C very well and I know mainframe assembler very well.  I may not really have the skill set to do it, but it might be interesting to try, but I don't want to waste my time if there already is a REXX implementation for these environments that I'm not aware of. > > It would be great but I think it's a big project. If you are ready to go, then I wish you the best of luck :-) > > > > > I too have thought about this but no time.  Had an idea though which may > help.  If on the MVS 380 one had the GCC compiler running, will it > output the translated C to assembler?  If so, one could take the > assembler output, clean it up, and assemble that on MVS 3.8. > > Just a thought...  Haven't worked much with C on IBM mainframes. I step away for 5 minutes ... You're vastly overthinking the difference between MVS/380 and MVS 3.8j. For the purposes of this discussion, MVS/380 *IS* MVS 3.8j. As such, BREXX was compiled and linked on MVS 3.8j, and the resultant executable was bundled in a "convenient" (the word Gerhard used was sadistic) package called "SEASIK" (also a term coined by Gerhard - so blame him if there is anything at all you don't like about SEASIK or GCC or C in general). The resultant 24-bit executable you can find on the "tape" will run perfectly fine on MVS 3.8j and above. Hell, it'll probably even run on MVT too, but I'm not aware of anyone who has tried it. People discussing converting a perfectly working 24-bit BREXX executable from C to assembler, to theoretically make some sort of microscopic (Gerhard is overstating the quality of the code - it's perfectly fine) speed improvement (that no-one, absolutely no-one cares about, especially given that the number of BREXX on MVS users probably aren't enough for a game of tennis), have way way way too much time on their hands, and should either be given a box of matches to play with, or pointed in the direction of the MVS 3.8j source code, with a view to producing a version of MVS that we actually have source code to. Or if you know C, there's a lot more things that can be done, depending on what you're hoping to achieve. This is actually why I never went past C. I'm used to not being able to wean people off assembler, so until everyone's on board with using a higher level language than assembler, I'm not going to make matters any "worse" than C. BFN.  Paul.
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 In reply to this post by Dave Wade-2 Didn't know that.  I'd like to remove the dependence on C if I can.   As to storage requirements I assume I would essentially have to implement paging for the BREXX data storage if I wanted it to support large amounts of data.  Meaning writing the data off into a dataset and retrieving it as needed.  This obviously could have a huge performance impact. --- In [hidden email], "Dave" wrote: > > > > -----Original Message----- > > From: [hidden email] > > [mailto:[hidden email]] On Behalf Of John > > Sent: 01 September 2012 17:51 > > To: [hidden email] > > Subject: [H390-MVS] Re: REXX for MVS 3.8J? > > > > > > My intent would be to rewrite BREXX in mainframe assembler > > and have it be executable on MVS 3.8J under MVS/370.  I'm > > hoping I could make the footprint small enough by removing > > use of the C runtime library. > > > > It should run just fine as it is. Looking at the file sizes and load map the > C runtime is about 150K loaded. BREXX itself is much bigger about 500K. It > also grabs lots of store to parse files. When I tried it on CMS it needed a > 2 Meg VM to parse simple files, which is actually more than I expected, but > I wouldn't have thought that was much of an issue on MVS. You only need > MVS/380 to re-build the GCC compiler > > > I can see issues related to the ANSI I/O model, but I have > > some thoughts about how to address those, unfortunately they > > would be heavily performance degrading - creating copies of 1 > > files that are opened. > > > > --- In [hidden email], "ScottC" wrote: > > > > > > --- In [hidden email], "John" wrote: > > > > > > > > I'm sure this has come up before, but is there a REXX > > implementation > > > > for MVS 3.8J?  I really prefer REXX to CLIST. > > > > > > > > From my searching around it looks like BREXX may be > > available, but > > > > only under VM/370. > > > > > > > > I have a lot of time on my hands and a thought I've had > > is that it > > > > may be interesting to try and write an assembler > > implementation of > > > > REXX for use on MVS 3.8J TSO and batch. > > > > > > > > I know the BREXX code is open source and I know C very well and I > > > > know mainframe assembler very well.  I may not really > > have the skill > > > > set to do it, but it might be interesting to try, but I > > don't want > > > > to waste my time if there already is a REXX > > implementation for these > > > > environments that I'm not aware of. > > > > > > > BREXX (v2.1.8 MVS 1.0 May 24 2010) is implemented as a part of the > > > MVS380 Project, a 31-bit variant of 24-bit MVS/370: > > > > > > Overlay to tk3upd: > > > > > http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_overlay.zi> > > p > > > > > > -or- Full Installation: > > > http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_rtr.zip> > > > > > Yahoo Discussion Group: > > > http://tech.groups.yahoo.com/group/hercules-os380> > > > > > If interested, please join us.  I believe there is still > > much work to > > > do to enhance BREXX's current features, but at least it has been > > > ported to MVS! > > > > > > ScottC > > > > > > P.S. BREXX was installed into MVS/380 from the "SEASIK" compilation > > > from the GCCMVS Project: > > http://sourceforge.net/projects/gccmvs/files> > > > > > > > > > > > > ------------------------------------ > > > > Yahoo! Groups Links > > > > > > > > >
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 In reply to this post by halfmeg I'll take a look at the code, that's for the info. --- In [hidden email], "halfmeg" wrote: > > > halfmeg wrote: > > Ooops!  Left off the finish and example. > > > Grab : > > http://sourceforge.net/projects/gccmvs/files/GCCMVS/GCC%203.4.6%20MVS%201.0/gccmvs-3_4_6-1_0-win32.zip/download> > > http://sourceforge.net/projects/pdos/files/pdpclib/pdpclib%203.10/pdpc310.zip/download> > > http://sourceforge.net/projects/brexx/files/2.1.8/brexx-2.1.8.tar.gz/download>   > > Unzip & untar the respective files.  You may need to change > > permissions on the GCCMVS.exe as on my system it was restored > > non-executable. >   > > In brexx-2.1.8\mvs\stdcomp.bat file, modify the gccmvs line to > > indicate the path to GCCMVS and path to PDPCLIB. >   > > Add '-g -dA' to have the output assembly source, xxx.s files, > > include the C source line numbers for the respective sections of > > code.  A separate utility to insert the actual C code into the > > assembler may exist but I don't know of it. >   > > My gccmvs line looks something like: >   > > c:\testgcc\gccmvs -g -dA -Os -S -DHAVE_CONFIG_H -I c:\testpdp -I . -I ../inc %1 %2 %3 %4 %5 %6 %7 %8 %9 >   > > Phil > > After the change to stdcomp.bat is completed, 'compile' needs to be run in a DOS window from the brexx-2.1.8\mvs directory. > > Example of BREXX C source from builtin.c > > 189:            case f_trace: > 190-                    i = 0; > 191-                    if (_proc[_rx_proc].interactive_trace) > 192-                            LSTR(*ARGR)[i++] = '?'; > 193-                    switch (_proc[_rx_proc].trace) { > 194-                            case all_trace:         LSTR(*ARGR)[i++] = 'A'; break; > 195-                            case commands_trace:    LSTR(*ARGR)[i++] = 'C'; break; > 196-                            case error_trace:       LSTR(*ARGR)[i++] = 'E'; break; > 197-                            case intermediates_trace:LSTR(*ARGR)[i++]= 'I'; break; > 198-                            case labels_trace:      LSTR(*ARGR)[i++] = 'L'; break; > 199-                            case normal_trace:      LSTR(*ARGR)[i++] = 'N'; break; > 200:                            case off_trace:         LSTR(*ARGR)[i++] = 'O'; break; > 201-                            case results_trace:     LSTR(*ARGR)[i++] = 'R'; break; > 202-                            case scan_trace:        LSTR(*ARGR)[i++] = 'S'; break; > 203-                    } > 204-                    LTYPE(*ARGR) = LSTRING_TY; > 205-                    LLEN(*ARGR)  = i; > 206-                    if (exist(1)) TraceSet(ARG1); > 207-                    break; > > is compiled to generate 370 Assembler output with C source line numbers as commented lines: > > * 190 ../src/builtin.c >          SLR   15,15 > * 191 ../src/builtin.c >          L     6,=V(@RX@PROC) >          L     2,0(6) >          L     5,=V(@PROC) >          L     3,0(5) >          MH    2,=H'148' >          L     2,144(2,3) >          LTR   2,2 >          BE    L33 > * 192 ../src/builtin.c >          L     2,4(4) >          L     2,0(2) >          MVI   0(2),111 >          LA    15,1(0,0) > L33      EQU   * > * 193 ../src/builtin.c >          L     2,0(6) >          L     3,0(5) >          MH    2,=H'148' >          L     2,140(2,3) >          LA    3,16(0,0) >          CR    2,3 >          BE    L39 >          BH    L44 >          LA    3,2(0,0) >          CR    2,3 >          BE    L36 >          BH    L45 >          LA    3,1(0,0) >          CLR   2,3 >          BE    L35 >          B     L34 > L45      EQU   * >          LA    3,4(0,0) >          CLR   2,3 >          BE    L37 >          LA    3,8(0,0) >          CLR   2,3 >          BE    L38 >          B     L34 > L44      EQU   * >          LA    3,64(0,0) >          CR    2,3 >          BE    L41 >          BH    L46 >          LA    3,32(0,0) >          CLR   2,3 >          BE    L40 >          B     L34 > L46      EQU   * >          LA    3,128(0,0) >          CLR   2,3 >          BE    L42 >          LA    3,256(0,0) >          CLR   2,3 >          BE    L43 >          B     L34 > L35      EQU   * > * 194 ../src/builtin.c >          L     2,=V(RXARG) >          L     2,4(2) >          L     2,0(2) >          AR    2,15 >          MVI   0(2),193 >          B     L51 > L36      EQU   * > * 195 ../src/builtin.c >          L     2,=V(RXARG) >          L     2,4(2) >          L     2,0(2) >          AR    2,15 >          MVI   0(2),195 >          B     L51 > L37      EQU   * > * 196 ../src/builtin.c >          L     2,=V(RXARG) >          L     2,4(2) >          L     2,0(2) >          AR    2,15 >          MVI   0(2),197 >          B     L51 > L38      EQU   * > * 197 ../src/builtin.c >          L     2,=V(RXARG) >          L     2,4(2) >          L     2,0(2) >          AR    2,15 >          MVI   0(2),201 >          B     L51 > L39      EQU   * > * 198 ../src/builtin.c >          L     2,=V(RXARG) >          L     2,4(2) >          L     2,0(2) >          AR    2,15 >          MVI   0(2),211 >          B     L51 > L40      EQU   * > * 199 ../src/builtin.c >          L     2,=V(RXARG) >          L     2,4(2) >          L     2,0(2) >          AR    2,15 >          MVI   0(2),213 >          B     L51 > L41      EQU   * > * 200 ../src/builtin.c >          L     2,=V(RXARG) >          L     2,4(2) >          L     2,0(2) >          AR    2,15 >          MVI   0(2),214 >          B     L51 > L42      EQU   * > * 201 ../src/builtin.c >          L     2,=V(RXARG) >          L     2,4(2) >          L     2,0(2) >          AR    2,15 >          MVI   0(2),217 >          B     L51 > L43      EQU   * > * 202 ../src/builtin.c >          L     2,=V(RXARG) >          L     2,4(2) >          L     2,0(2) >          AR    2,15 >          MVI   0(2),226 > L51      EQU   * >          A     15,=F'1' > L34      EQU   * > * 204 ../src/builtin.c >          L     3,=V(RXARG) >          L     2,4(3) >          MVC   12(2,2),=H'0' > * 205 ../src/builtin.c >          ST    15,4(2) > * 206 ../src/builtin.c >          L     2,8(3) >          LTR   2,2 >          BE    L25 >          ST    2,88(13) >          LA    1,88(,13) >          L     15,=V(TRACESET) >          BALR  14,15 > * 207 ../src/builtin.c >          B     L25 > L48      EQU   * > > The xxx.s files in the mvs directory can be moved to the mainframe and assembled then linked to see how BREXX actually works on 'real iron' I believe.  I haven't actually done that part as the last tinkering I did with BREXX was the version generated by JCC. > > The xxx.jcl files give some indication on what needs to be done but they are set up for the compiler to be on the mainframe which isn't the case for this quick look at the generated code without having to install mucho overhead just to see some source. > > Phil >
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 In reply to this post by kerravon86 I actually do have a ton of time on my hands - I'm on disability leave under my employer and may end up on government disability.  So I am looking for a big project that interests me. When I saw MVS/380 I assumed the code would require the use of the one special storage area above-the-line and therefore there would dependence in the code for that. Also please don't assume what my attitudes are, for example that I never want to use C, it's actually my favorite high level programming language. --- In [hidden email], "kerravon86" wrote: > > --- In [hidden email], scott wrote: > > > > On 08/31/2012 04:14 PM, Rene Ferland wrote: > > > > > > --- In [hidden email], "John" wrote: > > >> I'm sure this has come up before, but is there a REXX implementation for MVS 3.8J? > > > To the best of my knowledge, the answer is no. > > > > > >> I know the BREXX code is open source and I know C very well and I know mainframe assembler very well.  I may not really have the skill set to do it, but it might be interesting to try, but I don't want to waste my time if there already is a REXX implementation for these environments that I'm not aware of. > > > It would be great but I think it's a big project. If you are ready to go, then I wish you the best of luck :-) > > > > > > > > I too have thought about this but no time.  Had an idea though which may > > help.  If on the MVS 380 one had the GCC compiler running, will it > > output the translated C to assembler?  If so, one could take the > > assembler output, clean it up, and assemble that on MVS 3.8. > > > > Just a thought...  Haven't worked much with C on IBM mainframes. > > I step away for 5 minutes ... > > You're vastly overthinking the difference between > MVS/380 and MVS 3.8j. For the purposes of this > discussion, MVS/380 *IS* MVS 3.8j. > > As such, BREXX was compiled and linked on MVS 3.8j, > and the resultant executable was bundled in a > "convenient" (the word Gerhard used was sadistic) > package called "SEASIK" (also a term coined by > Gerhard - so blame him if there is anything at all > you don't like about SEASIK or GCC or C in general). > > The resultant 24-bit executable you can find on the > "tape" will run perfectly fine on MVS 3.8j and > above. Hell, it'll probably even run on MVT too, > but I'm not aware of anyone who has tried it. > > People discussing converting a perfectly working > 24-bit BREXX executable from C to assembler, to > theoretically make some sort of microscopic > (Gerhard is overstating the quality of the code - > it's perfectly fine) speed improvement (that > no-one, absolutely no-one cares about, especially > given that the number of BREXX on MVS users > probably aren't enough for a game of tennis), have > way way way too much time on their hands, and should > either be given a box of matches to play with, or > pointed in the direction of the MVS 3.8j source > code, with a view to producing a version of MVS > that we actually have source code to. > > Or if you know C, there's a lot more things that > can be done, depending on what you're hoping to > achieve. > > This is actually why I never went past C. I'm > used to not being able to wean people off > assembler, so until everyone's on board with > using a higher level language than assembler, > I'm not going to make matters any "worse" than C. > > BFN.  Paul. >
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Re: REXX for MVS 3.8J?

 In reply to this post by John-796 On 03/09/2012 17:39, John wrote: > Didn't know that.  I'd like to remove the dependence on C if I can. Then why start with a "C" implementation that is a total bodge and is missing much of the bits you want REXX on a mainframe for. And before you all "flame" I spent a long time getting it to work with GCC on an EBCDIC system so I probably know nearly as much about its internals as any one else. I also wrote the floating point support in the the GCC "C" library which you can flame me for.... Now although I did a lot of work porting it to VM/370 and GCC after jason had started with his JCC compiler, I don't really feel BREXX delivers what I was looking for in a mainframe REXX. It does not have any of the original Mainframe quirks such as EXECIO so you can't use it to run many classical downloadable REXX programs.  On VM I would say 50% of the REXX execs are XEDIT specific and used to deliver full screen panel applications, again something you can't do with REXX on VM/380R6, the last free VM as it has no XEDIT and no full screen I/O. Worse still it does binary arithmetic which to me is a total abomination. To continue the rant, the "C" it produces is un-readable for a number of reasons. All local variables are allocated on the stack so are merley offsets to the stack pointer, so its a nightmare to figure out what something refers to. Secondly if the optimizer is on then the instruction order may not match the source code. Lastly the code makes extensive use of "C" macros which again dn't show in the asembler. Here are a few lines from "main.c":-           L     15,=V(LSCPY)           BALR  14,15 L5       EQU   *           L     3,156(13)           A     3,=F'1'           ST    3,156(13)           B     L8 L3       EQU   *           L     2,156(13)           MH    2,=H'4'           A     2,4(11)           L     2,0(2)           IC    2,0(2)           CLM   2,1,=XL1'6F'           BE    L10           L     2,156(13)           MH    2,=H'4'           A     2,4(11)           L     2,0(2)           IC    2,0(2) So if you want a mainframe REXX that s assembler maintained, please start with Assembler. Dave > As to storage requirements I assume I would essentially have to implement paging for the BREXX data storage if I wanted it to support large amounts of data.  Meaning writing the data off into a dataset and retrieving it as needed.  This obviously could have a huge performance impact. > > --- In [hidden email], "Dave" wrote: >> >>> -----Original Message----- >>> From: [hidden email] >>> [mailto:[hidden email]] On Behalf Of John >>> Sent: 01 September 2012 17:51 >>> To: [hidden email] >>> Subject: [H390-MVS] Re: REXX for MVS 3.8J? >>> >>> >>> My intent would be to rewrite BREXX in mainframe assembler >>> and have it be executable on MVS 3.8J under MVS/370.  I'm >>> hoping I could make the footprint small enough by removing >>> use of the C runtime library. >>> >> It should run just fine as it is. Looking at the file sizes and load map the >> C runtime is about 150K loaded. BREXX itself is much bigger about 500K. It >> also grabs lots of store to parse files. When I tried it on CMS it needed a >> 2 Meg VM to parse simple files, which is actually more than I expected, but >> I wouldn't have thought that was much of an issue on MVS. You only need >> MVS/380 to re-build the GCC compiler >> >>> I can see issues related to the ANSI I/O model, but I have >>> some thoughts about how to address those, unfortunately they >>> would be heavily performance degrading - creating copies of 1 >>> files that are opened. >>> >>> --- In [hidden email], "ScottC" wrote: >>>> --- In [hidden email], "John" wrote: >>>>> I'm sure this has come up before, but is there a REXX >>> implementation >>>>> for MVS 3.8J?  I really prefer REXX to CLIST. >>>>> >>>>>  From my searching around it looks like BREXX may be >>> available, but >>>>> only under VM/370. >>>>> >>>>> I have a lot of time on my hands and a thought I've had >>> is that it >>>>> may be interesting to try and write an assembler >>> implementation of >>>>> REXX for use on MVS 3.8J TSO and batch. >>>>> >>>>> I know the BREXX code is open source and I know C very well and I >>>>> know mainframe assembler very well.  I may not really >>> have the skill >>>>> set to do it, but it might be interesting to try, but I >>> don't want >>>>> to waste my time if there already is a REXX >>> implementation for these >>>>> environments that I'm not aware of. >>>>> >>>> BREXX (v2.1.8 MVS 1.0 May 24 2010) is implemented as a part of the >>>> MVS380 Project, a 31-bit variant of 24-bit MVS/370: >>>> >>>> Overlay to tk3upd: >>>> >>> http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_overlay.zi>>>> p >>>> >>>> -or- Full Installation: >>>> http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_rtr.zip>>>> >>>> Yahoo Discussion Group: >>>> http://tech.groups.yahoo.com/group/hercules-os380>>>> >>>> If interested, please join us.  I believe there is still >>> much work to >>>> do to enhance BREXX's current features, but at least it has been >>>> ported to MVS! >>>> >>>> ScottC >>>> >>>> P.S. BREXX was installed into MVS/380 from the "SEASIK" compilation >>>> from the GCCMVS Project: >>> http://sourceforge.net/projects/gccmvs/files>>> >>> >>> >>> ------------------------------------ >>> >>> Yahoo! Groups Links >>> >>> >>> >>> > > > > ------------------------------------ > > Yahoo! Groups Links > > > -- Dave Wade G4UGM Illegitimi Non Carborundum *** For the Hams on the list three special event stations in Manchester now operational ***** **** GB2012MV, GB2012MS and GB2012MW. See http://GB2012MS.COM/ for links and schedules. ***
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 My intention is to use the BREXX C code for the logic and write a mainframe assembler implementation from the logic.  I don't want to take compiler produced assembler code (I know technically it is assembly code) and "clean it up". I would try to first implement BREXX with its current features and then look at extending it to have the missing traditional mainframe components.  A main reason for doing it this way is that I've never written a language parser, compiler, or interpreter so I really wouldn't want to try and write one from scratch. --- In [hidden email], Dave Wade wrote: > > On 03/09/2012 17:39, John wrote: > > Didn't know that.  I'd like to remove the dependence on C if I can. > Then why start with a "C" implementation that is a total bodge and is > missing much of the bits you want REXX on a mainframe for. And before > you all "flame" I spent a long time getting it to work with GCC on an > EBCDIC system so I probably know nearly as much about its internals as > any one else. I also wrote the floating point support in the the GCC "C" > library which you can flame me for.... > > Now although I did a lot of work porting it to VM/370 and GCC after > jason had started with his JCC compiler, I don't really feel BREXX > delivers what I was looking for in a mainframe REXX. It does not have > any of the original Mainframe quirks such as EXECIO so you can't use it > to run many classical downloadable REXX programs.  On VM I would say 50% > of the REXX execs are XEDIT specific and used to deliver full screen > panel applications, again something you can't do with REXX on VM/380R6, > the last free VM as it has no XEDIT and no full screen I/O. Worse still > it does binary arithmetic which to me is a total abomination. > > To continue the rant, the "C" it produces is un-readable for a number of > reasons. All local variables are allocated on the stack so are merley > offsets to the stack pointer, so its a nightmare to figure out what > something refers to. Secondly if the optimizer is on then the > instruction order may not match the source code. Lastly the code makes > extensive use of "C" macros which again dn't show in the asembler. Here > are a few lines from "main.c":- > >           L     15,=V(LSCPY) >           BALR  14,15 > L5       EQU   * >           L     3,156(13) >           A     3,=F'1' >           ST    3,156(13) >           B     L8 > L3       EQU   * >           L     2,156(13) >           MH    2,=H'4' >           A     2,4(11) >           L     2,0(2) >           IC    2,0(2) >           CLM   2,1,=XL1'6F' >           BE    L10 >           L     2,156(13) >           MH    2,=H'4' >           A     2,4(11) >           L     2,0(2) >           IC    2,0(2) > > So if you want a mainframe REXX that s assembler maintained, please > start with Assembler. > > Dave > > > As to storage requirements I assume I would essentially have to implement paging for the BREXX data storage if I wanted it to support large amounts of data.  Meaning writing the data off into a dataset and retrieving it as needed.  This obviously could have a huge performance impact. > > > > --- In [hidden email], "Dave" wrote: > >> > >>> -----Original Message----- > >>> From: [hidden email] > >>> [mailto:[hidden email]] On Behalf Of John > >>> Sent: 01 September 2012 17:51 > >>> To: [hidden email] > >>> Subject: [H390-MVS] Re: REXX for MVS 3.8J? > >>> > >>> > >>> My intent would be to rewrite BREXX in mainframe assembler > >>> and have it be executable on MVS 3.8J under MVS/370.  I'm > >>> hoping I could make the footprint small enough by removing > >>> use of the C runtime library. > >>> > >> It should run just fine as it is. Looking at the file sizes and load map the > >> C runtime is about 150K loaded. BREXX itself is much bigger about 500K. It > >> also grabs lots of store to parse files. When I tried it on CMS it needed a > >> 2 Meg VM to parse simple files, which is actually more than I expected, but > >> I wouldn't have thought that was much of an issue on MVS. You only need > >> MVS/380 to re-build the GCC compiler > >> > >>> I can see issues related to the ANSI I/O model, but I have > >>> some thoughts about how to address those, unfortunately they > >>> would be heavily performance degrading - creating copies of 1 > >>> files that are opened. > >>> > >>> --- In [hidden email], "ScottC" wrote: > >>>> --- In [hidden email], "John" wrote: > >>>>> I'm sure this has come up before, but is there a REXX > >>> implementation > >>>>> for MVS 3.8J?  I really prefer REXX to CLIST. > >>>>> > >>>>>  From my searching around it looks like BREXX may be > >>> available, but > >>>>> only under VM/370. > >>>>> > >>>>> I have a lot of time on my hands and a thought I've had > >>> is that it > >>>>> may be interesting to try and write an assembler > >>> implementation of > >>>>> REXX for use on MVS 3.8J TSO and batch. > >>>>> > >>>>> I know the BREXX code is open source and I know C very well and I > >>>>> know mainframe assembler very well.  I may not really > >>> have the skill > >>>>> set to do it, but it might be interesting to try, but I > >>> don't want > >>>>> to waste my time if there already is a REXX > >>> implementation for these > >>>>> environments that I'm not aware of. > >>>>> > >>>> BREXX (v2.1.8 MVS 1.0 May 24 2010) is implemented as a part of the > >>>> MVS380 Project, a 31-bit variant of 24-bit MVS/370: > >>>> > >>>> Overlay to tk3upd: > >>>> > >>> http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_overlay.zi> >>>> p > >>>> > >>>> -or- Full Installation: > >>>> http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_rtr.zip> >>>> > >>>> Yahoo Discussion Group: > >>>> http://tech.groups.yahoo.com/group/hercules-os380> >>>> > >>>> If interested, please join us.  I believe there is still > >>> much work to > >>>> do to enhance BREXX's current features, but at least it has been > >>>> ported to MVS! > >>>> > >>>> ScottC > >>>> > >>>> P.S. BREXX was installed into MVS/380 from the "SEASIK" compilation > >>>> from the GCCMVS Project: > >>> http://sourceforge.net/projects/gccmvs/files> >>> > >>> > >>> > >>> ------------------------------------ > >>> > >>> Yahoo! Groups Links > >>> > >>> > >>> > >>> > > > > > > > > ------------------------------------ > > > > Yahoo! Groups Links > > > > > > > > > -- > Dave Wade G4UGM > Illegitimi Non Carborundum > > *** For the Hams on the list three special event stations in Manchester now operational ***** > **** GB2012MV, GB2012MS and GB2012MW. See http://GB2012MS.COM/ for links and schedules. *** >
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 > John wrote: > My intention is to use the BREXX C code for the logic and write a > mainframe assembler implementation from the logic.  I don't want to > take compiler produced assembler code (I know technically it is > assembly code) and "clean it up".   > I would try to first implement BREXX with its current features and > then look at extending it to have the missing traditional mainframe > components.  A main reason for doing it this way is that I've never > written a language parser, compiler, or interpreter so I really > wouldn't want to try and write one from scratch. > You might want to join H390-VM group and peruse the messages there concerning REXX ( BREXX, REGINA & IBM versions ).  The father of REXX is a member of that list and has posted a few times.  There is also a file the the H390-VM files section of an off list email correspondence between him and another poster. ---------------------------------------------------------------------- May 2002 : http://games.groups.yahoo.com/group/H390-VM/message/1031"I gather that M.C. advises only that interpreters are easier than compilers" ---------------------------------------------------------------------- ---------------------------------------------------------------------- Feb 2010 : http://games.groups.yahoo.com/group/H390-VM/message/6772"Paperwork not yet signed yet, but my REXXIO CMS package (linein/lineout functions) is included in code I wrote when at IBM and hope to have a license to use when I retire a few weeks from now." ---------------------------------------------------------------------- ---------------------------------------------------------------------- Aug 2010 : http://games.groups.yahoo.com/group/H390-VM/message/7613"This version features BREXX (including file I/O) integrated into CMS" ---------------------------------------------------------------------- So BREXX & REGINA REXX are both working on VM/370 perhaps both with file I/O.  VM isn't all that familiar to me and I don't know if the C sources used there are the same as what can be pulled from sourceforge . Don't ever imagine IBM will permit old versions of program product ( monthly fee ) software to be distributed. Not sure what is and isn't implemented in BREXX on MVS but ran another test using BREXX at TSO READY prompt. Sieve of Eratosthenes from : http://cs.ecs.baylor.edu/~maurer/SieveE/SieveE.rex READY alloc dd(sysin) ds('brexx.jcl(sieve)')  READY alloc dd(sysprint) da(*)  READY alloc dd(systerm) da(*)  READY call 'brexx.linklib(brexx)' '-'  2  is prime :  3  is prime :  5  is prime :  7  is prime :  11  is prime :  13  is prime :  17  is prime :  19  is prime :  23  is prime :  29  is prime :  31  is prime :  37  is prime :  41  is prime :  43  is prime :  47  is prime :  53  is prime :  59  is prime :  61  is prime :  67  is prime :  71  is prime :  73  is prime :  79  is prime :  83  is prime :  89  is prime :  97  is prime :  101   is prime :  103  is prime :  107  is prime :  109  is prime :  113  is prime :   127  is prime :  131  is prime :  137  is prime :  139  is prime :  149  is pr ime :  151  is prime :  157  is prime :  163  is prime :  167  is prime :  173   is prime :  179  is prime :  181  is prime :  191  is prime :  193  is prime : 197  is prime :  199  is prime :  211  is prime :  223  is prime :  227  is prim e :  229  is prime :  233  is prime :  239  is prime :  241  is prime :  251  is  prime :  257  is prime :  263  is prime :  269  is prime :  271  is prime :  27 7  is prime :  281  is prime :  283  is prime :  293  is prime :  307  is prime :  311  is prime :  313  is prime :  317  is prime :  331  is prime :  337  is p rime :  347  is prime :  349  is prime :  353  is prime :  359  is prime :  367  is prime :  373  is prime :  379  is prime :  383  is prime :  389  is prime :  397  is prime :  401  is prime :  409  is prime :  419  is prime :  421  is pri me :  431  is prime :  433  is prime :  439  is prime :  443  is prime :  449  i s prime :  457  is prime :  461  is prime :  463  is prime :  467  is prime :  4 79  is prime :  487  is prime :  491  is prime :  499  is prime :  503  is prime  :  509  is prime :  521  is prime :  523  is prime :  541  is prime :  547  is prime :  557  is prime :  563  is prime :  569  is prime :  571  is prime :  577   is prime :  587  is prime :  593  is prime :  599  is prime :  601  is prime :   607  is prime :  613  is prime :  617  is prime :  619  is prime :  631  is pr ime :  641  is prime :  643  is prime :  647  is prime :  653  is prime :  659   is prime :  661  is prime :  673  is prime :  677  is prime :  683  is prime : 691  is prime :  701  is prime :  709  is prime :  719  is prime :  727  is prim e :  733  is prime :  739  is prime :  743  is prime :  751  is prime :  757  is  prime :  761  is prime :  769  is prime :  773  is prime :  787  is prime :  79 7  is prime :  809  is prime :  811  is prime :  821  is prime :  823  is prime :  827  is prime :  829  is prime :  839  is prime :  853  is prime :  857  is p rime :  859  is prime :  863  is prime :  877  is prime :  881  is prime :  883  is prime :  887  is prime :  907  is prime :  911  is prime :  919  is prime :  929  is prime :  937  is prime :  941  is prime :  947  is prime :  953  is pri  ***  me :  967  is prime :  971  is prime :  977  is prime :  983  is prime :  991   is prime :  997  is prime  READY Phil ps - that's it for me again for a while - good luck all
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## RE: Re: REXX for MVS 3.8J?

 In reply to this post by John-796 > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of John > Sent: 03 September 2012 21:11 > To: [hidden email] > Subject: [H390-MVS] Re: REXX for MVS 3.8J? > > > My intention is to use the BREXX C code for the logic and > write a mainframe assembler implementation from the logic.  I > don't want to take compiler produced assembler code (I know > technically it is assembly code) and "clean it up". > > I would try to first implement BREXX with its current > features and then look at extending it to have the missing > traditional mainframe components.  A main reason for doing it > this way is that I've never written a language parser, > compiler, or interpreter so I really wouldn't want to try and > write one from scratch. > I kind of thought that might be the case, but I still am not sure BREXX is the place to start. Its really a modern implementation and depends heavily on "C" paradigms. So it needs a  stack, and SETJMP/LONGJMP both of which don't think translate easily into "C". I think getting rid of SETJMP/LONGJMP would be high on my list of desirable features, which I think would involve a major re-design. It also reads and parses the entire file at one pass into a B-Tree which makes code parsing simple, but which is pretty memory hungry. I am pretty sure the IBM Assembler REXX parses a statement at a time, but I havn't looked too closley at the code so I can't say if that is true for certain. To sum up I think that replication of the necessary bits of the "C" environment might be harder than translating the "C" to assembler. Take a look through the "compile.c" and "bintree.c" routines if you don't believe me. I guess one thing is in its favour, its small enough for you to get a good idea on how all the routines work in a couple of evenings reading. The compiler proper is only 40 odd routines, the biggest of which is only aboyt 55k. Most are pretty small and easily understood. Dave > --- In [hidden email], Dave Wade wrote: > > > > On 03/09/2012 17:39, John wrote: > > > Didn't know that.  I'd like to remove the dependence on C > if I can. > > Then why start with a "C" implementation that is a total > bodge and is > > missing much of the bits you want REXX on a mainframe for. > And before > > you all "flame" I spent a long time getting it to work with > GCC on an > > EBCDIC system so I probably know nearly as much about its > internals as > > any one else. I also wrote the floating point support in > the the GCC "C" > > library which you can flame me for.... > > > > Now although I did a lot of work porting it to VM/370 and GCC after > > jason had started with his JCC compiler, I don't really feel BREXX > > delivers what I was looking for in a mainframe REXX. It > does not have > > any of the original Mainframe quirks such as EXECIO so you > can't use it > > to run many classical downloadable REXX programs.  On VM I > would say 50% > > of the REXX execs are XEDIT specific and used to deliver > full screen > > panel applications, again something you can't do with REXX > on VM/380R6, > > the last free VM as it has no XEDIT and no full screen I/O. > Worse still > > it does binary arithmetic which to me is a total abomination. > > > > To continue the rant, the "C" it produces is un-readable > for a number > > of > > reasons. All local variables are allocated on the stack so > are merley > > offsets to the stack pointer, so its a nightmare to figure out what > > something refers to. Secondly if the optimizer is on then the > > instruction order may not match the source code. Lastly the > code makes > > extensive use of "C" macros which again dn't show in the > asembler. Here > > are a few lines from "main.c":- > > > >           L     15,=V(LSCPY) > >           BALR  14,15 > > L5       EQU   * > >           L     3,156(13) > >           A     3,=F'1' > >           ST    3,156(13) > >           B     L8 > > L3       EQU   * > >           L     2,156(13) > >           MH    2,=H'4' > >           A     2,4(11) > >           L     2,0(2) > >           IC    2,0(2) > >           CLM   2,1,=XL1'6F' > >           BE    L10 > >           L     2,156(13) > >           MH    2,=H'4' > >           A     2,4(11) > >           L     2,0(2) > >           IC    2,0(2) > > > > So if you want a mainframe REXX that s assembler maintained, please > > start with Assembler. > > > > Dave > > > > > As to storage requirements I assume I would essentially have to > > > implement paging for the BREXX data storage if I wanted it to > > > support large amounts of data.  Meaning writing the data > off into a > > > dataset and retrieving it as needed.  This obviously could have a > > > huge performance impact. > > > > > > --- In [hidden email], "Dave" wrote: > > >> > > >>> -----Original Message----- > > >>> From: [hidden email] > [mailto:[hidden email]] > > >>> On Behalf Of John > > >>> Sent: 01 September 2012 17:51 > > >>> To: [hidden email] > > >>> Subject: [H390-MVS] Re: REXX for MVS 3.8J? > > >>> > > >>> > > >>> My intent would be to rewrite BREXX in mainframe assembler and > > >>> have it be executable on MVS 3.8J under MVS/370.  I'm hoping I > > >>> could make the footprint small enough by removing use of the C > > >>> runtime library. > > >>> > > >> It should run just fine as it is. Looking at the file sizes and > > >> load map the C runtime is about 150K loaded. BREXX > itself is much > > >> bigger about 500K. It also grabs lots of store to parse > files. When > > >> I tried it on CMS it needed a 2 Meg VM to parse simple > files, which > > >> is actually more than I expected, but I wouldn't have > thought that > > >> was much of an issue on MVS. You only need MVS/380 to > re-build the > > >> GCC compiler > > >> > > >>> I can see issues related to the ANSI I/O model, but I have some > > >>> thoughts about how to address those, unfortunately they > would be > > >>> heavily performance degrading - creating copies of 1 files that > > >>> are opened. > > >>> > > >>> --- In [hidden email], "ScottC" wrote: > > >>>> --- In [hidden email], "John" wrote: > > >>>>> I'm sure this has come up before, but is there a REXX > > >>> implementation > > >>>>> for MVS 3.8J?  I really prefer REXX to CLIST. > > >>>>> > > >>>>>  From my searching around it looks like BREXX may be > > >>> available, but > > >>>>> only under VM/370. > > >>>>> > > >>>>> I have a lot of time on my hands and a thought I've had > > >>> is that it > > >>>>> may be interesting to try and write an assembler > > >>> implementation of > > >>>>> REXX for use on MVS 3.8J TSO and batch. > > >>>>> > > >>>>> I know the BREXX code is open source and I know C > very well and > > >>>>> I know mainframe assembler very well.  I may not really > > >>> have the skill > > >>>>> set to do it, but it might be interesting to try, but I > > >>> don't want > > >>>>> to waste my time if there already is a REXX > > >>> implementation for these > > >>>>> environments that I'm not aware of. > > >>>>> > > >>>> BREXX (v2.1.8 MVS 1.0 May 24 2010) is implemented as a part of > > >>>> the MVS380 Project, a 31-bit variant of 24-bit MVS/370: > > >>>> > > >>>> Overlay to tk3upd: > > >>>> > > >>> > http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_overla> > >>> y.zi > > >>>> p > > >>>> > > >>>> -or- Full Installation: > > >>>> > http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_rtr.z> > >>>> ip > > >>>> > > >>>> Yahoo Discussion Group: > > >>>> http://tech.groups.yahoo.com/group/hercules-os380> > >>>> > > >>>> If interested, please join us.  I believe there is still > > >>> much work to > > >>>> do to enhance BREXX's current features, but at least > it has been > > >>>> ported to MVS! > > >>>> > > >>>> ScottC > > >>>> > > >>>> P.S. BREXX was installed into MVS/380 from the "SEASIK" > > >>>> compilation from the GCCMVS Project: > > >>> http://sourceforge.net/projects/gccmvs/files> > >>> > > >>> > > >>> > > >>> ------------------------------------ > > >>> > > >>> Yahoo! Groups Links > > >>> > > >>> > > >>> > > >>> > > > > > > > > > > > > ------------------------------------ > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > -- > > Dave Wade G4UGM > > Illegitimi Non Carborundum > > > > *** For the Hams on the list three special event stations in > > Manchester now operational ***** > > **** GB2012MV, GB2012MS and GB2012MW. See > http://GB2012MS.COM/ for links and schedules. *** > > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > >
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 In reply to this post by John-796 Ok, can you explain again why you want to "remove the dependence on C"? In what way is the BREXX load module "dependent on C"? At the time the load module was being built, all the input was pure assembler. Mostly generated assembler, but big deal. Are you under the mistaken apprehension that: 1. PDPCLIB is the same as IBM C in that it requires a runtime library to be loaded at runtime instead of being a self-contained load module? 2. C programs always use ATL memory? 3. C programs have a lot of runtime library overhead? PDPCLIB was designed to be a replacement for assembler, not a clone of IBM C. Regarding projects, you might be interested in the list you can find in here: http://mvs380.sourceforge.net/System380.txtBut really, as far as big projects are concerned, nothing beats "write a clone of MVS in C". And there's already a starting base for that - PDOS/390 at: http://pdos.sourceforge.netIt already runs certain MVS programs, and the goal is to expand it to run more. Being able to run IFOX and IEWL is particularly desirable as it would allow PDOS/390 to be a standalone system that allows you to develop PDOS using PDOS. Currently you still need to use MVS to develop PDOS. BFN.  Paul. --- In [hidden email], "John" wrote: > > I actually do have a ton of time on my hands - I'm on disability leave under my employer and may end up on government disability.  So I am looking for a big project that interests me. > > When I saw MVS/380 I assumed the code would require the use of the one special storage area above-the-line and therefore there would dependence in the code for that. > > Also please don't assume what my attitudes are, for example that I never want to use C, it's actually my favorite high level programming language. > > --- In [hidden email], "kerravon86" wrote: > > > > --- In [hidden email], scott wrote: > > > > > > On 08/31/2012 04:14 PM, Rene Ferland wrote: > > > > > > > > --- In [hidden email], "John" wrote: > > > >> I'm sure this has come up before, but is there a REXX implementation for MVS 3.8J? > > > > To the best of my knowledge, the answer is no. > > > > > > > >> I know the BREXX code is open source and I know C very well and I know mainframe assembler very well.  I may not really have the skill set to do it, but it might be interesting to try, but I don't want to waste my time if there already is a REXX implementation for these environments that I'm not aware of. > > > > It would be great but I think it's a big project. If you are ready to go, then I wish you the best of luck :-) > > > > > > > > > > > I too have thought about this but no time.  Had an idea though which may > > > help.  If on the MVS 380 one had the GCC compiler running, will it > > > output the translated C to assembler?  If so, one could take the > > > assembler output, clean it up, and assemble that on MVS 3.8. > > > > > > Just a thought...  Haven't worked much with C on IBM mainframes. > > > > I step away for 5 minutes ... > > > > You're vastly overthinking the difference between > > MVS/380 and MVS 3.8j. For the purposes of this > > discussion, MVS/380 *IS* MVS 3.8j. > > > > As such, BREXX was compiled and linked on MVS 3.8j, > > and the resultant executable was bundled in a > > "convenient" (the word Gerhard used was sadistic) > > package called "SEASIK" (also a term coined by > > Gerhard - so blame him if there is anything at all > > you don't like about SEASIK or GCC or C in general). > > > > The resultant 24-bit executable you can find on the > > "tape" will run perfectly fine on MVS 3.8j and > > above. Hell, it'll probably even run on MVT too, > > but I'm not aware of anyone who has tried it. > > > > People discussing converting a perfectly working > > 24-bit BREXX executable from C to assembler, to > > theoretically make some sort of microscopic > > (Gerhard is overstating the quality of the code - > > it's perfectly fine) speed improvement (that > > no-one, absolutely no-one cares about, especially > > given that the number of BREXX on MVS users > > probably aren't enough for a game of tennis), have > > way way way too much time on their hands, and should > > either be given a box of matches to play with, or > > pointed in the direction of the MVS 3.8j source > > code, with a view to producing a version of MVS > > that we actually have source code to. > > > > Or if you know C, there's a lot more things that > > can be done, depending on what you're hoping to > > achieve. > > > > This is actually why I never went past C. I'm > > used to not being able to wean people off > > assembler, so until everyone's on board with > > using a higher level language than assembler, > > I'm not going to make matters any "worse" than C. > > > > BFN.  Paul. > > >
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Re: REXX for MVS 3.8J?

 In reply to this post by Dave Wade-2 I knew it used a B-tree, but I didn't realize it put the whole file into it.  I assume that if other files are called it would have to put them in them into B-trees as well which will use even more storage. I'll have to look at the code for SETJUMP/LONGJUMP usage.  That could really be a lot of work to deal with because you have to arbitratily support jumping back one or more levels of the call stack releasing all the resources used by the levels in between and restoring the execution environment correctly for where you jump to. This is turning out to be a much more complicated idea than I originally thought. --- In [hidden email], "Dave" wrote: > > > -----Original Message----- > > From: [hidden email] > > [mailto:[hidden email]] On Behalf Of John > > Sent: 03 September 2012 21:11 > > To: [hidden email] > > Subject: [H390-MVS] Re: REXX for MVS 3.8J? > > > > > > My intention is to use the BREXX C code for the logic and > > write a mainframe assembler implementation from the logic.  I > > don't want to take compiler produced assembler code (I know > > technically it is assembly code) and "clean it up". > > > > I would try to first implement BREXX with its current > > features and then look at extending it to have the missing > > traditional mainframe components.  A main reason for doing it > > this way is that I've never written a language parser, > > compiler, or interpreter so I really wouldn't want to try and > > write one from scratch. > > > > I kind of thought that might be the case, but I still am not sure BREXX is > the place to start. Its really a modern implementation and depends heavily > on "C" paradigms. So it needs a  stack, and SETJMP/LONGJMP both of which > don't think translate easily into "C". I think getting rid of SETJMP/LONGJMP > would be high on my list of desirable features, which I think would involve > a major re-design. > > It also reads and parses the entire file at one pass into a B-Tree which > makes code parsing simple, but which is pretty memory hungry. I am pretty > sure the IBM Assembler REXX parses a statement at a time, but I havn't > looked too closley at the code so I can't say if that is true for certain. > > To sum up I think that replication of the necessary bits of the "C" > environment might be harder than translating the "C" to assembler. > > Take a look through the "compile.c" and "bintree.c" routines if you don't > believe me. > > I guess one thing is in its favour, its small enough for you to get a good > idea on how all the routines work in a couple of evenings reading. The > compiler proper is only 40 odd routines, the biggest of which is only aboyt > 55k. Most are pretty small and easily understood. > > Dave > > > --- In [hidden email], Dave Wade wrote: > > > > > > On 03/09/2012 17:39, John wrote: > > > > Didn't know that.  I'd like to remove the dependence on C > > if I can. > > > Then why start with a "C" implementation that is a total > > bodge and is > > > missing much of the bits you want REXX on a mainframe for. > > And before > > > you all "flame" I spent a long time getting it to work with > > GCC on an > > > EBCDIC system so I probably know nearly as much about its > > internals as > > > any one else. I also wrote the floating point support in > > the the GCC "C" > > > library which you can flame me for.... > > > > > > Now although I did a lot of work porting it to VM/370 and GCC after > > > jason had started with his JCC compiler, I don't really feel BREXX > > > delivers what I was looking for in a mainframe REXX. It > > does not have > > > any of the original Mainframe quirks such as EXECIO so you > > can't use it > > > to run many classical downloadable REXX programs.  On VM I > > would say 50% > > > of the REXX execs are XEDIT specific and used to deliver > > full screen > > > panel applications, again something you can't do with REXX > > on VM/380R6, > > > the last free VM as it has no XEDIT and no full screen I/O. > > Worse still > > > it does binary arithmetic which to me is a total abomination. > > > > > > To continue the rant, the "C" it produces is un-readable > > for a number > > > of > > > reasons. All local variables are allocated on the stack so > > are merley > > > offsets to the stack pointer, so its a nightmare to figure out what > > > something refers to. Secondly if the optimizer is on then the > > > instruction order may not match the source code. Lastly the > > code makes > > > extensive use of "C" macros which again dn't show in the > > asembler. Here > > > are a few lines from "main.c":- > > > > > >           L     15,=V(LSCPY) > > >           BALR  14,15 > > > L5       EQU   * > > >           L     3,156(13) > > >           A     3,=F'1' > > >           ST    3,156(13) > > >           B     L8 > > > L3       EQU   * > > >           L     2,156(13) > > >           MH    2,=H'4' > > >           A     2,4(11) > > >           L     2,0(2) > > >           IC    2,0(2) > > >           CLM   2,1,=XL1'6F' > > >           BE    L10 > > >           L     2,156(13) > > >           MH    2,=H'4' > > >           A     2,4(11) > > >           L     2,0(2) > > >           IC    2,0(2) > > > > > > So if you want a mainframe REXX that s assembler maintained, please > > > start with Assembler. > > > > > > Dave > > > > > > > As to storage requirements I assume I would essentially have to > > > > implement paging for the BREXX data storage if I wanted it to > > > > support large amounts of data.  Meaning writing the data > > off into a > > > > dataset and retrieving it as needed.  This obviously could have a > > > > huge performance impact. > > > > > > > > --- In [hidden email], "Dave" wrote: > > > >> > > > >>> -----Original Message----- > > > >>> From: [hidden email] > > [mailto:[hidden email]] > > > >>> On Behalf Of John > > > >>> Sent: 01 September 2012 17:51 > > > >>> To: [hidden email] > > > >>> Subject: [H390-MVS] Re: REXX for MVS 3.8J? > > > >>> > > > >>> > > > >>> My intent would be to rewrite BREXX in mainframe assembler and > > > >>> have it be executable on MVS 3.8J under MVS/370.  I'm hoping I > > > >>> could make the footprint small enough by removing use of the C > > > >>> runtime library. > > > >>> > > > >> It should run just fine as it is. Looking at the file sizes and > > > >> load map the C runtime is about 150K loaded. BREXX > > itself is much > > > >> bigger about 500K. It also grabs lots of store to parse > > files. When > > > >> I tried it on CMS it needed a 2 Meg VM to parse simple > > files, which > > > >> is actually more than I expected, but I wouldn't have > > thought that > > > >> was much of an issue on MVS. You only need MVS/380 to > > re-build the > > > >> GCC compiler > > > >> > > > >>> I can see issues related to the ANSI I/O model, but I have some > > > >>> thoughts about how to address those, unfortunately they > > would be > > > >>> heavily performance degrading - creating copies of 1 files that > > > >>> are opened. > > > >>> > > > >>> --- In [hidden email], "ScottC" wrote: > > > >>>> --- In [hidden email], "John" wrote: > > > >>>>> I'm sure this has come up before, but is there a REXX > > > >>> implementation > > > >>>>> for MVS 3.8J?  I really prefer REXX to CLIST. > > > >>>>> > > > >>>>>  From my searching around it looks like BREXX may be > > > >>> available, but > > > >>>>> only under VM/370. > > > >>>>> > > > >>>>> I have a lot of time on my hands and a thought I've had > > > >>> is that it > > > >>>>> may be interesting to try and write an assembler > > > >>> implementation of > > > >>>>> REXX for use on MVS 3.8J TSO and batch. > > > >>>>> > > > >>>>> I know the BREXX code is open source and I know C > > very well and > > > >>>>> I know mainframe assembler very well.  I may not really > > > >>> have the skill > > > >>>>> set to do it, but it might be interesting to try, but I > > > >>> don't want > > > >>>>> to waste my time if there already is a REXX > > > >>> implementation for these > > > >>>>> environments that I'm not aware of. > > > >>>>> > > > >>>> BREXX (v2.1.8 MVS 1.0 May 24 2010) is implemented as a part of > > > >>>> the MVS380 Project, a 31-bit variant of 24-bit MVS/370: > > > >>>> > > > >>>> Overlay to tk3upd: > > > >>>> > > > >>> > > http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_overla> > > >>> y.zi > > > >>>> p > > > >>>> > > > >>>> -or- Full Installation: > > > >>>> > > http://content.wuala.com/contents/sccosel/mvs380/mvs380-1_2_rtr.z> > > >>>> ip > > > >>>> > > > >>>> Yahoo Discussion Group: > > > >>>> http://tech.groups.yahoo.com/group/hercules-os380> > > >>>> > > > >>>> If interested, please join us.  I believe there is still > > > >>> much work to > > > >>>> do to enhance BREXX's current features, but at least > > it has been > > > >>>> ported to MVS! > > > >>>> > > > >>>> ScottC > > > >>>> > > > >>>> P.S. BREXX was installed into MVS/380 from the "SEASIK" > > > >>>> compilation from the GCCMVS Project: > > > >>> http://sourceforge.net/projects/gccmvs/files> > > >>> > > > >>> > > > >>> > > > >>> ------------------------------------ > > > >>> > > > >>> Yahoo! Groups Links > > > >>> > > > >>> > > > >>> > > > >>> > > > > > > > > > > > > > > > > ------------------------------------ > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > -- > > > Dave Wade G4UGM > > > Illegitimi Non Carborundum > > > > > > *** For the Hams on the list three special event stations in > > > Manchester now operational ***** > > > **** GB2012MV, GB2012MS and GB2012MW. See > > http://GB2012MS.COM/ for links and schedules. *** > > > > > > > > > > > > > ------------------------------------ > > > > Yahoo! Groups Links > > > > > > > > >
123
Loading...