XPost: alt.c64

COMP.BINARIES.CBM Official Frequently Asked Questions (FAQ)
4.10
written by Cameron Kaiser <ckaiser@floodgap.com>
based on documents by William Ward and Michael Miller

** START OF INTENSELY HUMOUROUS FAQ **

0. Introduction

This is the droll, charming and occasionally even informative Frequently Asked
Questions guide for the newsgroup comp.binaries.cbm (hereafter c.b.c). People
are urged to consult this immensely entertaining and mildly useful guide
before asking questions of the moderator(s) or posting them to the appropriate
discussion group, as doing so may answer your query much more quickly and in
such a manner that you do not collect mail along the lines of 'read the faq,
you blithering idiot' or significantly more unmentionable versions thereof.

This FAQ was written by Cameron Kaiser, who based it on an original draft
by William Ward, who based *that* on a draft by Michael Miller, and no one
knows where his came from. (Well, never mind. Michael says that he just made
it up. Thanks for clearing that up, Mike! ^^ )

In version 4.0, I completely rewrote Bill Ward's FAQ, which was version 1.3,
and gave it the wrong version number, which has now stuck.

In version 4.1, I added Jim Brain's notification that this FAQ will be/is now
available on his FTP site, John Iannetta's lament about CompuServe's mailing
subsystem, and made wording changes to the document for clarification, all
on 13 October 1997.

In version 4.2, I made some notes about proper documentation of postings,
did some cleanup of inexplicable garbage, and some helpful tips for posting
by mail, all on 1 December 1997. Also included is an entire section on
troubleshooting various complaints. I also have started doing a change-log
system, allowing you to see new changes. Here's how:

| NEW CHANGES IN THE FAQ ARE DOCUMENTED with a | symbol in the first column.
| WATCH FOR THEM.

In version 4.3, I announced where the FAQ can be found online, and made some
brief changes to netiquette notices, as well as adding the actual charter
in. Some notes from the big bad binaries thread on c.s.cbm have been added,
all on 27 March 1998.

In version 4.4, I added some information about the official c.b.c web page,
the Videocam archive, more troubleshooting, regular features on c.b.c, and
rewrote some commonly asked problems about c.b.c propagation, on 15
September 1998.

In version 4.5, I added notes about the mini-FAQ and the Things never to
do on c.b.c, on 17 January 1999.

In version 4.6, I introduced a new submission address, removed some old
information that was no longer applicable, brought various other
notes up to date, and issued a warning about autoposting, on 21 September
2001.

In version 4.7, after a long hiatus, I fixed all the old URLs and
E-mail addresses, and updated some preference notes on archiving, all
on November 26, 2004.

In version 4.8, I noted the existence of the OFTV bot, corrected the history
of Mike Miller's FAQ background, and a few other custodial changes, on
April 2, 2005.

In version 4.9, I introduced the new anti-spam standards for c.b.c and
various current updates on August 1, 2005.

| In version 4.10, I added the new mailing list archive on September 22, 2006
| that Spiro Trikaliotis maintains.

The humor in this FAQ is totally intentional. Posting to the group about
what a yutz the author is will be ignored, mostly by the author.

0.1 Where to get the FAQ from

This FAQ is posted semimonthly to comp.sys.cbm. You can also ask the author
for a copy. See 'Contacts' for addresses. You can also find it posted around
the same time to alt.c64.

A mini-FAQ appears weekly issuing and detailing the most common errors
and announcements. Important extracts from these mini-FAQs will eventually
appear here and vice versa. The mini-FAQ appears only in comp.binaries.cbm.

You can find the FAQ online at

http://www.floodgap.com/comp.binaries.cbm/

It is currently plaintext. I'm working on an HTML version. It also will be
posted at intervals to comp.answers in the future pending approval.

1. General Notes about c.b.c

1.1 What c.b.c is

c.b.c is a newsgroup for the posting of Commodore related binary files.
By Commodore we refer to the 8-bit systems. Amiga binaries (excepting those
that have direct pertinence to the 8-bits) are NOT accepted and you should
send those to the analogous group.

c.b.c is MODERATED. If you post to this group, it will not automatically
appear. You should not send posts to the group along the lines of 'where the
#$%@!# is my post?' because we will ignore them. Plus, you'll look silly and
we will post you to our list of people to laugh at for not reading the FAQ.
If your post does not appear, we have not approved it. If your post never
appears, we never approved it. You should read under 'What we don't post'
for why.

If you don't know how to post, refer to the section on (ta-da!) 'How to
post'. Even if you do, it will save us some grief if you read it anyway.

As with all moderated groups, your posting is not actually sent through Usenet.
Instead, it goes via E-mail to the moderators, and you should send your post in
an appropriate manner. (If you want to E-mail directly, see 'Contact list'.)
You should also refer to 'c.b.c courtesy' for how to get your post approved
faster. If you help us, we'll expedite things for you. If things are difficult
for us to do, it will take us longer, or not at all.

1.1.1 The c.b.c charter

This is the abridged charter. The full version can be found at

ftp://ftp.uu.net/usenet/control/comp/comp.bin...

  comp.binaries.cbm is a moderated newsgroup which passed its vote for
  creation by 170:24 as reported in news.announce.newgroups on 22 Sep 1993.

  >For your newsgroups file:
  comp.binaries.cbm       For the transfer of 8bit Commodore binaries.
  (Moderated)

  The newsgroup is for the purpose of swapping 8bit Comodore [sic] Binaries,
  mainly mainly for the 64 and 128 computers. The moderator will attempt
  to filter out copyrighted software, and insure that the programs work,
  although it is impossible to verify all software for all systems.

1.1.2 Why c.b.c is necessary

c.b.c is necessary because the comp.* hierarchy, with approximately two or
three exceptions, is discussion only. It is standard protocol to only post
binaries to comp.binaries.* groups, hence the motivation for creating this
group. This is not unique to the comp.* hierarchy; alt.binaries.* exists for
identical reasons.

Binary postings have started to appear in the comp.sys.cbm newsgroup in
spite of this fact, and they are subject to bincancel, not only by newsgroup
readers, but also by bincancel bots (such as Rich Depew's) and news admins.
Binaries in discussion-only groups also introduce serious breaches of
netiquette, discussion of which is beyond the scope of this FAQ. The reader
is invited to read any of the cancel and netiquette FAQs, routinely posted
to news.admin.net-abuse.usenet, news.admin.net-abuse.misc and easily found on
DejaNews and AltaVista.

1.1.3 Moderators

Currently, Markus Mehring is the primary moderator, with Cameron Kaiser,
the author of this FAQ, acting as moderator emeritus and technical backup.

Keep in mind that moderatorship can and does change from person to person.
It is therefore best to mail the moderators collectively, versus
individually. See 'Contacts'.

| 1.1.4 c.b.c On-Line and via FTP and Mailing List

c.b.c now has an official webpage and the most current submissions are also
| archived/kept at Videocam in Australia. There is now an online archive for
| previous postings as well, and a mailing list.

The c.b.c webpage is

http://www.floodgap.com/comp.binaries.cbm/

On the webpage, you can see what the most recent submissions were (for use
with threatening your newsadmin, see Troubleshooting), get a current copy of
this FAQ for bathroom reading, and also find out about submission policies,
moderators, etc. Also on the c.b.c page is a very trivial uudecoder which
will do in a pinch (it's BASIC 2.0, so don't expect too much) if you can't
get Fuzzy Fox's uuxfer (q.v.) to work.

If you prefer to get your files via FTP, Rod and Gaelyne Gasson at VideoCam
in the lend daun undaa have graciously offered their FTP server as a
repository for the most current c.b.c files (old postings are then archived
under the regular directory structure). Allow some time for the postings
to reach them first. Due to bandwidth rapists looting their connection,
downloads are limited to members, or you can contribute to their useful
Commodore-oriented Internet service and subscribe or purchase a CD.

ftp://videocam.net.au/cbm/incoming

There's no /pub in that address. Common pitfall. Watch out.

| Spiro Trikaliotis maintains a mailing list that is regularly updated with
| submissions past and present, a useful way of getting c.b.c both by E-mail
| and if your news server does not carry binary groups. In addition, there is
| a mailing list archive of old posts available to subscribers. Subscription
| is presently free-of-charge, but you must uudecode postings yourself for
| technical reasons.
|
| http://lists.trikaliotis.net/listinfo/comp-bi...

1.2 What we post

c.b.c posts any and all binaries related to the 8-bit Commodore that do not
fall along the lines of what we *don't* post (q.v.).

Some examples: shareware games (unregistered); freeware; demos; public
domain games, utilities, etc. In other words, freely available software
with unrestricted distribution will be accepted.

In the past, emulator-related binaries were not accepted to this group. While
they are not encouraged, as a significant number of c.b.c's readers don't
have personal access to anything but 8-bits (which frequently cannot handle
emulator formats without external conversion), they are now accepted to the
group. However, if there is a straight binary version of a file as opposed to
a .d64 or .p00, we exceedingly prefer it.

Binaries intended for other target systems, such as PC executables, are
accepted only if they have relevance to Commodore systems. Examples would
include emulators and converters, but again at the discretion of the
moderators only in their sole judgement.

1.2.1 What we re-post (One From The Vault)

Periodically, we also re-post previous submissions that we deem of particular
interest, or ones that are requested frequently. The "One From The Vault"
postings occur at sporadic intervals, sort of a best-of-comp.binaries.cbm
selection mix. If you have suggestions about something you would like to
see reposted, notify the moderators.

A robot now peruses a list of frequently requested posts and automatically
runs through the rotation putting up repostings on Mondays and Fridays. This
is in addition to what the moderators select for reposting by request.

Take care when replying to OFTV postings, as many were posted years ago.
Casey Jones, you'd better watch your speed.

1.2.2 How to download what we post

Most newsreaders are smart enough to uudecode the post automagically.
Chances are your PC or Mac newsreader already has downloaded and archived
the post before you even saw it. Check your newsreader's documentation.

Un*x shell newsreaders assume some intelligence on the part of the user.
Some will automatically decode the post; others won't. You'll need to check
your newsreader's documentation, but this method will always work:

* Save the post to a file on your shell account. (For nn, press 's'.) See
  your newsreader's documentation.

* Get to a shell prompt (usually something like % or $). If you see #, the
  first thing to do is type 'rm -rf /' to make sure you have plenty of
  space. (Just kidding.) You may have to quit your newsreader or press
  CTRL-Z to get to a shell prompt.

* Type 'grep ^begin <filename>' where filename is the name of the file you
  saved the post to. Don't type the angle brackets and don't forget that
  carat. You'll probably see something like this:

  % grep ^begin really.cool.post    << You typed this
  begin 644 program.prg

  There may be some other junk lines in the file; just look for one that
  resembles this one.

  As you can see from the above example, program.prg is the file that will
  be created by the uudecoder. To create that file from the uucode, type
  'uudecode <filename>', again substituting the post name without the angle
  brackets (our example would be 'uudecode really.cool.post'). If you see
  something like 'uudecode: short file', you didn't save the post properly.
  Go back to the beginning and try again.

* Use the sx, sb or sz utilities (Xmodem, Ymodem and Zmodem respectively) to
  download the created file to your terminal program. Usually the command is
  'sx <filename>'; our example would be 'sx program.prg'.

* Resume your newsreader. If you used CTRL-Z to get a shell, you'll probably
  type 'fg' to get back to it.

If you're all thumbs with this process, you can still get the most recent
postings via FTP. See section 1.1.4. Explaining FTP, however, is beyond the
scope of this FAQ; most ISPs offer assistance with FTP transfers, and most
web browsers support FTP, though.

| If you are using a post from Spiro's mailing list archive (see 1.1.4 also),
| you will need to uudecode it in a similar fashion, which is also beyond the
| scope of this FAQ. See your mail program's documentation.

1.3 What we don't post

We do not post:

	* non-binary items. Spam is deleted. Discussion is deleted. People
writing us about why no one discusses anything in this group get deleted.
Et cetera.
 	The exceptions are the FAQ, naturally, and moderator announcements.
	So where should you post if you want to talk about Commodore 8-bits?
A good question. Refer to:

	comp.emulators.cbm
	comp.sys.cbm
	alt.c64

	All of these, in particular the first two, have active discussion.
Talk on them. We'd love to hear from another 8-bit fanatic.

	* binary items not relevant to the 64. UUencoded JPEGs of your pet
wonderdog Snotbrain whizzing on Mrs. Eagleson's petunias get deleted. And so
on.

	* 'warez'. Cracks, hacks, etc. are NOT allowed. The old argument
that 'it's 10 years ago, the copyright doesn't matter' is hogwash. Someone
still has the copyright, even if they're not enforcing it, and we don't want
to be on their lawyer's target list if they decide to enforce it suddenly.
(Want an example? Okay. Three words: Activision fifteen pack. Case closed.)
Freeware and shareware versions of products are exempt because they are
explicitly freely distributable, in contrast to ...

	* restricted distribution products. This is a fancy way of referring
to 'stuff that shouldn't be publicly distributed', and includes things such
as registered versions of shareware or beta tests that are not intended for
the public. Moreover, if there's a restriction on the software's distribution,
it's probably heavily copyright-protected too ... see 'warez'.

	* programs not intended for all audiences. For example, posting a
nudie slide show for the 64 here would not be appropriate, and it would
never be approved, even if it *were* in the public domain and freely
distributable. This is not comp.binaries.erotica.cbm. You may think this is
a silly thing to say, but there are some of these demos around.

	* things that don't work. Garbled submissions don't work. Make sure
your uuencoded file didn't get truncated. Make sure your mailer didn't eat
characters or add new ones, because on our end it looks like hell. IF YOU MUST
MAIL US YOUR POST, PLEASE see the section on 'How to post by mail' to get
around this problem.
	Most importantly, however, if it don't work, it don't post. If we
can't get it to run, odds are most people who read this group won't either.

	* anything we decide not to post, at our discretion. Some people have
claimed we're ignoring their posts because we don't like them. Tough orange
peels.

1.4 What happens if you post something we don't post

Nothing.

Yes, nothing. You will get no response from us, ever.

In the past, the response was to notify you that we did not accept your post,
and to send you some appropriate reason why. In this day and age of rampant
spammage and people who blindly post insulting things instead of reading FAQs,
that is an insurmountable task. Therefore, if you do not get a response to your
post WITHIN A SUFFICIENT INTERVAL and/or your post never appears on the group,
we did not approve it.

If you have trouble with your newsreader, and want to know if your post
came through, please state you want confirmation in the message body. We will
confirm only in cases where we have a serious posting. If you post 'why aren't
my messages posting somebody please respond' you will get a resounding fat
load of nothing returned to you. However, if there's a possible submission
attached to your polite and understanding request, we would be happy to tell
you that it got there in one piece. Do not, though, assume that a lack of
response indicates bad connection and therefore multiple reposting, because
this will not endear yourself to the moderators and collect you many four-
letter words. Ask first before you send that 2.5MB file again.

If you do get a message back from us, we probably just need a small extra
thing from you, like a description. Please read the note and comply; upon
your doing so, you will be the proud parent of a new post.

The phrase 'WITHIN A SUFFICIENT INTERVAL' has been cap'ed for a reason. It
takes time to check through a submission, first to receive it, then to test
it and then for the final post (if any) to percolate through the fibrous
wire mishmash of Usenet. Please respect the fact it may take as long as a week
to finish this process -- we have lives of our own, and we do this out of
our free time. Therefore, not seeing your post immediately does in no way
imply open and extremely prejudical rejection.

1.5 What happens if you post something we post

We post it.

If appropriate, we will notify you (usually 'thanks!'), but in most cases
you will know your post has been approved when you see it in the group. It is
| good form to make sure your newsreader does in fact see this group. You
| might also subscribe to the mailing list echo.

If you want confirmation, say so. See above for conditions on that. Remember
that sending confirmation messages is not guaranteed.

1.6 c.b.c courtesy

| Good things to do that make things easy for the moderators (and also, I
| hasten to add, make things easier on the viewing audience):

	* Use .sda or .sfx, or any other self-dearcing format. It's easy
for us because we don't have to crank up the dearcer. Lynx is especially bad
on this point, since there's so many versions, a lesson I have learned the
hard way with many people asking me why Ultimate Lynx doesn't understand
CWI's Lynx archives. (Answer: We use Lynx IV, and they're mutually
incompatible.) Failing that:

	* Use a standard emulator disk or tape image (compressed would be
nice -- .zip okay, .gz even better!). With modern code, even zipped and
GZipped .d64s can be handled directly on a C64, and for those mods that
do quick testing on an emulator, we can drop the image right in. .d64 is
now so ubiquitous that it has supplanted most .arc and .lnx formats as the
preferred method of archiving floppies and files, despite its disadvantages.
	  Failing that:

	* Use a standardized arc format. I like .lnx best, but can tolerate
.arc. I find .lzh slightly exotic and .rar even more opaque. If you post using
Fritz Fluegelwagen's RLE-LZW-Huffman-Lynx encoder, something three people on
the planet use, the chances of my hitting delete in the mailreader increase
exponentially.
	The one standard arc format you should avoid, if at all possible, is
ZipCode (the 1! .. 2! .. files.) These cause some irritation on my part, mostly
because I have to deal with four files instead of one. There are some
circumstances where ZipCode is needed, but most of them involve copy-
protection, which you find on (surprise!) copyrighted warez. See above.
	If these are PC binaries, please please PLEASE use .zip. I HATE
unarj with a passion, and I don't like DOS tar or gunzip. I suspect the other
moderators have similar preferences.
	But best of all:

	* Don't arc. If you can avoid it, don't! That's best of all. Then
we can just run the stinking thing.

For clarity, preferred formats, from most preferred down, for Commodore:

.prg/.bin, .sfx/.sda/.spy/.sdl, .d64/.t64/.p00, .lnx, .arc/.lzh, .rar/.lbr

For PC/Mac/UNIX:

.zip/.infozip/.gz/.tgz, .Z, .sit, .arj, .rar/.lzh

These are my preferences only and should not be construed as support for
any format or having any rational basis in fact. :-)

	* UUencode. Don't Base64. This means refrain from using attachments.
Most Unix newsreaders don't understand MIME, and most of us use a Unix
newsreader. If you don't, please be kind to the large majority that do.
The only exception to this is if you use a MIME-enabled mailer, and in that
case you should read the section on 'How to post' BEFORE YOU POST!!!

	* No yEnc, please. There is no native C64 yEnc decoder, and we'd
prefer they can access all postings even if you think the target shouldn't
be a real machine. Furthermore, the autobots that handle automatic posting
and processing all expect documents to be in uucode.

	* Document! You don't need to tell us how to turn the computer on,
but please do tell us what we're looking at, and what we can expect when
we run it. We can probably guess the rest. Accuracy helps. :-)

	 A NOTE ON DOCUMENTATION: Some people believe that documentation
consists of a single sentence saying 'this is a program for the (648|+4)'.
We can see that already. Documentation is telling us what the program is
supposed to do and what it needs to run, and this information is vital!
Steve Judd writes particularly nice documentation. Look for some of this
previous posts, if your news spool goes back that far (!).
	If you are sending an archive of programs, like a freeware
archive, please describe each program individually and completely as if
you had posted each one separately. A nice paragraph about the archive
itself will probably not suffice. :-)

	* Post your post instead of mailing to us. The reason is not that
we care how the post arrives, but that most modern mailers fiddle around with
files and add metacharacters and 8-bit encoding and the like. Most news
programs don't. Therefore, a post arrives more cleanly in general than does
the mail.
	IF YOU MUST MAIL, PLEASE see the section on 'How to post by Mail'.

	* Above all, remember that your post must be readable by the lowest
common denominator. Usually, that's us.

1.7 Things you should *never* do

	* Crosspost. Never ever crosspost. Announcements about your web site,
whether or not it will resurrect the 64 to millions of waiting fans
worldwide and usher in a new computing paradigm renaissance, are not binary
and therefore not germaine. Announcements about service offerings you may
be providing, or the software opus you're writing, are not binary and
therefore not germaine. (But if you have a demo, why not post that?)
Why am I picking on announcements? Announcements are, bar none, the single
most crossposted crud I can think of. STOP IT.
	Moreover, it s a waste of time for you, because if I don't approve
the post, or any of the other moderators, it won't appear in any of the other
groups you've crossposted to either. And we're not going to strip the c.b.c
group and and repost it for you. It's not our job.
	The problem is now of such an extent that c.b.c no longer accepts
crossposts, even if they *are* on-topic. Sorry. See section 2.1.1.

	* Mass post or autopost. In the past six months or so I have had two
incidences of nearly several hundred megabytes of warez end up in my mailbox
with more on the way, to the point where I had to complain to the offender's
ISP to get them to stop before my server's mail spool got overrun.
 	Not only is this unspeakably rude and impossible to process in a
timely fashion, but it also can cause denial of service problems for
moderators' ISPs and systems. Do NOT load your programs into an autoposter
and let your program blast us on autopilot. Do NOT pack everything into a
gigantic archive and bolus us at 5 gigs a post. If we can't contact you to
turn it off, we *will* make sure you're disconnected one way or another.
Please don't forget there's a human being looking at every post you send,
and that not everyone's hard disk is as big as yours.

	* Use a hopelessly munged address. We're a fairly astute bunch of
guys, and most mail munges are creative enough to be bot-foolers but still
humanly decipherable, and we have no problem with munging per se. (Heck, I
used to regularly munge mine.) However, we have received submissions from
"G@RT" (actual from address) that we needed more information on. Guess what,
bucko? Into the bit bucket. If we can't contact you about your post, we will
reject it.

	* Bite your nails. Don't do it, it's a nasty habit and you look funny
gnawing on them like that.

2. Talking to c.b.c

2.1 How to post

2.1.1 The anti-spam bot

In days gone by, the c.b.c moderator job had become increasingly difficult
because of large amounts of spam to both the group and to the submission
addresses, as well as large and frequently lengthy and repeated crossposts
to groups where things should not be crossposted. This has meant many mod
mailbox overflows and many ruined keyboards bouncing on whatever delete
key is defined.

Seriously, it really has been a problem, and only because of the magnitude
have more drastic options been applied.

On August 1, 2005, this policy went into effect (which is also given in the
mini-FAQ). To successfully submit a formal submission or a question through
the request address, your post or E-mail:

 - MUST HAVE: either the words 'commodore' or 'comp.binaries.cbm',
   spelled correctly, in upper/lower case, in either your MESSAGE BODY,
   MESSAGE SUBJECT, or both. No other headers will qualify. Odds are
   your message contains these key terms already! If it doesn't, it
   will be silently DELETED.

** Simply having comp.binaries.cbm in the Newsgroups: header is not enough! **

 - MUST -NOT- HAVE: newsgroups *other* than comp.binaries.cbm in the
   Newsgroups: header, if one exists. If you crosspost, it will be
   silently DELETED. (If you do not have a Newsgroups: header, then
   the first rule applies.)

I'm sorry about the onerousness of the requirements, but they are a needed
measure to keep c.b.c running smoothly, and most legitimate submissions
should not be affected by this policy. Please note that messages that are
trapped by the anti-spam filter do not reach the moderator, so we will not
see them if your post fails any of these conditions.

2.1.2 How to post by newsreader (MOST preferred)

Simply point your newsreader to comp.binaries.cbm and post your document.
You should refer to your newsreader for the appropriate documentation. Make
sure it is uuencoded -- raw binaries never make it, and yEnc or MIME may be
eaten by our pre-processing bots.

What will happen is that your post will be sent by UUnet to the moderators,
who will then review it. This method is most preferred because mailreaders
screw around with mail they send, particularly MIME-enabled mailers. Most
newsreaders don't. See above for the rest of the process.

Please remember that your posts are pre-filtered! Read section 2.1.1.

2.1.3 How to post by mail

While we don't really encourage this, people do have trouble posting through
Usenet, especially if your only access is through Google Groups or the like.
If you really can't post by news, send your document to:

comp-binaries-cbm(at)floodgap.com

which is a mail alias maintained by Cameron Kaiser. If you use a
MIME-enabled mailer, DO NOT UUENCODE IT BECAUSE THE MAILER EATS IT! In this
case, and this case only, SEND IT AS AN ATTACHMENT. If the mailer is not
MIME-enabled, like mailx or many Elm versions, send uuencoded files as
usual.

| Even if you subscribe to Spiro's mailing list (1.1.4), you can't submit
| through it as posts do not enter the c.b.c moderation stream (and the
| list is configured to block posts except from administrators anyway). Use
| the submission address above instead.

As a point of clarity, if you intend to send your program as an attachment,
do NOT uuencode the program and send the *uucode* as the attachment. SEND
THE BINARY ITSELF! Also, try to give the attachment a semi-descriptive name.
We often strip out attachments in one big bunch, and a whole lot of similar
looking files makes it tough to match files with posts.

CompuServe seems to be problematic with uuencoded attachments. If you can
use 'NewMail', please do so. If you can't, please alert the moderators in
the message body that you're using CompuServe OldMail and we will try to
rescue the post. (Thanks to John Iannetta.)

Please remember that your posts are pre-filtered! Read section 2.1.1.

2.2 Contacts

As mentioned, it is better to mail the moderators collectively. Posting
will have the same effect as mailing, but it's better to mail because we
can differentiate between the two.

The alias

cbc-request+at+floodgap.com

will send to all members of the moderation team, including me.

If you wish to contact me personally regarding the FAQ or the large check
you'll send me or the attractive, unmarried sister you have, send mail to

ckaiser{at}floodgap.com

and I promise to ignore it for as long as I can, unless I really like your
sister or the check is good.

John Iannetta has promised me an attractive sister, but I think someone at
| Federal Express routed the crate to the Sultan of Brunei. Spiro Trikaliotis
| has not sent me one yet.

2.3 Troubleshooting

2.3.1 'My post was approved, but it hasn't appeared yet'

If you know that we approved your post, there are several reasons why it
hasn't appeared yet. The only reason under our control is that we simply
haven't injected it into the Usenet stream yet.

Normally, we post things as soon as we approve them, just to get them out of
our hair, so most of the time these reasons below apply. In such cases,
there's no one you can blame, unless you have contacts at WorldCom. Usenet
is a very haphazard mishmash, so patience is a true virtue. Consider:

* Your ISP's newsfeed is behind. If your ISP does not have a 24/7 NNTP
  connection, it could take up to a few days for it to percolate your way.

* Bad Usenet routing. Some computer between us and you burped or did a nasty
  thing. Either way, the post is the immediate victim. Have patience -- it
  should start propagating with the computer's imminent resurrection.

* Our ISP stream is queuing up. I use Newscene, which is a pretty reliable
  Usenet injection point. Some moderators might use smaller ISPs that don't
  have a 24/7 NNTP feed, and so the actual injection step might be delayed.

2.3.1.1 'I post over and over, but you say my post never gets to you'

If you are crossposting your message, it will be deleted by our
pre-processor bot long before it ever gets to us. Furthermore, if you do
not include certain keywords in your messagebody or subject, the bot will
also eat them. Read section 2.1.1. It's not very hard, and a single tweak
will fix it. Sorry. Blame the spammers and bot posters for that.

If you've already done that and it still won't work, another issue is that
certain news sites with semi-morons for news administrators do not properly
mark comp.binaries.cbm as a moderated newsgroup. When your news server is not
aware that c.b.c is moderated, it will post the message as if it were an
unmoderated group, and pass it to another server. When it gets to a server
that knows c.b.c is moderated and this server sees that your message doesn't
have the proper credentials, it will silently drop it. End result: the
moderators don't get your post, and your post goes to the great bitbucket in
the sky.

There are two (well, two and a half) ways to fix this:

* Mail your post all the time. Easier, but gets annoying.


[continued in next message]

--- SoupGate-Win32 v1.05
 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)