BS> Hello Bob!

Hi, Bo....

 BS>> I notice, if calledbefore is set, there is no problem..

 BJ> Ah.....  maximus has I believe two mecca files that are shown to a 
 BJ> user on the first few calls.  There is a new user (initial login 
 BJ> sequence) and then a thanks for comming back / here's some more 
 BJ> startup info sequence....  Maybe Max is getting 
 BJ> hung up on processing 
 BJ> this second set of files?

 BS> Hmm.. can you remember the filenames of those scripts?

Ok.....

On initial login NEWUSER1.MEC / .BBS is processed to display info about
selecting a password.  NEWUSER2.MEC / .BBS is also displayed as part of the
initial login process.  Another file (early) in this sequence is
WELCOME.MEC / .BBS and APPLIC.MEC / .BBS .

ROOKIE.MEC / .BBS is displayed on the 2nd thru nth call (I think 2nd thru
5th by default).  After that it drops out of the log in sequence.

BULLETIN.MEC / .BBS are displayed on most logins, if I remember correctly.

Depending on how you are "faking" BPS rates, there are other
possible .MEC files displayed before haning up on the connection, shortly
into the login process.

All of the above files are typically in the ...\MAX\MISC directory and the
.MEC files are processed via MECCA(P) into .BBS files.  The .BBS files are
what the running BBS actually uses.

 BS>> Well let me say it.. it look like a old school bbs in dos, after a 
 BS>> printf "\033(U".. I'm running ANSI, else i won't be able to 
 BS>> write this message in MaxEd.

 BJ> I figured some of that was hard coded.  Not nice in a unix 
 BJ> enviornment where a TERMCAP or CURSES library should be used instead 
 BJ> (old school Unix thoughts).  Now, with almost all 
 BJ> folks emulating the 
 BJ> terminal as a VT-100 work-alike, it is less of a problem......  
 BJ> Hmmm....  I wonder if the exchange sequence 
 BJ> includes a control-s from 
 BJ> either end?  I recognize the \033 as escape, and 
 BJ> the (U is one of the 
 BJ> functions (following an escape character)....

 BS> Well you need \033(U to see the normal .ans files graphic.

But that dates back to VT-100 standards.....  Ok...  I'm showing my age
here, but back when you actually connected with real terminals to unix
boxes, there were several different terminals, most with their own (unique)
escape sequences.....  The VT-52 set is different from the VT-100 set. 
It's just the VT-100 set was the most widely implemented as the terminal
became virtualized, and only a standard configuration of the VT-100 (i.e.
subset) at that.  Then that "standard" became expanded into the
ANSI or PC standard.....  Any ways....  Since Max was written for PC based
equiement, it hardcoded the sequence.  Programs on Unix systems usually
used CURSES or TERMCAP libraries to support multiple types of
terminals.....  At some point after Max starts running under Linux / Unix
boxes, we will probably see a complaint that Max doesn't work with
, even with the proper TERMCAP
setup.    

 BJ> I think eventually max needs to be able to take a hand-off from 
 BJ> either mgetty or inetd.  

 BS> Well i don't think.. If i run the BBS, i've no chance 
 BS> to run a mailer too.. I don't know how mutch you know 
 BS> about mgetty..

There is a version of GETTY that is supposed to differenciate between
Fidonet hand shakes, PPP and regular modem calls, FAX calls, and possibly
even a voice (on a voice modem) call.....  getty normally hands off regular
modem calls to a shell.  We could have getty had it off to a shell and have
users login into "max" as a user of the system and then have that
shell in to Maximus (directly) and proceed from there... or we could have
getty directly start Maximus and proceed from there.....

My goal would be to eventually have Fax, modem and Voice answering machine
all handled via a single modem on a single serial port controlled by getty
handing off to the appropriate software.  I'd also like getty to handle
caller ID and distictive ring information, and be able to act according to
my wishes.

 BS> BTW max is getting better day for day.. i've been 
 BS> making several changes in the MSGAPI, so squish is 
 BS> working very good, except for it has some problems 
 BS> about dupechecking, but it has them too with *.MSG, and 
 BS> i can't figure out the problem, maybe wesley can..

 BS> BTW it's only if dupechecking should be out from msgid 
 BS> or msgid and header... i run only specified header there is no problem..

Ah.....  Who / what program is generating the "dupes"?  The msgid
standard that I think Squish / Maximus implemented has a problem if one
tries to generate two messages (or more) within one (or was it two)
second(s).  Back when the design was done, it wasn't possible to generate
messages that fast.  But with faster hardware, and with robots producing
net and/or echo mail, it is fairly easy now to generate messages too fast
to get unique msgid's.  And Squish's dupe checker, when MSGID checking is
enabled, will toss the non-duplicate messages with the same MSGID as dupes,
if I remember correctly....

Take care.....

Bob Jones, 1:343/41



--- Maximus/2 3.01