Hi, since I made the 'leap' from developing on an old AMOS box to running A/Shell on my laptop, I can't get XCALL GET to behave nicely.

In the .BAS program I compiled under A/Shell, I can RUN my application on my laptop running A/Shell fine. When I send the .RUN file to run under the AMOS environment, it just hangs and you have to CTRL-C to get out.

I can't find a GET.SBR under A/Shell to compare it to the version/hash on the AMOS box, so I don't know where to go next.

Thanks,
Mike
mterwilliger4@comcast.net

Standard (SBR) subroutines under A-Shell are "built-in", so you won't be able to compare them to the AMOS versions. (Even if they weren't built-in, they're written in C and would never match the hash of the old assembler SBR routines anyway.)

SBX subroutines are written in A-Shell/Basic and are loaded dynamically from disk as needed - so you can get a version and hash on them (but again it wouldn't do any good when comparing against AMOS implementations).

So, the issue appears to be that you had a particular implementation of GET.SBR under AMOS which does not seem to act the same as GET.SBR under A-Shell (or you're looking for one that does). Unfortunately, I don't think there was any particular standard for GET.SBR (it wasn't part of the AlphaACCOUNTING package, or included with AlphaBasic, as far as I know), so it is difficult to provide useful advice without more details.

With subroutines like GET, where the general concept is common enough that many people may have independently created different implementations under AMOS, the A-Shell version ends up combining the capabilities of several of the original AMOS versions (in order to accommodate different "standards"). This makes it easier for people to port from AMOS to A-Shell, but not so well the other way around.

My guess is that the typical GET.SBR under AMOS accepts only a single argument, and works something like ACCEPT.SBR, i.e., waits for a single character and then returns it. Variations would include whether the character was returned as a string, or as a floating point (like ACCEPT.SBR does), whether it was echoed to the screen, and whether you needed to use XCALL NOECHO first. (The symptom you describe is somewhat consistent with routines that require NOECHO to be called first.)

If you provide details about the exact syntax and features of GET that you're trying to use, perhaps I or someone out there can find or suggest an equivalent AMOS version.

Hi,
I've got one huge string with only one CRLF, at the end.
What I'm trying to do is to pull 80 characters, at a time, from this sequential file.
Basically, in pseudocode:
While not eof,
get 80 characters
print 80 characters with CRLF
Loop

Usage:
XCALL GET,INSTRING,1,80

Check out INPUT RAW in the consolidated reference. You can input into an X formatted variable using this. I can't find where I use it, so I'm not sure if you can input more than 1 byte at a time, but I think you can do the following and input 80 at a time:


map1 x80,x,80
map1 q$,s,100
open #1, "text.lst", input
i1:
input raw, x80
if (eof(1)) then
close #1
end
endif
q$ = x80
print q$
goto i1

I think that the eof() check needs to be

Otherwise, the last bit of the string may never be processed.

INPUT RAW is a good suggestion if you need AMOS compatibility, since I don't know of any specific AMOS GET.SBR that supports the semantics or the function you want. (In fact, it's likely that the GET.SBR you're using only does keyboard I/O, which is one reason why it doesn't do anything.)

We should note, however, that INPUT RAW was a BasicPlus addition. (IF/ENDIF and DO/LOOP were also only supported by BasicPlus under AMOS, but if you compiled the program under A-Shell with the /RC switch, the resulting RUN would be compatible with the regular old RUN.LIT under AMOS. But that isn't true for INPUT RAW, so you would definitely need RUNP, which means you would definitely need to recompile the source AMOS using COMPLP.)

And just to second Stephen's observation, the EOF is set when an input operation hits the end of file before satisfying the input (which in the case of INPUT LINE would mean hitting a line terminator, and in the case of INPUT RAW would mean inputting the requested number of raw bytes). So unless you can be sure your that the last line of your input file contains a proper line terminator (in the case of INPUT LINE), or is exactly the desired length (in the case of INPUT RAW), you should always check to see if you received any data from an INPUT statement, even if the EOF flag was set.

Here's another take on how you might code your loop:

The above code uses the trick of overlaying the same variable memory with a raw (X,80) and string (S,80) variable, so that we can access it in raw mode for the INPUT RAW, and as a null terminated string to test if we got anything and to print out just the bytes received. (This all assumes that there will be no embedded nulls in your input data; if otherwise, then you probably need to use some kind of XCALL to get the actual size of the file in bytes and use that to determine the exact number and size of INPUT RAW statements needed. Unfortunately, although there is an XCALL SIZE under A-Shell, I'm not sure what equivalent function exists under AMOS, if any.)

In contrast to all of this, I guess it turns out that A-Shell's implementation of GET.SBR is pretty handy.

I use GETBYT.SBR to accomplish what you are doing. I'm not sure if it's compatible with AMOS:

XCALL GETBYT, 200, INPUT'REC, 80

This will read 80 bytes from sequential file #200 into INPUT'REC mapped as:

MAP1 INPUT'REC,X,80

Test for EOF before doing each GETBYT if you are not sure when to expect End of File. Otherwise, you can just read everything into as large an area as you need, ignoring or discarding the final CRLF.

If your file has multiple records, don't forget to get each CRLF either as part of the data field (adding 2 bytes to account for it) or in a separate 2-byte GETBYT call.