Hello Bob!

May 28 17:57 03, Bob Jones wrote to Bo Simonsen:

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

 BJ> Ok.....

...

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

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

That right.

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

I'm faking it to 38400.. 

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

Yep i did that..

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

 BJ> But that dates back to VT-100 standards.....  Ok...  I'm showing my 
 BJ> age here, but back when you actually connected with real terminals to 
 BJ> unix boxes, there were several different terminals, most with their 
 BJ> own (unique) escape sequences.....  

Yeah, the VT100 was mostly used, as far as i've been told.

 BJ> The VT-52 set is different from 
 BJ> the VT-100 set.  It's just the VT-100 set was the most widely 
 BJ> implemented as the terminal became virtualized, and only a standard 
 BJ> configuration of the VT-100 (i.e. subset) at that.  Then that 
 BJ> "standard" became expanded into the ANSI or PC standard.....  Any 
 BJ> ways....  Since Max was written for PC based equiement, it hardcoded 
 BJ> the sequence.  

Yeah that right.

 BJ> Programs on Unix systems usually used CURSES or 
 BJ> TERMCAP libraries to support multiple types of terminals.....  At 
 BJ> some point after Max starts running under Linux / Unix boxes, we will 
 BJ> probably see a complaint that Max doesn't work with  terminal name here>, even with the proper TERMCAP setup.    

Now i understand!

 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..

 BJ> There is a version of GETTY that is supposed to differenciate between 
 BJ> Fidonet hand shakes, PPP and regular modem calls, FAX calls, and 
 BJ> possibly even a voice (on a voice modem) call.....  

It's mgetty as i wrote. But if maximus is taking care of listening at the
port, and so on, it's quite hard to get it in tuch with a mailer.

 BJ> getty normally 
 BJ> hands off regular modem calls to a shell.  We could have getty had it 
 BJ> off to a shell and have users login into "max" as a user of the 
 BJ> system and then have that shell in to Maximus (directly) and proceed 
 BJ> from there... or we could have getty directly start Maximus and 
 BJ> proceed from there.....

Yes.. Well it could call Maximus directly, like fx. it does with MBSE...

Then the telnet IO module, will be useless, because it could smoothly be
called from inetd.

So it's the arguments of what max is beeing called with, there is telling
max if it's a telnet user or a dialup user..

Inetd calls a program with -h hostname and other arguments, mgetty calls it
with -b connect bound ... Or something.

But in a unix environment, i really can't see the difference of a TELNET
call or a POTS/ISDN call.

I wonder if the operating system can?

The idea in having maximus listening on a port, could be it would control
the chat system and so on, but it doesn't do that... 

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

That correct. You could even make a PPP connection if you were out.

 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 
 BS>> problem..

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

Well i don't have the big interest in using Squish, because it get all what
squish can with the hpt tosser from the husky project..

Even more, it share configfile with my ticker, msgeditor and other programs.

I wrote a quick and durty C program there is using the fidoconf-liberay to
get hpt's area configuration and write msgareas.ctl.

Regards,
Bo

--- Msged/LNX 6.1.2