I've been following these posts, at least some of them, and what I'm missing is the
why. Are you trying to develop a set of aptitude tests for hiring OE-specific resources? Are you trying to acquire OE platform knowledge yourself? Train existing staff? Something else?
When I read this, I'm inclined to to try understand the motivation for asking this in the first place. Is it because you read the phrase "data buffer" in the docs or a KB article, or heard them being discussed, and wondered what they are? If so, that context would be useful to have. As stated, this inquiry seems to me more like a trivia question than a search for understanding.
Anyone know what are called data buffers?
How many types of data buffers are used in progress?
What are they?
"Buffer" is a generic term. It is a data structure in memory. Because its purpose is to store data, the qualifier "data" in "data buffer" doesn't add meaning; to me it sounds like "beverage glass"
. A buffer may be a cache, or an addressable unit of storage within a cache. Caches are used everywhere in computing, from CPU and network hardware to storage devices to OSes to software platforms to the applications built on top of them and the front-ends through which users interact with them. Buffers can be on the client-side, the application tier, DB server-side, or elsewhere. Progress uses the term "buffer" in many different contexts within OpenEdge. Even within a single component like the database or the AVM there are many different types of buffers.
I think it's more fruitful to try to understand concepts (e.g. what the various platform components are, what are the functional units within them, how they work, how they interact with each other, how to configure them, etc.) rather than memorize definitions or sets of high-level questions and answers. As you progress with OpenEdge, you will have lots of gray areas in your knowledge and perhaps also some misconceptions. That's true of all of us. We're all on a continuous journey of learning and no one is infallible or knows everything, not even the folks who build the platform. So I suggest that for a particular area of interest, start a discussion thread, state your assumptions and any relevant information about your situation (e.g. OE version, platform info, etc.) and then ask a set of specific questions. If you don't understand the answers or they seem to contradict things you already know (or
think you know), state the perceived conflict and ask follow-up questions. If you are earnest and ask good questions and put at least as much work into your inquiries as you hope others will put into their responses, this site will be a beneficial resource for you and you'll be on the path to understanding.
If you wonder what I meant above by "good questions", maybe some examples will help.
Good questions:
- When I run
find first customer use-index cust-num. // (sorry Tom...)
and the database engine gets the rowid of that record from the index, how does it know whether the latest copy of the record block that contains that record is in the database buffer pool or out on disk?
- When I run
run foo.p.
for the second time in a client session, what does the AVM do? Does it search the propath again for the corresponding .r or does it run a cached copy of the program that it ran the first time? Is this behaviour configurable in any way?
Bad questions:
- How does the propath work?
- Why is my database slow?
- Can you write me a program that does X?
A good question provides context. It helps others understand what you know already, what misconceptions you have, and the level of detail you're capable of absorbing in an answer. Most people here will bend over backwards to help you (for free!) if you approach them in a reasonable way and don't waste their time. But don't expect that if an inquiry comes across like "please write my exam/complete my assignments for me".
Also, with regard to the discussion in another thread from 2011 that seems to have started this, I fully agree with
@tamhas. Ultimate success in hiring an OE resource (whether developer, technician, or DBA) isn't a matter of constructing a quiz and selecting the person who gets the high score. Most of the best OE developers and architects I've worked with over the years had zero OE knowledge before joining us. But they understood concepts like systems design, application design, API design, OOP, learned and practised in other languages and platforms. I believe it's much more important to have a good (and modern/evolving) understanding of these concepts than to have encyclopedic knowledge of the esoterics of OE.