🚀 go-pugleaf

In article <709@aaec.OZ> sba@aaec.OZ (Sal Barbagallo) writes:
>PS: There are steps afoot to have net.micro.mac terminated and for
>mod.mac to be the main mac newsgroup. If you hate moderated newsgroups
>like I do, and hate wading through digests,
>register a protest.

Moderation doesn't bother me, but I dislike digests intensely!  Two reasons:
they make it harder to reply or follow-up; you can't break part-way through a
digest without having to plough through all the stuff you have already read when
you return.  The latter is a big problem when you use the gaps between visitors
and phone calls to read the news.

In article <709@aaec.OZ>, sba@aaec.OZ (Sal Barbagallo) writes:
 
> PS: There are steps afoot to have net.micro.mac terminated and for
> mod.mac to be the main mac newsgroup. If you hate moderated newsgroups
> like I do, and hate wading through digests,
> register a protest.

hmm, if there is really someone *ACTIVELY* promoting this, I sure would like
to know who, and where this is being discussed so that I can have my say.
Of course, I know of people with such inclinations, but would not expect
they would even consider to insult participants in such an active group
with "faits-accomplits" without a good discussion.  Don't let me down,
guys ....

when we started net.micro.mac and when we revived INFO-MAC later, there was
absolutely *NO WAY* that the INFO-MAC moderator was willing to deal with the 
additional USENET traffic.  Personally, I like moderated groups and prefer
the wading through digests to wading through random contributions, but if
the experience with mod.mac.* is any indication I worry about where we will
find a moderator with the time and dedication to handle this difficult
job of moderating a very active group like this ...

In article <1183@murdu.OZ>, stephenw@murdu.OZ (Stephen Withers) writes:
> In article <709@aaec.OZ> sba@aaec.OZ (Sal Barbagallo) writes:
> >PS: There are steps afoot to have net.micro.mac terminated and for
 
> Moderation doesn't bother me, but I dislike digests intensely!  Two reasons:
> they make it harder to reply or follow-up; you can't break part-way through a
> digest without having to plough through all the stuff you have already read 
> when you return.  The latter is a big problem when you use the gaps between 
> visitors and phone calls to read the news.


on this machine, we have software that undigests properly formatted digests
and allows you to read and reply to individual messages.  (at least, we used
to be able to do this.  Nowadays I download all digests and process them
locally - which is somewhat more of a pain to get replies and follow-ups out,
but less of a pain to "wade through" ...)

	Don't terminate net.micro.mac!!!!

I subscribe to the "net.news" tree of newsgroups, and I don't remember
any discussion about eliminating "net.micro.mac".  Its *name* is going
to change (in accordance with the overall newsgroup reorganization).

"net.sources.mac" is a different story; all of the unmoderated sources
newsgroups will be terminated.

If you are interested in the fate of newsgroups, I suggest that you
subscribe to "net.news.group" (to which I have cross-posted this
and redirected followups).  You are more likely to find correct
and (more) timely information regarding the USENET reorganization and
the fate of newsgroups in there than in "net.micro.mac".  (At the very
least, if I'm wrong on any aspect of the fate of the Mac groups there
will probably be at least one correction posted to "net.news.group".)
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb@mordor [jdb@s1-c.ARPA]	(415) 422-0758
  UUCP: ...!ucbvax!decwrl!mordor!jdb 	...!seismo!mordor!jdb

	I am examining some assembly code that makes does the following...

   204F           ' O'             MOVEA.L A7,A0
   42A8 000C      'B...'           CLR.L   ioCompletion(A0)
   317C FFFD 0018 '1|....'         MOVE    #-3,ioCRefNum(A0)
   317C 0006 001A '1|....'         MOVE    #6,CSCode(A0)
   217C 0002 FFFD '!|....'         MOVE.L  #$2FFFD,CSParam(A0)
   42A8 0020      'B.. '           CLR.L   CSParam+4(A0)
   42A8 0024      'B..$'           CLR.L   CSParam+8(A0)
   A004           '..'             _Control ; (A0|IOPB:ParmBlkPtr):D0\OSErr 

	I cannot find in any of my documantation a description of what a 
_control call with CScode set to 6 does. Can someone out there give me
some help and tell me what this call does?
		Thanks!
		Peter Espen (espen@well)

In article <1970@well.UUCP>, espen@well.UUCP (Peter Espen) writes:
> 	I cannot find in any of my documantation a description of what a 
> _control call with CScode set to 6 does.

     This is probably driver-dependant, and you don't say what kind of program
you're looking at, so it's hard to infer.  The disk driver, for example, uses a
CSCode of 6 as an instruction to erase the disk.  I don't think that's what
your piece of code was doing, because the CSParam field was not filled in
correctly.  (The disk driver wanted an integer in CSParam.)

Brian H. Powell
		UUCP:	{ihnp4,seismo,ctvax}!ut-sally!brian
		ARPA:	brian@sally.UTEXAS.EDU