Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

You're on your own for z/OS-specific python scripts. Mr. Google will let you see many python examples out on the net, but none I suspect oriented on z/OS facilities. As for JCL, I use IBM's batch utility to run awk scripts, I don't know of python will work in the same way due to the

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

All of this sounds interesting, so if I wanted to try out some Python scripts to see how they stack up to Rexx, where might I find some Python source members along with JCL members to run them? Thanks! Billy -- Original Message -- From "Farley, Peter x23353"

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

It is my understanding that Java is and has been available in z/OS for a long time now, but not from TSO or CLIST directly. From REXX via SYSCALL and BPXWUNIX I suspect it is possible, but not from, e.g., the TSO / ISPF command line directly. The python interpreter is I think going to be

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I keep seeing references like this, from time to time, but so far whenever I ask I get answers that aren't quite what I was looking for. Am I hearing that both Java and Python are available in TSO, like CLIST and REXX? Or only in some environment with which I am (so far) unfamiliar, such as

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> If only I could remember CLIST, Tom! If only I could forget CLIST! The paired apostrophes could replicate to an obscene degree, especially after the enhancements in OS/VS2 R3.6; REXX is much cleaner. Do you mean that IBM's JS port is faster, or that you prefer JS to Python? If the latter,

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 12/1/22 1:41 am, Tom Brennan wrote: Nice! Now do CLIST If only I could remember CLIST, Tom! I did work on a project last year where I had to convert 3 CLIST scripts to REXX and it quite was painful. Variable substitution killed me, but I remembered it from the NetMaster NCL language. I

Re: Top 8 Reasons for using Python instead of REXX for z/OS

I can't remember other than it was only around 10 lines. I think just variable access and some simple calculations. On 1/11/2022 10:47 AM, Paul Gilmartin wrote: What didn't your "small performance test" do? -- For IBM-MAIN

Re: Top 8 Reasons for using Python instead of REXX for z/OS

(Subject: and content trimmed.) On Tue, 11 Jan 2022 09:41:23 -0800, Tom Brennan wrote: >... >finally pushed me over: I ran a small performance test and Rexx beat >CLIST by about 1000 times if I remember correctly. So I pulled out the >Rexx manuals. > Back in the day when fiche was available

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Nice! Now do CLIST Ok, just joking. I was probably the last person on my block to switch from CLIST to Rexx when it became available on MVS. A simple thing finally pushed me over: I ran a small performance test and Rexx beat CLIST by about 1000 times if I remember correctly. So I pulled

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 11.01.2022 14:06, David Crayford wrote: > I've gone silent now Rony. But if you're a Windows user you may want to check > out Measure-Command > for PowerShell so you don't have to instrument your code with timers. > > [1] >

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I've gone silent now Rony. But if you're a Windows user you may want to check out Measure-Command for PowerShell so you don't have to instrument your code with timers. [1] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/measure-command?view=powershell-7.2 On

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

And here an example of ooRexx being used without any direct access to Java: d1=.datetime~new /* take time */ "java squares"/* run command */ d2=.datetime~new /* take time */ say "duration:" d2-d1 The results of running this program are:

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Now, if you want ooRexx to control an application and need to run the NetRexx program from it, you can do that with ooRexx (including timings) as such: /* ooRexx solution to control execution of NetRexx' squares */ clz=bsf.loadClass("squares") /* load NetRexx' squares class */ /*

Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 11.01.2022 05:46, David Crayford wrote: > On 10/1/22 11:15 pm, Seymour J Metz wrote: >>> ooRexx will never be high speed because it's implementation is >>> fundamentally ineffecient. >> That seems to be begging the question. Certainly the current implementation >> is inefficient, but >> what

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 10/1/22 11:28 pm, René Jansen wrote: I find that a very interesting question - I think there is no real reason, and that is one of the things CREXX is trying to prove. I've already said enough in this thread. CREXX looks interesting and fun. I'm happy to contribute. For the other

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 10/1/22 11:15 pm, Seymour J Metz wrote: ooRexx will never be high speed because it's implementation is fundamentally ineffecient. That seems to be begging the question. Certainly the current implementation is inefficient, but what fundamental issue prevents a more efficient implementation?

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Please be careful with attributions; "fundamentally ineffecient" was David, not me. I was questioning his claim. OOREXX does seem to be less efficient than SAA ("classic") REXX, but I use it regardless because of its expressive power. I know of no barrier to a more efficient design, nor do I

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Am 10.01.2022 um 16:16 schrieb Seymour J Metz : > >  >> >> ooRexx will never be high speed because it's implementation is >> fundamentally ineffecient. No, for what ooRexx does and allows for it is not „fundamentally inefficient“. If forgoing all its helpful new features, because all of a

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I find that a very interesting question - I think there is no real reason, and that is one of the things CREXX is trying to prove. For the other things, other mailing lists. But we have to remember that ooRexx is doing a lot of work like keeping activation records and doing garbage collection,

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> ooRexx will never be high speed because it's implementation is > fundamentally ineffecient. That seems to be begging the question. Certainly the current implementation is inefficient, but what fundamental issue prevents a more efficient implementation? For that matter, what fundamental issue

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> > Am 10.01.2022 um 15:34 schrieb David Crayford : > > On 10/1/22 10:10 pm, Rony G. Flatscher wrote: >>> On 10/1/22 8:34 pm, Rony G. Flatscher wrote: > On 09.01.2022 16:29, Seymour J Metz wrote: >>> Well all of your languages miss the support for the message paradigm. >> What do

Re: Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> > Am 10.01.2022 um 15:22 schrieb Seymour J Metz : > >  >> >> As a little teaser, if interested, just look-up the ooRexx runtime objects >> named .input, .output and .error. > > Aren't those just monitor objects? Yes. They monitor stdin, stdout and stderr (all three are streams that could

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

That page has other issues. The “IBM Open XL Fortran for AIX” and the “IBM XL Fortran for AIX” refer to the same page. The "IBM XL Fortran for Linux” link omits to mention that is it also Open, but only for Power systems; it doesn’t mention the repo from which the community edition is to be

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

When I follow that link - very s l o w it is I might add - I see: IBM® VS FORTRAN compiles FORTRAN code to generate efficient applications for the IBM z/OS® and IBM z/VM® platforms. It includes a compiler, a library and interactive debugging facilities. Is it not supported? That might be

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> AFAIK, there is no officially supported Fortran (or Ada) compiler for z/OS "mainframe ¬= 'z/OS" > we had to port a Fortran to C transpiler. ? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> One important thing though: if you have no need for these features do not use > them! :) Why? I find chained messages more readable than nested function calls. Similarly, I find "foo[expresion]" more readable than "bar=expression;foo.bar". -- Shmuel (Seymour J.) Metz

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 10/1/22 10:10 pm, Rony G. Flatscher wrote: On 10/1/22 8:34 pm, Rony G. Flatscher wrote: On 09.01.2022 16:29, Seymour J Metz wrote: Well all of your languages miss the support for the message paradigm. What do you mean by "the message paradigm"? How does it differ from sending method

Re: Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> As a little teaser, if interested, just look-up the ooRexx runtime objects > named .input, .output and .error. Aren't those just monitor objects? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 10.01.2022 14:13, David Crayford wrote: > On 10/1/22 8:34 pm, Rony G. Flatscher wrote: >> On 09.01.2022 16:29, Seymour J Metz wrote: Well all of your languages miss the support for the message paradigm. >>> What do you mean by "the message paradigm"? How does it differ from sending >>>

Re: EXTERNAL: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

The 4GL's from the 80's had two problems, as I remember. First, if you wanted to customize something, make it a little snazzier than out of the box, you had to od some pretty wicked things that weren't human language like at all. Second, they didn't perform as well as real programming

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 10/1/22 8:34 pm, Rony G. Flatscher wrote: On 09.01.2022 16:29, Seymour J Metz wrote: Well all of your languages miss the support for the message paradigm. What do you mean by "the message paradigm"? How does it differ from sending method invocation and response messages to objects? The

Re: Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 10.01.2022 05:28, David Crayford wrote: > On 9/1/22 11:22 pm, Rony G. Flatscher wrote: >> On 09.01.2022 03:19, David Crayford wrote: >>> On 9/1/22 2:15 am, Rony G. Flatscher wrote: On 08.01.2022 01:52, David Crayford wrote: > On 7/1/22 7:53 pm, Rony G. Flatscher wrote: ... cut ...

Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 09.01.2022 16:29, Seymour J Metz wrote: >> Well all of your languages miss the support for the message paradigm. > What do you mean by "the message paradigm"? How does it differ from sending > method invocation and response messages to objects? The message paradigm as set forth by Smalltalk

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 10/1/22 6:13 am, Seymour J Metz wrote: he raison d'être of the mainframe is to run applications written in COBOL. What is FORTRAN, chopped liver? AFAIK, there is no officially supported Fortran (or Ada) compiler for z/OS. When Rocket ported the R programming language to z/OS we had to

Re: Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 9/1/22 11:22 pm, Rony G. Flatscher wrote: On 09.01.2022 03:19, David Crayford wrote: On 9/1/22 2:15 am, Rony G. Flatscher wrote: On 08.01.2022 01:52, David Crayford wrote: On 7/1/22 7:53 pm, Rony G. Flatscher wrote: ... cut ... Well all of your languages miss the support for the message

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

He was talking about NetREXX. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Fatal error; system halted. Press any key to do nothing. */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Sunday, January 9, 2022 19:28 Which Rexx?

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Sun, 9 Jan 2022 18:38:07 -0400, René Jansen wrote: >... >In the meantime, the case in which you just quote the command you would like >to be executed, works very well. Quoting commands sounds like the way (FSVO) good old Rexx works. >> On 9 Jan 2022, at 18:34, Seymour J Metz wrote: >>

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Create the temp file. Open it. Unlink it. When you close the file, it will be removed by the filesystem. Until then, the inside exists without a directory entry. On Sun, Jan 9, 2022, 16:51 Seymour J Metz wrote: > Unique names for temporary Unix files is trivial. Making them go away at > the

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Sun, 9 Jan 2022 22:50:46 +, Seymour J Metz wrote: >Unique names for temporary Unix files is trivial. Making them go away at the >completion of the work is more difficult. > Most implementations of tmpfile() unlink the file immediately on creating it, before returning to the caller. z/OS

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Yeah, I've become a BIG fan of comments in my old age. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* He that is of the opinion money will do everything may well be suspected of doing everything for money. -Ben Franklin */ -Original Message- From: IBM Mainframe

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I think that is a very valid requirement. Due to the platform it is running on, the JSR223 interface would also be usable for that purpose, although that is also rather light on retaining state at the moment. It will not be in the next release (4.02) because that is functionally closing, but

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

What I want to do is to register environments and function packages in a manner similar to what REXX supports, including retaining context. For instance, I would like for an editor to be able to call an edit macro written in NetRexx and allow the macro to issue commands and queries back to the

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Well, I've promoted the use of symbolic parameters since OS/360 R14, causing me to curse the old 100 character limit on PARM. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I don't like anything complex enough that I have trouble figuring out what the original programmer had in mind. The worst though, is when I get halfway into something I'm already complaining about, then realize it's my own code I wrote 10 years earlier :) On 1/9/2022 2:17 PM, Seymour J Metz

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Unique names for temporary Unix files is trivial. Making them go away at the completion of the work is more difficult. The user can also make ad hoc changes to many scripts by changing environment variables or configuration files. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Yes, we are working on that. If you can tell me what you want to see, we’ll have a go. In the meantime, the case in which you just quote the command you would like to be executed, works very well. Best regards, René. > On 9 Jan 2022, at 18:34, Seymour J Metz wrote: > > I downloaded the

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I downloaded the new documentation, and address doesn't seem to have the same semantics as in REXX. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of René Jansen

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I take it you don't like REXX scripts, since they can conditionally select different dynamic allocations. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Brennan

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> he raison d'être of the mainframe is to run applications written in COBOL. What is FORTRAN, chopped liver? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David

Re: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> I could be wrong, but I think the first use of "macro" in a > programming/computer context was introduced in Assembler languages: The first programming use of the term macro that I'm aware of was 705 Autocoder. The first macro assembler that I'm aware of to allow conditional code generation

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Hi Shmuel. NetRexx has ADDRESS. It was added by Marc Remes in release 4.01. It can address any executable on your system. Subsequent versions will add ADDRESS WITH for collections and network. This was a syntactical addition, the runtime contains, for years and years already, the package

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I wish, but I had no access to their outside network. My work was done locally via crash cart. On 1/9/2022 10:33 AM, Paul Gilmartin wrote: On Sun, 9 Jan 2022 10:04:52 -0800, Tom Brennan wrote: ... shouldn't I call the customer and make sure he can remotely access the unit? ProTip:

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Sun, 9 Jan 2022 10:04:52 -0800, Tom Brennan wrote: >... >shouldn't I call the customer and make sure he can remotely access the >unit? > ProTip: When I pretend to be an operator and want to know whether the link to Remotehost is working, I don't ask the local host. I ask Remotehost via

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 1/9/2022 7:25 AM, Rony G. Flatscher wrote: Ah, "http" instead of "https", sorry (wrote it from memory and did not test it) ! I have this joke I try to follow that sometimes makes the people I work with upset with me: "Unless you tested it, there is *absolutely* no way it will work". A

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I've always felt that a professional should be willing and able to learn new tools while continuing to use old tools when appropriate. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

While REXX is my preferred scripting language, my passion is languages that are or were leading edge, e.g., Icon, SETL. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I'm a TSO bigot, but my main objections to Unix System Services (née MVS OpenEdition) have not been based ondislike for Unix. Rather, I saw two major flaws in the goals. In the Unix world, there are requirements for certification, but there is a large ecology of tools that users have come to

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I would, in general, not compare any programming language to any natural language. The evolution of natural languages was driven by the types of challenges we faced over the millenia, and those did not require expressing algorithms and data structures. COBOL may be a terrible language, but it

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> Well all of your languages miss the support for the message paradigm. What do you mean by "the message paradigm"? How does it differ from sending method invocation and response messages to objects? > NetRexx follows the Rexx philosophy, FSVO follows. NetRexx doesn't have the concept of

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 09.01.2022 05:52, Wayne Bickerdike wrote: > I couldn't find Netrexx at (https://www.netrexx.org), I did find it here > http://www.netrexx.org Ah, "http" instead of "https", sorry (wrote it from memory and did not test it) ! > I like it! +1 ---rony ... cut ...

Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 09.01.2022 03:19, David Crayford wrote: > On 9/1/22 2:15 am, Rony G. Flatscher wrote: >> On 08.01.2022 01:52, David Crayford wrote: >>> On 7/1/22 7:53 pm, Rony G. Flatscher wrote: ... cut ...  >> Well all of your languages miss the support for the message paradigm. > > What on earth are

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I couldn't find Netrexx at (https://www.netrexx.org), I did find it here http://www.netrexx.org I like it! On Sun, Jan 9, 2022 at 1:20 PM David Crayford wrote: > On 9/1/22 2:15 am, Rony G. Flatscher wrote: > > On 08.01.2022 01:52, David Crayford wrote: > >> On

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 9/1/22 2:15 am, Rony G. Flatscher wrote: On 08.01.2022 01:52, David Crayford wrote: On 7/1/22 7:53 pm, Rony G. Flatscher wrote: Here is my list of must haves for a scripting language. Does REXX or ooRexx meet the requirements? 1. Short circuit evaluation 2. Functions as first class

Re: VBA -> ooRexx and ooRexx -> VBA (Re: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I've mentioned before that once I dropped my first major, I floundered around a little before settling on Accounting. I had a best friend who was moving from Pennsylvania to southern California about this time, and he came by way of North Carolina to give me a visit on his way out there. He'd

Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 08.01.2022 01:52, David Crayford wrote: > On 7/1/22 7:53 pm, Rony G. Flatscher wrote: >>> Here is my list of must haves for a scripting language. Does REXX or ooRexx >>> meet the requirements? >>> >>> 1. Short circuit evaluation >>> 2. Functions as first class objects >>> 3. Mutli-threading

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Before saying something like "COBOL is terrible compared to the English language" try studying a remote analysis of common, everyday English sentences --- the study based on a wholly different language base. The order of words in English, and the exact meaning of the order in a particular

Re: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 07.01.2022 17:38, Seymour J Metz wrote: > Some language purists claim that the messages are an intrinsic part of > object-oriented programming. Check the documentation for Concurrency or for > the REPLY instruction for some context. > > I always thought that object-oriented programming

VBA -> ooRexx and ooRexx -> VBA (Re: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 07.01.2022 16:16, Bob Bridges wrote: > When I first started learning ooREXX (not that long ago, and I still don't > know it well) I read that bit about "messages" that are apparently sent to > methods and properties and was confused. My only object-oriented language at > the time was VB

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Link to the Lua CICSs 3270 SHARE presentation shorturl.at/ilyFG On 8/1/22 10:29 pm, David Crayford wrote: I think we will have to agree to disagree Rene. I certainly don't want to engage in a sh**storm because I respect you. I'm a REXX expert. Not only do I know the language I have written

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I agree, let’s agree we both like Java. > On 8 Jan 2022, at 10:29, David Crayford wrote: > > I think we will have to agree to disagree Rene. I certainly don't want to > engage in a sh**storm because I respect you. -- For

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I think USS is very interesting, a great technical accomplishment, but it is generally agreed that the differences with other Unices made life different for people wanting to use it in anger for applications. It gives z/OS the Unix system calls in a library that wraps MVS supervisor calls, and

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I think we will have to agree to disagree Rene. I certainly don't want to engage in a sh**storm because I respect you. I'm a REXX expert. Not only do I know the language I have written many extensions. It's not easy because the REXX API is designed for HLASM so I had to write a CEEPIPI glue

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I've not followed this thread. But, one thing I saw in your latest reply, about z/OS USS/Open Edition and Linux. USS/Open Edition is/was a port of UNIX. I remember the IBM marketing presentation about OE/USS, the local IBM rep stated "more UNIX than UNIX". -Original Message- From:

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

“the passionate programmer”, I think I’ll keep that. > On 8 Jan 2022, at 09:19, W Mainframe > <01304632a58d-dmarc-requ...@listserv.ua.edu> wrote: > > If you are coding as professional, use the best language for that, if you are > coding by passion, just use Rexx... :) > Dan >

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I thought gmail had eaten my reply so I took some time to give you a more elaborate reaction. I am still sorry that you need to resort to ad-hominems but I would like to give you some facts. It is not only my undeniable love for Rexx (but I do program in anything that the job requires, even

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Speaking as a PL/1 bigot -- it was my first language -- there's no doubt you're right. I dislike COBOL for its wordiness, but even I have to admit that aside from that it's powerful enough to do the job and a bit over. I have occasionally had to pause to reluctantly admire its ability to do

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

If you are coding as professional, use the best language for that, if you are coding by passion, just use Rexx... :) Dan Sent from Yahoo Mail for iPhone On Saturday, January 8, 2022, 8:50 AM, David Crayford wrote: Nobody is denying the value of that code. I wrote thousands of lines of REXX 

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Nobody is denying the value of that code. I wrote thousands of lines of REXX code for system automation back in the 90s I just can’t find a use case for writing new REXX code today. Everything had changed. > On 8 Jan 2022, at 19:40, René Jansen wrote: > > Well I am explicitly not reacting

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Well I am explicitly not reacting on another round of namecalling. What is worrying to me is the denial of the value of all existing interfaces in the OS and infrastructure to the standard scripting language on the platform, making the ‘modernization’ effort a reduction to uss, which will be

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Why not compile lua to support utf8? Your unrelenting love of REXX worries me. it’s the perfect example of personal preference over a functional requirement which is unprofessional and a red flag. > On 8 Jan 2022, at 14:57, René Jansen wrote: > > I looked at your list and I am happy to

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I looked at your list and I am happy to see that these include the things you find important. JS is undeniably a big factor but “the good parts” is a thin booklet. As is groovy - slow and nevery had any appeal to me, just looks messy. I quite like Ruby as an idea but slow as molasses. Today I

Re: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I could be wrong, but I think the first use of "macro" in a programming/computer context was introduced in Assembler languages:  A macro invocation statement basically looked like an assembly statement with parameters, but instead of generating a single machine instruction or data definition

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 8/1/22 1:42 am, Tony Harminc wrote: On Fri, 7 Jan 2022 at 11:45, Lionel B. Dyck wrote: I've been following this thread and one thing that has yet to appear, or I missed it, has to do with 4GL's and the drive, at one point, for languages that were more human oriented - those that could be

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 7/1/22 8:35 pm, Ronald Wells wrote: Most hackable If by hackable you mean it's not secure then that's far from true. Everything is Lua is contained in a single data structure, the table. Game mods and frameworks such as Redis use a technique called sandboxing to remove anything that

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 7/1/22 8:44 pm, Matt Hogstrom wrote: A path forward that would make sense would be a new job control language like HELM that is familiar and modern and Kubernetes is the scheduler that runs the jobs. Embracing the new paradigms along side the existing models is what we as practitioners

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Friday 07/01/2022 at 4:41 pm, Seymour J Metz wrote: COBOL was supposed to be that, no? The use of "magic numbers" as levels in the DATA DIVISION totally blows away any claim that COBOL is English like or understandable to someone without training. 66 foo PIC X(10). The syntax of 66

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 7/1/22 7:53 pm, Rony G. Flatscher wrote: Here is my list of must haves for a scripting language. Does REXX or ooRexx meet the requirements? 1. Short circuit evaluation 2. Functions as first class objects 3. Mutli-threading 4. Dynamically typed, preferably with type hints 5. co-routintes 6.

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I was more talking about JCL forcing the DD-to-dataset relationships into one place, which makes them easier to find. Here's a line I had to mess with last week in a Linux shell script: $IM_INSTALL_LOCATION/eclipse/IBMIM -input "$SCRIPTHOME/updateSKLM.xml" While those $ variables are set in

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Fri, 7 Jan 2022 20:30:03 +, Seymour J Metz wrote: >> Would it be a favor to programmers to make misiplacing IF, etc. >> within a job step, or SET within IF ... ENDIF a syntax error? The >> effect is probably not what the programmers intend. > >IMHO, the current behavior is a bug, but it

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

One of the better 4GLs I worked with was IDEAL from ADR, later CA and Broadcom. It had FOR ENDFOR SELECT IF THEN ELSE LOOP ENDLOOP and GOTOless... It fitted very nicely with James Martin and Michael Jackson (MJSL) programming and design methodologies. Other awful 4GLs, Natural (ADABAS). I

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Fri, 7 Jan 2022 19:43:58 +, Seymour J Metz wrote: >Well, if you introduced the concept of steps into a script language then it >shouldn't be too hard to also add the concept of passed data sets. Named >temporary data sets also shouldn't be difficult. Or you could just use, e.g.,

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Not strictly speaking, no. But find me an old-timer (especially manager types) who is symbol-aware and actively uses them or promotes their extensive use in crafting PROC's for other than UNIT, REGION and sometimes HLQ and SPACE. I have faced active resistance on several jobs to my "overuse"

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I believe that reall AI will eventually arrive, and there has certainly been progress, but I no longer believe in the fairy tale that it is only 5 years away. I wish that here was a likeklihood that we would address the ethical issues before then, but I doubt it. -- Shmuel (Seymour J.) Metz

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I agree with Shmuel; we heard a lot about 4GLs back in the '80s and '90s, but I never saw one that lived up to the claims. DYL-280II, for example, was advertised as a 4GL, but it wasn't close. Don't get me wrong, as a 3GL I liked it just fine, and my company had me teach it to end users so they

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

+There's no forced standard for the choice of ddnames either; you need to know whether it's INPUT, SYSIN, SYSUT1 or "E. None of the above." -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I know of languages that have been peddled as human oriented or English like; I don't know of any that even come close. As for REXX, I find it comfortable but it too has pitfalls. See, e.g., , .

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Yes, but since there's no forced standard, variables and other methods mean I might have to look the script or code to figure out what's going on. Sometimes that can get quite complex with the things people do that eventually comes up with a filename/path string. JCL makes everything nice

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> COBOL was supposed to be that, no? The use of "magic numbers" as levels in the DATA DIVISION totally blows away any claim that COBOL is English like or understandable to someone without training. 66 foo PIC X(10). 77 bar PIC X(10). 88 baz VALUE "S", "Y". Then there is the weird behavior

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

> Would it be a favor to programmers to make misiplacing IF, etc. > within a job step, or SET within IF ... ENDIF a syntax error? The > effect is probably not what the programmers intend. IMHO, the current behavior is a bug, but it might take an RFE to get it fixed, and IBM might add a

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

The Initiator does the ENQ, not JES. By that time the Converter and Interpreter have already run. The condition code is unknown until the job actually runs, far too late for the Converter to examine it. The issue transcends the ENQ. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3

  1   2   3   4   >