On 28/06/2021 2:46 pm, David Crayford wrote:
Well, I'm seeing different results on z/OS. There is no PyPy on z/OS.
I don't know. IBM describe it as a "Native Python compiler for z/OS" so
maybe it is JIT compiled? I guess it's a good thing if it is.
--
Andrew Rowley
Black Hill Software
On 28/06/2021 12:31 pm, Andrew Rowley wrote:
On 28/06/2021 1:51 pm, David Crayford wrote:
That not particularily fast either. How can Python be faster than C?
danielspaangberg_1of2;2756;5.000862;1;algorithm=base,faithful=yes,bits=1
How did you run the Python version? From the comments it
On 28/06/2021 1:51 pm, David Crayford wrote:
That not particularily fast either. How can Python be faster than C?
danielspaangberg_1of2;2756;5.000862;1;algorithm=base,faithful=yes,bits=1
How did you run the Python version? From the comments it looks like
running it using PyPy improves the
On 28/06/2021 9:56 am, Andrew Rowley wrote:
On 26/06/2021 4:50 pm, David Crayford wrote:
That's an exaggeration. C is just over 3x faster.
C
mckoss-c830;14285;5.0;1;algorithm=wheel,faithful=yes,bits=1
The C implementations are confusing because there are various
algorithm changes as
On 25/06/2021 11:35 pm, Andrew Rowley wrote:
I set the limit to 100,000,000 (the source validates results for
multiples of 10) and got 10 passes in 5 seconds on my laptop. At
100,000,000 the bit map doesn't fit in processor cache which might be
a significant penalty. 1,000,000 gives better
On 26/06/2021 4:50 pm, David Crayford wrote:
That's an exaggeration. C is just over 3x faster.
C
mckoss-c830;14285;5.0;1;algorithm=wheel,faithful=yes,bits=1
The C implementations are confusing because there are various algorithm
changes as well, rather than just the language change.
Correct, setting IOC to 0 will change SMF30IO as you noted ... IBM does
document that changing service coefficients may require changing accounting
procedures. The next release of z/OS after 2.4 is stated to not allow
setting any coefficients (and IOC is hard-coded as 0). From a resource
On Sun, 27 Jun 2021 22:52:26 +, Seymour J Metz wrote:
>...
>They originally wrote Unix for ASCII, which doesn't have a new line character.
>Unix, and C, used a line feed as a logical new line, but I don't know what The
>Open Group or IEEE say about that. OMVS uses an EBCDIC NL character
As I recall, at the time IBM announced MVS-OE, there were significant
difference between IEEE's POSIX and X.OPEN's standard. The names have changed
since then, and the standards have converged.
They originally wrote Unix for ASCII, which doesn't have a new line character.
Unix, and C, used a
Linux is not UNIX. Gnu is not UNIX. That's the easy part, although it is a bar
bet that you can win.
I believe Posix is a subset or further qualification of UNIX. I am pretty
certain that UNIX System Services (USS or OMVS) is always UNIX, but Posix On is
a choice that a USS program can make.
FWIW, I always do it your way, Gil.
We couldn't possibly BOTH be wrong.
(Except, of course, that I never use all-caps for variable names. Sometimes
I'll name something MaxVal, but usually not even that.)
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Computers in the future may
On Sun, 27 Jun 2021 15:05:08 -0400, Steve Thompson wrote:
>The diff between Posix compliant and not? Linux is Not Unix. zOS, iirc is by
>being Posix compliant.
>
Unfortunately, "compliant" with an outdated version of POSIX.
-- gil
On Tue, 22 Jun 2021 20:39:57 +0800, David Crayford wrote:
>
>Lua ports to TSO/MVS just fine with no changes because it uses fopen().
>All I had to do was add "dd:lua(%s)" to package.lua and it just worked.
>Lua runs in CICS no problems. Rocket's Python port uses fopen() but it
>requires enhanced
The diff between Posix compliant and not? Linux is Not Unix. zOS, iirc is by
being Posix compliant.
Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct
mistaks
> On Jun 27, 2021, at 1:55 PM, Seymour J Metz wrote:
>
> Yes, but the original code inserted a blank
OREXX does the same thing. I don't recall that being vakid syntax, but it sort
of makes sense.
/* test continued comment */
say 'foo'/*,
*/'bar'
say 'foo'/**/'bar'
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM
On Sun, 27 Jun 2021 18:12:26 +, Seymour J Metz wrote:
>Which code looks cleaner?
>
> foo = bar' 'baz,
> foo = bar baz
>
FWIW, I prefer coding:
say 'Result =' RESULT
to:
say 'Result = 'RESULT
I seem to be in a minority.
-- gil
On Sun, 27 Jun 2021 11:01:55 -0700, Charles Mills wrote:
>I tend to think of the insertion of blanks to be unfortunate.
>
Alas, in Regina, with no blanks in the source:
trace R
say 'foo',
'bar'
2 *-* say 'foo' 'bar'
foo bar
607 $
However:
trace R
say 'foo'/* ,
*/'bar'
2 *-* say
Which code looks cleaner?
foo = bar' 'baz,
foo = bar baz
When you're building command strings that include spaces, it's more readable if
those spaces appear in the source in a manner similar to the generated command.
I agree, though, that in things like BNF it's desirable to make
I tend to think of the insertion of blanks to be unfortunate.
It is great if you are wanting to demonstrate the incredible simplicity of
Rexx:
Say Hello World
But I think if you want a blank between the two halves of the "continued"
(in quotations) literal then just code it.
Foo = "blah blah_"
Yes, but the original code inserted a blank between the two strings; It's the
difference between continuing "'foo bar'" and continuing "'foo bar '".
Linux on z and z/OS Unix System Services both run on an IBM mainframe but they
don't use the same line end convention.
What if I want the code to
Right, it makes it into (effectively) on long "continued" (if you will)
literal. Effectively, not literally.
I was assuming the IBM mainframe as this is the IBMMAIN mailing list. And my
point is not the value x'0a' but rather the technique. Substitute whatever
magic number is a linefeed on your
Peter - you're correct (as usual).
This is better:
/* rexx */
Return mvsvar('sysmvs')
This returns the level of z/os. For 2.4 you get SP7.2.4
Cheers
Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck
"Worry more about your character than your
RACFLEV = RACFVER || '.' || RACFREL || '.' || RACFMOD
I'm afraid that that is not particularly helpful. That is just
reformatting the value already provided by
As RCVTVRMN documents, that value does not represent the level of RACF as
of z/OS 2.2 -- the level of RACF is the level
lör 2021-06-26 klockan 14:09 + skrev kekronbekron:
> To be honest, your whole post below went right over my head.
>
> - KB
>
sorry.
Yeah, i read it again ... so:
> ‐‐‐ Original Message ‐‐‐
>
With regards to Shark Tank: it is immaterial ie it is only readable
from the server only
Hi Gil,
No, the LINEND Character does not work in this instance (to retain the
command buffer post-CMS crash.)
The LINEND Character (default "#") LOGICALLY separates the command(s)
being placed into the CMS Buffer.
This buffer is destroyed when CMS crashes (due to the TERM CONMODE 3270
25 matches
Mail list logo
