Remote Access long standing problem

Scripting Forums AppleScript | Classic Mac OS
,
#1

:?: Being new to AppleScript I probably haven’t expressed my problem very well, hence no solution yet.

Here goes again. Have a script which starts by accessing the internet to get the info it needs to process. All is well as remote access dials out, EXCEPT when the line is busy, when the script tries to continue while unable to retrieve the info it needs from the net and eventually jams in the process.

This script is triggered remotely so a considerable journey is needed to reset things when this happens. Hardly satisfactory…

All I need is a way to check that remote access has made a connection before the script is allowed to continue, and a way to order the connection process to repeat until connection is made.

I sense this is probably a simple if and repeat sequence, but I can’t get one to work.

Pleaase help if you can.

#2

First, I would say get a different ISP if you are getting busy signals. But I guess that isn’t always an option for some folks.

I wish I could test Remote Access status but I am on a T1 at work and broadband at home and have no account to fiddle with. I thought I’d be able to at least get RA’s status but Network Setup Scripting makes no sense to me. I believe there is a Remote Access scripting addition, maybe this will make it easier. I thought you’d be able to just do the following.

tell application "Network Setup Scripting"
	try -- 
		close database
	end try
	open database
	set myConfig to Remote Access configurations whose active = true--this works for me
	connect Remote Access configuration myConfig --this does not
	repeat until activity of myConfig = connected --repeat until this configuration is connected (I cannot test this, I think it should work without an account but...)
	end repeat
	--do your thing here
	close database
end tell

I cannot test connecting or get the activity of my configuration. Maybe this is what you are looking for. I do know that on newer versions of AS you can declare something like “with synchronous” in the connect command but I do not have that here. That supposedly makes the script wait until connection has been achieved. I will check at work tomorrow if that was spelled correctly.

But that still raises a concern. That will still allow the script to proceed even if the info you are getting hasn’t fully downloaded.

I remember from your other post that you are using Eudora. Maybe, you could use something to check to see if any messages have downloaded.

tell application "Eudora"
	set emailCount to the count of messages of mailbox "In"--get the count of messages 
end tell
if emailCount = 0 then --if there are no messages then
	--try to connect again (but if you did connect and simply have no data to process it would blindly connect and connect again.)
end if

If you are checking a mailbox other than in, like a <> account try:

tell application "Eudora"
	set emailCount to the count of messages of mailbox "mailbox name" of mail folder 1--change the mail folder number if it is not the <<dominant>> account. 
end tell

Sorry I don’t have more to offer.

#3

Hello Mytztscript,

Many thanks. You recall I have been trying to slove this for some time now, and we may be close. Trying your suggestion, it does connect but I get

Execution Error, Can’t Get state of (Remote Access configeration “myISP” of application Network Setup Scripting"

This is what I used before to connect

tell application "XAT offline:System Folder:Scripting Additions:Network Setup Scripting"
	
	open database
	connect Remote Access configuration "my ISP"
	
	close database
	
end tell

[u] upon closing I use

[/u]

tell application "XAT offline:System Folder:Scripting Additions:Network Setup Scripting"
	
	try
		
		open database
		
		set activeSet to a reference to (every Remote Access configuration whose active is true)
		
		disconnect activeSet
		
		close database
		
	on error
		
		beep 3 --so I knows thars an error 
		
		close database
		
		
		
	end try
	
	
end tell

here the script seems able to detect that activity is on, yet the error I mentioned when trying to detect activity off.

Is there no way to have the connection process repeat until connected before allowing the script to continue to it’s next step?

As I said, I’m new to this and the solution is probably simple to one who knows.

Thanks again

#4

I wasn’t able to get the current Remote Access status through NSA. I’m sure there is a way but I am lazy and resorted to the RA PPP scripting addition.

Download RA PPP OSAX here:
http://osaxen.com/ra_ppp.html

I was able to see if RA was idle, or connecting with this. From there we can just repeat until the message of the status record = “connected”. That should hold your script back until Remote Access is connected.

--do whatever works for you to connect here
set raStatusRec to (RA status) --get the current Remote Access Status Record

repeat until message of raStatusRec contains "connected"
	set raStatusRec to (RA status) --keep getting the RA status until the message = connected
	if message of raStatusRec contains "idle" or message of raStatusRec contains "disconnecting" then
		--I'm thinking remote access shouldn't be idle or disconnecting at this point unless
		--there was a problem.  If it is, try your connections commands again here
		--do whatever works for you to connect here
	end if
end repeat
--continue with your script, you should be connected at this point

I am not able to connect but was able to get this to repeat until Remote Access status was “connecting” so I’m thinking this should work for you.

Good luck.

#5

getting closer.

Error message: asking for Apple Shared Library Manager

Can’t find download for this.

have ‘shared library manager’

can you advise?

many thanks

#6

post what you have and where the error occurs.

#7

When running the script above with my connection syntax I get:
Execution Error
An Error of Type :3201 has occurred
(this has replaced an error message asking for Apple Shared Library Manager)not sure why?

Then Remote Access connects leaving the error message providing the line is not busy…

My untrained mind tells me part of our problem is that the script calls to remote access to connect and then moves on while Remote Access takes it’s time to connect.

While the script is checking for connection, Remote Access is still in the process of dialing so no connection is there to report, despite the fact that all is well and there will be a connection within about 30 seconds.

Rather than check connection after the connection syntax has been activated, is there perhaps a way to insure connection is completed before the script goes to the next step?

Since it is Remote Access that is dialing and not the script, the script needs to account for the extra time involved outside it’s instruction.

Is this making any sense?

#8

Right - the script I posted should repeat until the message of the status of Remote Access contains “connected”. I tested this at home, granted on OS 8.6, but was able to build a script that stayed in a repeat loop until the message status of Remote Access = “connecting”. ( I can’t program it to wait until “connected” as I have nothing to connect to)

That’s right, and what I posted should make the script wait until the status of remote access is connected. Is it possible that the message of remote access says connected when it really isn’t yet?

repeat until message of raStatusRec contains "connected"

This line should disallow any progress in your script until Remote Access has connected.

Perhaps I’m just not getting what you are having problems with.

No clue as to why you would be getting this error - sorry. When do you get this error?

#9

All sounds good and I am very grateful for all the time you are dedicating to this. It means a lot to me to solve this problem.

On the error. It has become An Error of Type :3201 and remains so.

When starting the script it higlights the first (RA status) in the script and displays the error message. It then connects providing the line is not busy. This error is stopping the script from fulfilling the repeat function should it need to.

#10

I was testing that at home using OS 8.6 and had no troubles. But now that I am at work I too get the -3201 Error. The documentation for the RA PPP OSAX does state something about getting the status. I am able to get the status if it is idle but if it is connecting I get the same error as you. I’d be interested in finding out if the error is generated only when connecting, or disconnecting. Unfortunately I cannot test this as I don’t have the means.

You could try it by testing the following on the premise that the error is only generated when connecting/disconnecting. The following will TRY to get the message of RA status and if it fails assumes it is connecting or disconnecting. If my theory is flawed, and the error is also generated when connected, then this will not work.

(*Robert, This theory is solely based on the assumption that we only get the
error -3201 if RA is currently in the process of connecting or disconnecting.
I know the (RA status) command works when RA is idle and am gambling that it
works when connected as well.  If this is not the case then the following is useless.
But it is worth a shot.*)

--do whatever works for you to connect here 
try --try, if RA is connecting you may get the -3201 error (fine, at least we know we are not idle)
	set raStatusRec to (RA status) --get the current Remote Access Status Record 
on error
	set raStatusRec to {message:"Connecting"} --if we do get the error, then I'm guessing it is connecting/disconnecting (so set up a fake record for now, just to get us to where we can repeat until message is obtainable)
end try

--I sometimes use this in repeat scenario's where I repeat until something happens.  In case it never does I keep track of how
--many times I've tried and exit repeat if I deem it just isn't going to work.  Totally optional...
set timesTried to 0
set connectionFailed to false --if the connection fails after a number of tries set this to true

repeat until message of raStatusRec contains "connected"
	try
		set raStatusRec to (RA status) --keep trying to get the RA status.  Again, my theory is that it fails on connecting/disconnecting.  
		--if it gets to this point then it did not error, see if it is idle.  If it is, maybe the line was busy and we need to try to connect again
		--if it isn't idle, and it didn't error, then hopefully we should exit the repeat connected, and ready to rock.
		if message of raStatusRec contains "idle" then
			--I'm thinking remote access shouldn't be idle at this point unless 
			--there was a problem.  If it is, try your connections commands again here 
			--do whatever works for you to connect here 
			set timesTried to timesTried + 1 --add one to denote yet another connection try
		end if
	end try
	if timesTried = 20 then --if we tried to connect, say 20 times, (you can adjust this to however many times you want to try), exit the repeat and give up
		set connectionFailed to true
		exit repeat
	end if
end repeat
if connectionFailed = false then --then we didn't try 20 times yet we made it out of the repeat.  I'm thinking it's connected at this point
	--continue with your script, you should be connected at this point
else
	return --or do something else (not connected, failed to connect)
end if

Let me know what happens. Good Luck!

#11

Sorry for the delay in reply.

The script is working but often on about the third try to dial I get:

'The appication “script editor” has unexpectedly quit because an error of type 3 occurred you should save your work in other open applications and restart.

or

‘Sorry a system error occurred Script Editor error type 3’

on odd occasions it has sited error type 1 and error type 10

and sometimes the script just freezes with no error message.

Thought it might be a problem in my Script Editor so reinstalled system 9.1 and still the errors occur more often than not.

This really is promising if only these error did not occur.

Have not experienced this while running any other AppleScripts.

Hope you can help.

#12

This leads me to believe you are running your script via the editor, which should work. It is frustrating to have mysterious freezes and errors without much help from your Mac to track them down. I too have had scripts that simply would not run correctly within a script editor but for some strange reason would if compiled and saved as applications. So that would be my first suggestion.

The other would be to make your Mac, more specifically your script, communicate where the problem lies. If you were using a script editor other than Apple’s you could step through the script, one line at a time and isolate the problematic line of code. You could also isolate the quirk by having your script log something to a file after each action, or just the critical or suspicious steps. I had a 3000 line pig that sprouted a bug and I ended up inserting what ended up to be 300 lines of logging just to track down where it derailed. You can be as detailed as you wish, and once you track down and fix the naughty line you can remove the debugging lines.

You can define a path to a file to your activity log file at the beginning of the script. Something like:

set activityLog to "Mac HD:Desktop Folder:Activity.txt"

Then, before each line that you suspect, or if your script is small enough, before every action, insert a line of code that appends a line of text to your log. The thought is, if your script fails, or worse yet, locks up your station again you can open this log and find out what the last successful line of code was. For writing to a file I favor Tanaka’s appendtofile command (Tanaka’s OSAX v1) . It is quick and easy and would look something like:

appendtofile "Line 174 About to get RA status" & return to activityLog

If you don’t want to download Tanaka’s fine scripting addition you can achieve the same effect through Standard Additions.

set activityEOF to get eof activityLog--first get the end of the file (where we'll start writing)
write return & "Line 174 About to get RA status " to activityLog starting at activityEOF--then write the line, starting at EOF, and be sure to include a carraige return

I wish I could throw you a quick fix but without knowing where your script is failing, or being there to see it in action makes it tough. This should get you on your way to isolating the problem though.

Best of luck!

#13

Hello Mytzlscript,

Been on a break and abandoned my quest for a dialing script that deals with a busy signal for a bit…

Got back and must admit I’m not clear on what you are suggesting.

When you question how long my script is, I finally realized you probably think I’ve included your code at the head of a long script that’s failing. Probably because I’ve mentioned the long script before.

Actually what causes the failure is within the code you provided as that is all I was testing on it’s own.

My knowledge of AppleScript has increased a great deal thanks to you, but I’m still pretty green on this. Is my just testing your connection code on it’s own, not at the top of a script, possibly the problem?

Hope you are still there and this finds you well.

Respect

#14

Hi Robert all is well, thanks!.

My last post suggested 2 main things.

  1. Save your script as an application and run it from there instead of from within the script editor. Since the script editor is what is failing, and since you won’t be running this remotely via the script editor anyway I thought it might be a good idea to run it as an application, as it will be run. Maybe the errors will stop, maybe not.

  2. My other suggestion, long winded as it was, dealt with error trapping. From your previous post I was unable to determine where you were getting your error messages.
    I am spoiled in that I have a nice, feature packed script editor so I am able to step through scripts, see results a line at a time. I was trying to tell you how to do the same using dialogs to see results after every line, or to get your errors logged to help track down why your script was stopping.

My post from [4/17/03 at 10:42] am provided a script that would work but only if the error is generated on connecting and disconnecting processes. I was wondering if you had a chance to test that one. And again, try running it as a stand alone application instead of from the script editor.

I am pretty much out of suggestions on this one. Am unable to test at work (T1), and no longer have a phone line at home. Perhaps someone with more resources and a little more knowledge could step in?

Good luck Robert!

#15

This one keeps coming to haunt me. It would be great to have it working. I’ve added the connection code as follows.

(*Robert, This theory is solely based on the assumption that we only get the 
error -3201 if RA is currently in the process of connecting or disconnecting. 
I know the (RA status) command works when RA is idle and am gambling that it 
works when connected as well.  If this is not the case then the following is useless. 
But it is worth a shot.*)

--do whatever works for you to connect here 

tell application "XAT offline:System Folder:Scripting Additions:Network Setup Scripting"
	
	open database
	connect Remote Access configuration "onetell"
	
	close database
	
end tell

try --try, if RA is connecting you may get the -3201 error (fine, at least we know we are not idle) 
	set raStatusRec to (RA status) --get the current Remote Access Status Record 
on error
	set raStatusRec to {message:"Connecting"} --if we do get the error, then I'm guessing it is connecting/disconnecting (so set up a fake record for now, just to get us to where we can repeat until message is obtainable) 
end try

--I sometimes use this in repeat scenario's where I repeat until something happens.  In case it never does I keep track of how 
--many times I've tried and exit repeat if I deem it just isn't going to work.  Totally optional... 
set timesTried to 0
set connectionFailed to false --if the connection fails after a number of tries set this to true 

repeat until message of raStatusRec contains "connected"
	try
		set raStatusRec to (RA status) --keep trying to get the RA status.  Again, my theory is that it fails on connecting/disconnecting.  
		--if it gets to this point then it did not error, see if it is idle.  If it is, maybe the line was busy and we need to try to connect again 
		--if it isn't idle, and it didn't error, then hopefully we should exit the repeat connected, and ready to rock. 
		if message of raStatusRec contains "idle" then
			--I'm thinking remote access shouldn't be idle at this point unless 
			--there was a problem.  If it is, try your connections commands again here 
			--do whatever works for you to connect here 
			tell application "XAT offline:System Folder:Scripting Additions:Network Setup Scripting"
				
				open database
				connect Remote Access configuration "onetell"
				
				close database
				
			end tell
			
			set timesTried to timesTried + 1 --add one to denote yet another connection try 
		end if
	end try
	if timesTried = 20 then --if we tried to connect, say 20 times, (you can adjust this to however many times you want to try), exit the repeat and give up 
		set connectionFailed to true
		exit repeat
	end if
end repeat
if connectionFailed = false then --then we didn't try 20 times yet we made it out of the repeat.  I'm thinking it's connected at this point 
	--continue with your script, you should be connected at this point 
else
	return --or do something else (not connected, failed to connect) 
end if

Using only this connection script which is meant keep redialing until connection is made, It more often than not freezes the computer, crashes the script editor if I’m using it, or crashes itself as an application.

If someone could try this and advise, that would be brilliant.