I have a printed copy of the 'How To Ask Questions the Smart Way'
document at my desk.
On slow days, I sometimes re-read it for entertainment.
One thing is for sure:
Dropping F-bombs (something which I have *never* done) on any
midrange.com list is the quickest way to a permanent ban from the
lists. (Unless, however, you're up to writing a matching-record logic
program which uses all 99 indicators...)
"Vernon Hamberg" wrote in message
The granddaddy of the " how to ask" documents is probably this one at
It is not always going to be politically correct, or even polite! An
example - ".../you/ are one of the idiots we are talking about..." in
Please do not let that deter anyone from seriously reading the relevant
parts. The document is from a kind of "hacker" community who are very
willing to share. One should probably look at just what "hacker" means -
I think that includes all of us on these lists.
Just the table of contents is a helpful list of suggestions.
And here are a couple quotes from the intro that mirrors Buck's
"Despite this, hackers have a reputation for meeting simple questions
with what looks like hostility or arrogance. It sometimes looks like
we're reflexively rude to newbies and the ignorant. But this isn't
"We're (largely) volunteers. We take time out of busy lives to answer
questions, and at times we're overwhelmed with them. So we filter
ruthlessly. In particular, we throw away questions from people who
appear to be losers in order to spend our question-answering time more
efficiently, on winners."
Take time to read the thing to see what the technical term "loser"
The language & attitude may seem stronger, at times, than we like to see
on these lists. Nonetheless, it is well worth a good read - even if just
the TOC, as I suggest above.
I know i can always ask better questions - I've tried to do just that in
recent posts here. And have received replies of clarification and the
like. That is all helpful, and I think those on these lists for their
willingness to take their limited time to participate.
On 7/8/2014 2:31 PM, Buck Calabro wrote:
...and really enjoy all the information that is passed betweenThat makes me sad. The purpose of this list is to share knowledge.
users, however I have been reluctant to post anything in fear of
There are practical limitations as to how much knowledge can be shared
via email; we can't really /teach/ someone from the ground up. The time
investment would be enormous on both sides. Much etiquette on 'How to
ask questions' springs from that fact.
It's something of a paradox that the hardest question to answer is the
easiest to ask. An example: 'What is the best way to read a record?'
Read? CL? Rexx? RPG/36, RPG III, RPG/400, ILE RPG? Cobol, Fortran, C,
SQL? Java via JDBC, Excel via ODBC, Crystal Reports? Best? Fastest to
execute once, fewest lines of code, easiest to maintain, fastest to
execute for a million rows?
The easiest question for me to answer involves enough code and sample
data that I can recreate the situation on my machine. That's usually
the hardest thing for the asker to do, because it means he has to
extract out the bits that aren't working, set up a dummy table and then
cut and paste the lot into a question (although code.midrange.com can
help with that; post your code there, then paste the link here).
So help us to help you. If you have a question, show your code and
sample data that makes it fail. It sounds weird, but the more specific
your question, the faster you'll get an answer. I've been on this list
since the BBS days, and honestly can't recall complaints that an asker
gave too much detail in her question. The list is far more likely to
complain that it takes forever to tease out every last morsel of
information needed to understand the problem.
I've taken too much of your time as it is. I hope this helps to
encourage you to ask - or answer - some questions. The community draws
its strength from those who actively participate.
This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact