Bat file that executes itself as a REXX program

[Swifty]

I've written a BAT file which executes itself as a REXX program by
coding it as follows:

REM /*
@echo off
set BAT_PATH=%~s0
title This is the %BAT_PATH% file's doing
cls
rexx.exe %BAT_PATH% %*
goto stop
*/
Trace ?r
Say 'This came from the rexx code'
/*
:stop
REM */

The incentive was to find a way to automatically set the window title,
as the "title" command seems ineffective from inside REXX code...

This all works neatly, apart from the fact that the BAT processor echoes
the "REM /*" line to the console (hence the "cls" command to make it
dissapear)

If I move the "@echo off" line up, then REXX barfs on the "@"

Is there some way to tidy this up?

--
Steve Swift
http://www.swiftys.org.uk/

[Arthur T.]

In Message-ID:<k8chmp$v0q$1...@speranza.aioe.org>,

Swifty <steve....@gmail.com> wrote:

>I've written a BAT file which executes itself as a REXX program by
>coding it as follows:
>
> REM /*
> @echo off
> set BAT_PATH=%~s0
> title This is the %BAT_PATH% file's doing
> cls
> rexx.exe %BAT_PATH% %*
> goto stop
> */
> Trace ?r
> Say 'This came from the rexx code'
> /*
> :stop
> REM */
>

<snip>

>If I move the "@echo off" line up, then REXX barfs on the "@"

In what way does it barf? In Regina a program with just that
@echo line works fine.

--
Arthur T. - ar23hur "at" intergate "dot" com

[Gil Barmwater]

I worked on this issue almost 15 years ago and ran into similar
problems. One (ugly) way around it is to add enough backspace
characters on the first line - REM /* - so that the line is displayed as
a blank line instead. I also wrote some REXX code to determine the
cursor position on the screen and then reposition it to where the REM
was displayed and overwrote it. Way too complicated!

Gil B.

[Shmuel Metz]

In <k8chmp$v0q$1...@speranza.aioe.org>, on 11/19/2012

at 05:56 AM, Swifty <steve....@gmail.com> said:

>I've written a BAT file which executes itself as a REXX program

For what REXX interpreter?

>by coding it as follows:

> REM /*
> @echo off

Doesn't REXX require a comment on the first line, not just the
beginning of one?

>If I move the "@echo off" line up, then REXX barfs on the "@"

Is it interpreted as REXX or as BAT? If REXX, why? What does it do
with this code?

@echo off /*
REM */


--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Gil Barmwater]

Shmuel (Seymour J.) Metz wrote:
> In <k8chmp$v0q$1...@speranza.aioe.org>, on 11/19/2012
> at 05:56 AM, Swifty <steve....@gmail.com> said:
>
>
>>I've written a BAT file which executes itself as a REXX program
>
>
> For what REXX interpreter?
>
>
>>by coding it as follows:
>
>
>> REM /*
>> @echo off
>
>
> Doesn't REXX require a comment on the first line, not just the
> beginning of one?
>

No, not on any of the PC interpreters with which I'm familiar; it is a
convention, a holdover from the early mainframe Rexx days. The first
line is interpreted by the .BAT processor - CMD - as a REMark and then,
again, by the Rexx interpreter as a COMMAND which gets passed to CMD
where it does nothing. Try REM whatever at a command prompt to see what
happens for this case.

[Gerard_Schildberger]

Well, one way would be to change the 1st statement:

@rem /*

--- which works for Regina, PC/REXX, and R4. _______ Gerard Schildberger

[Shmuel Metz]

In <k8dig9$c5f$1...@speranza.aioe.org>, on 11/19/2012

at 10:16 AM, Gil Barmwater <gbarm...@alum.rpi.edu> said:

>No, not on any of the PC interpreters with which I'm familiar;

What does the ANSI standard say?

[LesK]

On 11/19/2012 4:36 PM, Shmuel (Seymour J.) Metz wrote:
> In <k8dig9$c5f$1...@speranza.aioe.org>, on 11/19/2012
> at 10:16 AM, Gil Barmwater <gbarm...@alum.rpi.edu> said:
>
>> No, not on any of the PC interpreters with which I'm familiar;
>
> What does the ANSI standard say?
>

As far as I can tell, it's silent on the subject. *nix requires the #!
to point to the interpreter (see below). TSO etc. require /* REXX */ and
CMS requires /* so it can differentiate between Rexx/EXEC/EXEC2, since
the files all share the filetype EXEC.

A lot of the ooRexx samples start with:

#!/usr/bin/rexx


--

Les (Change Arabic to Roman to email me)

[Swifty]

On 19/11/2012 06:19, Arthur T. wrote:
> In what way does it barf?

If I place "@echo off" as the first line of a BAT file, and then cause
the BAT file to run the file as a REXX program, then oorexx complains
about an "Illegal character" and it doesn't start execution.

So it's a complete non-starter

[Swifty]

On 19/11/2012 14:06, Gil Barmwater wrote:
> Way too complicated!

Indeed. It was fine as an intellectual exercise, but I'd been planning
on using the technique routinely. It's too intrusive for that.

[Swifty]

On 19/11/2012 20:27, Gerard_Schildberger wrote:
> Well, one way would be to change the 1st statement:
>
> @rem /*

oorexx fails instantly when it find an "@" in the code:

Error 13 running E:\temp\t1.bat line 1: Invalid character in program
Error 13.1: Incorrect character in program "@" ('40'X)

This is why I started with the line:

REM /*
... which means that REXX ignores the rest of the BAT code.

It's lucky that Windows implements REM as a valid command.

[LesK]

On 11/20/2012 1:14 AM, Swifty wrote:
> On 19/11/2012 06:19, Arthur T. wrote:
>> In what way does it barf?
>
> If I place "@echo off" as the first line of a BAT file, and then cause
> the BAT file to run the file as a REXX program, then oorexx complains
> about an "Illegal character" and it doesn't start execution.
>
> So it's a complete non-starter
>

I think that's an ooRexx bug. You should report it on SF. I did the
similar test after creating a file @les.rex. Now I can't execute it by
default!

[Shmuel Metz]

In <k8fpc8$vmj$1...@speranza.aioe.org>, on 11/20/2012

at 06:26 AM, LesK <5mr...@tampabay.rr.com> said:

>I think that's an ooRexx bug.

While symbols containing national characters (#, $, @) were valid in
VM/SP CMS and TSO/E, they are not valid in the OS/2 Object REXX[1]
that OOREXX is based on.

BTW, is there any reason not to split the code into separate BAT and
REXX files?

[1] Or SAA REXX, for that matter.

[Shmuel Metz]

In <k8ehia$e0b$1...@speranza.aioe.org>, on 11/19/2012

at 07:07 PM, LesK <5mr...@tampabay.rr.com> said:

>As far as I can tell, it's silent on the subject. *nix requires
>the #! to point to the interpreter (see below).

OS/2 uses EXTPROC as an equivalent to the *ix shebang.

>TSO etc. require /* REXX */

That hasn't been true for decades. Anything found in SYSEXEC is
treated as REXX, the EXEC command recognizes the file type CLIST and
EXEC and the EXEC command has CLIST and EXEC keywords.

>and CMS requires /* so it can differentiate between
>Rexx/EXEC/EXEC2, since the files all share the filetype EXEC.

That's a funny way to spell XEDIT (-;

For those not familar with CMS, the System Product Editor supports
REXX macros with a file type of XEDIT.

[LesK]

On 11/20/2012 8:42 AM, Shmuel (Seymour J.) Metz wrote:
> In <k8fpc8$vmj$1...@speranza.aioe.org>, on 11/20/2012
> at 06:26 AM, LesK <5mr...@tampabay.rr.com> said:
>
>> I think that's an ooRexx bug.
>
> While symbols containing national characters (#, $, @) were valid in
> VM/SP CMS and TSO/E, they are not valid in the OS/2 Object REXX[1]
> that OOREXX is based on.
>
> BTW, is there any reason not to split the code into separate BAT and
> REXX files?
>
> [1] Or SAA REXX, for that matter.
>

That's the problem: ooRexx thinks it's a symbol, but it's not. It's a
command!

[LesK]

On 11/20/2012 8:16 AM, Shmuel (Seymour J.) Metz wrote:
> In <k8ehia$e0b$1...@speranza.aioe.org>, on 11/19/2012
> at 07:07 PM, LesK <5mr...@tampabay.rr.com> said:
>
>> As far as I can tell, it's silent on the subject. *nix requires
>> the #! to point to the interpreter (see below).
>
> OS/2 uses EXTPROC as an equivalent to the *ix shebang.
>
>> TSO etc. require /* REXX */
>
> That hasn't been true for decades. Anything found in SYSEXEC is
> treated as REXX, the EXEC command recognizes the file type CLIST and
> EXEC and the EXEC command has CLIST and EXEC keywords.
>

Interesting! That's not what I found the last time I looked at the
online manuals.

>> and CMS requires /* so it can differentiate between
>> Rexx/EXEC/EXEC2, since the files all share the filetype EXEC.
>
> That's a funny way to spell XEDIT (-;
>

Good one! :-)) If memory serves, there are a couple of other filetypes
that are tri-lingual... maybe GCS? But I never worked with any of them,
so my memory is quite hazy.

> For those not familar with CMS, the System Product Editor supports
> REXX macros with a file type of XEDIT.
>


--

[Shmuel Metz]

In <k8gnes$eno$1...@speranza.aioe.org>, on 11/20/2012

at 03:00 PM, LesK <5mr...@tampabay.rr.com> said:

>Interesting! That's not what I found the last time I looked at
>the online manuals.

What manuals? In z/OS TSO/E REXX Reference, Document Number
SA22-7790-08, I see

2.1.3 Tokens

...

Symbols:
Symbols are groups of characters, selected from the:

English alphabetic characters (A-Z and a-z (1))
Numeric characters (0-9)
Characters @ # $ ¢ . ! (2) ? and underscore.
Double-Byte Character Set (DBCS) characters
(X'41'-X'FE')--ETMODE must be in effect for these
characters
to be valid in symbols.

Any lowercase alphabetic character in a symbol is
translated to
uppercase (that is, lowercase a-z to uppercase A-Z)
before use.

>Good one! :-)) If memory serves, there are a couple of other
>filetypes that are tri-lingual... maybe GCS?

I don't know whether GCS supports EXEC or EXEC2, but under CMS it is
common for an application to use REXX as a scripting language, with
its own filetype for macros.

[Shmuel Metz]

In <k8gmtp$cua$1...@speranza.aioe.org>, on 11/20/2012

at 02:50 PM, LesK <5mr...@tampabay.rr.com> said:

>That's the problem: ooRexx thinks it's a symbol, but it's not. It's a
> command!

REXX deals with expressions and environments, not with commands. You
need a different mindset from what is appropriate for bash or BAT.

[Swifty]

On 20/11/2012 13:42, Shmuel (Seymour J.) Metz wrote:
> BTW, is there any reason not to split the code into separate BAT and
> REXX files?

My reason is that I would end up with two files to maintain. Also, using
up 2 4K blocks in my filesystem!

Having two files to maintain might seem trivial, but I'm having
short-term memory problems. If I'm editing a single file, containing two
functions, I can hold that in memory OK. But once the functions are
separated into two files, the transition between the two files in my
editor is just about sufficient for me to be left wondering "Now why did
I come here?".

Incidentally, I've been doing this for years. I write webpages that
process user input via CGI. I started by writing the webpage as an HTML
FORM, and handling the POST data with a REXX script. Then I realised
that building the webpage from the same CGI script that handles the POST
data would usually simplify things. Now, it's become a habit, keeping
the related stuff all in one place. For example, I keep all my tools in
the same tool chest, rather than having one chest for the hammers, and
another for the screwdrivers... :-)

[CyberSimian]

Swifty wrote

> This is why I started with the line:
> REM /*
> ... which means that REXX ignores the rest of the BAT code.
> It's lucky that Windows implements REM as a valid command.

Before REXX became part of VM/CMS, users who wanted to write REXX execs
had to install the REXX processor into their execution environment (typically
done in "PROFILE EXEC"). I suspect that what this did was to create a nucleus
extension called "EXEC", so that when the operating system looked for a
program called "EXEC" to interpret a user exec file (in response to the user
typing the name of his exec file on the command line), the OS found the
nucleus extension instead of the real EXEC1 processor.

In the nucleus extension, REXX had a non standard fix-up that caused it to
treat the first line as a comment if the line began with:

*/*

What did this do? Well, it allowed bilingual execs to be written. In the
EXEC1 language, lines beginning with a "*" character were treated as comment
lines, and ignored. If a tool writer wanted a tool written in REXX to be
usable by people who had NOT installed REXX into their execution environment,
the tool writer would put something like the following at the start of the
exec:

*/*
REXX INSTALL
EXEC &0 &1 &2 &3 &4 &5 &6 &7 &8 &9
&exit &retcode
*/
...the actual REXX code for the tool goes here...
exit rc

If invoked in an environment without REXX installed, the EXEC1 interpreter
would get invoked. EXEC1 would see the first line as a comment, and would
execute lines 2-4. Line 2 installs REXX into the environment, line 3 then
re-invokes the exec (but this time REXX will get invoked instead of EXEC1),
and line 4 exits with the return code.

If invoked with REXX already installed, REXX special-cases the first line and
treats it as the start of a comment, which is not ended until line 5. Result:
the EXEC1 lines are ignored by REXX, and REXX sees only the subsequent REXX
lines.

To get a similar effect on Windows, you need a BAT statement that does not
produce any output on the screen, and which is capable of being subverted
(i.e. is valid REXX). Although lines beginning with the "@" character do not
produce any output, they are not valid REXX. Hence, the only way to enable
bilingual BAT files is to include a non-standard fix-up into the ooRexx
interpreter, for example by treating:

REM /*

as the start of a REXX comment if found on the first line of a BAT file. Would
the ooRexx maintainers be amenable to such a change? Ask them!

-- from CyberSimian in the UK

[LesK]

On 11/20/2012 8:50 PM, Shmuel (Seymour J.) Metz wrote:
> In <k8gmtp$cua$1...@speranza.aioe.org>, on 11/20/2012
> at 02:50 PM, LesK <5mr...@tampabay.rr.com> said:
>
>> That's the problem: ooRexx thinks it's a symbol, but it's not. It's a
>> command!
>
> REXX deals with expressions and environments, not with commands. You
> need a different mindset from what is appropriate for bash or BAT.
>

My mindset is correct, since I know next to nothing about bash or BAT.
By definition, anything Rexx doesn't understand gets passed to the
underlying system to be handled as a command. I think what we're seeing
is a bug because this rule isn't being applied during verification.

[LesK]

On 11/20/2012 9:01 PM, Shmuel (Seymour J.) Metz wrote:
> In <k8gnes$eno$1...@speranza.aioe.org>, on 11/20/2012
> at 03:00 PM, LesK <5mr...@tampabay.rr.com> said:
>
>> Interesting! That's not what I found the last time I looked at
>> the online manuals.
>
> What manuals? In z/OS TSO/E REXX Reference, Document Number
> SA22-7790-08, I see
>
> 2.1.3 Tokens
>
> ...
>
> Symbols:
> Symbols are groups of characters, selected from the:
>
> English alphabetic characters (A-Z and a-z (1))
> Numeric characters (0-9)

> Characters @ # $ � . ! (2) ? and underscore.

> Double-Byte Character Set (DBCS) characters
> (X'41'-X'FE')--ETMODE must be in effect for these
> characters
> to be valid in symbols.
>
> Any lowercase alphabetic character in a symbol is
> translated to
> uppercase (that is, lowercase a-z to uppercase A-Z)
> before use.
>

The discussion was about /* REXX */ being required, not valid characters
in symbols!

>> Good one! :-)) If memory serves, there are a couple of other
>> filetypes that are tri-lingual... maybe GCS?
>
> I don't know whether GCS supports EXEC or EXEC2, but under CMS it is
> common for an application to use REXX as a scripting language, with
> its own filetype for macros.
>


--

[Glenn Knickerbocker]

On 11/21/2012 12:36 PM, LesK wrote:
> By definition, anything Rexx doesn't understand gets passed to the
> underlying system to be handled as a command.

No, only things that Rexx understands and can interpret as expressions
get passed as commands. Anything Rexx doesn't understand raises a
syntax error. You'd get the exact same error from this program on VM:

/**/ ~les

ŹR

[LesK]

Well, I tried to simplify the whole logical process of determining that
what Rexx is seeing is just an expression. My bad.

That's an interesting example. I think that perhaps if I had ~LES FURKY
EXECLOADed as an EXEC, the error might not occur, but I don't have the
time to try it.

[LesK]

That brings back LOTS of memories of the days of early Rex! I used that
trick a lot to make Rex available to users on the RALVM8 system where I
had a widely linked tools disk created from Capek's VM Newsletter items.

Maybe Jonathan's solution on the other thread would work as a PUBLIC
routine?

[Swifty]

On 21/11/2012 12:13, CyberSimian wrote:
> the only way to enable
> bilingual BAT files is to include a non-standard fix-up into the ooRexx
> interpreter, for example by treating:
>
> REM /*
>
> as the start of a REXX comment if found on the first line of a BAT file.

This is exactly what I was doing. Unfortunately, a BAT file with a "REM"
statement in its' first line will always echo that first line to the
console, as such echoing is the default behaviour.

So, the REM statement fails the requirement: "you need a BAT statement

that does not produce any output on the screen"

Unfortunately, the only BAT statement that I know of which satisfied
that requirement is "@echo off", but that statement is instant death to
an ooRexx program.

This all came about because I wanted to find a way to set the Window
title from REXX running in a command prompt window. Jonathan Hosking
provided a "pure ooRexx" example using WinSystm.cls and the
WindowsManager~ConsoleTitle=title statement.

So, from my perspective, this thread is now just for intellectual curiosity.

[Shmuel Metz]

In <k8j3dt$7ff$1...@speranza.aioe.org>, on 11/21/2012
at 12:36 PM, LesK <5mr...@tampabay.rr.com> said:

>My mindset is correct,

Mot even close.

>By definition, anything Rexx doesn't understand gets passed to the
>underlying system to be handled as a command

Not even close; anything REXX doesn't understand is flagged as an
error. A valid REXX statement is either a keyword statement or an
expression. REXX evaluates expression statements and passes the
results to the current environment.

>I think what we're seeing is a bug because this rule isn't being
>applied during verification.

The "rule" has nothing to do with REXX.

[Shmuel Metz]

In <k8j3oq$87r$1...@speranza.aioe.org>, on 11/21/2012

at 12:42 PM, LesK <5mr...@tampabay.rr.com> said:

>The discussion was about /* REXX */ being required, not valid
>characters in symbols!

Sorry, I was thinking of the question of @ being allowed in symbols
for CMS and TSO. The correct references are z/OS TSO/E Command
Reference, SA22-7782-11, 1.15 EXEC command:

CLIST | EXEC
specifies whether a CLIST or an exec is to be run. To fully
qualify the data set name, the EXEC command adds the suffix
CLIST or EXEC to the data set name. For more information
about these operands, including what happens when you omit
the parameter, see "Using the explicit form of the EXEC
command" in topic 1.15.4.

CLIST specifies that a CLIST is to be run.

EXEC specifies that an exec is to be run.

and z/OS TSO/E REXX Reference, SA22-7790-08, 2.0 Chapter 2. REXX
general concepts

You can call an exec implicitly by entering the member name of the
exec.
You can call an exec implicitly only if the PDS in which the exec
is
stored has been allocated to a system file (SYSPROC or SYSEXEC).
SYSEXEC
is a system file whose data sets can contain REXX execs only.
SYSPROC is a
system file whose data sets can contain either CLISTs or REXX
execs. If an
exec is in a data set that is allocated to SYSPROC, the exec must
start
with a comment containing the characters "REXX" within the first
line
(line 1). This enables the TSO/E EXEC command to distinguish a REXX
exec
from a CLIST. For more information, see "Structure and general
syntax" in
topic 2.1.

See also 14.15.6 Using SYSPROC and SYSEXEC for REXX execs.

[Shmuel Metz]

In <k8ji0m$eei$1...@speranza.aioe.org>, on 11/21/2012

at 04:45 PM, LesK <5mr...@tampabay.rr.com> said:

>Well, I tried to simplify the whole logical process of
>determining that what Rexx is seeing is just an expression.

Except that @echo is not an expression in the REXX propcessors under
discussion, only in the CMS and TSO/E REXX processors.

[LesK]

On 11/22/2012 9:10 AM, Shmuel (Seymour J.) Metz wrote:
> In <k8j3oq$87r$1...@speranza.aioe.org>, on 11/21/2012
> at 12:42 PM, LesK <5mr...@tampabay.rr.com> said:
>
>> The discussion was about /* REXX */ being required, not valid
>> characters in symbols!
>
> Sorry, I was thinking of the question of @ being allowed in symbols
> for CMS and TSO. The correct references are z/OS TSO/E Command
> Reference, SA22-7782-11, 1.15 EXEC command:
>

No problem! My brain has cross-threaded more than I can remember.

So the safe thing to do is to always use /* REXX */ and not be concerned
about where someone might put your code some day on some system.

This link:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKJ3C302/1.2.2?SHELF=IKJOSE10&DT=19990113130034

might be out of date, but it's the one that I originally got my TSO/E
info from.

[Gerard_Schildberger]

On Thursday, November 22, 2012 9:31:45 AM UTC-6, Seymour J. Shmuel Metz wrote:
> on 11/21/2012 at 04:45 PM, LesK <5mr...@tampabay.rr.com> said:

>>Well, I tried to simplify the whole logical process of
>>determining that what Rexx is seeing is just an expression.

> Except that @echo is not an expression in the REXX propcessors under
> discussion, only in the CMS and TSO/E REXX processors.
> --
> Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

@echo is also an expression in PC/REXX, Personal REXX, Regina, R4, and
ROO (ROO!), and maybe others. ______________________ Gerard Schildberger

[Shmuel Metz]

In <k8lpnv$kei$1...@speranza.aioe.org>, on 11/22/2012
at 01:09 PM, LesK <5mr...@tampabay.rr.com> said:

>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKJ3C302/1.2.2?SHELF=IKJOSE10&DT=19990113130034

Read it carefully.

1.2.2 What is a REXX Exec?

Note that this simple exec starts with a comment line to identify the
program as a REXX exec. A comment begins with /* and ends with */. To
prevent incompatibilities with CLISTs, IBM recommends that all REXX
execs start with a comment that includes the characters "REXX" within
the first line (line 1) of the exec. Failure to do so can lead to
unexpected or unintended results in your REXX exec. More about
comments and why you might need a REXX exec identifier appears later
in topic 1.2.3.3.4.

1.2.5.2 Running an Exec Implicitly

SYSPROC is a system file whose data sets can contain both CLISTs and
execs. (Execs are distinguished from CLISTs by the REXX exec
identifier, a comment at the beginning of the exec the first line of
which includes the word "REXX".) SYSEXEC is a system file whose data
sets can contain only execs. (Your installation might have changed the
name to something other than SYSEXEC, but for the purposes of this
book, we will call it SYSEXEC.

[LesK]

On 11/22/2012 5:23 PM, Shmuel (Seymour J.) Metz wrote:
> In <k8lpnv$kei$1...@speranza.aioe.org>, on 11/22/2012
> at 01:09 PM, LesK <5mr...@tampabay.rr.com> said:
>
>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKJ3C302/1.2.2?SHELF=IKJOSE10&DT=19990113130034
>
> Read it carefully.
>
> 1.2.2 What is a REXX Exec?
>
> Note that this simple exec starts with a comment line to identify the
> program as a REXX exec. A comment begins with /* and ends with */. To
> prevent incompatibilities with CLISTs, IBM recommends that all REXX
> execs start with a comment that includes the characters "REXX" within
> the first line (line 1) of the exec. Failure to do so can lead to
> unexpected or unintended results in your REXX exec. More about
> comments and why you might need a REXX exec identifier appears later
> in topic 1.2.3.3.4.
>
> 1.2.5.2 Running an Exec Implicitly
>
> SYSPROC is a system file whose data sets can contain both CLISTs and
> execs. (Execs are distinguished from CLISTs by the REXX exec
> identifier, a comment at the beginning of the exec the first line of
> which includes the word "REXX".) SYSEXEC is a system file whose data
> sets can contain only execs. (Your installation might have changed the
> name to something other than SYSEXEC, but for the purposes of this
> book, we will call it SYSEXEC.
>

I did read it carefully and it agrees with my earlier post about being
safe. What do you think I missed?

[Shmuel Metz]

In <k8mbq5$12n$1...@speranza.aioe.org>, on 11/22/2012

at 06:18 PM, LesK <5mr...@tampabay.rr.com> said:

>I did read it carefully and it agrees with my earlier post about
>being safe.

The issue is not being safe; the issue is whether the /* REXX */ is
necessary.

[LesK]

On 11/23/2012 11:27 AM, Shmuel (Seymour J.) Metz wrote:
> In <k8mbq5$12n$1...@speranza.aioe.org>, on 11/22/2012
> at 06:18 PM, LesK <5mr...@tampabay.rr.com> said:
>
>> I did read it carefully and it agrees with my earlier post about
>> being safe.
>
> The issue is not being safe; the issue is whether the /* REXX */ is
> necessary.
>

IBM's advice is to always code it.
Your advice is to only code it if it's necessary, irrespective of what
the future might hold.
Should it be removed if not necessary?

[Glenn Knickerbocker]

On Wed, 21 Nov 2012 16:45:35 -0500, LesK wrote:
>That's an interesting example. I think that perhaps if I had ~LES FURKY
>EXECLOADed as an EXEC, the error might not occur, but I don't have the
>time to try it.

Nope. Rexx never gets to the point of trying it as a command (or doing
anything else), because it gives up trying to interpret the program.

ŹR / Darla: Leftovers aren't the mark of a man. \ www.bestweb.net/~notr
Andrew Reid: Actually, they are, because that's how men's shirts button.

[Shmuel Metz]

In <k8osig$rlf$1...@speranza.aioe.org>, on 11/23/2012

at 05:16 PM, LesK <5mr...@tampabay.rr.com> said:

>IBM's advice is to always code it.

The issue is not advice, it is requirements.

>Your advice

Had I meant to give advise I would have done so. Please do not your
words to me.

>Should it be removed if not necessary?

It's not my dog.