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

[easlab at absamail.co.za]

Peter,

>  ---------- 15 minutes later  System.ShowTasks ==
> Oberon  PC = 5015  safe  29558585 waiting 28407ms
> PPPMain  PC = 84  unsafe  0 ready   <-------- !!
> NetSystem  PC = 13426  safe  229587 ready
>  ---------- After   de-lock via Ctrl=Break  System.ShowTasks ==
> Oberon  PC = 5015  safe  29978466 waiting 31386ms
> NetSystem  PC = 13426  safe  229587 ready
> Dialer  PC = 1630  unsafe  0 ready
> 
> So if you can also reproduce the problem, confirm that
> PPPMain is 'still running' in the bad-state.
> 
> I think that relates to 'task switching' ?
><><><><><><><><><><><><><><><><><>

So then trying: System.Free  PPPMain ~ ==
PPPMain unloaded

and now it's possible to dial.
I.e. the lock-effect is removed:--
]Dial script startedModem off-line, device 0 closed
]
]Sending [ATZ]
]Waiting 10s for [OK] {ATZ||OK}
]Sending [ATX]
]Waiting 10s for [OK] {|ATX||OK}
]Sending [ATM2D 3407501]
]Waiting 60s for [CONNECT] {|ATM2D 3407501||CONNECT}
]Calling [PPPMain.StartInst PPP 2nm4nx6x at za]

but not surprisingly I get:---
TRAP -14  NIL reference ( 00000CBCH ) (PC Native 11.10.2001)
PPPMain.StartInst  PC = 627
	S =  00000014H
	ao =  00000038H
	papname = "2nm4nx6x at za"
	pappasswd = "...
---------------

And that's why I was previously inspecting the interaction
with the task switching mechanism.

Truely, I don't think even an in-depth understanding of PPP will
solve this.

Apparently with a good/normal session completion, PPPMain
is removed from the task-loop, but with an 'abort' it is not.
If so, one would need to know about the task installation
& deinstallation mechanism of n-o ?

The CO-laboration [i.e. division of labour, v. each one working
privately] of n-o is less than optimum -- to envolve those with 
knowledge of the tasking mechanism, but no interest in using,
hence fixing, the n-o dial-in facilities.

== Chris Glur.