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
