On Sun, 27 Jul 2025 02:19:14 +0000, kekronbekron <kekronbek...@protonmail.com>
wrote:
>> For me, someone saying "Parallel run" and "split-up behavior"
>That's a heavy assumption man.
You don't use z/OS terminology nor language that everyone in this group
understands without thinking. Your responses require we think about what you
"might" be saying.
> not just to prove someone else is wrong on the internet.
This is not about proving anyone wrong. I couldn't figure out if your questions
had been answered nor if you understood my responses.
My only question to you (I should have asked long ago), did we answer your
question or is there something that needs clarification?
>Yes, your observation is wrong. I'm not a unix person
You don't need to answer this but I wonder why you don't use language that is
commonly used by this group.
>> Most Unix programmers don't understand that threads are a small subset of
>> multi-tasking.
>Assuming again...
Unix tends to use some form of sockets (native sockets, pipes, named pipes and
...). Even Unix SYSLOGD uses named pipe /dev/log for non-kernel messages.
>But otherwise, it's "funny" isn't it. In z/OS land, everyone has to go to the
>assembler tap.
It's funnier that C utilizes between 20% to 40% of the x86 instruction set.
Most x86 instructions are for use by Windows. It's painful writing ASM in GNU C.
// MSVC syntax (Intel syntax)
int a = 10, b = 20, sum;
__asm {
mov eax, a
add eax, b
mov sum, eax
}
>I know there's Metal C now but don't think it 100% matches what's possible
>with assembler APIs.
I've never used Metal C but I believe it generates assembler code instead of an
object deck. In theory, macro calls should be possible.
C can call HLASM API's but it's painful. IBM C is heavily modified. Consider
MVS38j where they use GCC(GNU C) that only the most simple HLASM APIs are used.
You won't see robust interfaces like ACB, DCB, OPEN, CLOSE & more.
>Obviously, z/OS is well designed, and has to accommodate decades of small &
>big decisions.
>Same for unix/linux.
>This hobbled together technology is what's powering a significant portion of
>technology.
ROTFLOL. Just because Linux does the job doesn't mean it does the job well. For
example, z/OS DB2 is magnitudes faster than zLinux DB2 on the same hardware.
>It's not that it was insulting, it's the assumption of what the other person
>is trying to say.
Sorry but we have to assume because of the language used.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
