On 21/06/2022 12:53 pm, Charles Mills wrote:
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.
I implemented something similar for our product to create CSV files to
be loaded into DB2/IDAA. Much higher volumes. Our stuff is in Java and I
found a really nifty rotating log library by one of the Apache
developers https://github.com/vy/rotating-fos. It's policy based so can
be configured in a YAML file.
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
