The Communication ECB is key 0, not fetch protected. Despite the key 0, a key 8 task is allowed to do a WAIT.
IRXEXCOM returns contents, not addre4sses. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Charles Mills [[email protected]] Sent: Monday, June 20, 2022 5:39 PM To: [email protected] Subject: Re: Some UNIX file usage questions Nay! Rexx passes everything by value, both to internal and to external functions. So passing <context> will give the assembler code 200 zero bytes to play with but it will go away on return. And it is unnecessary. I know of no need for persistent storage. Perhaps it is worth persisting the STIMER MF=L and friends. (I have not yet done detail design. If indicated I will use name/token to do the persisting. There is also a persistent "user" pointer in the "environment block" that Rexx maintains and passes, so that is perhaps a better alternative. I have some detail design work to do.) The pseudocode is otherwise on target. I would add (watch the line wrap!) When Left(Res, 1) = 'T' /* Rexx PARSE command from Res */ /* Re-parametize or whatever is indicated by the command */ Iterate end end /* Close files, clean up and terminate */ The ECB is in MVS-managed storage but it is apparently user-key. I won't "persist" the STIMER; I will cancel it when I get an F or a P. F should be infrequent enough that there is little wasted overhead in cancelling the STIMER and presumably re-starting it. If the caller wants to resume the remaining interval it can readily enough keep the absolute wakeup time desired and do the necessary arithmetic. OTOH I guess F could return the remaining interval but that neglects any time spent processing the F. For P of course the remaining interval is irrelevant. Whoever mentioned Rexx variables moving around was on target. Rexx's internal storage management is a black box. It may well move stuff around from time to time. As I say, everything is passed by value. And there is no C ampersand operator. I know of no way to get the address of a Rexx variable. Actually, now that I think about it, I have used IRXEXCOM which returns Rexx variable data "in bulk" to an assembler routine, but I do not recall the details. It may pass the actual address, not a copy of the value -- I don't recall. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Crayford Sent: Monday, June 20, 2022 11:10 AM To: [email protected] Subject: Re: Some UNIX file usage questions I think I understand what Charles is doing. context = copies('00'x,200) <-- state for HLASM program wait_time = 30 do forever res = console(context, wait_time) select when res = 'T' then iterate when res = 'P' then leave otherwise ... end end On 21/06/2022 1:58 am, Paul Gilmartin wrote: > I'll correct my earlier misstatement. You did not say you were the client; > merely "-n-house". > > On Mon, 20 Jun 2022 10:41:25 -0700, Charles Mills wrote: > >> The ECB is not in the Rexx. It is in MVS-owned storage IIRC. >> > I believe ECBs routinely occupy user-owned storage. > >> -----Original Message----- >>> ... >>> ... Well, the actual parameter passed by the Rexx is continuously >>> accessible to the Assembler. It is of course possible to access any Rexx >>> variable from assembler, but I see no need. If I understand your question, >>> the answer is No. >>> > I took "continuously accessible" to mean accessible by concurrent tasks even > after > the Assembler returns to Rexx. > >> That depends on the AFAIK undocumented behavior of Rexx storage >> management. What happens if Rexx compacts variable storage, thereby >> moving an ECB? Rexx spurns concurrency. >> > "ECB" for example. The Devil's advocate was envisioning using the parameter > passed by Rexx as working storage. Which is OK until returning to Rexx. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
