Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
FINALLY got OOREXX working under Ubuntu!!
267 views
Skip to first unread message
Jaime Cruz
Sep 18, 2012, 7:49:24 AM9/18/12
to
I see the secret is the !# line indicating where the REXX interpreter
lives. Why isn't it smart enough to recognize the "/*" in the first line
like just about every other platform??
Also, I had to use SysAddRexxMacro to define all of the external
functions even though the directory in which they all reside is defined
in the $PATH variable.
Finally, does the .deb package also install the documentation? If so,
where did it put it??
Thanks,
--
Jaime A. Cruz
Secretary
Nassau Wings Motorcycle Club
http://www.nassauwings.org/
AMA District 34
http://www.AMADistrict34.com/
Pop's Run
http://www.popsrun.org/
lives. Why isn't it smart enough to recognize the "/*" in the first line
like just about every other platform??
Also, I had to use SysAddRexxMacro to define all of the external
functions even though the directory in which they all reside is defined
in the $PATH variable.
Finally, does the .deb package also install the documentation? If so,
where did it put it??
Thanks,
--
Jaime A. Cruz
Secretary
Nassau Wings Motorcycle Club
http://www.nassauwings.org/
AMA District 34
http://www.AMADistrict34.com/
Pop's Run
http://www.popsrun.org/
Jeremy Nicoll - news posts
Sep 18, 2012, 8:17:36 AM9/18/12
to
Jaime Cruz <Spam...@Bite.Me> wrote:
>I see the secret is the !# line indicating where the REXX interpreter
>lives. Why isn't it smart enough to recognize the "/*" in the first line
>like just about every other platform??
Presumably because in Linux/Unix it's the OS that reads the !# thing and
>I see the secret is the !# line indicating where the REXX interpreter
>lives. Why isn't it smart enough to recognize the "/*" in the first line
>like just about every other platform??
then invokes the right language processor. That is, it's not ooREXX that
makes that decision.
Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS, which rely
on the location of the file. Which platform did you have in mind?
>Also, I had to use SysAddRexxMacro to define all of the external
>functions even though the directory in which they all reside is defined
>in the $PATH variable.
out by Linux's case-sensitive file names? That is, the thing you invoke in
the REXX program has to be spelled exactly the same way as the external
filename (I think) though maybe an all-lowercase name works regardless.
It might be worth checking that the value of PATH that the rexx exec sees is
what you think it is; in Windows one can use:
say value("PATH",,"ENVIRONMENT")
to find that out; I'm not sure if Linux is the same.
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "aaa" by "284".
Jaime Cruz
Sep 18, 2012, 6:27:07 PM9/18/12
to
Jeremy Nicoll - news posts wrote:
> Jaime Cruz <Spam...@Bite.Me> wrote:
>
>> I see the secret is the !# line indicating where the REXX interpreter
>> lives. Why isn't it smart enough to recognize the "/*" in the first line
>> like just about every other platform??
>
> Presumably because in Linux/Unix it's the OS that reads the !# thing and
> then invokes the right language processor. That is, it's not ooREXX that
> makes that decision.
>
> Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS, which rely
> on the location of the file. Which platform did you have in mind?
>
>
>> Also, I had to use SysAddRexxMacro to define all of the external
>> functions even though the directory in which they all reside is defined
>> in the $PATH variable.
>
> There's REXX_PATH too, but both should work I think. Are you being caught
> out by Linux's case-sensitive file names? That is, the thing you invoke in
> the REXX program has to be spelled exactly the same way as the external
> filename (I think) though maybe an all-lowercase name works regardless.
>
> It might be worth checking that the value of PATH that the rexx exec sees is
> what you think it is; in Windows one can use:
>
> say value("PATH",,"ENVIRONMENT")
>
> to find that out; I'm not sure if Linux is the same.
>
>
echo $PATH
> Jaime Cruz <Spam...@Bite.Me> wrote:
>
>> I see the secret is the !# line indicating where the REXX interpreter
>> lives. Why isn't it smart enough to recognize the "/*" in the first line
>> like just about every other platform??
>
> Presumably because in Linux/Unix it's the OS that reads the !# thing and
> then invokes the right language processor. That is, it's not ooREXX that
> makes that decision.
>
> Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS, which rely
> on the location of the file. Which platform did you have in mind?
>
>
>> Also, I had to use SysAddRexxMacro to define all of the external
>> functions even though the directory in which they all reside is defined
>> in the $PATH variable.
>
> There's REXX_PATH too, but both should work I think. Are you being caught
> out by Linux's case-sensitive file names? That is, the thing you invoke in
> the REXX program has to be spelled exactly the same way as the external
> filename (I think) though maybe an all-lowercase name works regardless.
>
> It might be worth checking that the value of PATH that the rexx exec sees is
> what you think it is; in Windows one can use:
>
> say value("PATH",,"ENVIRONMENT")
>
> to find that out; I'm not sure if Linux is the same.
>
>
Shows the REXX directory is in the path... in fact, it's at the very
beginning of the path and spelled exactly as shown. I'll try the
"REXX_PATH" and see if that makes a difference. Didn't know about that one.
OS/2 and PC DOS 7 both recognized the "/*" comment card and invoked the
REXX command processor instead of the standard command shell (CMD.EXE or
COMMAND.COM respectively).
Been awhile since I've used VM/CMS, but I recall that was EXACTLY how it
recognized the difference between an EXEC2 script vs. REXX (which was
EXEC3).
In MVS, however, since the CLIST language also uses "/*" as a comment
delimiter you have to enclose the word "REXX" inside the first comment
line in order for the Terminal Monitor program to recognize it is a REXX
EXEC and not a CLIST.
LesK
Sep 18, 2012, 6:57:15 PM9/18/12
to
On 9/18/2012 8:17 AM, Jeremy Nicoll - news posts wrote:
> Jaime Cruz <Spam...@Bite.Me> wrote:
>
>> I see the secret is the !# line indicating where the REXX interpreter
>> lives. Why isn't it smart enough to recognize the "/*" in the first line
>> like just about every other platform??
>
> Presumably because in Linux/Unix it's the OS that reads the !# thing and
> then invokes the right language processor. That is, it's not ooREXX that
> makes that decision.
>
Unix/Linux are still living in the late 60's/early 70's when resources
> Jaime Cruz <Spam...@Bite.Me> wrote:
>
>> I see the secret is the !# line indicating where the REXX interpreter
>> lives. Why isn't it smart enough to recognize the "/*" in the first line
>> like just about every other platform??
>
> Presumably because in Linux/Unix it's the OS that reads the !# thing and
> then invokes the right language processor. That is, it's not ooREXX that
> makes that decision.
>
were severely restricted. The OS had to be 'mean and lean' to leave
memory for applications. The lack of 'file associations' is just one
side-effect. Another is command 'flags' so that the code to figure out
the options you wanted was minimized. Didn't matter if it required a 100
page Quick Reference to know how to use the command. The other part of
the 'flag' mind set was the slow terminals of the time... often a 33
baud teletype. So the less you had to type for each command, the more
work you could get done in your time slot.
> Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS, which rely
> on the location of the file. Which platform did you have in mind?
>
EXEC is to be interpreted by Rexx. If the first line starts with
&CONTROL then the original EXEC interpreter gets control. If it's &TRACE
then the EXEC2 interpreter gets control. The location of the file means
nothing in VM. It can, in fact, reside in storage and not even be
visible to the file system.
MVS requires the first line to be /* REXX */. I think MVS lets you
define where Rexx code lives.
>
>> Also, I had to use SysAddRexxMacro to define all of the external
>> functions even though the directory in which they all reside is defined
>> in the $PATH variable.
>
> There's REXX_PATH too, but both should work I think. Are you being caught
> out by Linux's case-sensitive file names? That is, the thing you invoke in
> the REXX program has to be spelled exactly the same way as the external
> filename (I think) though maybe an all-lowercase name works regardless.
>
> It might be worth checking that the value of PATH that the rexx exec sees is
> what you think it is; in Windows one can use:
>
> say value("PATH",,"ENVIRONMENT")
>
> to find that out; I'm not sure if Linux is the same.
>
>
--
Les (Change Arabic to Roman to email me)
>> Also, I had to use SysAddRexxMacro to define all of the external
>> functions even though the directory in which they all reside is defined
>> in the $PATH variable.
>
> There's REXX_PATH too, but both should work I think. Are you being caught
> out by Linux's case-sensitive file names? That is, the thing you invoke in
> the REXX program has to be spelled exactly the same way as the external
> filename (I think) though maybe an all-lowercase name works regardless.
>
> It might be worth checking that the value of PATH that the rexx exec sees is
> what you think it is; in Windows one can use:
>
> say value("PATH",,"ENVIRONMENT")
>
> to find that out; I'm not sure if Linux is the same.
>
>
--
Jeremy Nicoll - news posts
Sep 18, 2012, 7:08:26 PM9/18/12
to
Jaime Cruz <Spam...@Bite.Me> wrote:
>Shows the REXX directory is in the path... in fact, it's at the very
>beginning of the path and spelled exactly as shown.
It's the way the function name (which will equal a file's base leafname) is
>Shows the REXX directory is in the path... in fact, it's at the very
>beginning of the path and spelled exactly as shown.
spelled that matters, not the directory name.
>OS/2 and PC DOS 7 both recognized the "/*" comment card and invoked the
>REXX command processor instead of the standard command shell (CMD.EXE or
>COMMAND.COM respectively).
DOS 7, but my recollection for the latter is that rexx execs needed to have
a file extension, eg "bat", or "cmd" or "rex", and - just like Windows now -
that had to be associated with the program that would process the file. Are
you saying that a bat file and a rexx exec could have the same extension and
something would work out which interpreter to use?
>Been awhile since I've used VM/CMS, but I recall that was EXACTLY how it
>recognized the difference between an EXEC2 script vs. REXX (which was
>EXEC3).
have to be "EXEC", for example "MYPROG EXEC A"? So...
>In MVS, however, since the CLIST language also uses "/*" as a comment
>delimiter you have to enclose the word "REXX" inside the first comment
>line in order for the Terminal Monitor program to recognize it is a REXX
>EXEC and not a CLIST.
processor which is started by the OS (and I'm pretty sure it's the same
basic mechanism in VM/CMS). Then the EXEC command processor, not the OS,
reads the first line and decides which language processor to use. For the
file to be loaded by the EXEC cp in the first place, it has to be in SYSPROC
or SYSEXEC (so identified by its location) or in an ALTLIBbed dataset, or
explicitly named as a parameter to an "EXEC datasetname" TSO command.
Jeremy Nicoll - news posts
Sep 18, 2012, 7:23:54 PM9/18/12
to
LesK <5mr...@tampabay.rr.com> wrote:
JN said:
> > Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS, which
> > rely on the location of the file. Which platform did you have in mind?
>VM does recognize the '/*'! That's how it knows a file with the filetype
>EXEC is to be interpreted by Rexx. If the first line starts with
>&CONTROL then the original EXEC interpreter gets control. If it's &TRACE
>then the EXEC2 interpreter gets control. The location of the file means
>nothing in VM.
I really don't believe that that decision is being made by the /OS/, in
contrast with Unix/Linux where any flagged-executable file (in the absence
of filetypes etc) has to be opened and examined to decide what program will
then process it.
I'm sure it's the same as MVS where the exec command processor makes the
decision. But the decision to invoke the exec command processor, against a
file of name "fn EXEC *" is made by the OS's binding of the "EXEC" filetype
with that processor.
I said "location" because in MVS unless you explicitly issue (eg a TSO)
command "EXEC datasetname" the exec has to be in //SYSPROC or //SYSEXEC (or
a logical equivalent). There is (was, anyway, this may have changed) no
way you can execute a CLIST or REXX exec without telling the EXEC command
processor where to find it. In VM/CMS my recollection is it has to be "fn
EXEC *". I don't know how, or if, VM/CMS also supports PDSs or PDSEs; those
didn't exist on the VM/CMS systems I used.
In NetView (under MVS for example) the 'NetView CLISTs' (which include both
those written in something akin to TSO CLIST, and REXX execs) have to be in,
IIRC, //DSICLD.
> It can, in fact, reside in storage and not even be visible to the file
> system.
Even then surely some aspect of loading the file into storage requires the
(systems?) programmer to use a command that's at least specific to EXECs?
Assuming that you're not talking about rolling your own code to invoke the
interpreter you've chosen, pointed at some storage you've also loaded code
into?
JN said:
> > Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS, which
> > rely on the location of the file. Which platform did you have in mind?
>VM does recognize the '/*'! That's how it knows a file with the filetype
>EXEC is to be interpreted by Rexx. If the first line starts with
>&CONTROL then the original EXEC interpreter gets control. If it's &TRACE
>then the EXEC2 interpreter gets control. The location of the file means
>nothing in VM.
contrast with Unix/Linux where any flagged-executable file (in the absence
of filetypes etc) has to be opened and examined to decide what program will
then process it.
I'm sure it's the same as MVS where the exec command processor makes the
decision. But the decision to invoke the exec command processor, against a
file of name "fn EXEC *" is made by the OS's binding of the "EXEC" filetype
with that processor.
I said "location" because in MVS unless you explicitly issue (eg a TSO)
command "EXEC datasetname" the exec has to be in //SYSPROC or //SYSEXEC (or
a logical equivalent). There is (was, anyway, this may have changed) no
way you can execute a CLIST or REXX exec without telling the EXEC command
processor where to find it. In VM/CMS my recollection is it has to be "fn
EXEC *". I don't know how, or if, VM/CMS also supports PDSs or PDSEs; those
didn't exist on the VM/CMS systems I used.
In NetView (under MVS for example) the 'NetView CLISTs' (which include both
those written in something akin to TSO CLIST, and REXX execs) have to be in,
IIRC, //DSICLD.
> It can, in fact, reside in storage and not even be visible to the file
> system.
(systems?) programmer to use a command that's at least specific to EXECs?
Assuming that you're not talking about rolling your own code to invoke the
interpreter you've chosen, pointed at some storage you've also loaded code
into?
Shmuel Metz
Sep 18, 2012, 7:48:55 PM9/18/12
to
In <24OdnQFeqaJTwsXN...@giganews.com>, on 09/18/2012
recognize EXTPROC? Why doesn't OS/2 recognize a shebang?
--
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
at 07:49 AM, Jaime Cruz <Spam...@Bite.Me> said:
>I see the secret is the !# line indicating where the REXX interpreter
> lives. Why isn't it smart enough to recognize the "/*" in the first
>line like just about every other platform??
Because it isn't integrated into the shell. Why doesn't Linux
>I see the secret is the !# line indicating where the REXX interpreter
> lives. Why isn't it smart enough to recognize the "/*" in the first
>line like just about every other platform??
recognize EXTPROC? Why doesn't OS/2 recognize a shebang?
--
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
Shmuel Metz
Sep 18, 2012, 7:52:49 PM9/18/12
to
In <mpro.majotb...@wingsandbeaks.org.uk.invalid>, on
09/18/2012
at 01:17 PM, Jeremy Nicoll - news posts
z/VM the first line indicates whether a script is in EXEC, EXEC2 or
REXX, and in TSO/E the first line in any version of MVS supporting
REXX indicates whether a script from SYSPROC is in CLIST or REXX.
09/18/2012
at 01:17 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS,
Untrue. I can't speak to what windoze recognizes, but in VM/SP through
>Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS,
z/VM the first line indicates whether a script is in EXEC, EXEC2 or
REXX, and in TSO/E the first line in any version of MVS supporting
REXX indicates whether a script from SYSPROC is in CLIST or REXX.
Jeremy Nicoll - news posts
Sep 18, 2012, 8:29:34 PM9/18/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>In <mpro.majotb...@wingsandbeaks.org.uk.invalid>, on
>09/18/2012
> at 01:17 PM, Jeremy Nicoll - news posts
><jn.nntp....@wingsandbeaks.org.uk> said:
>
>>Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS,
>
>Untrue. I can't speak to what windoze recognizes, but in VM/SP through
>z/VM the first line indicates whether a script is in EXEC, EXEC2 or
>REXX, and in TSO/E the first line in any version of MVS supporting
>REXX indicates whether a script from SYSPROC is in CLIST or REXX.
Yet another person who didn't read what I wrote ;-)
>In <mpro.majotb...@wingsandbeaks.org.uk.invalid>, on
>09/18/2012
> at 01:17 PM, Jeremy Nicoll - news posts
><jn.nntp....@wingsandbeaks.org.uk> said:
>
>>Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS,
>
>Untrue. I can't speak to what windoze recognizes, but in VM/SP through
>z/VM the first line indicates whether a script is in EXEC, EXEC2 or
>REXX, and in TSO/E the first line in any version of MVS supporting
>REXX indicates whether a script from SYSPROC is in CLIST or REXX.
It's NOT MVS that makes the decision, but the EXEC command processor. The
file being in SYSPROC/SYSEXEC is what determines that the EXEC command
processor is called to examine the file.
The OP was asking about something in Unix/Linux - ie an OS - so I answered
in terms of the OS.
Cruz, Jaime
Sep 18, 2012, 8:42:19 PM9/18/12
to
Jeremy Nicoll - news posts wrote:
> Jaime Cruz <Spam...@Bite.Me> wrote:
>
>> I see the secret is the !# line indicating where the REXX interpreter
>> lives. Why isn't it smart enough to recognize the "/*" in the first line
>> like just about every other platform??
>
> Presumably because in Linux/Unix it's the OS that reads the !# thing and
> then invokes the right language processor. That is, it's not ooREXX that
> makes that decision.
>
> Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS, which rely
> on the location of the file. Which platform did you have in mind?
>
>
>> Also, I had to use SysAddRexxMacro to define all of the external
>> functions even though the directory in which they all reside is defined
>> in the $PATH variable.
>
> There's REXX_PATH too, but both should work I think. Are you being caught
> out by Linux's case-sensitive file names? That is, the thing you invoke in
> the REXX program has to be spelled exactly the same way as the external
> filename (I think) though maybe an all-lowercase name works regardless.
>
> It might be worth checking that the value of PATH that the rexx exec sees is
> what you think it is; in Windows one can use:
>
> say value("PATH",,"ENVIRONMENT")
>
> to find that out; I'm not sure if Linux is the same.
>
>
REXX_PATH was the secret. Once that was set, I was able to remove all
> Jaime Cruz <Spam...@Bite.Me> wrote:
>
>> I see the secret is the !# line indicating where the REXX interpreter
>> lives. Why isn't it smart enough to recognize the "/*" in the first line
>> like just about every other platform??
>
> Presumably because in Linux/Unix it's the OS that reads the !# thing and
> then invokes the right language processor. That is, it's not ooREXX that
> makes that decision.
>
> Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS, which rely
> on the location of the file. Which platform did you have in mind?
>
>
>> Also, I had to use SysAddRexxMacro to define all of the external
>> functions even though the directory in which they all reside is defined
>> in the $PATH variable.
>
> There's REXX_PATH too, but both should work I think. Are you being caught
> out by Linux's case-sensitive file names? That is, the thing you invoke in
> the REXX program has to be spelled exactly the same way as the external
> filename (I think) though maybe an all-lowercase name works regardless.
>
> It might be worth checking that the value of PATH that the rexx exec sees is
> what you think it is; in Windows one can use:
>
> say value("PATH",,"ENVIRONMENT")
>
> to find that out; I'm not sure if Linux is the same.
>
>
of the calls to SysAddRexxMacro and it still works. Thanks.
Cruz, Jaime
Sep 18, 2012, 8:44:56 PM9/18/12
to
Shmuel (Seymour J.) Metz wrote:
> In <24OdnQFeqaJTwsXN...@giganews.com>, on 09/18/2012
> at 07:49 AM, Jaime Cruz <Spam...@Bite.Me> said:
>
>> I see the secret is the !# line indicating where the REXX interpreter
>> lives. Why isn't it smart enough to recognize the "/*" in the first
>> line like just about every other platform??
>
> Because it isn't integrated into the shell. Why doesn't Linux
> recognize EXTPROC? Why doesn't OS/2 recognize a shebang?
>
I had hoped the rxapi daemon running would somehow hook the system and
> In <24OdnQFeqaJTwsXN...@giganews.com>, on 09/18/2012
> at 07:49 AM, Jaime Cruz <Spam...@Bite.Me> said:
>
>> I see the secret is the !# line indicating where the REXX interpreter
>> lives. Why isn't it smart enough to recognize the "/*" in the first
>> line like just about every other platform??
>
> Because it isn't integrated into the shell. Why doesn't Linux
> recognize EXTPROC? Why doesn't OS/2 recognize a shebang?
>
take care of that. Shows you how much I know.
Cruz, Jaime
Sep 18, 2012, 8:45:39 PM9/18/12
to
Jaime Cruz wrote:
>
> Finally, does the .deb package also install the documentation? If so,
> where did it put it??
>
> Thanks,
>
No one has yet answered this question...
>
> Finally, does the .deb package also install the documentation? If so,
> where did it put it??
>
> Thanks,
>
LesK
Sep 18, 2012, 10:02:09 PM9/18/12
to
On 9/18/2012 7:23 PM, Jeremy Nicoll - news posts wrote:
> LesK <5mr...@tampabay.rr.com> wrote:
>
> JN said:
>
>>> Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS, which
>>> rely on the location of the file. Which platform did you have in mind?
>
>> VM does recognize the '/*'! That's how it knows a file with the filetype
>> EXEC is to be interpreted by Rexx. If the first line starts with
>> &CONTROL then the original EXEC interpreter gets control. If it's &TRACE
>> then the EXEC2 interpreter gets control. The location of the file means
>> nothing in VM.
>
> I really don't believe that that decision is being made by the /OS/, in
> contrast with Unix/Linux where any flagged-executable file (in the absence
> of filetypes etc) has to be opened and examined to decide what program will
> then process it.
>
It really doesn't make much difference exactly where the decision is
> LesK <5mr...@tampabay.rr.com> wrote:
>
> JN said:
>
>>> Windows doesn't "recognise the /*" either. Nor do VM/CMS or MVS, which
>>> rely on the location of the file. Which platform did you have in mind?
>
>> VM does recognize the '/*'! That's how it knows a file with the filetype
>> EXEC is to be interpreted by Rexx. If the first line starts with
>> &CONTROL then the original EXEC interpreter gets control. If it's &TRACE
>> then the EXEC2 interpreter gets control. The location of the file means
>> nothing in VM.
>
> I really don't believe that that decision is being made by the /OS/, in
> contrast with Unix/Linux where any flagged-executable file (in the absence
> of filetypes etc) has to be opened and examined to decide what program will
> then process it.
>
made in CMS. You're running in your own virtual machine and can do
anything non-privileged that you want.
> I'm sure it's the same as MVS where the exec command processor makes the
> decision. But the decision to invoke the exec command processor, against a
> file of name "fn EXEC *" is made by the OS's binding of the "EXEC" filetype
> with that processor.
>
> I said "location" because in MVS unless you explicitly issue (eg a TSO)
> command "EXEC datasetname" the exec has to be in //SYSPROC or //SYSEXEC (or
> a logical equivalent). There is (was, anyway, this may have changed) no
> way you can execute a CLIST or REXX exec without telling the EXEC command
> processor where to find it. In VM/CMS my recollection is it has to be "fn
> EXEC *". I don't know how, or if, VM/CMS also supports PDSs or PDSEs; those
> didn't exist on the VM/CMS systems I used.
>
>
> In NetView (under MVS for example) the 'NetView CLISTs' (which include both
> those written in something akin to TSO CLIST, and REXX execs) have to be in,
> IIRC, //DSICLD.
>
>
>> It can, in fact, reside in storage and not even be visible to the file
>> system.
>
> Even then surely some aspect of loading the file into storage requires the
> (systems?) programmer to use a command that's at least specific to EXECs?
> Assuming that you're not talking about rolling your own code to invoke the
> interpreter you've chosen, pointed at some storage you've also loaded code
> into?
>
by all users, user storage which can be loaded by the user or system
programmer (EXECLOAD command), and accessed disks. There is a reserved
bit for each disk descriptor that tells CMS if the disk contains
executables, thus speeding up the search for them.
Jeremy Nicoll - news posts
Sep 19, 2012, 7:21:06 AM9/19/12
to
"Cruz, Jaime" <Spam...@Bite.Me> wrote:
>Jaime Cruz wrote:
>>
>> Finally, does the .deb package also install the documentation? If so,
>> where did it put it??
>Jaime Cruz wrote:
>>
>> Finally, does the .deb package also install the documentation? If so,
>> where did it put it??
>No one has yet answered this question...
In Windows, it's in the \doc subfolder of the whole app.
Shmuel Metz
Sep 19, 2012, 8:20:35 AM9/19/12
to
In <k3au7k$v3p$1...@speranza.aioe.org>, on 09/18/2012
was faster than 33 baud.
>MVS requires the first line to be /* REXX */.
Only if it comes from SYSPROC or is invoked via the EXEC command. If
it comes from SYSEXEC, it has to be REXX.
at 06:57 PM, LesK <5mr...@tampabay.rr.com> said:
>Unix/Linux are still living in the late 60's/early 70's when
>resources were severely restricted. The OS had to be 'mean and lean'
>to leave memory for applications. The lack of 'file associations' is
>just one side-effect. Another is command 'flags' so that the code to
>figure out the options you wanted was minimized. Didn't matter if it
>required a 100 page Quick Reference to know how to use the command.
>The other part of the 'flag' mind set was the slow terminals of the
>time... often a 33 baud teletype.
ITYM a Teletype® Model 33, which ran at 110 bps. Even the old Model 28
>Unix/Linux are still living in the late 60's/early 70's when
>resources were severely restricted. The OS had to be 'mean and lean'
>to leave memory for applications. The lack of 'file associations' is
>just one side-effect. Another is command 'flags' so that the code to
>figure out the options you wanted was minimized. Didn't matter if it
>required a 100 page Quick Reference to know how to use the command.
>The other part of the 'flag' mind set was the slow terminals of the
>time... often a 33 baud teletype.
was faster than 33 baud.
>MVS requires the first line to be /* REXX */.
it comes from SYSEXEC, it has to be REXX.
Shmuel Metz
Sep 19, 2012, 8:27:33 AM9/19/12
to
In <mpro.makiy2...@wingsandbeaks.org.uk.invalid>, on
09/19/2012
at 12:08 AM, Jeremy Nicoll - news posts
extension can be either BAT or REXX; it's the first line that selects
the interpreter.
>I don't think that's right. Didn't the filetype of a REXX or EXEC2
>file have to be "EXEC", for example "MYPROG EXEC A"?
Yes, if you mean one that you could invoke with just the name. There
were other file types for, e.g., edit macros.
09/19/2012
at 12:08 AM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>I don't know anything about OS/2, and it's been years since I last
>used PC DOS 7, but my recollection for the latter is that rexx execs
>needed to have a file extension, eg "bat", or "cmd" or "rex", and -
>just like Windows now -
>that had to be associated with the program that would process the
>file. Are you saying that a bat file and a rexx exec could have the
>same extension and something would work out which interpreter to use?
I don't know what PC DOS 7 does, but in OS/2 a file with the CMD
>I don't know anything about OS/2, and it's been years since I last
>used PC DOS 7, but my recollection for the latter is that rexx execs
>needed to have a file extension, eg "bat", or "cmd" or "rex", and -
>just like Windows now -
>that had to be associated with the program that would process the
>file. Are you saying that a bat file and a rexx exec could have the
>same extension and something would work out which interpreter to use?
extension can be either BAT or REXX; it's the first line that selects
the interpreter.
>I don't think that's right. Didn't the filetype of a REXX or EXEC2
>file have to be "EXEC", for example "MYPROG EXEC A"?
were other file types for, e.g., edit macros.
Shmuel Metz
Sep 19, 2012, 8:31:22 AM9/19/12
to
In <mpro.makmpa...@wingsandbeaks.org.uk.invalid>, on
09/19/2012
at 01:29 AM, Jeremy Nicoll - news posts
Good guess, but no.
>It's NOT MVS that makes the decision, but the EXEC command
>processor.
What is TSO/E, chopped liver? EXEC is part of MVS.
09/19/2012
at 01:29 AM, Jeremy Nicoll - news posts
Good guess, but no.
>It's NOT MVS that makes the decision, but the EXEC command
>processor.
Jeremy Nicoll - news posts
Sep 19, 2012, 8:38:18 AM9/19/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>In <mpro.makmpa...@wingsandbeaks.org.uk.invalid>, on
>09/19/2012
> at 01:29 AM, Jeremy Nicoll - news posts
><jn.nntp....@wingsandbeaks.org.uk> said:
>>It's NOT MVS that makes the decision, but the EXEC command
>>processor.
>
> What is TSO/E, chopped liver? EXEC is part of MVS.
Come off it, you must know what I mean. The point is that you can't just
>09/19/2012
> at 01:29 AM, Jeremy Nicoll - news posts
><jn.nntp....@wingsandbeaks.org.uk> said:
>>It's NOT MVS that makes the decision, but the EXEC command
>>processor.
>
> What is TSO/E, chopped liver? EXEC is part of MVS.
tell MVS (or TSO) to run an arbitrary file which happens to contain either a
clist or a rexx exec in the way that one could do with an executable file
under Linux.
You have instead explicitly to use a mechanism that already knows the file
is something that the EXEC command processor can execute.
Cruz, Jaime
Sep 19, 2012, 10:47:47 AM9/19/12
to
Shmuel (Seymour J.) Metz wrote:
> I don't know what PC DOS 7 does, but in OS/2 a file with the CMD
> extension can be either BAT or REXX; it's the first line that selects
> the interpreter.
>
In PC DOS 7, REXX EXECs had an extension of .BAT, like any other
> extension can be either BAT or REXX; it's the first line that selects
> the interpreter.
>
COMMAND.COM script. If COMMAND.COM detected the "/*" in the first line,
it transferred control over to the PC DOS version of REXX.EXE to process
the script. Pretty much transparent.
Cruz, Jaime
Sep 19, 2012, 10:52:28 AM9/19/12
to
Jeremy Nicoll - news posts wrote:
> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>
>> In <mpro.makmpa...@wingsandbeaks.org.uk.invalid>, on
>> 09/19/2012
>> at 01:29 AM, Jeremy Nicoll - news posts
>> <jn.nntp....@wingsandbeaks.org.uk> said:
>
>>> It's NOT MVS that makes the decision, but the EXEC command
>>> processor.
>>
>> What is TSO/E, chopped liver? EXEC is part of MVS.
>
> Come off it, you must know what I mean. The point is that you can't just
> tell MVS (or TSO) to run an arbitrary file which happens to contain either a
> clist or a rexx exec in the way that one could do with an executable file
> under Linux.
>
> You have instead explicitly to use a mechanism that already knows the file
> is something that the EXEC command processor can execute.
>
>
You're missing the point, and Seymour has it right. TSO/E is part of
> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>
>> In <mpro.makmpa...@wingsandbeaks.org.uk.invalid>, on
>> 09/19/2012
>> at 01:29 AM, Jeremy Nicoll - news posts
>> <jn.nntp....@wingsandbeaks.org.uk> said:
>
>>> It's NOT MVS that makes the decision, but the EXEC command
>>> processor.
>>
>> What is TSO/E, chopped liver? EXEC is part of MVS.
>
> Come off it, you must know what I mean. The point is that you can't just
> tell MVS (or TSO) to run an arbitrary file which happens to contain either a
> clist or a rexx exec in the way that one could do with an executable file
> under Linux.
>
> You have instead explicitly to use a mechanism that already knows the file
> is something that the EXEC command processor can execute.
>
>
MVS (and you're dating yourself... it's been z/OS for over a decade
now). If you have a REXX EXEC defined to the SYSPROC DD concatenation
for your TSO/E address space and you implicitly execute it from the
READY prompt, the TSO/E Terminal Monitor Program (again, PART of the
z/OS operating system) scans the first line and determines whether or
not it is a CLIST or REXX EXEC and passes control automatically to the
proper command interpreter.
This is no different than OS/2 (eComStation) or PC DOS 7, or z/VM for
that matter.
Shmuel Metz
Sep 19, 2012, 12:31:52 PM9/19/12
to
In <mpro.malkft...@wingsandbeaks.org.uk.invalid>, on
09/19/2012
at 01:38 PM, Jeremy Nicoll - news posts
Yes, you mean that TSO isn't part of MVS, and you're wrong.
>The point is that you can't just tell MVS (or TSO) to run an
>arbitrary file which happens to contain either a clist or a rexx
>exec in the way that one could do with an executable file under
>Linux.
That's *a* point; it has nothing to do with your claim "Windows
doesn't "recognise the /*" either. Nor do VM/CMS or MVS".
>You have instead explicitly to use a mechanism that already knows
>the file is something that the EXEC command processor can execute.
The same is true for Linux; it can only handle files for which it
knows the format. The fact that it recognizes more than three is
irrelevant, as is the fact that one of the formats it recognizes is a
text file with a shebang in the first line.
09/19/2012
at 01:38 PM, Jeremy Nicoll - news posts
Yes, you mean that TSO isn't part of MVS, and you're wrong.
>The point is that you can't just tell MVS (or TSO) to run an
>arbitrary file which happens to contain either a clist or a rexx
>exec in the way that one could do with an executable file under
>Linux.
doesn't "recognise the /*" either. Nor do VM/CMS or MVS".
>You have instead explicitly to use a mechanism that already knows
>the file is something that the EXEC command processor can execute.
knows the format. The fact that it recognizes more than three is
irrelevant, as is the fact that one of the formats it recognizes is a
text file with a shebang in the first line.
Jeremy Nicoll - news posts
Sep 19, 2012, 4:16:58 PM9/19/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>In <mpro.malkft...@wingsandbeaks.org.uk.invalid>, on
>09/19/2012
> at 01:38 PM, Jeremy Nicoll - news posts
><jn.nntp....@wingsandbeaks.org.uk> said:
>
>>Come off it, you must know what I mean.
>
>Yes, you mean that TSO isn't part of MVS, and you're wrong.
Am I? Different fmid, not absolutely essential - eg you could conceivably
>09/19/2012
> at 01:38 PM, Jeremy Nicoll - news posts
><jn.nntp....@wingsandbeaks.org.uk> said:
>
>>Come off it, you must know what I mean.
>
>Yes, you mean that TSO isn't part of MVS, and you're wrong.
have an MVS system that only accepted work via eg RJE or NJE systems. You
could certainly run a workload without ever starting TCAS or TSO.
>>The point is that you can't just tell MVS (or TSO) to run an
>>arbitrary file which happens to contain either a clist or a rexx
>>exec in the way that one could do with an executable file under
>>Linux.
>
>That's *a* point; it has nothing to do with your claim "Windows
>doesn't "recognise the /*" either. Nor do VM/CMS or MVS".
the EXEC command processor from the system and MVS would still run just
fine.
>>You have instead explicitly to use a mechanism that already knows
>>the file is something that the EXEC command processor can execute.
>
>The same is true for Linux; it can only handle files for which it
>knows the format. The fact that it recognizes more than three is
>irrelevant, as is the fact that one of the formats it recognizes is a
>text file with a shebang in the first line.
works in Linux but not elsewhere, though, is it?
Jeremy Nicoll - news posts
Sep 19, 2012, 4:20:59 PM9/19/12
to
"Cruz, Jaime" <Spam...@Bite.Me> wrote:
>Jeremy Nicoll - news posts wrote:
>> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>>
>>> In <mpro.makmpa...@wingsandbeaks.org.uk.invalid>, on
>>> 09/19/2012
>>> at 01:29 AM, Jeremy Nicoll - news posts
>>> <jn.nntp....@wingsandbeaks.org.uk> said:
>>
>>>> It's NOT MVS that makes the decision, but the EXEC command
>>>> processor.
>>>
>>> What is TSO/E, chopped liver? EXEC is part of MVS.
>>
>> Come off it, you must know what I mean. The point is that you can't just
>> tell MVS (or TSO) to run an arbitrary file which happens to contain
either a
>> clist or a rexx exec in the way that one could do with an executable file
>> under Linux.
>>
>> You have instead explicitly to use a mechanism that already knows the
file
>> is something that the EXEC command processor can execute.
>>
>>
>You're missing the point, and Seymour has it right. TSO/E is part of
>MVS (and you're dating yourself... it's been z/OS for over a decade
>now).
Yes I know that the name has changed, but the mechanism has not.
>Jeremy Nicoll - news posts wrote:
>> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>>
>>> In <mpro.makmpa...@wingsandbeaks.org.uk.invalid>, on
>>> 09/19/2012
>>> at 01:29 AM, Jeremy Nicoll - news posts
>>> <jn.nntp....@wingsandbeaks.org.uk> said:
>>
>>>> It's NOT MVS that makes the decision, but the EXEC command
>>>> processor.
>>>
>>> What is TSO/E, chopped liver? EXEC is part of MVS.
>>
>> Come off it, you must know what I mean. The point is that you can't just
>> tell MVS (or TSO) to run an arbitrary file which happens to contain
either a
>> clist or a rexx exec in the way that one could do with an executable file
>> under Linux.
>>
>> You have instead explicitly to use a mechanism that already knows the
file
>> is something that the EXEC command processor can execute.
>>
>>
>You're missing the point, and Seymour has it right. TSO/E is part of
>MVS (and you're dating yourself... it's been z/OS for over a decade
>now).
> If you have a REXX EXEC defined to the SYSPROC DD concatenation for your
> TSO/E address space and you implicitly execute it from the READY prompt,
> the TSO/E Terminal Monitor Program (again, PART of the z/OS operating
> system) scans the first line
forget) has nothing to do with it. It's the EXEC command processor that
makes the decision.
> and determines whether or not it is a CLIST or REXX EXEC and passes
> control automatically to the proper command interpreter.
here, whether you implicitly call it, or explicitly with the TSO EXEC
command.
>This is no different than OS/2 (eComStation) or PC DOS 7, or z/VM for
>that matter.
between the rexx exec's file extension and the program to be used to run it.
Jeremy Nicoll - news posts
Sep 19, 2012, 4:52:32 PM9/19/12
to
Jeremy Nicoll - news posts <jn.nntp....@wingsandbeaks.org.uk> wrote:
>"Cruz, Jaime" <Spam...@Bite.Me> wrote:
>>This is no different than OS/2 (eComStation) or PC DOS 7, or z/VM for
>>that matter.
>
> It is different. In PC DOS 7 the decision is made by the association
> between the rexx exec's file extension and the program to be used to run
> it.
I'm sorry, I find I need to fall on my sword in this last case... I was
certain that that's how I ran rexx execs on PC DOS 7, but have found some
doc - with lots of alternate methods, some very devious
ftp://service.boulder.ibm.com/software/awdtools/obj.../orxhowrx.pdf
that says it couldn't be done by a separate file extension.
>"Cruz, Jaime" <Spam...@Bite.Me> wrote:
>>This is no different than OS/2 (eComStation) or PC DOS 7, or z/VM for
>>that matter.
>
> It is different. In PC DOS 7 the decision is made by the association
> between the rexx exec's file extension and the program to be used to run
> it.
certain that that's how I ran rexx execs on PC DOS 7, but have found some
doc - with lots of alternate methods, some very devious
ftp://service.boulder.ibm.com/software/awdtools/obj.../orxhowrx.pdf
that says it couldn't be done by a separate file extension.
Jeremy Nicoll - news posts
Sep 19, 2012, 5:00:48 PM9/19/12
to
> ftp://service.boulder.ibm.com/software/awdtools/obj.../orxhowrx.pdf
B*gger. That URL c&p from google is wrong. It should be:
ftp://service.boulder.ibm.com/software/awdtools/obj-rexx/orxhowrx.pdf
B*gger. That URL c&p from google is wrong. It should be:
ftp://service.boulder.ibm.com/software/awdtools/obj-rexx/orxhowrx.pdf
Cruz, Jaime
Sep 19, 2012, 5:28:45 PM9/19/12
to
regular PC DOS batch files and REXX EXECs BOTH have the ".BAT"
extension. Just like z/OS, the first line of the script (the "/*"
determines whether it is a standard batch file, or REXX.
Just like OS/2 (which is *.CMD), the extension makes NO difference...
the command processor sees the "/*" and knows to invoke REXX.
REXX EXECs and TSO CLISTS co-exist in the SYSPROC concatenation. The
command processor knows to check that first line to determine whether it
is a CLIST or REXX.
In z/VM, the "EXEC" filetype can also be either EXEC1, EXEC2, or REXX.
Repeat after me:
The extension has NOTHING to do with it.
The extension has NOTHING to do with it.
The extension has NOTHING to do with it.
The extension has NOTHING to do with it.
The extension has NOTHING to do with it.
The extension has NOTHING to do with it.
The extension has NOTHING to do with it.
The extension has NOTHING to do with it.
The extension has NOTHING to do with it.
The extension has NOTHING to do with it.
The extension has NOTHING to do with it.
Jeremy Nicoll - news posts
Sep 19, 2012, 5:39:01 PM9/19/12
to
"Cruz, Jaime" <Spam...@Bite.Me> wrote:
>You're being deliberately obtuse
I realise it seems that way now, but actually I intended the original
statement I made to be just ... accurate. And I did deliberately choose OS
names rather than component names when I wwote what I did.
> or you missed the point where I said regular PC DOS batch files and REXX
> EXECs BOTH have the ".BAT" extension.
I'm bleeding, (see other post), and accept I was wrong there.
> REXX EXECs and TSO CLISTS co-exist in the SYSPROC concatenation. The
> command processor knows to check that first line to determine whether it
> is a CLIST or REXX.
How come you're now agreeing with me? You're finally saying "ocmmand
processor", not OS.
>In z/VM, the "EXEC" filetype can also be either EXEC1, EXEC2, or REXX.
>
>Repeat after me:
>The extension has NOTHING to do with it.
>The extension has NOTHING to do with it.
So, what happens if you put an EXEC1 program in a file with an EXEC2 or REXX
filetype? If the system can cope with that, surely that means CMS's
equivalent of TSO's command processor (I don't know the VM/CMS terminology)
is making the decision of which language processor to call?
>You're being deliberately obtuse
I realise it seems that way now, but actually I intended the original
statement I made to be just ... accurate. And I did deliberately choose OS
names rather than component names when I wwote what I did.
> or you missed the point where I said regular PC DOS batch files and REXX
> EXECs BOTH have the ".BAT" extension.
> REXX EXECs and TSO CLISTS co-exist in the SYSPROC concatenation. The
> command processor knows to check that first line to determine whether it
> is a CLIST or REXX.
processor", not OS.
>In z/VM, the "EXEC" filetype can also be either EXEC1, EXEC2, or REXX.
>
>Repeat after me:
>The extension has NOTHING to do with it.
>The extension has NOTHING to do with it.
filetype? If the system can cope with that, surely that means CMS's
equivalent of TSO's command processor (I don't know the VM/CMS terminology)
is making the decision of which language processor to call?
Jaime Cruz
Sep 19, 2012, 6:46:16 PM9/19/12
to
Crap, I have to take it back... REXX_PATH didn't solve the problem. I
was premature. Apparently, since the SysRexxAddMacro function was
already invoked, the environment knew about the external functions
despite the environment variable. After I deleted those lines from the
EXEC and ran it again, I simply assumed it worked because of the
environment variable.
After a reboot, the EXEC couldn't find the external functions, despite
the fact I had the REXX_PATH environment variable set, AND the directory
of external REXX functions was in the regular PATH too.
Oh well, at least it works when you jump through the proper hoops. Sure
would be nice if it worked the same way everywhere though.
was premature. Apparently, since the SysRexxAddMacro function was
already invoked, the environment knew about the external functions
despite the environment variable. After I deleted those lines from the
EXEC and ran it again, I simply assumed it worked because of the
environment variable.
After a reboot, the EXEC couldn't find the external functions, despite
the fact I had the REXX_PATH environment variable set, AND the directory
of external REXX functions was in the regular PATH too.
Oh well, at least it works when you jump through the proper hoops. Sure
would be nice if it worked the same way everywhere though.
U. Zinngrebe
Sep 19, 2012, 9:36:58 PM9/19/12
to
Jaime Cruz wrote:
> > Also, I had to use SysAddRexxMacro to define all of the external
> > functions even though the directory in which they all reside is
> > defined in the $PATH variable.
> > Also, I had to use SysAddRexxMacro to define all of the external
> > functions even though the directory in which they all reside is
> > defined in the $PATH variable.
> Crap, I have to take it back... REXX_PATH didn't solve the problem. I
> was premature. Apparently, since the SysRexxAddMacro function was
> already invoked, the environment knew about the external functions
> despite the environment variable.
> ...
> was premature. Apparently, since the SysRexxAddMacro function was
> already invoked, the environment knew about the external functions
> despite the environment variable.
> After a reboot, the EXEC couldn't find the external functions, despite
> the fact I had the REXX_PATH environment variable set, AND the directory
> of external REXX functions was in the regular PATH too.
Jaimes,
> the fact I had the REXX_PATH environment variable set, AND the directory
> of external REXX functions was in the regular PATH too.
I never ever used SysAddMacro to reach external functions, and the
first line starting with #! is convenient but not essential.
Can you post more information about your computer ?
It seems you lauch from the command prompt (and don't click on icons on the
desktop).
(1)
Could you please run these commands and copy-paste the output ?
uname -a
whoami
rexx -v (the first few lines)
which rexx
echo $PATH
help (the first few lines)
The output should look like
uli@ulmo:~/oorexx> uname -a
Linux ulmo 3.4.6-2.10-desktop #1 SMP PREEMPT Thu Jul 26 09:36:26 UTC 2012
(641c197) x86_64 x86_64 x86_64 GNU/Linux
uli@ulmo:~/oorexx> rexx -v
Open Object Rexx Version 4.2.0
Build date: Aug 29 2012
Addressing Mode: 64
uli@ulmo:~/oorexx> which rexx
/usr/bin/rexx
uli@ulmo:~/oorexx> echo $PATH
/home/uli/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:
/usr/games:/opt/kde3/bin:/opt/cross/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:
/opt/BSF4ooRexx
uli@ulmo:~/oorexx> help
GNU bash, version 4.2.24(1)-release (x86_64-suse-linux-gnu)
(2)
At the command prompt where you launch the main program, could you please
copy-paste:
the command to launch the main program
echo $PWD
ls -l <directory+name-of-external-function>
a command to launch the external function directly
The result should look like
uli@ulmo:~/oorexx> ./newTest
uli@ulmo:~/oorexx> echo $PWD
/home/uli/oorexx
uli@ulmo:~/oorexx> ls -l ~/bin/mytest.rex
-rw-r--r-- 1 uli users 5944 Sep 2 01:15 /home/uli/bin/mytest.rex
uli@ulmo:~/oorexx> mytest
If 'mytest' is not a typo you can use command-not-found to lookup the
package that contains it, like this:
cnf mytest
uli@ulmo:~/oorexx> mytest.rex
bash: /home/uli/bin/mytest.rex: Permission denied
(3)
From the main program, the line that calls the external function and the
output of TRACE '?I' when that line was executed.
The result could look like
mytest
+++ "LINUX COMMAND /home/uli/oorexx/newTest"
2 *-* mytest
>V> MYTEST => "MYTEST"
>>> "MYTEST"
sh: MYTEST: command not found
+++ "RC(127)"
+++ Interactive trace. "Trace Off" to end debug, ENTER to Continue. +++
Cheers, Uli
LesK
Sep 19, 2012, 10:38:51 PM9/19/12
to
standard CMS command resolution search order looks for EXEC, then MODULE
and then some others that I don't recall but have nothing to do with execs.
Of course z/VM being as flexible as it is, your local sysprog can
probably change the default behavior.
> Repeat after me:
> The extension has NOTHING to do with it.
> The extension has NOTHING to do with it.
> The extension has NOTHING to do with it.
> The extension has NOTHING to do with it.
> The extension has NOTHING to do with it.
> The extension has NOTHING to do with it.
> The extension has NOTHING to do with it.
> The extension has NOTHING to do with it.
> The extension has NOTHING to do with it.
> The extension has NOTHING to do with it.
> The extension has NOTHING to do with it.
>
>
>
>
--
Cruz, Jaime
Sep 20, 2012, 7:41:35 AM9/20/12
to
U. Zinngrebe wrote:
> Jaimes,
> I never ever used SysAddMacro to reach external functions, and the
> first line starting with #! is convenient but not essential.
>
> Can you post more information about your computer ?
> It seems you lauch from the command prompt (and don't click on icons on the
> desktop).
>
> (1)
> Could you please run these commands and copy-paste the output ?
> uname -a
Linux jaime-ThinkPad-SL500 3.2.0-30-generic-pae #48-Ubuntu SMP Fri Aug
> Jaimes,
> I never ever used SysAddMacro to reach external functions, and the
> first line starting with #! is convenient but not essential.
>
> Can you post more information about your computer ?
> It seems you lauch from the command prompt (and don't click on icons on the
> desktop).
>
> (1)
> Could you please run these commands and copy-paste the output ?
> uname -a
24 17:14:09 UTC 2012 i686 i686 i386 GNU/Linux
> whoami
jaime
> rexx -v (the first few lines)
Build date: Aug 31 2012
Addressing Mode: 32
> which rexx
/usr/bin/rexx
> echo $PATH
./:/home/jaime/REXX:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/lib/ooRexx:/usr/share/ooRexx
> help (the first few lines)
These shell commands are defined internally. Type `help' to see this list.
Type `help name' to find out more about the function `name'.
Use `info bash' to find out more about the shell in general.
Use `man -k' or `info' to find out more about commands not in this list.
>
> (2)
> At the command prompt where you launch the main program, could you please
> copy-paste:
> the command to launch the main program
> echo $PWD
/home/jaime
> ls -l <directory+name-of-external-function>
total 204
-rwxrwxr-x 1 jaime jaime 3235 Sep 17 18:27 B2mmddyy
-rwxrwxr-x 1 jaime jaime 18809 Sep 19 18:13 Hello
-rwxrwxr-x 1 jaime jaime 18084 Sep 18 20:38 Hello~
-rwxrwxr-x 1 jaime jaime 503 Sep 17 18:29 Hhmmss2s
-rwxrwxr-x 1 jaime jaime 3791 Sep 17 18:53 JCCalJul
-rwxrwxr-x 1 jaime jaime 4468 Sep 17 18:24 JCDoM
-rwxrwxr-x 1 jaime jaime 2438 Sep 17 18:55 JCDoW
-rwxrwxr-x 1 jaime jaime 2850 Sep 17 18:25 JCEaster
-rwxrwxr-x 1 jaime jaime 3684 Sep 17 18:26 JCJulCal
-rwxrwxr-x 1 jaime jaime 1212 Sep 17 18:51 JCLepYer
-rwxrwxr-x 1 jaime jaime 2934 Sep 17 18:32 JCSort
-rw-rw-r-- 1 jaime jaime 2934 Sep 17 18:30 JCSort~
-rwxrwxr-x 1 jaime jaime 3078 Sep 17 18:27 Mmddyy2b
-rwxrwxr-x 1 jaime jaime 634 Sep 17 18:28 S2hhmmss
> a command to launch the external function directly
/home/jaime/REXX/JCSort: line 2: /bin: Is a directory
/home/jaime/REXX/JCSort: line 3: /bin: Is a directory
/home/jaime/REXX/JCSort: line 4: /bin: Is a directory
/home/jaime/REXX/JCSort: line 5: /bin: Is a directory
/home/jaime/REXX/JCSort: line 6: /bin: Is a directory
/home/jaime/REXX/JCSort: line 7: /bin: Is a directory
/home/jaime/REXX/JCSort: line 8: /bin: Is a directory
/home/jaime/REXX/JCSort: line 9: /bin: Is a directory
/home/jaime/REXX/JCSort: line 10: /bin: Is a directory
/home/jaime/REXX/JCSort: line 11: /bin/: Is a directory
/home/jaime/REXX/JCSort: line 12: /bin: Is a directory
/home/jaime/REXX/JCSort: line 13: /bin/: Is a directory
/home/jaime/REXX/JCSort: line 14: Parse: command not found
/home/jaime/REXX/JCSort: line 15: Do: command not found
/home/jaime/REXX/JCSort: line 16: Parse: command not found
/home/jaime/REXX/JCSort: line 17: End: command not found
/home/jaime/REXX/JCSort: line 19: Parse: command not found
/home/jaime/REXX/JCSort: line 20: syntax error near unexpected token `('
/home/jaime/REXX/JCSort: line 20: `direction = Left(direction, 1)'
> The result should look like
> uli@ulmo:~/oorexx> ./newTest
> uli@ulmo:~/oorexx> echo $PWD
> /home/uli/oorexx
> uli@ulmo:~/oorexx> ls -l ~/bin/mytest.rex
> -rw-r--r-- 1 uli users 5944 Sep 2 01:15 /home/uli/bin/mytest.rex
> uli@ulmo:~/oorexx> mytest
> If 'mytest' is not a typo you can use command-not-found to lookup the
> package that contains it, like this:
> cnf mytest
> uli@ulmo:~/oorexx> mytest.rex
> bash: /home/uli/bin/mytest.rex: Permission denied
>
> (3)
> From the main program, the line that calls the external function and the
> output of TRACE '?I' when that line was executed.
> The result could look like
>
310 *-* Call JCSort
>>> "0"
311 *-* Trace 'O'
>
> Cheers, Uli
Shmuel Metz
Sep 20, 2012, 10:25:35 AM9/20/12
to
In <mpro.mam5oa...@wingsandbeaks.org.uk.invalid>, on
09/19/2012
at 09:16 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>Am I? Different fmid,
Do you really believe that there is only a single FMID for MVS?
>not absolutely essential - eg you could conceivably
>have an MVS system that only accepted work via eg RJE or NJE
>systems.
Sure, and you could still run TSO commands on those systems, unless
you're running something out of the 1970's.
>You could certainly run a workload without ever starting TCAS or
>TSO.
Yes, you could even run a workload that used TSO commands without
starting rgw TCAS address space.
>Neither VM nor MVS do;
Only if you have private definitions of "VM" and "MVS". In the rest of
the world, those are generic terms for a series of free and licensed
packages culminating in z/VM and z/VM, each of which included
unprivileged code. Neither VM nor MVS is just the BCP.
>It's not irrelevant in terms of the OP's question about how the
>shebang works in Linux but not elsewhere, though, is it?
Yes. It amount to saying that it works the way it works, instead of
explaining how it works or why.
09/19/2012
at 09:16 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>Am I? Different fmid,
Do you really believe that there is only a single FMID for MVS?
>not absolutely essential - eg you could conceivably
>have an MVS system that only accepted work via eg RJE or NJE
>systems.
you're running something out of the 1970's.
>You could certainly run a workload without ever starting TCAS or
>TSO.
starting rgw TCAS address space.
>Neither VM nor MVS do;
the world, those are generic terms for a series of free and licensed
packages culminating in z/VM and z/VM, each of which included
unprivileged code. Neither VM nor MVS is just the BCP.
>It's not irrelevant in terms of the OP's question about how the
>shebang works in Linux but not elsewhere, though, is it?
explaining how it works or why.
Shmuel Metz
Sep 20, 2012, 10:34:58 AM9/20/12
to
In <mpro.mam9h1...@wingsandbeaks.org.uk.invalid>, on
09/19/2012
at 10:39 PM, Jeremy Nicoll - news posts
type EXEC begins with a line that distinguishes among three different
languages, EXEC, EXEC2 and REXX.
09/19/2012
at 10:39 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>So, what happens if you put an EXEC1 program in a file with an EXEC2
>or REXX filetype?
I'm not aware of any EXEC2 or REXX file type in VM. A file with file
>So, what happens if you put an EXEC1 program in a file with an EXEC2
>or REXX filetype?
type EXEC begins with a line that distinguishes among three different
languages, EXEC, EXEC2 and REXX.
Glenn Knickerbocker
Sep 20, 2012, 12:16:53 PM9/20/12
to
On 9/20/2012 10:25 AM, Shmuel (Seymour J.) Metz wrote:
> Only if you have private definitions of "VM" and "MVS"
One would think the correct definitions were the ones the company that
> Only if you have private definitions of "VM" and "MVS"
produced them used, and their definition of MVS hasn't included TSO
since the overall package was renamed OS/390. The EXEC processor has
certainly been a part of VM for at least 30 years, though, and MVS has
included System REXX in the past 5 releases of z/OS (and one of my first
big tasks in my current job was supporting its rollback into the
previous release).
�R
LesK
Sep 20, 2012, 1:22:30 PM9/20/12
to
On 9/20/2012 7:41 AM, Cruz, Jaime wrote:
>
>> a command to launch the external function directly
>
> /home/jaime/REXX/JCSort: line 1: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 2: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 3: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 4: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 5: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 6: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 7: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 8: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 9: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 10: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 11: /bin/: Is a directory
> /home/jaime/REXX/JCSort: line 12: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 13: /bin/: Is a directory
> /home/jaime/REXX/JCSort: line 14: Parse: command not found
> /home/jaime/REXX/JCSort: line 15: Do: command not found
> /home/jaime/REXX/JCSort: line 16: Parse: command not found
> /home/jaime/REXX/JCSort: line 17: End: command not found
> /home/jaime/REXX/JCSort: line 19: Parse: command not found
> /home/jaime/REXX/JCSort: line 20: syntax error near unexpected token `('
> /home/jaime/REXX/JCSort: line 20: `direction = Left(direction, 1)'
>
>
I can't be sure because I don't know anything about Linux, but the error
>
>> a command to launch the external function directly
>
> /home/jaime/REXX/JCSort: line 1: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 2: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 3: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 4: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 5: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 6: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 7: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 8: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 9: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 10: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 11: /bin/: Is a directory
> /home/jaime/REXX/JCSort: line 12: /bin: Is a directory
> /home/jaime/REXX/JCSort: line 13: /bin/: Is a directory
> /home/jaime/REXX/JCSort: line 14: Parse: command not found
> /home/jaime/REXX/JCSort: line 15: Do: command not found
> /home/jaime/REXX/JCSort: line 16: Parse: command not found
> /home/jaime/REXX/JCSort: line 17: End: command not found
> /home/jaime/REXX/JCSort: line 19: Parse: command not found
> /home/jaime/REXX/JCSort: line 20: syntax error near unexpected token `('
> /home/jaime/REXX/JCSort: line 20: `direction = Left(direction, 1)'
>
>
associated with line 20 of JCSort deserves your attention.
Jeremy Nicoll - news posts
Sep 20, 2012, 1:55:27 PM9/20/12
to
"Cruz, Jaime" <Spam...@Bite.Me> wrote:
>jaime@jaime-ThinkPad-SL500:~$ Hello
> 310 *-* Call JCSort
Shouldn't this be:
>jaime@jaime-ThinkPad-SL500:~$ Hello
> 310 *-* Call JCSort
Call 'JCSort'
because the exact spelling/case of the external function file is 'JCSort'?
I would guess that when oorexx sees:
Call JCSort
(assuming that JCSort isn't a variable) it replaces "JCSort" with its
default value which would be "JCSORT", and then fails to find a file with
that exact name.
Personally I don't like seeing rexx keywords in mixed case, eg "Call" rather
than "call" or "CALL" because I think it can help to confuse between places
where case matters and those where it doesn't.
Jeremy Nicoll - news posts
Sep 20, 2012, 2:37:17 PM9/20/12
to
Jaime Cruz <Spam...@Bite.Me> wrote:
> I see the secret is the !# line indicating where the REXX interpreter
> lives. Why isn't it smart enough to recognize the "/*" in the first line
> like just about every other platform??
I had another thought about this question...
If that was the approach Linux typically took, all the many script-type
languages would have to have some way of declaring what they were at the
start of their files too. More than likely some other much older language
would have long since claimed "/*" as its identifying trait.
Am I wrong (not knowing much about linux) in assuming that provided any
file, with any name, is marked "executable", that one can use its name as a
command to run it? That is, without an extension/filetype there is nothing
outwith the file to tell Linux what to do with the file? No meta data, for
example?
(In one OS I've used a lot, RISC OS, files of any sort can have any name,
but filetype info is stored as a 3-hex-digit metadata value. Eg text files
are x'FFF, jpegs are x'C85, and so on. Environment vars dictate a bunch of
things about each filetype value - its name, how to 'run' it and so on,
using vars named: Alias$@RunType_xxx eg: Alias$@RunType_FFF - which
defines the command to run an x'FFF' file.)
The difference in Windows and TSO etc is that there's always other
information available that tells the system that the file is (or at least is
expected to be) something that can be run by whatever program it is that
discriminates between BAT/CLIST/REXX etc. That's different from the free
for all in Linux where any file could contain anything.
> I see the secret is the !# line indicating where the REXX interpreter
> lives. Why isn't it smart enough to recognize the "/*" in the first line
> like just about every other platform??
I had another thought about this question...
If that was the approach Linux typically took, all the many script-type
languages would have to have some way of declaring what they were at the
start of their files too. More than likely some other much older language
would have long since claimed "/*" as its identifying trait.
Am I wrong (not knowing much about linux) in assuming that provided any
file, with any name, is marked "executable", that one can use its name as a
command to run it? That is, without an extension/filetype there is nothing
outwith the file to tell Linux what to do with the file? No meta data, for
example?
(In one OS I've used a lot, RISC OS, files of any sort can have any name,
but filetype info is stored as a 3-hex-digit metadata value. Eg text files
are x'FFF, jpegs are x'C85, and so on. Environment vars dictate a bunch of
things about each filetype value - its name, how to 'run' it and so on,
using vars named: Alias$@RunType_xxx eg: Alias$@RunType_FFF - which
defines the command to run an x'FFF' file.)
The difference in Windows and TSO etc is that there's always other
information available that tells the system that the file is (or at least is
expected to be) something that can be run by whatever program it is that
discriminates between BAT/CLIST/REXX etc. That's different from the free
for all in Linux where any file could contain anything.
Jeremy Nicoll - news posts
Sep 20, 2012, 3:11:18 PM9/20/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>In <mpro.mam5oa...@wingsandbeaks.org.uk.invalid>, on
>09/19/2012
> at 09:16 PM, Jeremy Nicoll - news posts
><jn.nntp....@wingsandbeaks.org.uk> said:
>
>>Am I? Different fmid,
>
>Do you really believe that there is only a single FMID for MVS?
No of course not. Looking back at old notes I see that all the core MVS
>09/19/2012
> at 09:16 PM, Jeremy Nicoll - news posts
><jn.nntp....@wingsandbeaks.org.uk> said:
>
>>Am I? Different fmid,
>
>Do you really believe that there is only a single FMID for MVS?
fmids correspond to products called "MVS BASE this or that". TSO isn't
described as a base part of the OS.
Not only do I think that TSO needn't be installed, it's clear that some
sites didn't, using eg ROSCOE instead.
> Only if you have private definitions of "VM" and "MVS". In the rest of the
> world, those are generic terms for a series of free and licensed packages
> culminating in z/VM and z/VM, each of which included unprivileged code.
> Neither VM nor MVS is just the BCP.
is not part of MVS. Frankly I find it amazing that a sysprog could fail to
see the difference.
U. Zinngrebe
Sep 20, 2012, 3:45:58 PM9/20/12
to
LesK wrote:
>>
>>> a command to launch the external function directly
>>
>> /home/jaime/REXX/JCSort: line 1: /bin: Is a directory
...
>>
>>> a command to launch the external function directly
>>
>> /home/jaime/REXX/JCSort: line 1: /bin: Is a directory
> I can't be sure because I don't know anything about Linux, but the error
> associated with line 20 of JCSort deserves your attention.
this was for checking whether the command processor (bash) would locate the
external function (/home/jaime/REXX/JCSort).
If not located then bash would give a corresponding message.
In this case bash located the external function and started processing it.
There was no indication that it is in REXX, so bash interpretes it as
default (shellscript).
Therefore I don't think the error messages matter.
Cheers, Uli
Shmuel Metz
Sep 20, 2012, 10:31:24 AM9/20/12
to
In <mpro.mam5uz...@wingsandbeaks.org.uk.invalid>, on
09/19/2012
at 09:20 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>"Cruz, Jaime" <Spam...@Bite.Me> wrote:
>Yes I know that the name has changed,
What's relevant is that TSO has always been part of MVS, and *that*
has not changed.
>>This is no different than OS/2 (eComStation) or PC DOS 7, or z/VM for
>>that matter.
>It is different. In PC DOS 7 the decision is made by the
>association between the rexx exec's file extension and the program
>to be used to run it.
Perhaps, I don't have a PC DOS 7 to try it on. What I know from
personal experience is that in OS/2 the same extension is used for BAT
and REXX scripts, with the first line determining which it is.
09/19/2012
at 09:20 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>"Cruz, Jaime" <Spam...@Bite.Me> wrote:
>Yes I know that the name has changed,
has not changed.
>>This is no different than OS/2 (eComStation) or PC DOS 7, or z/VM for
>>that matter.
>It is different. In PC DOS 7 the decision is made by the
>association between the rexx exec's file extension and the program
>to be used to run it.
personal experience is that in OS/2 the same extension is used for BAT
and REXX scripts, with the first line determining which it is.
Jeremy Nicoll - news posts
Sep 20, 2012, 5:00:40 PM9/20/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
> What's relevant is that TSO has always been part of MVS, and *that* has
> not changed.
So why would some sites not install it, using eg ROSCOE instead?
> not changed.
Are you not being blinded by the fact that that what was ordered, in CBIPOs
or whatever, in the sites you worked in, did include TSO? So far as I
recall the order was made, FMID by FMID, according to what a site needed.
U. Zinngrebe
Sep 20, 2012, 6:41:49 PM9/20/12
to
Cruz, Jaime wrote:
>> Can you post more information about your computer ?
...
>> Can you post more information about your computer ?
Jaime,
thank you for the info. It looks normal except for
>> (3)
>> From the main program, the line that calls the external function and the
>> output of TRACE '?I' when that line was executed.
>> The result could look like
>>
>
> jaime@jaime-ThinkPad-SL500:~$ Hello
> 310 *-* Call JCSort
> >>> "0"
> 311 *-* Trace 'O'
>
When I try the same it returns an error (Routine not found):
uli@ulmo:~/oorexx> ls -l ~/bin/JCSort
-rw-r--r-- 1 uli users 9 Sep 20 21:47 /home/uli/bin/JCSort
uli@ulmo:~/oorexx> cat ~/bin/JCSort
return 0
uli@ulmo:~/oorexx> cat Hello
#! /usr/bin/rexx
Call JCSort
uli@ulmo:~/oorexx> ./Hello
2 *-* Call JCSort
REX0043E: Error 43 running /home/uli/oorexx/Hello line 2: Routine not
found
REX0417E: Error 43.1: Could not find routine "JCSORT"
The last line shows that the routine "JCSORT" instead of "JCSort" was looked
for. Enclosing JCSort in quotes makes the error disappear and TRACE '?I'
gives the same output as you posted:
uli@ulmo:~/oorexx> ./Hello
+++ "LINUX COMMAND /home/uli/oorexx/Hello"
3 *-* Call 'JCSort'
>>> "0"
+++ Interactive trace. "Trace Off" to end debug, ENTER [...]
So what JCSort does Hello find on your computer ?
(4)
Does also JCSORT exist as a file ? It need not be executable for rexx to
pick it up, so an error when entering JCSORT at the command prompt is not a
proof. The brute force approach
find / -iname 'jcsort' |& grep -v 'Permission denied'
is slow, but I have no better idea. The output should also contain:
/home/jaime/REXX/JCSort
(5)
Does JCSort exist also as internal label ? If
Call JCSort''
fails while
Call JCSort
works then this should be the case.
(6)
Does Call or JCSort contain unexpecte data ? A statement
say Call JCSort
should reveal it.
(7)
You can verify whether /home/jaime/REXX/JCSort is accessed by editing it
while tracing Hello. The difference should be visible when re-executing the
call:
uli@ulmo:~/oorexx> ./Hello
+++ "LINUX COMMAND /home/uli/oorexx/Hello"
3 *-* Call 'JCSort'
>>> "0"
+++ Interactive trace. "Trace Off" to end debug, ENTER to Continue. +++
"echo 'return 77' >~/bin/JCSort"
=
3 *-* Call 'JCSort'
>>> "77"
(8)
JCSort does not have a file extension. According to the documentation, in
this case the interpreter will manipulate the external function filename:
a) add the file extension of the caller
b) add the default extension .REX
and only if a) and b) fail then
c) search for a file JCSort without extension.
So JCSORT.REX might be picked up instead of JCSort.
(9)
You may have to call SysClearRexxMacroSpace() in case JCSort is already
loaded there.
(10)
JCSort could be present as ::ROUTINE (maybe indirectly through ::REQUIRES).
I don't know how to check for these except looking at the source code.
Cheers, Uli
Cruz, Jaime
Sep 20, 2012, 7:03:32 PM9/20/12
to
directory is an external function called by "Hello". I just picked that
one out of the hat. They all work if I use SysAddRexxMacro, they all
fail if I don't.
However... Jeremy pointed out something I forgot... JCSort is going to
be thought of as an uninitialized variable, and the default would
therefore be JCSORT. Case does matter under Linux, so maybe if I
converted all of the external functions to all caps? Worth a shot...
I'll test it later and report my result. Thanks.
Cruz, Jaime
Sep 20, 2012, 7:06:53 PM9/20/12
to
Jeremy Nicoll - news posts wrote:
> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>
>> In <mpro.mam5oa...@wingsandbeaks.org.uk.invalid>, on
>> 09/19/2012
>> at 09:16 PM, Jeremy Nicoll - news posts
>> <jn.nntp....@wingsandbeaks.org.uk> said:
>>
>>> Am I? Different fmid,
>>
>> Do you really believe that there is only a single FMID for MVS?
>
> No of course not. Looking back at old notes I see that all the core MVS
> fmids correspond to products called "MVS BASE this or that". TSO isn't
> described as a base part of the OS.
>
FYI: TSO/E has been part of MVS since the days of MVS/SE. Whether the
> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>
>> In <mpro.mam5oa...@wingsandbeaks.org.uk.invalid>, on
>> 09/19/2012
>> at 09:16 PM, Jeremy Nicoll - news posts
>> <jn.nntp....@wingsandbeaks.org.uk> said:
>>
>>> Am I? Different fmid,
>>
>> Do you really believe that there is only a single FMID for MVS?
>
> No of course not. Looking back at old notes I see that all the core MVS
> fmids correspond to products called "MVS BASE this or that". TSO isn't
> described as a base part of the OS.
>
site decides to configure it and start it at IPL time is up to them, but
the joke has been that "TSO" stands for "Time Sharing Option" but it
hadn't been an "Option" for decades... you got it whether you wanted it
or not.
Jeremy Nicoll - news posts
Sep 20, 2012, 7:07:20 PM9/20/12
to
"Cruz, Jaime" <Spam...@Bite.Me> wrote:
> Case does matter under Linux, so maybe if I converted all of the external
> functions to all caps? Worth a shot...
I think you should read the ref manual's section on function search order.
> Case does matter under Linux, so maybe if I converted all of the external
> functions to all caps? Worth a shot...
I think one option rexx tries is to convert the function name in the program
to all lower case, so changing the external fn files to all lowercase names
might mean you could then refer to them with any mix of upper & lowercase
names.
However it's likely to be fractionally more efficient if you use the same
casing in the program as the files actually have.
Jeremy Nicoll - news posts
Sep 20, 2012, 7:10:20 PM9/20/12
to
"Cruz, Jaime" <Spam...@Bite.Me> wrote:
> FYI: TSO/E has been part of MVS since the days of MVS/SE. Whether the
> site decides to configure it and start it at IPL time is up to them, but
> the joke has been that "TSO" stands for "Time Sharing Option" but it
> hadn't been an "Option" for decades... you got it whether you wanted it or
> not.
Never mind whether they configure it, why would they choose to APPLY &
> FYI: TSO/E has been part of MVS since the days of MVS/SE. Whether the
> site decides to configure it and start it at IPL time is up to them, but
> the joke has been that "TSO" stands for "Time Sharing Option" but it
> hadn't been an "Option" for decades... you got it whether you wanted it or
> not.
ACCEPT it if they don't want it?
Jaime Cruz
Sep 20, 2012, 8:05:04 PM9/20/12
to
Jeremy Nicoll - news posts wrote:
>
> However it's likely to be fractionally more efficient if you use the same
> casing in the program as the files actually have.
>
>
That is what I'm doing. So you say if I give them all lower-case names
>
> However it's likely to be fractionally more efficient if you use the same
> casing in the program as the files actually have.
>
>
it might find them?
I used mixed-case as part of my own programming "style" in all platforms.
variables are all lower case
Function calls are mixed case
External program calls are all upper-case.
Just makes it easier for me when I scan my own code to remember what it
was I was doing. I know REXX itself doesn't really care.
I realize I'll have to rethink that third case, as just about all
Linux/Unix commands are lower case (and case sensitive).
Jeremy Nicoll - news posts
Sep 20, 2012, 9:11:48 PM9/20/12
to
Jaime Cruz <Spam...@Bite.Me> wrote:
>Jeremy Nicoll - news posts wrote:
>>
>> However it's likely to be fractionally more efficient if you use the same
>> casing in the program as the files actually have.
>That is what I'm doing. So you say if I give them all lower-case names
>it might find them?
No, I say you should read the section of the manual on this. I only skim
>Jeremy Nicoll - news posts wrote:
>>
>> However it's likely to be fractionally more efficient if you use the same
>> casing in the program as the files actually have.
>That is what I'm doing. So you say if I give them all lower-case names
>it might find them?
read the linux bits very quickly, because none of it meant much to me, & I
think that's what it said. But you need to read about all the wrinkles.
Have you found the installed docs yet?
>I used mixed-case as part of my own programming "style" in all platforms.
>
>variables are all lower case
>Function calls are mixed case
>External program calls are all upper-case.
>
>Just makes it easier for me when I scan my own code to remember what it
>was I was doing. I know REXX itself doesn't really care.
called as well, IIRC. I think there's a way you can have a labelled bit of
code inside an exec with the same name as a BIF (built-in function) and yet
discriminate between which one is to be called.
Case also matters in some environments; obviously in edit macros of course.
But less well known in NetView where there's an 'address netvasis' option to
issue command strings in mixed case rather than the default where everything
gets folded to uppercase. I recall using this to have SA/390 execs create
WTO and WTOR texts in mixed case.
Cruz, Jaime
Sep 20, 2012, 10:04:43 PM9/20/12
to
Jeremy Nicoll - news posts wrote:
>
> Have you found the installed docs yet?
>
Nope. I'm using the ones on my Windows partition because I know where
>
> Have you found the installed docs yet?
>
those are.
Cruz, Jaime
Sep 20, 2012, 10:08:30 PM9/20/12
to
Jeremy Nicoll - news posts wrote:
> "Cruz, Jaime" <Spam...@Bite.Me> wrote:
>
>> Case does matter under Linux, so maybe if I converted all of the external
>> functions to all caps? Worth a shot...
>
> I think you should read the ref manual's section on function search order.
>
> I think one option rexx tries is to convert the function name in the program
> to all lower case, so changing the external fn files to all lowercase names
> might mean you could then refer to them with any mix of upper & lowercase
> names.
>
> However it's likely to be fractionally more efficient if you use the same
> casing in the program as the files actually have.
>
Okay, I rebooted, edited out all the "SysAddRexxMacro" calls, then
>
>> Case does matter under Linux, so maybe if I converted all of the external
>> functions to all caps? Worth a shot...
>
> I think you should read the ref manual's section on function search order.
>
> I think one option rexx tries is to convert the function name in the program
> to all lower case, so changing the external fn files to all lowercase names
> might mean you could then refer to them with any mix of upper & lowercase
> names.
>
> However it's likely to be fractionally more efficient if you use the same
> casing in the program as the files actually have.
>
renamed all of the external functions in the directory to lower case.
That didn't work.
Next, I renamed them to all upper case. BINGO! That worked! So it
looks like your first guess was right... "JCSort" was viewed as an
uninitialized variable, so it substituted "JCSORT" and searched for
that. I do remember seeing something somewhere about how REXX was going
to assume all lower case, but it doesn't seem to apply... at least, not
in this particular environment.
Anyway, it's working now and I've learned that much more about REXX and
Linux. Thanks!
LesK
Sep 20, 2012, 11:24:54 PM9/20/12
to
On 9/20/2012 3:45 PM, U. Zinngrebe wrote:
> LesK wrote:
>
>>>
>>>> a command to launch the external function directly
>>>
>>> /home/jaime/REXX/JCSort: line 1: /bin: Is a directory
> ....
> LesK wrote:
>
>>>
>>>> a command to launch the external function directly
>>>
>>> /home/jaime/REXX/JCSort: line 1: /bin: Is a directory
>
>> I can't be sure because I don't know anything about Linux, but the error
>> associated with line 20 of JCSort deserves your attention.
>
>
> Les,
>
> this was for checking whether the command processor (bash) would locate the
> external function (/home/jaime/REXX/JCSort).
> If not located then bash would give a corresponding message.
>
> In this case bash located the external function and started processing it.
> There was no indication that it is in REXX, so bash interpretes it as
> default (shellscript).
>
> Therefore I don't think the error messages matter.
>
> Cheers, Uli
>
>
Ok. Just trying to add another pair of eyeballs to the problem :-)
>> I can't be sure because I don't know anything about Linux, but the error
>> associated with line 20 of JCSort deserves your attention.
>
>
> Les,
>
> this was for checking whether the command processor (bash) would locate the
> external function (/home/jaime/REXX/JCSort).
> If not located then bash would give a corresponding message.
>
> In this case bash located the external function and started processing it.
> There was no indication that it is in REXX, so bash interpretes it as
> default (shellscript).
>
> Therefore I don't think the error messages matter.
>
> Cheers, Uli
>
>
LesK
Sep 20, 2012, 11:35:57 PM9/20/12
to
On 9/20/2012 9:11 PM, Jeremy Nicoll - news posts wrote:
> Jaime Cruz <Spam...@Bite.Me> wrote:
>
>> Jeremy Nicoll - news posts wrote:
>>>
>>> However it's likely to be fractionally more efficient if you use the same
>>> casing in the program as the files actually have.
>
>> That is what I'm doing. So you say if I give them all lower-case names
>> it might find them?
>
> No, I say you should read the section of the manual on this. I only skim
> read the linux bits very quickly, because none of it meant much to me, & I
> think that's what it said. But you need to read about all the wrinkles.
>
> Have you found the installed docs yet?
>
>
>> I used mixed-case as part of my own programming "style" in all platforms.
>>
>> variables are all lower case
>> Function calls are mixed case
>> External program calls are all upper-case.
>>
>> Just makes it easier for me when I scan my own code to remember what it
>> was I was doing. I know REXX itself doesn't really care.
>
> It affects the way internal functions (at labels inside a rexx exec) are
> called as well, IIRC. I think there's a way you can have a labelled bit of
> code inside an exec with the same name as a BIF (built-in function) and yet
> discriminate between which one is to be called.
>
If you put the function name in quotes, the internal file search is skipped.
> Jaime Cruz <Spam...@Bite.Me> wrote:
>
>> Jeremy Nicoll - news posts wrote:
>>>
>>> However it's likely to be fractionally more efficient if you use the same
>>> casing in the program as the files actually have.
>
>> That is what I'm doing. So you say if I give them all lower-case names
>> it might find them?
>
> No, I say you should read the section of the manual on this. I only skim
> read the linux bits very quickly, because none of it meant much to me, & I
> think that's what it said. But you need to read about all the wrinkles.
>
> Have you found the installed docs yet?
>
>
>> I used mixed-case as part of my own programming "style" in all platforms.
>>
>> variables are all lower case
>> Function calls are mixed case
>> External program calls are all upper-case.
>>
>> Just makes it easier for me when I scan my own code to remember what it
>> was I was doing. I know REXX itself doesn't really care.
>
> It affects the way internal functions (at labels inside a rexx exec) are
> called as well, IIRC. I think there's a way you can have a labelled bit of
> code inside an exec with the same name as a BIF (built-in function) and yet
> discriminate between which one is to be called.
>
> Case also matters in some environments; obviously in edit macros of course.
> But less well known in NetView where there's an 'address netvasis' option to
> issue command strings in mixed case rather than the default where everything
> gets folded to uppercase. I recall using this to have SA/390 execs create
> WTO and WTOR texts in mixed case.
>
>
--
LesK
Sep 20, 2012, 11:39:49 PM9/20/12
to
On 9/20/2012 7:10 PM, Jeremy Nicoll - news posts wrote:
> "Cruz, Jaime" <Spam...@Bite.Me> wrote:
>
>> FYI: TSO/E has been part of MVS since the days of MVS/SE. Whether the
>> site decides to configure it and start it at IPL time is up to them, but
>> the joke has been that "TSO" stands for "Time Sharing Option" but it
>> hadn't been an "Option" for decades... you got it whether you wanted it or
>> not.
>
> Never mind whether they configure it, why would they choose to APPLY &
> ACCEPT it if they don't want it?
>
Maybe because IBM requires it for maintenance purposes? Just guessing!
> "Cruz, Jaime" <Spam...@Bite.Me> wrote:
>
>> FYI: TSO/E has been part of MVS since the days of MVS/SE. Whether the
>> site decides to configure it and start it at IPL time is up to them, but
>> the joke has been that "TSO" stands for "Time Sharing Option" but it
>> hadn't been an "Option" for decades... you got it whether you wanted it or
>> not.
>
> Never mind whether they configure it, why would they choose to APPLY &
> ACCEPT it if they don't want it?
>
LesK
Sep 20, 2012, 11:45:21 PM9/20/12
to
Jeremy Nicoll - news posts
Sep 21, 2012, 6:43:18 AM9/21/12
to
LesK <5mr...@tampabay.rr.com> wrote:
>Maybe because IBM requires it for maintenance purposes? Just guessing!
I don't think it does; maintenance work was (in my experience) run in batch.
>Maybe because IBM requires it for maintenance purposes? Just guessing!
Jeremy Nicoll - news posts
Sep 21, 2012, 7:49:31 AM9/21/12
to
"Cruz, Jaime" <Spam...@Bite.Me> wrote:
> Okay, I rebooted, edited out all the "SysAddRexxMacro" calls, then renamed
> all of the external functions in the directory to lower case. That didn't
> work.
>
> Next, I renamed them to all upper case. BINGO! That worked!
I asked why lower case didn't work (when my 4.1.1 manual says it should) on
> Okay, I rebooted, edited out all the "SysAddRexxMacro" calls, then renamed
> all of the external functions in the directory to lower case. That didn't
> work.
>
> Next, I renamed them to all upper case. BINGO! That worked!
the developer's mail list:
JN: Why does the ref manual say that a lower-case name search will be tried?
Because it IS part of the search order. But that really only applies to the
searches using file extensions. This is not done with the "raw" name
because it resulted in too many false positives with non-rexx programs
(this was actually added at one point, but it had to be backed out). In
the poster's situation, he's created his files without extensions, so only
the matching case is used. If he renamed them to have a ".rex" extension,
then there is much less case insensitivity involved.
I'll raise a DOC error so hopefully someone will clarify this properly in
future manuals.
Shmuel Metz
Sep 21, 2012, 10:06:22 AM9/21/12
to
In <bfSdnQojCeL23MbN...@bestweb.net>, on 09/20/2012
<http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html>,
chopped liver? "Multiple Virtual Storage (MVS). An earlier form of the
z/OS operating system. In current usage, the term MVS refers to those
services and functions of z/OS other than z/OS UNIX system services,
such as those provided by the base control program (BCP), a base
element of z/OS."
at 12:16 PM, Glenn Knickerbocker <No...@bestweb.net> said:
>One would think the correct definitions were the ones the company
>that produced them used, and their definition of MVS hasn't included
>TSO since the overall package was renamed OS/390.
What is
>One would think the correct definitions were the ones the company
>that produced them used, and their definition of MVS hasn't included
>TSO since the overall package was renamed OS/390.
<http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html>,
chopped liver? "Multiple Virtual Storage (MVS). An earlier form of the
z/OS operating system. In current usage, the term MVS refers to those
services and functions of z/OS other than z/OS UNIX system services,
such as those provided by the base control program (BCP), a base
element of z/OS."
Jeremy Nicoll - news posts
Sep 21, 2012, 10:36:27 AM9/21/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>What is
><http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html>,
>chopped liver? "Multiple Virtual Storage (MVS). An earlier form of the
>z/OS operating system. In current usage, the term MVS refers to those
>services and functions of z/OS other than z/OS UNIX system services,
>such as those provided by the base control program (BCP), a base
>element of z/OS."
I'd have thought that would mean for example services provided by various
><http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html>,
>chopped liver? "Multiple Virtual Storage (MVS). An earlier form of the
>z/OS operating system. In current usage, the term MVS refers to those
>services and functions of z/OS other than z/OS UNIX system services,
>such as those provided by the base control program (BCP), a base
>element of z/OS."
system address spaces, eg CATALOG, LLA ...
Mark Miesfeld
Sep 21, 2012, 12:26:32 PM9/21/12
to
On Sep 18, 5:45 pm, "Cruz, Jaime" <Spamm...@Bite.Me> wrote:
> Jaime Cruz wrote:
>
> > Finally, does the .deb package also install the documentation? If so,
> > where did it put it??
>
> > Thanks,
>
> No one has yet answered this question...
No, it doesn't. None of the Linux installs, install the
documentation. You can download the docs separately and put them
where you like. You can get the docs package at:
https://sourceforge.net/projects/oorexx/files/oorexx-docs/4.1.2/
for 4.1.2. Location is similar for other ooRexx versions.
--
Mark Miesfeld
> Jaime Cruz wrote:
>
> > Finally, does the .deb package also install the documentation? If so,
> > where did it put it??
>
> > Thanks,
>
> No one has yet answered this question...
No, it doesn't. None of the Linux installs, install the
documentation. You can download the docs separately and put them
where you like. You can get the docs package at:
https://sourceforge.net/projects/oorexx/files/oorexx-docs/4.1.2/
for 4.1.2. Location is similar for other ooRexx versions.
--
Mark Miesfeld
Shmuel Metz
Sep 21, 2012, 1:02:15 PM9/21/12
to
In <mpro.mao2d4...@wingsandbeaks.org.uk.invalid>, on
09/20/2012
at 10:00 PM, Jeremy Nicoll - news posts
occurred. Only in pre-MVS systems is it possible to install without
including TSO.
>Are you not being blinded
PKB.
>So far as I recall
Your recollection is seriously flawed, and not just on this issue.
09/20/2012
at 10:00 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>So why would some sites not install it, using eg ROSCOE instead?
Why should an elephant fly? I don't need to explain events that never
>So why would some sites not install it, using eg ROSCOE instead?
occurred. Only in pre-MVS systems is it possible to install without
including TSO.
>Are you not being blinded
>So far as I recall
Shmuel Metz
Sep 21, 2012, 1:00:08 PM9/21/12
to
In <mpro.mao8d8...@wingsandbeaks.org.uk.invalid>, on
09/21/2012
at 12:10 AM, Jeremy Nicoll - news posts
09/21/2012
at 12:10 AM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>Never mind whether they configure it, why would they choose to APPLY
>& ACCEPT it if they don't want it?
Because that's how IBM set up the install process.
>Never mind whether they configure it, why would they choose to APPLY
>& ACCEPT it if they don't want it?
Shmuel Metz
Sep 21, 2012, 12:53:12 PM9/21/12
to
In <mpro.manxat...@wingsandbeaks.org.uk.invalid>, on
09/20/2012
at 08:11 PM, Jeremy Nicoll - news posts
Then you've never installed anything more recent than OS/360.
>it's clear that some sites didn't,
What's clear and what's true are often different.
>using eg ROSCOE instead.
An MVS site using Roscoe still has TSO installed, whether they choose
to use it or not.
>And I also know that TSO is not part of MVS.
Then you know more than IBM, because
<http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html>
disagrees with you.
>Frankly I find it amazing that a sysprog could fail to
>see the difference.
The difference is that TSO is part of MVS but MVS is not part of TSO.
HTH.
09/20/2012
at 08:11 PM, Jeremy Nicoll - news posts
Then you've never installed anything more recent than OS/360.
>it's clear that some sites didn't,
>using eg ROSCOE instead.
An MVS site using Roscoe still has TSO installed, whether they choose
to use it or not.
>And I also know that TSO is not part of MVS.
<http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html>
disagrees with you.
>Frankly I find it amazing that a sysprog could fail to
>see the difference.
HTH.
Shmuel Metz
Sep 21, 2012, 12:47:27 PM9/21/12
to
In <mpro.manvq4...@wingsandbeaks.org.uk.invalid>, on
09/20/2012
at 07:37 PM, Jeremy Nicoll - news posts
applications that append a period and some letters to generate names,
but that is a separate issue. I'm not aware of anything analogous to
the way the OS/2 WPS uses extended attributes to provide a file type
for selecting an application.
Some Linux file systems do support metadata, so it would be possible
to do that sort of processing.
09/20/2012
at 07:37 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>Am I wrong (not knowing much about linux) in assuming that provided
>any file, with any name, is marked "executable", that one can use its
>name as a command to run it? That is, without an extension/filetype
>there is nothing outwith the file to tell Linux what to do with the
>file? No meta data, for example?
Neither extension nor file type is a Linux concept. There are
>Am I wrong (not knowing much about linux) in assuming that provided
>any file, with any name, is marked "executable", that one can use its
>name as a command to run it? That is, without an extension/filetype
>there is nothing outwith the file to tell Linux what to do with the
>file? No meta data, for example?
applications that append a period and some letters to generate names,
but that is a separate issue. I'm not aware of anything analogous to
the way the OS/2 WPS uses extended attributes to provide a file type
for selecting an application.
Some Linux file systems do support metadata, so it would be possible
to do that sort of processing.
Shmuel Metz
Sep 21, 2012, 10:18:20 AM9/21/12
to
In <mpro.mantse...@wingsandbeaks.org.uk.invalid>, on
09/20/2012
at 06:55 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>"Cruz, Jaime" <Spam...@Bite.Me> wrote:
>>jaime@jaime-ThinkPad-SL500:~$ Hello
>> 310 *-* Call JCSort
>Shouldn't this be:
> Call 'JCSort'
>because the exact spelling/case of the external function file is
>'JCSort'?
>I would guess that when oorexx sees:
> Call JCSort
>(assuming that JCSort isn't a variable) it replaces "JCSort" with its
>default value which would be "JCSORT", and then fails to find a file
>with that exact name.
I'm not sure about OOREXX, but in OREXX CALL will not treat a simple
symbol as a variable name. CALL JCSort is equivalent to CALL 'JCSORT';
if you want CALL to treat JCSort as a variable name, use CALL
(JCSort).
09/20/2012
at 06:55 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>"Cruz, Jaime" <Spam...@Bite.Me> wrote:
>>jaime@jaime-ThinkPad-SL500:~$ Hello
>> 310 *-* Call JCSort
> Call 'JCSort'
>because the exact spelling/case of the external function file is
>'JCSort'?
>I would guess that when oorexx sees:
> Call JCSort
>(assuming that JCSort isn't a variable) it replaces "JCSort" with its
>default value which would be "JCSORT", and then fails to find a file
>with that exact name.
I'm not sure about OOREXX, but in OREXX CALL will not treat a simple
symbol as a variable name. CALL JCSort is equivalent to CALL 'JCSORT';
if you want CALL to treat JCSort as a variable name, use CALL
(JCSort).
Jeremy Nicoll - news posts
Sep 21, 2012, 2:18:12 PM9/21/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>In <mpro.manxat...@wingsandbeaks.org.uk.invalid>, on
>09/20/2012
> at 08:11 PM, Jeremy Nicoll - news posts
><jn.nntp....@wingsandbeaks.org.uk> said:
>
>>Not only do I think that TSO needn't be installed,
>
>Then you've never installed anything more recent than OS/360.
But I have. Why would you need to install TSO on the system you're
>09/20/2012
> at 08:11 PM, Jeremy Nicoll - news posts
><jn.nntp....@wingsandbeaks.org.uk> said:
>
>>Not only do I think that TSO needn't be installed,
>
>Then you've never installed anything more recent than OS/360.
creating? Obviously you need it or an equivalent - at least an ability to
edit JCL and submit jobs etc on the driving system. And I would agree that
it would be slow using only batch SMP/E to research stuff, but not
impossible.
>>And I also know that TSO is not part of MVS.
>
>Then you know more than IBM, because
><http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html>
>disagrees with you.
Shmuel Metz
Sep 21, 2012, 4:51:46 PM9/21/12
to
In <mpro.mapf8q...@wingsandbeaks.org.uk.invalid>, on
09/21/2012
at 03:36 PM, Jeremy Nicoll - news posts
that there are more than they list. "BCP" means a lot more than system
address spaces.
In <mpro.mappib...@wingsandbeaks.org.uk.invalid>, on
09/21/2012
at 07:18 PM, Jeremy Nicoll - news posts
whether other parts of the system use TSO services under the covers.
>>Then you know more than IBM, because
>><http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html>
>>disagrees with you.
>Where, specifically?
09/21/2012
at 03:36 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>I'd have thought that would mean for example services provided by
>various system address spaces, eg CATALOG, LLA ...
"Everything but Unix" means everything but Unix, and "such as" means
>I'd have thought that would mean for example services provided by
>various system address spaces, eg CATALOG, LLA ...
that there are more than they list. "BCP" means a lot more than system
address spaces.
In <mpro.mappib...@wingsandbeaks.org.uk.invalid>, on
09/21/2012
at 07:18 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>But I have. Why would you need to install TSO on the system you're
>creating?
Because that's how IBM packaged it. There's also a question as to
>But I have. Why would you need to install TSO on the system you're
>creating?
whether other parts of the system use TSO services under the covers.
>>Then you know more than IBM, because
>><http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html>
>>disagrees with you.
>Where, specifically?
"Multiple Virtual Storage (MVS). An earlier form of the z/OS operating
system. In current usage, the term MVS refers to those services and
functions of z/OS other than z/OS UNIX system services, such as those
provided by the base control program (BCP), a base element of z/OS."
system. In current usage, the term MVS refers to those services and
functions of z/OS other than z/OS UNIX system services, such as those
provided by the base control program (BCP), a base element of z/OS."
U. Zinngrebe
Sep 21, 2012, 4:39:40 PM9/21/12
to
Shmuel Metz wrote:
> In <mpro.manvq4...@wingsandbeaks.org.uk.invalid>, on
> 09/20/2012
> at 07:37 PM, Jeremy Nicoll - news posts
> <jn.nntp....@wingsandbeaks.org.uk> said:
>
>>Am I wrong (not knowing much about linux) in assuming that provided
>>any file, with any name, is marked "executable", that one can use its
>>name as a command to run it? That is, without an extension/filetype
>>there is nothing outwith the file to tell Linux what to do with the
>>file? No meta data, for example?
> Neither extension nor file type is a Linux concept.
I respectfully disagree with both.
> In <mpro.manvq4...@wingsandbeaks.org.uk.invalid>, on
> 09/20/2012
> at 07:37 PM, Jeremy Nicoll - news posts
> <jn.nntp....@wingsandbeaks.org.uk> said:
>
>>Am I wrong (not knowing much about linux) in assuming that provided
>>any file, with any name, is marked "executable", that one can use its
>>name as a command to run it? That is, without an extension/filetype
>>there is nothing outwith the file to tell Linux what to do with the
>>file? No meta data, for example?
> Neither extension nor file type is a Linux concept.
But under Linux they are unrelated, so the extension doesn't tell the file
type.
File type can be queried by the file command which checks file content, not
extension. Examples:
uli@ulmo:~/oorexx> file ~/bin/test.rex
/home/uli/bin/test.rex: OS/2 REXX batch file, ISO-8859 text, with
CRLF line terminators
uli@ulmo:~/oorexx> cp ~/bin/test.rex ./data
uli@ulmo:~/oorexx> file data
data: OS/2 REXX batch file, ISO-8859 text, with CRLF line terminators
uli@ulmo:~/oorexx> echo '#! /usr/bin/perl' > data
uli@ulmo:~/oorexx> file data
data: Perl script, ASCII text executable
uli@ulmo:~/oorexx> file /usr/bin/file
/usr/bin/file: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=0x5ec453ea76958cfb1f249a3da9e75fb88a1a247c, stripped
uli@ulmo:~/oorexx> file ~
/home/uli: directory
> I'm not aware of anything analogous to
> the way the OS/2 WPS uses extended attributes to provide a file type
> for selecting an application.
>
> Some Linux file systems do support metadata, so it would be possible
> to do that sort of processing.
>
for filetypes. You can actually associate filename patterns (like file
extensions) to one or several filetypes.
Any combination of desktops may be installed or concurrently running, so it
is understandable that each one manages its own associations, for each user
separately.
A terminal (command line interface) may run embedded in or independently of
a desktop, so I'm not surprised that a shell like bash checks file content
to determine how to process an executable file, apparently ignoring the
desktops.
Cheers, Uli
Glenn Knickerbocker
Sep 21, 2012, 6:41:18 PM9/21/12
to
On 9/21/2012 4:51 PM, Shmuel (Seymour J.) Metz wrote:
>>> <http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html>
>>> disagrees with you.
>>> <http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html>
>>> disagrees with you.
> "Multiple Virtual Storage (MVS). An earlier form of the z/OS operating
> system. In current usage, the term MVS refers to those services and
> functions of z/OS other than z/OS UNIX system services, such as those
> provided by the base control program (BCP), a base element of z/OS."
The product documentation is more specific, though.
> system. In current usage, the term MVS refers to those services and
> functions of z/OS other than z/OS UNIX system services, such as those
> provided by the base control program (BCP), a base element of z/OS."
http://publib.boulder.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.iea%2Fiea.htm
> z/OS MVS
> Description
> MVS provides the essential operating system services of z/OS. It
includes the I/O Control Program, the z/OS UNIX System Services Kernel,
and z/OS XML System Services.
If you look for information about TSO, JES, RACF, etc. in the MVS books,
you won't find it.
ŹR
Jeremy Nicoll - news posts
Sep 21, 2012, 6:44:26 PM9/21/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
> "Multiple Virtual Storage (MVS). An earlier form of the z/OS operating
> system. In current usage, the term MVS refers to those services and
> functions of z/OS other than z/OS UNIX system services, such as those
> provided by the base control program (BCP), a base element of z/OS."
But this text is not explicit which services are part of z/OS and which are
> system. In current usage, the term MVS refers to those services and
> functions of z/OS other than z/OS UNIX system services, such as those
> provided by the base control program (BCP), a base element of z/OS."
not.
Is RACF? Is RMF? ...
Cruz, Jaime
Sep 21, 2012, 7:00:05 PM9/21/12
to
Mark Miesfeld wrote:
> On Sep 18, 5:45 pm, "Cruz, Jaime" <Spamm...@Bite.Me> wrote:
>> Jaime Cruz wrote:
>>
>>> Finally, does the .deb package also install the documentation? If so,
>>> where did it put it??
>>
>>> Thanks,
>>
>> No one has yet answered this question...
>
> No, it doesn't. None of the Linux installs, install the
> documentation. You can download the docs separately and put them
> where you like. You can get the docs package at:
>
> https://sourceforge.net/projects/oorexx/files/oorexx-docs/4.1.2/
>
> for 4.1.2. Location is similar for other ooRexx versions.
>
> --
> Mark Miesfeld
>
Thank you!!
> On Sep 18, 5:45 pm, "Cruz, Jaime" <Spamm...@Bite.Me> wrote:
>> Jaime Cruz wrote:
>>
>>> Finally, does the .deb package also install the documentation? If so,
>>> where did it put it??
>>
>>> Thanks,
>>
>> No one has yet answered this question...
>
> No, it doesn't. None of the Linux installs, install the
> documentation. You can download the docs separately and put them
> where you like. You can get the docs package at:
>
> https://sourceforge.net/projects/oorexx/files/oorexx-docs/4.1.2/
>
> for 4.1.2. Location is similar for other ooRexx versions.
>
> --
> Mark Miesfeld
>
--
Jaime A. Cruz
Secretary
Cruz, Jaime
Sep 21, 2012, 7:37:01 PM9/21/12
to
Jeremy Nicoll - news posts wrote:
> "Cruz, Jaime" <Spam...@Bite.Me> wrote:
>
>> Okay, I rebooted, edited out all the "SysAddRexxMacro" calls, then renamed
>> all of the external functions in the directory to lower case. That didn't
>> work.
>>
>> Next, I renamed them to all upper case. BINGO! That worked!
>
> I asked why lower case didn't work (when my 4.1.1 manual says it should) on
> the developer's mail list:
>
>
> JN: Why does the ref manual say that a lower-case name search will be tried?
>
> Because it IS part of the search order. But that really only applies to the
> searches using file extensions. This is not done with the "raw" name
> because it resulted in too many false positives with non-rexx programs
> (this was actually added at one point, but it had to be backed out). In
> the poster's situation, he's created his files without extensions, so only
> the matching case is used. If he renamed them to have a ".rex" extension,
> then there is much less case insensitivity involved.
>
>
> I'll raise a DOC error so hopefully someone will clarify this properly in
> future manuals.
>
>
Confirmed. I changed all the external function names to all lower case
>
>> Okay, I rebooted, edited out all the "SysAddRexxMacro" calls, then renamed
>> all of the external functions in the directory to lower case. That didn't
>> work.
>>
>> Next, I renamed them to all upper case. BINGO! That worked!
>
> I asked why lower case didn't work (when my 4.1.1 manual says it should) on
> the developer's mail list:
>
>
> JN: Why does the ref manual say that a lower-case name search will be tried?
>
> Because it IS part of the search order. But that really only applies to the
> searches using file extensions. This is not done with the "raw" name
> because it resulted in too many false positives with non-rexx programs
> (this was actually added at one point, but it had to be backed out). In
> the poster's situation, he's created his files without extensions, so only
> the matching case is used. If he renamed them to have a ".rex" extension,
> then there is much less case insensitivity involved.
>
>
> I'll raise a DOC error so hopefully someone will clarify this properly in
> future manuals.
>
>
and added the .rex extension and that too works. Interesting. However,
if I add the .rex extension to the main EXEC, I have to specify the
extension when I invoke it or it isn't found.
Linux is just so much more confusing than Windows or OS/2, but I'm
learning it more and more every day. I'm just not likely to install it
on my mother's computer just yet...
Shmuel Metz
Sep 22, 2012, 9:40:48 PM9/22/12
to
In <505cd08c$0$713$7ade...@textreader.nntp.internl.net>, on
09/21/2012
09/21/2012
at 10:39 PM, "U. Zinngrebe" <Na...@inter.NL.net> said:
>But under Linux they are unrelated, so the extension doesn't tell the
>file type.
What is a file extension under Linux?
>But under Linux they are unrelated, so the extension doesn't tell the
>file type.
Shmuel Metz
Sep 22, 2012, 9:43:03 PM9/22/12
to
In <-cWdndzCMtGecMHN...@bestweb.net>, on 09/21/2012
part of the online publications catalog.
In <mpro.maq1u1...@wingsandbeaks.org.uk.invalid>, on
09/21/2012
at 11:44 PM, Jeremy Nicoll - news posts
without a license.
at 06:41 PM, Glenn Knickerbocker <No...@bestweb.net> said:
>The product documentation is more specific, though.
>http://publib.boulder.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.iea%2Fiea.htm
The text on that page is not part of the product documentation; it is
>The product documentation is more specific, though.
>http://publib.boulder.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.iea%2Fiea.htm
part of the online publications catalog.
In <mpro.maq1u1...@wingsandbeaks.org.uk.invalid>, on
09/21/2012
at 11:44 PM, Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> said:
>But this text is not explicit which services are part of z/OS and
>which are not.
>Is RACF? Is RMF?
I'd say that those are features of MVS but that they are inoperable
>But this text is not explicit which services are part of z/OS and
>which are not.
>Is RACF? Is RMF?
without a license.
U. Zinngrebe
Sep 23, 2012, 6:47:58 AM9/23/12
to
Shmuel Metz wrote:
> In <505cd08c$0$713$7ade...@textreader.nntp.internl.net>, on
> 09/21/2012
> at 10:39 PM, "U. Zinngrebe" <Na...@inter.NL.net> said:
>
>>But under Linux they are unrelated, so the extension doesn't tell the
>>file type.
>
> What is a file extension under Linux?
>
The smallest suffix part of a file basename, separated by a dot.
> In <505cd08c$0$713$7ade...@textreader.nntp.internl.net>, on
> 09/21/2012
> at 10:39 PM, "U. Zinngrebe" <Na...@inter.NL.net> said:
>
>>But under Linux they are unrelated, so the extension doesn't tell the
>>file type.
>
> What is a file extension under Linux?
>
example:
uli@ulmo:~> filespec=~/bin.bak/test.rex.tar.gz
uli@ulmo:~> filename=`basename $filespec`
uli@ulmo:~> extension=${filename##*.}
uli@ulmo:~> echo $extension
gz
0 new messages