Actually IEAMDBLG is more than read-only in that it can purge data
from the logstream
At 11:55 AM 7/26/2025, Jon Perryman 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
