[Oberon] Re (3): n-o PPP modifications

[easlab at absamail.co.za]

Peter wrote:
]A verb is missing.  Is this correct?
]> I noticed when I freed the main module the task was still "alive".
Well, in the bad 'state' the task was shown as still "alive".

> Several points of confusion remain for me.
> 
> 1. Simultaneous connections.
> I wonder whether Oberon PPP was meant to 
> support multiple simultaneous connections. 
> Does anyone have access to a design specification
> used by Martin Aeschlimann and Claude Knaus?
> Native Oberon would need more than one 
> simultaneous connection rarely but an Aos 
> with multiple modems will need a PPP process
> for each.
> 
> 2. Distinction between PPPMain.Stop and PPPMain.Remove.  
> Seems that the intention of Stop is to close 
> the connection but leave the PPP task idling 
> in the event loop.  Whereas Remove does Stop 
> and then removes the task from the loop. 
> Presumeably Stop will allow a subsequent 
> connection to start faster than after Remove.
> At least RemovePPP should release the serial port
> so that it is available for a terminal session. 
>  
> 3. In PPPMain.Mod we find 
> 	IMPORT ... PT:=(*es*)NetBase, ...
> Anyone have an idea what PT abbreviates?
> 
Yes, apparently "PT" is Edgar's alias for "NetBase".
It allows him to use shorter, more meaningful IDs.

> 3. In PPPMain.Mod we find 
> PROCEDURE * Connect (me: Oberon.Task);
> ....
> BEGIN
> 	IF V24.Available(ppp.me.c) > 0 THEN
> 		...
> 		IF ppp.me.state = PT.open THEN
> 			Oberon.Remove(ppp.task); ppp.task := NIL;
> 		END;
> 	END;
> END Connect;		
> 
> Puzzling.  What is the case where 
> V24.Available(...) is true but PT.open is false?

If/when I find time, I'll look into this.
I think you are on the right track now; ie. it has to do with
tasking.   The following extracts also point there, but are
way beyond my experience [fiddling with tasking! ]:
"NetSystem.Mod > CloseConnection , Cleanup ,
		one task per connection.  for all items in c.rq, call c.handle"
----------------------
> > John, that is a good suggestion about
> > PPPMain.CleanUp.

John Drake wrote:
> Thanks.  If anyone's had a chance to test this,
> please let us know if it worked.

Yes, I tried it immediately. And I though it solved the problem,
because I just cut the line, without PPPMain.StopInst 'properly',
when I was finished. And yet I was able to redial OK.

Then later the ISP was 'congested' [I evaluate probabilistically,
based on the weather - outdoor activety - time of day, week, 
month, TV showing...etc. ] and it 'dropped me' before login,
[ I've always wondered why these clowns don't feed-back an 
engaged signal and save their clients a call charge ?] and I had 
the same old problem.

Then I remembered that I had Peter's version of PPP loaded,
and though that perhaps your patch was only applicable to 
'standard' n-o PPP.   

Then I remembered that I had also my own "@->$" patch.    

Then I though that perhaps the 'CleanUp' should better be 
at the start of the main block, instead of after other 
initialisation, since the the existing initialisation
shouldn't be overwritten/undone by a CleanUp. And also
the problem originates from the *previous* run.

Then I though that the 'main block' is only run when the 
module is initially loaded  -  which perhaps relates to the
fact that a re-boot fixes it - so your clean up won't execute.

Then I though of making your CleanUp externally callable,
and I forget the result.

Then I though "I'm very unhappy that no one else has yet
admitted that they can confirm my claimed error symptom".

I have to test/debug this on my work-horse machine, and
pay a call-charge for each test cycle.

We really need a working CVS ?

== Chris Glur.