I *think* it would be possible to monitor the console ECB from Rexx, and
extract any MODIFY text -- you can do almost anything in Rexx with enough
C2D()'s -- but multiple levels of C2D() does not exactly make for a pretty
application. I think it would be Rexx abuse.
Answering @kekronbekron's question, I don't think there is any "system"
facility that lets a program written in Rexx be aware of STOP or MODIFY. I have
two similar Rexx STC's -- one is essentially version zero of the app I am
designing here, and will be replaced by it -- and for both, I admit it, the
command to stop them is CANCEL. :-(
I don't think there is any facility for Rexx running in batch-type
environments, whether compiled or interpreted, including as an STC, to process
HI (Halt Interpretation, not "Hello!"). I would be happy if someone would
correct me.
What I keep meaning to do, and will do as part of this application, is write a
little assembler (sorry, David <g>) routine to solve this issue. All of these
STC's have the general flow
Do Forever
Perform some sort of processing
Delay several minutes
(Watch out if the list folds those lines!)
The assembler routine will take as input a delay time in hundredths of a second
(because of STIMER), do a WAIT ECBLIST, and return one of
'T' -- the time expired
'P' -- the operator entered STOP
'F modify command operand' -- the operator entered MODIFY
That will make for an application that could be halted without CANCEL, and also
could potentially be re-parametized on the fly.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Crayford
Sent: Sunday, June 19, 2022 10:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions
On 20/06/2022 12:08 pm, wrote:
> 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?
If it's written in REXX I very much doubt it's handling operator
commands. That would require a console handler thread which is waaayyy
outside the limits of the language. I'm not familar with this product
and RMF is one of our products.
>
> - 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
----------------------------------------------------------------------
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
