1 - Yes I didn't look at the samplib 2 - Yes I didn't look at the API 3 - Okay 4 - Okay, whatever you say 5 - Okay
Yes, your observation is wrong. I'm not a unix person and I'm not thinking with a "unix mindset", I just asked a question on a topic. I clarified what I meant. If it helped, fine. If it didn't, if someone was interested, they'd have asked to clarify again, not just to prove someone else is wrong on the internet. > For me, someone saying "Parallel run" and "split-up behavior" are referring > to thread-safe languages (e.g. GO's goroutines and channels) That's a heavy assumption man. How is thread safety even in the same area of the topic here. Let me try again... by parallel run, I meant something like A B deployments or canary deployments. In this case, not "deployments" but the concept of going from Tap A - 100% Tap A - 100%, Tap B - 0% Tap A - 50%, Tap B - 50% Tap A - 0%, Tap B - 100% > Most Unix programmers don't understand that threads are a small subset of > multi-tasking. Assuming again... Looking at the rest of this para, I see where you're coming from, wrt assuming I'm asking in a unix minded way, because you saw what I was explaining as something similar to the unix syslogd "setup". But otherwise, it's "funny" isn't it. In z/OS land, everyone has to go to the assembler tap. Who knows what % of interfaces are still assembler only. I know there's Metal C now but don't think it 100% matches what's possible with assembler APIs. So no wonder a unix mindset won't always apply in z/OS as there are very few commonalities like that. It's not that it was insulting, it's the assumption of what the other person is trying to say. 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. Possibly even this email server; but since it's IBM-MAIN, it may be on z/VM or something. I was using syslog/operlog interchangeably, my bad; because I meant to only ask about the line width aspect of it. Sent with Proton Mail secure email. On Saturday, July 26th, 2025 at 22:25, Jon Perryman <[email protected]> wrote: > On Sat, 26 Jul 2025 02:18:06 +0000, kekronbekron [email protected] > wrote: > > > I meant to find out the impact of updating IEAMDBLG, > > and if doing so affects what automation sees; > > or if IEAMDBLG affects only syslog or only operlog, or both. > > > Here are some noteworthy comments > > 1. You didn't look at SAMPLIB(IEAMDBLG) otherwise you would have noted it is > a sample that reads OPERLOG. > > 2. You didn't look at the OPERLOG API otherwise you would have realized it > "can't affect" anything. It is a READ only API that can't modify OPERLOG in > any way. > > 3. OPERLOG is an end destination whereas Automation occurs on the SSI at the > message source location. > > 4. I suspect that IEAMDBLG stands for "IEA" = MVS, MDB probably = "Message > DeBug" and "LG" = "LoG" (MVS Message DeBug LoG). > > 5. IBM supplies sample IEAMDBLG as one example that the OPERLOG might be > useful. IBM lets each site build their own solutions that they find are > useful. > > > > > By parallel run, I mean letting the current, split-up behaviour remain > > > > the canonical way/source > > > > How do you know I've mistaken unix threading to multi-tasking? > > > > How do you know I'm in the unix mindset? > > > From your posts, it's obvious. Are my observations wrong? > > You were asked to define "parallel run". Do you think that your definition is > correct? Do you think people understood this definition? > > For me, someone saying "Parallel run" and "split-up behavior" are referring > to thread-safe languages (e.g. GO's goroutines and channels) > > Most Unix programmers don't understand that threads are a small subset of > multi-tasking. For instance, both Unix & z/OS have message handling but in > Unix, SYSLOGD collects messages and those messages are redirected to various > locations (files, automation, ...). z/OS on the other hand processes messages > at the source using the SSI. > > > It's better if you state what you want to say directly than assume > > intentions > > > I'm sorry you took this as an insult but it was intended as constructive > criticism. The sooner you realize z/OS is well designed, the sooner you will > think in terms of software design. Unix on the other hand is mostly hobbled > together. For instance, consider all the information lost because it doesn't > have message IDs. > > > So you're saying leave syslog configs alone, but use operlog as it's richer? > > > I'm saying, use what best solves your problem. If SYSLOG meets your needs, > then stay with SYSLOG. > > I'm saying SYSLOG will not change. I'm guessing vendors still ask for SYSLOG > instead of OPERLOG. I'm guessing that OPERLOG hasn't been life changing for > most sites. > > I'm saying that OPERLOG has unrealized potential but it appears most sites > can't justify investing in its use. If SYSLOG meets your needs, then stay > with SYSLOG. > > Most of the world relies on Unix SYSLOGD which is worse than z/OS SYSLOG. If > you need more than z/OS SYSLOG, then you will consider OPERLOG. > > ---------------------------------------------------------------------- > 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
