🚀 go-pugleaf

You can compress a Rexx exec with /*% NOcomment Rexx */ in the first line.
Or compile it if you have the Rexx compiler available.

Regards,
John K



From:	Steve Thompson <sthompson@US.IBM.COM>
To:	TSO-REXX@vm.marist.edu
Date:	02/26/2013 11:31 AM
Subject:	[TSO-REXX] Tuning Question
Sent by:	TSO REXX Discussion List <TSO-REXX@vm.marist.edu>



Are there some rules of thumb, or some generic principles for tuning REXX
to cut elapsed time (wall, not necessarily CPU)?

I know that an I/O that one does not have to do cuts down on time. So I
have all my stuff in stems that I can put there. I have logic to detect
when I can do an early out of a DO and so issue LEAVE/ITERATE as soon as I
can.

Anything about REXX that is known to be less efficient that I can attack?

Regards,
Steve Thompson

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

I found that repeatedly calling the same external REXX routine slowed me down a lot.  

I also found that some functions, although easy to code take a long time to execute.  For example, I used to have code that would add a word to a string if the word was not already there:

IF WORDPOS(NEEDLE,HAYSTACK) = 0 THEN
  HAYSTACK = HAYSTACK NEEDLE;

When the above code was executed many times, it slowed the program down a lot.  Instead of the above code, I used stems which improved the performance:

IF SYMBOL("HAYSTACK.NEEDLE") <> "VAR" then
  HAYSTACK.NEEDLE = "";


John

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-REXX@vm.marist.edu] On Behalf Of Steve Thompson
Sent: Tuesday, February 26, 2013 12:29 PM
To: TSO-REXX@vm.marist.edu
Subject: [TSO-REXX] Tuning Question

Are there some rules of thumb, or some generic principles for tuning REXX
to cut elapsed time (wall, not necessarily CPU)?

I know that an I/O that one does not have to do cuts down on time. So I
have all my stuff in stems that I can put there. I have logic to detect
when I can do an early out of a DO and so issue LEAVE/ITERATE as soon as I
can.

Anything about REXX that is known to be less efficient that I can attack?

Regards,
Steve Thompson

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

If we're talking interpreted rexx than make all external routines internal -
a great saving.
Use literals as much as possible - don't keep resolving variables - do it
once only.

But compiling to a load module will solve those problems for you if I
remember correctly.

And talking of elapsed time then I/O is a big issue since you wait for I/O
channel calls - so optimal block sizes on all files helps a lot.

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf Of
Steve Thompson
Sent: den 26 februari 2013 18:29
To: TSO-REXX@VM.MARIST.EDU
Subject: [TSO-REXX] Tuning Question

Are there some rules of thumb, or some generic principles for tuning REXX
to cut elapsed time (wall, not necessarily CPU)?

I know that an I/O that one does not have to do cuts down on time. So I
have all my stuff in stems that I can put there. I have logic to detect
when I can do an early out of a DO and so issue LEAVE/ITERATE as soon as I
can.

Anything about REXX that is known to be less efficient that I can attack?

Regards,
Steve Thompson

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

On Feb 26, 2013, at 11:05, John P Kalinich wrote:

> You can compress a Rexx exec with /*% NOcomment Rexx */ in the first line.
> Or compile it if you have the Rexx compiler available.
>
Does this work in OMVS?

-- gil

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

From:   Steve Thompson/Dallas/IBM@IBMUS
Date:   02/26/2013 11:41 AM

Are there some rules of thumb, or some generic principles for tuning REXX
to cut elapsed time (wall, not necessarily CPU)?
<SNIPPAGE>

Wow, I had never seen anything said about this:   /*% NOcomment Rexx  */ .
 I put that in immediately for the next test I run to see how it behaves.

And the comment about WORDPOS, yes, that is exactly the kind of thing I
was concerned about. Using a trick like that which allows rapid coding to
get something written, but in the long run causes things to be quite slow
during execution (and I am actually making use of that technique, but in
the batch oriented REXX code).

And I have everything I can as internal routines for the REXX that is
executed under ISPF.  I really want to keep a TSO user from getting
penalized with 3rd & 4th period.

The batch executions are not that critical to me, but the TSO execution is
my biggest concern.  (Trust me, what I am doing without tuning will be at
least two orders of magnitude faster than the Java it replaces because I
will be running at "z/OS speed", and not at an external system's speed
with having to poll, wait for something, then poll, etc.).

Once we get finished with acceptance testing, I will see if I can get this
code compiled. I know that speeds things up, I just don't know by how
much.

Regards,
Steve Thompson

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

I would be cautious about making all modules internal, just as I would be
cautious about making all modules external:

   - If they need to be internal because you need access to a variable pool
   or for performance, do so.  If a module is only called once, or only under
   certain conditions, making it internal is unnecessary with little benefit.
   - If you don't need to make a module external , don't.  It's a
   maintenance headache.

I've seen people go to both extremes. They were sorry!

Compiling is generally a good idea from a performance point of view.  Under
CMS and TSO, you get the added benefit of seeing all your errors at once,
identifying uninitialized variables, etc., etc.  But it's an extra step.
 For real fun under TSO, compile using an ISPF edit macro, and merge any
error messages into the edit session at =NOTE= lines just before the line
in error.  It's a real productivity boost.

If you want performance benefits while keeping the module external, you
have these options:

   - Under CMS EXECLOAD.  Compile first, if you can.
   - Under TSO, write your own EXECLOAD:  If not already allocated,
   allocate a dd (e.g. EXECLOAD) to VIO PDS /* else continue */.  Compile the
   EXEC and place the CEXEC into this DD.  See LMCOPY.  It will scream and, if
   done right, will confuse your capacity planners.  :-)
   - Under Windows, use SysREXXMacroLoad() /*I think?*/
   - Under Linux, I'm not sure.

I would say the advice about literals produces minimal improvement at the
expense of clarity and maintainability.

Note that for PDSEs, the coded BLKSIZE is only the buffer size.  The
physical block is always 4096.  Strange, but true.  There is no need to go
for track optimal blocking.  The highest allowed multiple of 4096 will give
you the best I/O performance, possibly at the expense of a larger working
set.

On Tue, Feb 26, 2013 at 1:17 PM, Adrian Stern <adriangstern@gmail.com>wrote:

> If we're talking interpreted rexx than make all external routines internal
> -
> a great saving.
> Use literals as much as possible - don't keep resolving variables - do it
> once only.
>
> But compiling to a load module will solve those problems for you if I
> remember correctly.
>
> And talking of elapsed time then I/O is a big issue since you wait for I/O
> channel calls - so optimal block sizes on all files helps a lot.
>
> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf
> Of
> Steve Thompson
> Sent: den 26 februari 2013 18:29
> To: TSO-REXX@VM.MARIST.EDU
> Subject: [TSO-REXX] Tuning Question
>
> Are there some rules of thumb, or some generic principles for tuning REXX
> to cut elapsed time (wall, not necessarily CPU)?
>
> I know that an I/O that one does not have to do cuts down on time. So I
> have all my stuff in stems that I can put there. I have logic to detect
> when I can do an early out of a DO and so issue LEAVE/ITERATE as soon as I
> can.
>
> Anything about REXX that is known to be less efficient that I can attack?
>
> Regards,
> Steve Thompson
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
>



--
OREXXMan

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

Actually a literal instead of a function call makes noticeable savings

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf Of
Hobart Spitz
Sent: den 26 februari 2013 22:55
To: TSO-REXX@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Tuning Question

I would be cautious about making all modules internal, just as I would be
cautious about making all modules external:

   - If they need to be internal because you need access to a variable pool
   or for performance, do so.  If a module is only called once, or only
under
   certain conditions, making it internal is unnecessary with little
benefit.
   - If you don't need to make a module external , don't.  It's a
   maintenance headache.

I've seen people go to both extremes. They were sorry!

Compiling is generally a good idea from a performance point of view.  Under
CMS and TSO, you get the added benefit of seeing all your errors at once,
identifying uninitialized variables, etc., etc.  But it's an extra step.
 For real fun under TSO, compile using an ISPF edit macro, and merge any
error messages into the edit session at =NOTE= lines just before the line
in error.  It's a real productivity boost.

If you want performance benefits while keeping the module external, you
have these options:

   - Under CMS EXECLOAD.  Compile first, if you can.
   - Under TSO, write your own EXECLOAD:  If not already allocated,
   allocate a dd (e.g. EXECLOAD) to VIO PDS /* else continue */.  Compile
the
   EXEC and place the CEXEC into this DD.  See LMCOPY.  It will scream and,
if
   done right, will confuse your capacity planners.  :-)
   - Under Windows, use SysREXXMacroLoad() /*I think?*/
   - Under Linux, I'm not sure.

I would say the advice about literals produces minimal improvement at the
expense of clarity and maintainability.

Note that for PDSEs, the coded BLKSIZE is only the buffer size.  The
physical block is always 4096.  Strange, but true.  There is no need to go
for track optimal blocking.  The highest allowed multiple of 4096 will give
you the best I/O performance, possibly at the expense of a larger working
set.

On Tue, Feb 26, 2013 at 1:17 PM, Adrian Stern <adriangstern@gmail.com>wrote:

> If we're talking interpreted rexx than make all external routines internal
> -
> a great saving.
> Use literals as much as possible - don't keep resolving variables - do it
> once only.
>
> But compiling to a load module will solve those problems for you if I
> remember correctly.
>
> And talking of elapsed time then I/O is a big issue since you wait for I/O
> channel calls - so optimal block sizes on all files helps a lot.
>
> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf
> Of
> Steve Thompson
> Sent: den 26 februari 2013 18:29
> To: TSO-REXX@VM.MARIST.EDU
> Subject: [TSO-REXX] Tuning Question
>
> Are there some rules of thumb, or some generic principles for tuning REXX
> to cut elapsed time (wall, not necessarily CPU)?
>
> I know that an I/O that one does not have to do cuts down on time. So I
> have all my stuff in stems that I can put there. I have logic to detect
> when I can do an early out of a DO and so issue LEAVE/ITERATE as soon as I
> can.
>
> Anything about REXX that is known to be less efficient that I can attack?
>
> Regards,
> Steve Thompson
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
>



--
OREXXMan

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

well i'm not an expert at all in this case, but did some testing some time
ago (with uncompiled rexx):

* as it has been mentioned, i use /*% nocomment rexx */ in the first line

* i try to avoid ELSE conditions; it seemed to be much more efficient to
set a variable and then only have one IF statement for a possibly change
of the default variable value instead of an IF... ELSE construction

* also, many builtin functions seems to be slightly faster then a single
IF statement, example giving: A = MAX(A, 10) did faster than IF A < 10
THEN A = 10


BUT: typically, those kinds of things might speed up an EXEC and you won't
even notice because the EXEC finishes right away. those EXECS i run that
take significant amount of time to finish usually slow down to completely
other reasons, example giving issuing RACF commands in the TSO environment
or some ISPF commands in edit macros. actually, i use external functions
extensively, because that has never has been the bottleneck (and i don't
have to write the same or similar code again and again).

one other thing is processing a hugh amount of data. then i recommend to
use batch jobs with SORT instead of REXX EXECS. this is a way to decrease
processing time dramatically.


regards,
andi



TSO REXX Discussion List <TSO-REXX@VM.MARIST.EDU> schrieb am 26.02.2013
18:29:22:

> Von: Steve Thompson <sthompson@US.IBM.COM>
> An: TSO-REXX@VM.MARIST.EDU,
> Datum: 26.02.2013 18:31
> Betreff: [TSO-REXX] Tuning Question
> Gesendet von: TSO REXX Discussion List <TSO-REXX@VM.MARIST.EDU>
>
> Are there some rules of thumb, or some generic principles for tuning
REXX
> to cut elapsed time (wall, not necessarily CPU)?
>
> I know that an I/O that one does not have to do cuts down on time. So I
> have all my stuff in stems that I can put there. I have logic to detect
> when I can do an early out of a DO and so issue LEAVE/ITERATE as soon as
I
> can.
>
> Anything about REXX that is known to be less efficient that I can
attack?
>
> Regards,
> Steve Thompson
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

On Feb 27, 2013, at 01:46, Adrian Stern wrote:
>
> Note that for PDSEs, the coded BLKSIZE is only the buffer size.  The
> physical block is always 4096.  Strange, but true.  There is no need to go
> for track optimal blocking.  The highest allowed multiple of 4096 will give
> you the best I/O performance, possibly at the expense of a larger working
> set.
>
For RECFM=FB, that needs to be the highest allowed multiple of
LRECL.  E.g, for LRECL=80, that would be 32720.

-- gil

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

From:   Hobart Spitz <orexxman@GMAIL.COM>
Date:   02/26/2013 03:56 PM

I would be cautious about making all modules internal, just as I would be
cautious about making all modules external:

   - If they need to be internal because you need access to a variable
pool
   or for performance, do so.  If a module is only called once, or only
under
   certain conditions, making it internal is unnecessary with little
benefit.
   - If you don't need to make a module external , don't.  It's a
   maintenance headache.

I've seen people go to both extremes. They were sorry!
<SNIPPAGE>

I know one of the extremes. There is a certain REXX that was written that
is 23000+ lines (IIRC). There is a book about bad coding techniques. What
should and shouldn't be done for giving variables names, having comment
-less code, or comments that are cryptic, etc.

That particular REXX would have been the reason for writing that book (I
wish I could remember the title, but one look at that book after having to
do maint on that sucker told me they had to have been looking over the
author's shoulder).

At any rate, the one that I've written for running under ISPF control is
designed for doing a particular thing and then a JOB takes over from
there.  The batch oriented REXX has both internal and external routines,
and even invokes IBM utilities.

So as I've said before, my main concern is the code that has to run under
TSO/ISPF where a user's terminal could be tied up for a long period. I
want it to be as fast as possible to stay out of 3rd / 4th period.

I think that the ultimate improvement will be compiling that REXX.

Regards,
Steve Thompson

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

My example of an external routine that had to be internalised was one that
translated names read from a database where they were stored in capitals to
a more natural look where each name started with a capital letter and
continued with small letters. And it had to cope with Irish, Scottish,
French and German quirks. Dead slow when external and interpreted - zipped
along when internal.

I would agree about size though - I think my longest program was 4 or 500
lines and that was because it contained a lot of formatting to emulate
windows forms.

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf Of
Steve Thompson
Sent: den 27 februari 2013 18:05
To: TSO-REXX@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Tuning Question

From:   Hobart Spitz <orexxman@GMAIL.COM>
Date:   02/26/2013 03:56 PM

I would be cautious about making all modules internal, just as I would be
cautious about making all modules external:

   - If they need to be internal because you need access to a variable
pool
   or for performance, do so.  If a module is only called once, or only
under
   certain conditions, making it internal is unnecessary with little
benefit.
   - If you don't need to make a module external , don't.  It's a
   maintenance headache.

I've seen people go to both extremes. They were sorry!
<SNIPPAGE>

I know one of the extremes. There is a certain REXX that was written that
is 23000+ lines (IIRC). There is a book about bad coding techniques. What
should and shouldn't be done for giving variables names, having comment
-less code, or comments that are cryptic, etc.

That particular REXX would have been the reason for writing that book (I
wish I could remember the title, but one look at that book after having to
do maint on that sucker told me they had to have been looking over the
author's shoulder).

At any rate, the one that I've written for running under ISPF control is
designed for doing a particular thing and then a JOB takes over from
there.  The batch oriented REXX has both internal and external routines,
and even invokes IBM utilities.

So as I've said before, my main concern is the code that has to run under
TSO/ISPF where a user's terminal could be tied up for a long period. I
want it to be as fast as possible to stay out of 3rd / 4th period.

I think that the ultimate improvement will be compiling that REXX.

Regards,
Steve Thompson

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

On Feb 27, 2013, at 01:46, Adrian Stern wrote:

> Actually a literal instead of a function call makes noticeable savings
>
You've said that repeatedly.  I'm not sure I understand.
Obviuosly:

    X = 'A'

will outperform:

    X = translate( 'a' )

... but that's pretty trivial.

A colleague once tested and found that for string comparisons:

    if A==B ...

slightly outperforms:

    if A=B ...

The semantics are different, but often acceptable;
sometimes preferable.  I always test:

    if RC==0 ...

Someone once claimed that by some optimization, Rexx
performs better with single-character symbols than with
multi-character symbols, perhaps more so than could be
explained by lexical analyzer overhead.

-- gil

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

Obviouosly not. But for example you may write:

If pos() then
Do
	X=substr(pos())
End

Whereas:

iPos=pos()

if iPos then
Do
	X=substr(iPos)
End
Uses fewer resources

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Sent: den 27 februari 2013 18:46
To: TSO-REXX@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Tuning Question

On Feb 27, 2013, at 01:46, Adrian Stern wrote:

> Actually a literal instead of a function call makes noticeable savings
>
You've said that repeatedly.  I'm not sure I understand.
Obviuosly:

    X = 'A'

will outperform:

    X = translate( 'a' )

... but that's pretty trivial.

A colleague once tested and found that for string comparisons:

    if A==B ...

slightly outperforms:

    if A=B ...

The semantics are different, but often acceptable;
sometimes preferable.  I always test:

    if RC==0 ...

Someone once claimed that by some optimization, Rexx
performs better with single-character symbols than with
multi-character symbols, perhaps more so than could be
explained by lexical analyzer overhead.

-- gil

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

I'm just catching up with this discussion, and I've marked a lot of places
to ask additional questions.  This is one of them:  I've never known about
this "/*% nocomment rexx */ thingy, and I have to guess at what it does.
But surely it does something about ignoring the comments during processing,
which confuses me because at execution time REXX does that anyway...doesn't
it?

If it helps, understand that I've never used the compiler; my experience is
entirely with interpreted TSO-REXX.

---
Bob Bridges
  rhbridg@attglobal.net, cell 336 382-7313
  bbridges-vendor@foodlion.com, 704 310-4526

/* On the international front, President Bush and Russian President Vladimir
Putin sign an arms-reduction treaty under which the U.S. will destroy about
two-thirds of its nuclear arsenal, and Russia will ''make every effort,
within reason'' to try to find out who, exactly, HAS its nuclear arsenal.
-from Dave Barry's 2002 "Year in Review" */

-----Original Message-----
From: Andreas Fischer
Sent: Wednesday, February 27, 2013 04:44

* as it has been mentioned, i use /*% nocomment rexx */ in the first line

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

From:   Bob Bridges <rhbridg@ATTGLOBAL.NET>
Date:   03/11/2013 04:11 PM



I'm just catching up with this discussion, and I've marked a lot of places
to ask additional questions.  This is one of them:  I've never known about
this "/*% nocomment rexx */ thingy, and I have to guess at what it does.
But surely it does something about ignoring the comments during
processing,
which confuses me because at execution time REXX does that
anyway...doesn't
it?
<SNIPPAGE>

Take a look at TSO/E REXX Reference SA22-7790-09 and search for
%nocomment.

I hadn't read that part of the manual before either, because I didn't
think I needed to read those parts of the manual... So much for
assumptions.

Regards,
Steve Thompson

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX

I think I am the one that mentioned the nocomment thingy.  But as I read more about this compression feature, I have a feeling that it may be tied to VLF (Virtual Lookaside Facility) based on this link.

http://publib.boulder.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.ikjb600%2Ffilec.htm

Regards,
John K

-----TSO REXX Discussion List <TSO-REXX@vm.marist.edu> wrote: -----
To: TSO-REXX@vm.marist.edu
From: Bob Bridges 
Sent by: TSO REXX Discussion List 
Date: 03/11/2013 04:11PM
Subject: Re: [TSO-REXX] Tuning Question (% NOCOMMENT REXX)

I'm just catching up with this discussion, and I've marked a lot of places
to ask additional questions.  This is one of them:  I've never known about
this "/*% nocomment rexx */ thingy, and I have to guess at what it does.
But surely it does something about ignoring the comments during processing,
which confuses me because at execution time REXX does that anyway...doesn't
it?

If it helps, understand that I've never used the compiler; my experience is
entirely with interpreted TSO-REXX.

---
Bob Bridges
  rhbridg@attglobal.net, cell 336 382-7313
  bbridges-vendor@foodlion.com, 704 310-4526

/* On the international front, President Bush and Russian President Vladimir
Putin sign an arms-reduction treaty under which the U.S. will destroy about
two-thirds of its nuclear arsenal, and Russia will ''make every effort,
within reason'' to try to find out who, exactly, HAS its nuclear arsenal.
-from Dave Barry's 2002 "Year in Review" */

-----Original Message-----
From: Andreas Fischer
Sent: Wednesday, February 27, 2013 04:44

* as it has been mentioned, i use /*% nocomment rexx */ in the first line

----------------------------------------------------------------------


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX