Nooooo! 96 24-byte *records* per day. My current vision is to use a UNIX file, write the records every 15 minutes as they are produced, and do the close/rename/start over once per *month*, on the first write after midnight on the 1st of every month.
There are two basic reports, a daily report for yesterday and a monthly report for last month. The daily report will find the right day within the current month's file by spinning to the right record. Worst case that is ~3000 reads. The monthly report will process all of a month's records. Everything in the post you quote is about the internal loop logic. It does not address the file strategy one way or the other. I am good. I think I have a design. I know of no open problems. Now I just have to actually get to work. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of kekronbekron Sent: Monday, June 20, 2022 8:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Some UNIX file usage questions Hey Charles, Does the 96-files a day solution not work? You could cat *-yyyymmdd.txt > yyyymmdd.txt at 00.05 and then delete the 96 files. You wouldn't have to worry about losing out data in memory if it's written to a file every 15 min. It appears to be a pretty basic & simple solution? - KB ------- Original Message ------- On Tuesday, June 21st, 2022 at 3:09 AM, Charles Mills <charl...@mcn.org> wrote: > 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:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of David Crayford > Sent: Monday, June 20, 2022 11:10 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 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
