When a program doesn't work, it's hard to know what is causing the problem when it works on an Alpha Micro, but not in a-shell. I'm thinking that there is a problem with Subroutines. I did a hash on all *.sbr's and they check out the same on both sides.
Example:

Error message: Record not locked in line 9010

! * 9. ANYCN.SBR - Subroutine to allow changes to any input field.
9010 CNGCTL = 4 : XCALL ANYCN,CNGCTL,WHATNO : RETURN

I looked in the program and there isn't an error message - Record not locked
So it has to be a-shell system generated?

In my amosl.ini the subroutines are load into memory, could this be the reason none of the xcalls work? I don't know how to load subroutines only by amosl.ini. I thought the sbr only had to be in [7,6] to work. As you can see I'm confused

Stephen

All SBR modules in A-Shell are linked into the A-Shell executable, rather than fetched from disk or "LOADed" into memory as under AMOS. So there is no point in copying your SBR/XBR files over from AMOS. (See Chapter 5 of the User's Guide, particularly the first page, where this is discussed, followed by a list of all the subroutines that were included as of the printing of that guide about 18 months ago. Since then, dozens more have been added, which are currently only discussed in the UPDATE.TXT file.)

As of 4.6(746), A-Shell supports a new mechanism of developing and calling XCALL subroutines which are written in Basic and which have SBX extensions. This is very significant if you need to develop subroutines, but these SBX modules cannot be used directly under AMOS. See the A-Shell Technical Note 1002 on the Advanced Support Page for full documentation about writing SBX subroutines. (There are also many notes about SBX routines in UPDATE.TXT - just search for "SBX".)

Going back to your question, if your program performs an XCALL specifying a subroutine which is not already linked inside of the A-Shell executable (and which does not exist on disk as an SBX module), then A-Shell will pop-up a message box telling you the name of the subroutine which is missing. This pretty much eliminates guesswork about missing subroutines, although it does not help you locate errors and discrepancies between the A-Shell implementation of a particular subroutine, like ANYCN.SBR, and the AMOS version.

There is no magic solution to that problem, although there are some debugging tricks you can use. One is to use the commands:

.SET TRACE XCALL ON
.SET TRACE FOPENS ON
.SET TRACE SYSERR ON

before running your program. The XCALL trace will leave a record of each XCALL in the file ashell.log (in the same directory where the MIAME.INI file is.) This can help you tell what the last subroutine called was before you get an error. The FOPENS trace will log the opening and closing of each file to the same log, which is often quite useful in debugging. The SYSERR trace will display on the screen additional OS-level information about errors that might otherwise only cause a Basic error condition.

If you suspect that an error occurs within an XCALL, but aren't sure, you might be able to use the ALIAS option in the miame.ini to ALIAS the routine to some non-existing routine, then when it gets called you can select the option to "Ignore" the subroutine. If your error still occurs, then surely it was not in that subroutine. (This doesn't work so well with subroutines that the program can't function at all without.)

As for the "record not locked" error (Basic Error #42), this and every other Basic error
message is listed in SYS:ERRMSG.xxx (where xxx is your language extension.) So indeed, you won't find the message within your program. This particular error is LOKSER-related, and indicates that you tried to perform a record update operation without previously locking the record. My guess is that your program was not intended to run with LOKSER on (and probably predated the introduction of LOKSER under AMOS.) So the first thing to do would be to set LOKSER=OFF in your miame.ini file.

It seems doubtful to me that the XCALL ANYCN operation is generating this error. Probably the error is occurring in a subsequent instruction following the RETURN on that line. Note that any subsequent lines without line numbers will effectively share the line number of the last line with a number.

I think my main problem is subroutines.
Here is a problem with one of my programs. It's a menu program that loads a text file of the description and then a list of the program name down the bottom. It uses chain "name" to link to the program.
Error message:
?can not find program .run
It uses noecho and echo
100 F = ENTRY
200 CH(F)= CH(F)[4,30]
300 XCALL ECHO
400 CHAIN CH(F)

If I force the name chain "cusmas" ..... then it works. ?can not find program .run must be a ashell error message.



I did a directory of my sbr's and there were 80 and a lot you don't have. That is like eliminating all the common code among programs. How can you cover all possible SBR's, when there user generated?


Stephen

You're raising a couple of independent issues here. On the chain problem, the error message "?can not find program .run" implies that there is a problem in the contents of the string variable you are chaining to. As a general rule, if your code worked under AMOS, it should work the same under A-Shell, but since you appear to have the source code to the program, I would suggest printing out the contents of the variable you are chaining to just before the chain so that we can get right to the bottom of the problem, e.g.:

200 CH(F)= CH(F)[4,30]
300 XCALL ECHO
350 PRINT "CHAIN TO '";CH(F);"'" : stop
400 CHAIN CH(F)

As for your question "how can you cover all possible SBR's...", the answer is multi-fold. Obviously we can't (in advance) cover SBR's we don't even know about. But we have been doing this for about 10 years now, and have converted hundreds of existing SBR's, including virtually all of the commonly used ones distributed by Alpha Micro and most of those distributed by the AMUS User's group. When we come across SBR's that we have not previously converted, then we typically use or suggest the following steps to decide how to deal with the SBR:

1. First, determine what it does and what it's precise parameter requirements are. (If nothing else, use the SET TRACE XCALL ON feature to log the XCALL parameters to ashell.log)

2. Review the list of documented subroutines which we have converted to see if it can simply be ALIASed to another.

3. Send us what you know about the subroutine (including the M68 if you have it, as well as Basic source code which calls it) and we can evaluate whether the possibilities. In many cases, if the SBR can't be ALIASed to an existing SBR, a relatively simple extension can be made to an existing SBR to allow it. Failing that, we can evaluate how much work is involved in rewriting it in C from scratch, or as an SBX in Basic (which you can write yourself), and also suggest how you can work around it in your Basic source, perhaps through the use of similar routines we support.

4. If we jointly decide that the best approach is to rewrite it in C, we will quote you a fixed price to do it and once complete, it will become part of the standard A-Shell.

Admittedly, if you have 80 custom-written subroutines, this process might be expensive. But in the vast majority of cases, the list of all subroutines in a package can be quickly whittled down to a very manageable list to be converted or worked around.

I suggest you start by making a list of all your XCALLs, and apply steps 1-3 above to it.
We generally don't charge anything for helping you evaluate your possibilities and for providing a quote for us to do the conversion, unless the complexity of the evaluation warrants it, in which case we would first make the appropriate arrangements with you.

> As a general rule, if your code worked under AMOS, it should work the same under A-Shell,

That is the problem, it doesn't.

I already did your suggestion of printing out the string
PRINT TAB(10,1);CH(F)
XCALL MESAG,"",1
and the selection was cusmas and it came out cusmas but the system still said ?can not find program .run
so I forced the chain... chain "cusmas" and it worked. The problem has to be with XCALL ECHO going back
to my statement none of your subroutines are compatible.

>commonly used ones distributed by Alpha Micro
ECHO is a common sub, but it doesn't work.

Should I email you the program and the data file so you can see for your self that it's the subroutine?
I was thinking of posting it here, but I thought it might make you mad If it doesn't I will.

Stephen

I was guessing that perhaps there were some blanks or other control characters preceding the "cusmas" which were throwing off the parser, which is why I suggested bracketing the output with quotes. It is always possible that there is something strange and unexpected before or after the "cusmas" that the AMOS CHAIN is not bothered by but that A-Shell CHAIN is. That might explain why this particular CHAIN statement does not work, since I can assure you that virtually every application uses CHAIN heavily, and I do not think anyone has reported this particular problem. But once we can identify it we can fix it. If you want to send me the program and whatever data files it needs to work, I'll be happy to take a look at it. Just zip them up (or not) and email them to support@microsabio.com.

You were right about the string it had led with a blank, but that creates a problem of knowing which side the problem is on. I'm going on the assumption if it worked before then it has to be on the A-shell side.
You were right about the string it had led with a blank, but that creates a problem of knowing which side the problem is on. I'm going on the assumption if it worked before then it has to be on the A-shell side.

I'll just have to take one program at a time, I hope you don't get tired.. I really do need to abandon Alpha.

This is a good example of an undocumented "feature" that can go "unappreciated" for years. Although it is only applicable in cases of sloppy programming, I see no harm in modifying A-Shell to trim any leading blanks from the string specified in a CHAIN statement and have added it to 4.6(787)-4. You can download now it from the "Beta" page on the "Advanced Support Network" site (http://www.a-shell.net)

I notices you use a command I'm not familiar with "stop" I have used XCALL MESAG,"",1
but I notice it gives the error: Windows box Application Error.
Is stop a good replacement?

A-shell manual:



I've notice a dialog box won't let you ctrl c out of the program and creates an uncontrollable loop.

"STOP" is a standard AlphaBasic statement which simply prints a message:

Program stop in MESAG.RUN
Enter CR to continue:

and waits for you to hit a Carriage Return (CR), or if control-C is enabled, you can hit that also and abort the program. This is a useful debugging tool.

XCALL MESAG,"",1 accomplishes much the same thing, although it is somewhat more complex because it is an XCALL and subject to some externally configurable variations. One is implemented by the MIAME.INI parameter SBR=MESAGRTN parameter which you can read about in the User's Guide. (It only affects the wording of the message.) Another is implemented by the MIAME.INI parameter SBR=INFDEF:|S which will take an "auto snapshot" upon responding to the message prompt. (See UPDATE.TXT 4.6(772).) Yet another is that under A-Shell/Windows, if you use a driver with "G" on the end (e.g. PCTDVG instead of PCTDV) then it will convert XCALL MESAG,,flag to a standard Windows message box, with the in the interior of the box. The title bar of the message box will say "Application Error" if the flag parameter is 1, else it will say "Application Message".

The available ways of acknowledging such a message box are to click on the OK button, or to click on the "X" in the upper right corner, or to hit ESCAPE. Control-C is not am option to the Windows message box, although it is to the standard text version XCALL MESAG. In neither case do I see a way to create an infinite loop. If you have a reproducible recipe for that, please submit it to support@microsabio.com as a bug.

While on the subject of message boxes, here are a couple of other tidbits worthy of note. One is that if you are making a TELNET-style connection to A-Shell/Windows (using the ATSD Telnet Server) then any such Windows message boxes have to be implemented as as text equivalents using the INMEMO free-form menu mechanism. The other note is that if you like Windows-style message boxes and are using A-Shell Windows, you can display a variety of message box styles using PRINT TAB(-10,4) and TAB(-10,17). See the sample program TCRTEX in the sample directory DSK0:[7,376] on a standard release for more details.