How does it work in windows? I would be happy with a port that required dubbing, but I know that there are shops that feel otherwise.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of David Crayford <[email protected]> Sent: Monday, June 23, 2025 7:32 PM To: [email protected] <[email protected]> Subject: Re: REXX say & OOREXX was: In IBM-land, AFP means... External Message: Use Caution The ooRexx message passing code uses pthreads so I would say that’s a pretty big POSIX requirement. It’s also nailed to the file system. A port of ooRexx would be akin to Python. Enhanced ASCII and run from a USS environment. > On 24 Jun 2025, at 02:55, Seymour J Metz <[email protected]> wrote: > > You haven't got a clue as to what I understand; you've made that abundantly > clear. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > > ________________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf of > Jon Perryman <[email protected]> > Sent: Monday, June 23, 2025 2:22 PM > To: [email protected] <[email protected]> > Subject: Re: REXX say & OOREXX was: In IBM-land, AFP means... > > > External Message: Use Caution > > >> On Mon, 23 Jun 2025 13:21:12 +0000, Seymour J Metz <[email protected]> wrote: >> >> You keep saying that, but you haven't provided any specifics. > > Ask questions and learn something. I'm conveying concepts you don't > understand. You're wasting my time by constantly making statements of fact > that may or may not be relevant nor true. > >> I'm not aware of any *ix-related issues for defining an environment. > > I never said *ix-related but instead said designed for *ix. You can write > code that does not use anything *ix-related but it is still designed around > *ix assumptions. E.g. the design assumes fork, spawn, processes and threads. > The design did not plan for the problems introduced by ISPEXEC SELECT > PGM(xxx) nor other z/OS concepts. They assume the *ix storage model while > ignoring subpools, keys, address spaces and TCBs. The shared storage concept > is very different. > >> There is a well defined interface that does not involve any *ix services, >> based on the SAA interface, and already implemented on non-*ix system. > > I don't see this as an insurmountable problem because it is definable and can > be worked around. > > On the other hand, design based on *ix assumptions means that all code must > be reviewed for incompatible assumptions that may not be obvious. > >> That siid, It is tied to C++, so a bridge is required. > > Design isn't tied to a language but instead to the assumptions made. With the > right design, would a bridge be necessary (even in C++). > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
