SMF logging of data for management information? I never did much with SMF, but I can't see why not.
I did briefly consider being able to parse existing mapping macros, but that's bound to be a bigger job than it seems, especially now I'm a bit rusty and only have Hercules to play with. Structures (maybe 'map' because 'str' is already short for the most basic type of 'string'). And pointers to them, yes. Wouldn't be without them :-) I'll probably be old and slow, or losing my concentration, before it's even half finished. Still, it keeps me out of mischief when I'm not at work or converting the van for mobile glamping :-) Roops On Sun, 17 Mar 2024, 18:31 Seymour J Metz, <sme...@gmu.edu> wrote: > I probably would use ":=" for assignment and "=" for equality. > > Are you supporting SMF-like structures? > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Rupert Reynolds <rreyno...@cix.co.uk> > Sent: Sunday, March 17, 2024 2:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation > question > > It's too soon to publish much, especially when I have a full time job doing > something else. To be honest I probably never will, because it only suits > my pet bigotries :-) > > But briefly, I looked at day 1 notes (on back of a gas bill). They included > these, not all of which will ever make it into use of course: > > . fairly terse {} syntax, borrowing from 'C' etc. > > . strongly typed by default > > . one type is bignum--arbitrary precision and base arithmetic, trig, logs > > . correctness and flexibility more important than speed (like external > functions in Rexx scripts, for example) > > . project to include thorough test cases, and any bugs/unintended quirks in > either impl or tests will be fixed ruthlessly, not supported. If it fails > the test, it is not the real thing. > > . compiled code could include interpreter for scripting > > . preserves case, but keywords and functions etc. not case sensitive > > . all keywords can be abbreviated (eg. if min abbreviation is 3, 'fun' is > same as 'function') > > . '=' not required for assignment! > > . ability to convert 'C' style strings and call 'C' code > > . all built-in functions for handling null-terminated data and UTF-16 to be > prefixed gk_ (short for "ghastly kludge" ;-) ) > > Feel free to laugh/crjticise, but please be kind--I was drinking during > lockdown when I finished that list :-) > > I made some progress on the bignum logarithms and trig early, borrowing > heavily on the external Rexx functions I used under Windows. > > It does basics such as finding and moving files interpreted, so I can use > it to test my Rexx admin scripts, and vice versa, but there are *huge* > gaps, and I'm moving house this year, so... :-) > > Roops > > > On Sun, 17 Mar 2024, 16:58 Seymour J Metz, <sme...@gmu.edu> wrote: > > > > I'm developing a language > > > > Have you published any details? > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > עַם יִשְׂרָאֵל חַי > > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > ________________________________________ > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > > of Rupert Reynolds <rreyno...@cix.co.uk> > > Sent: Saturday, March 16, 2024 9:07 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation > > question > > > > My experience of modern scripting languages, compared with classic Rexx, > is > > that they all do something new more easily, but also I can't think of one > > that doesn't have an obvious pitfall (such as, for example, stumbling > badly > > over certain byte values such as NUL in strings). > > > > Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite > > certain old-fashioned quirks, are still sometimes what I reach for when I > > want to process some data while avoiding those pitfalls. > > > > The differences are so strong to me that I'm developing a language which > is > > effectively the best bits (IMHO) of Rexx, C and even older languages such > > as Algol 68 (much underrated in my book) and hints of PL/1. I don't make > > that much effort without reason :-) > > > > By definition it works the same interpreted or compiled, which brings a > > couple of restrictions I'm willing to live with :-) > > > > Roops > > p.s. I'm not convinced that that familiarity is a reason to criticise > > choosing a language. Using something you know well is often a way of > giving > > bettet value and reliability for ones employers. > > > > > > > > > > > > On Sat, 16 Mar 2024, 11:49 David Crayford, < > > 00000595a051454b-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Hey Rony, > > > > > > From what I understand, you haven't had experience working on z/OS. > Let's > > > stick to the topic and focus on discussing REXX as it functions on > z/OS. > > > This means no discussions about ooRexx or Java bridges, as they don't > > exist > > > and are unlikely to in the future on z/OS. > > > > > > The majority of REXX programmers here utilize classic TSO REXX and > > > primarily work within a TSO/ISPF environment. In this setup, REXX > lacks a > > > module system. Therefore, any routines or libraries need to be manually > > > copied and pasted wherever they're needed, or you have to create a > > > pre-processor to merge source files together. If your language lacks > the > > > fundamental basic features to sort an array then to me that’s a good > > > indication you should use one that does. > > > > > > I'm not spreading fear, uncertainty, and doubt (FUD). I'm simply > stating > > > my observations based on over 30 years of using REXX on z/OS, including > > > developing extensions. I believe this gives me a significant level of > > > expertise to offer commentary on the matter. > > > > > > > > > > ---------------------------------------------------------------------- > > 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
