Hey Charles, > I know exactly how to execute a Started Task written in Rexx, and I know most > of the gotchas.
Could you expand a bit on this please. I have this compiled REXX called MON3B from IBM, from 2016. https://ftpmirror.your.org/pub/misc/ftp.software.ibm.com/s390/zos/wlm/MonitorIIIBatch-v1.10.pdf Is cancelling it the only way to stop it, if the source for the REXX isn't available to modify? - KB ------- Original Message ------- On Sunday, June 19th, 2022 at 10:45 PM, Charles Mills <charl...@mcn.org> wrote: > > Why not use Python? Good question. > > > 1. I can undoubtedly do it perfectly satisfactorily, and almost certainly > more quickly, in Rexx (because of the learning curve). I would have trouble > justifying billing the client for my Python learning time when there is > little benefit (that I know of -- correct me if I am wrong) for the client > who is paying the bills. > > Why not, then, learn Python on my own time? Don't I want to learn Python? Yes > I do, but there are only so many hours in a day, and there are other things I > want to learn more than I do Python. For example, I would rather spend the > time learning to make the Roman-Jewish fried artichokes that are in the > current Cooks Illustrated. Learning Python is just not very high on my bucket > list. It's there, but probably not high enough to ever rise to the top. > > 2. I know exactly how to execute a Started Task written in Rexx, and I know > most of the gotchas. In my experience, THAT is the problem with the "new > tools" on z/OS. What would I have to do to execute a Started Task written in > Python? What are the gotchas? Heck, what do I have to do to set up any Python > environment at all? That is the time-consuming issue, and it holds about zero > personal gratification for me. I could probably learn the Python language > pretty readily, and it would be one more notch in my belt. Solving the > probable gotchas of getting Python to actually do productive work on z/OS -- > not so much. > > > it would trivial to serve those reports as a REST API > > > Neat, but that is not what the client (who is paying the bills) wants. He > wants a trivial-to-read-on-his-iPhone email in his inbox every morning. > Again, it would be nice to have "how to write a REST API" in my toolkit, but > not nice enough for me to learn it on my own time. Frankly, I am in an "I > wish I had less work on my plate" mode and I would probably rather learn that > artichoke recipe than learn to write REST APIs even if I were getting paid > for the learning time. > > > use SQLite instead of a file which will significantly simplify writing > > reports > > > Not for me, and probably not for the "report" (I am flattering the > requirement calling it a report -- maybe call it an "alert") that the client > wants. And again, a learning curve that is difficult to justify. > > So I think I will write it in Rexx, with perhaps a little bit of Assembler. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of David Crayford > Sent: Saturday, June 18, 2022 11:43 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Some UNIX file usage questions > > On 19/06/2022 1:33 am, Paul Gilmartin wrote: > > > On Sat, 18 Jun 2022 09:51:45 -0700, Charles Mills wrote: > > > > > ... > > > I picture writing the started task in Rexx, so I would have to write to a > > > DD > > > name allocated to the UNIX file (either dynamically or with JCL), not with > > > "native" C fopen(), fwrite(), etc. Does that change any of the answers? > > > > Why? In Rexx you can "address SYASCALL write ..." instead. > > > Why REXX? Is it a case of knowing the banjo so you play Stairway to > Heaven in the style of Earl Schruggs? > > Why not use IBMs z/OS Python? You can then use SQLite instead of a file > which will significantly simplify writing reports. In fact, it would > trivial to serve those > reports as a REST API and put a nice WebUI on top using a simple > template that supports data tables. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
