I've been a user of Alpha Micro for 20 years and most of my software works up to 1.4b. I'm excited to see what the possibilities that A-shell will have and it's backward compatibility. I just downloaded the windows version, but I didn't see how to pay for it or if it offers a guarantee of backward compatibility. I'm going to install in now...wish me luck! Stephen

[ 28 October 2001: Message edited by: Jack McGregor ]

Welcome Stephen. I think you will find that A-Shell has pretty good backwards compatibility to AMOS 1.4 and earlier. If you use OCMPIL, you can be pretty much guaranteed of 100% hash compatibility with the RUN files. With the new COMPIL, things get a bit trickier, since there were actually several sub-versions of COMPIL.LIT/RUN.LIT which had minor hash variations. Refer to the User's Guide section on COMPIL for information about the various switches that affect the level of compatibility or features implemented. Another common compatibility issue relates to whether you are using LOKSER. A-Shell works either way, but you must set the LOKSER parameter in the MIAME.INI accordingly. (Programs not designed to work with LOKSER on will get all sorts of errors if you run them with LOKSER=ON under A-Shell, just as they would under AMOS.)

As for paying for it, just contact us directly via email (admin@microsabio.com) or by phone (818-710-8437) to arrange the details. In the meantime, feel free to use the eval version. And please feel free to post questions on the message board.

Hi Jack,

Actually, I do have a problem. I'm using Kermit to transfer the information over, and the run's give me the error: ?run file is an incompatible format. Do you know of a transfer program that will keep the run's, and transfer dat files? About 50% of my programs, I don't have the source for. If I can make the transition, it will be one heck of a lifesaver
Stephen

I thought that Kermit was capable of binary file transfers, but perhaps it depends on the version, switches, etc. Step one would be to see if the hash of the file is being changed by the transfer. (DIR/H works the same on both A-Shell and AMOS.) If not, then obviously you need to fix the file transfer. One alternative you could try is ZTERM, which certainly will do binary file transfers. Follow the link on our website to the ZTERM download page and get ZTERM 2000. It runs in eval mode for a couple of weeks which should give you time to test it.

If the hash is not changing, and you are still getting "incompatible run format", then your RUN files must be in some format not presently recognized by A-Shell. This could be because they are extremely old (prior to what is not the OCMPIL RUN format) or because they were compiled with some non-Alpha compiler, such as d/Soft's. In the latter case, you are in trouble, because A-Shell will not ever recognize the d/Run binary format (although it will recognize many of the d/Basic source extensions.) In the former case (very old RUN files), it may just be a matter of us having to enhance our RUN to recognize a different header signature. (By the way, what kind of versions do you get with DIR/V on these RUN files? If they are all kinds of weird garbage, then it probably means that these RUN's pre-date the introduction of the standard version headers for RUN, SBR, and LIT files (which I think means they came from the old AMOS-WD16 days.)

If you're not sure, you can email an example to support@microsabio.com and we can take a look at it.

However, I must warn you that when porting without source code, it is difficult to guarantee success. Certainly if the source code you have is representative of the programs for which you don't have source code, then your chances improve. But it is not unusual to have to review the source code to figure out why a program isn't working as expected. Often this is because of a programming error or inadvertant reliance on an undocumented feature or bug which is difficult or non-sensical to try to emulate.

The other problem you may run into is use of novel XCALLs. Fortunately, A-Shell will report their names, and even give you information about the number and types of parameters. And A-Shell does include hundreds of XCALLs, including all the most common ones. But if you didn't write the program and don't recognize the XCALL, that could be difficult to deal with.

If it comes down to absolutely needing source code, you may be able to obtain a decompiler. We do not have one, but I (vaguely) recall that one or more were marketed in AMUS over the years. You might contact Jeff Kreider at AMUS to see if he can point you in the right direction on that.

Non-amos versions of Kermit default to files being of type "TEXT", which means you need to set the file type to binary on the DOS/Windows side before you start those Kermit file transfers. Otherwise, Kermit is creatively adding line ending characters in the middle of your file!

For most Kermits, the command would be "set file type binary". Alpha Kermit and Autolog's built in Kermit commands default to sending binary type files.

Jack McGregor:


I installed Zterm 2000, but I was thinking my problem is on the Alpha side.

Currently to connect my Alpha to my IBM, I used Kermit on the Alpha side and ProCom Plus on the IBM side, through the serial port.

If I'm using Zterm 2000 could I just use the AM-62 terminal driver on the Alpha side? Or do I need a program on the Alpha side, and if so what program?

Bob Rubendunst :

Thanks for your advice, I will check that out also. Is Alpha Kermit, that which runs on Amos. Because, I do have IBM Kermit too, but I like ProCom Plus better for Dos. On the Alpha side, I run Kermit then set block 1 and it would only transfer text. I didn't know of the set file type binary command.


I'm slow at this, but determined

Thanks, Stephen

As far as terminal emulation goes, ZTERM 2000 will emulate am62a (or wyse50, am62c, am65, etc.) so you can just use the standard or appropriate terminal driver (e.g. am62a.tdv) on the Alpha side. But for file transfer, if the connection is serial, you'll need one other module that handles the Alpha side of the transfer. In ZTERM's case, the module is ZTXFER.LIT. It's installed on the PC side when you install ZTERM 2000, and you'll need to move it to the Alpha before you can do serial transfers. One way to do that would be with another file transfer program like Kermit. Or, you can use the Configuration..Serial Transfer dialog with ZTERM 2000 itself to upload it to (slowly) to the Alpha.

Using Kermit or Zterm 2000 the runs still have the error.

I only have two types of runs that get the ?run file is incompatible format.
Examples:
Vlist was from Alpha Accounting package by Alpha Micro
Sysman was from program generator called DANIEL FAUST - SYSTEMS RESEARCH
So far everything I programmed will run ok.
If you need the actual files or the source, I'll send them, but I thought this would be easier.
dump of file: vlist.run

Record 0001
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0000 01 f0 00 00 2c 03 00 00 02 00 00 00 46 01 00 00 ....,.......F...
0010 2c 01 10 0a 05 21 80 53 3c 31 38 2c 56 4c 49 53 ,....!.S<18,VLIS
0020 54 00 20 10 28 05 21 80 62 3d 41 00 20 10 3c 05 T. .(.!.b=A. .<.
0030 21 80 6c 3d 43 e6 20 10 46 05 21 80 71 3d 42 f8 !.l=C. .F.!.q=B.
0040 20 10 50 05 21 80 76 3d 43 58 20 10 64 05 2a 3d .P.!.v=CX .d.*=
0050 40 80 20 10 6e 05 09 3d 00 00 20 0a 3d 40 80 06 @. .n..=.. .=@..
0060 3d 40 80 20 0a 3d 40 80 06 3d 42 20 20 0e 3c 41 =@. .=@..=B .0070 4c 50 48 41 42 45 54 49 43 41 4c 20 56 45 4e 44 LPHABETICAL VEND

Record 0002
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0080 4f 52 20 4c 49 53 54 49 4e 47 00 20 10 02 10 78 OR LISTING. ...x
0090 05 1f f1 8f 00 7d 22 77 02 3d 41 80 20 80 67 00 .....}"w.=A. .g.
00a0 10 82 05 09 3d 00 00 20 0a 3d 40 80 06 3d 40 80 ....=.. .=@..=@.
00b0 20 0e 3d 42 20 36 20 0e 3c 42 55 49 4c 44 20 49 .=B 6 .00c0 4e 44 45 58 00 20 10 02 10 8c 05 1b 04 3d 43 c6 NDEX. .......=C.
00d0 20 3c 41 50 53 59 53 2e 44 41 54 00 20 80 76 20 00e0 80 7b 10 96 05 21 80 7b 3d 40 80 20 10 a0 05 12 .{...!.{=@. ....
00f0 3d 43 c6 20 80 33 00 10 aa 05 1c 3d 43 c6 20 10 =C. .3.....=C. .


dump of file: sysman.run

Record 0001
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0000 01 f0 00 00 ca 26 00 00 02 00 00 00 1a 06 00 00 .....&..........
0010 aa 0d 21 81 2a 3c 53 59 53 4d 41 4e 2e 44 41 54 ..!.*0020 00 20 21 81 2f 3c 53 59 53 4d 41 4e 2e 44 41 54 . !./0030 00 20 21 81 39 3d 43 60 20 1f 5b 4d c0 44 22 77 . !.9=C` .[M.D"w
0040 81 56 00 24 81 56 3d 40 80 22 20 3e 00 01 9c 00 .V.$.V=@." >....
0050 09 3d 00 00 20 0a 3d 40 80 06 3d 00 00 20 0a 3d .=.. .=@..=.. .=
0060 42 20 3d 40 80 20 0e 3d 41 e0 36 20 0e 3c 4c 6f B =@. .=A.6 .0070 63 6b 20 62 6f 61 72 64 20 6e 6f 74 20 69 6e 73 ck board not ins

Record 0002
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0080 74 61 6c 6c 65 64 20 69 6e 20 73 79 73 74 65 6d talled in system
0090 2c 20 63 61 6e 6e 6f 74 20 65 78 65 63 75 74 65 , cannot execute
00a0 20 70 72 6f 67 72 61 6d 2e 00 20 10 02 13 21 81 program.. ...!.
00b0 4a 3d 40 80 20 3c 30 34 31 39 33 30 30 41 45 00 J=@. <0419300AE.
00c0 20 21 81 4a 3d 42 e0 20 3c 31 36 32 33 30 36 30 !.J=B. <1623060
00d0 41 45 00 20 21 81 4a 3d 41 00 20 3c 30 35 31 39 AE. !.J=A. <0519
00e0 32 35 30 41 45 00 20 21 81 4a 3d 42 e8 20 3c 31 250AE. !.J=B. <1
00f0 37 32 33 30 36 30 41 45 00 20 21 81 4a 3d 41 40 723060AE. !.J=A@
#2
To create a dsk1 .2.3... would I edit the /vm/miame/miame.ini file with
DEVICE=DSK1 /vm/miame/dsk1/
DEVICE=DSK2 /vm/miame/dsk2/
DEVICE=DSK3 /vm/miame/dsk3/

Tried to create dsk1: so I did a sysact dsk1:
and got ?cannot init dsk1: device does not exist
so I created a directory dsk1\40000
and in logging to dsk1:[40,0] I got ?nonexistant device.


#3 is there an ini file to emulate a AM62a terminal?


Thanks for your help, I am getting closer to having the bugs worked out.

Stephen

[ 16 November 2001: Message edited by: Stephen Wadsworth ]

The first 2 bytes (01 f0) of these dumps indicate they were compiled under a version of COMPIL prior to 1.3. (The 1.3 OCMPIL signature is 02 f0, and is usually preceded by 10 bytes of version information.) I'm not sure how much difference there is the rest of the format, but just to see, I've added support to 4.6(787)-3 to treat that version the same as OCMPIL and will email the ashw32.exe for you to test it with. If it works, great. If not, I can probably find you a copy of the source to the standard vlist.bas from AlphaAccounting, but as for the other program, you may need to find a decompiler or contact the developer or just forget about it (or rewrite it.)

As for your questions #2 and #3, at the risk of being difficult, could you please repost them as separate topics? (One of the goals of this BBS is to make it possible for people to help themselves by searching or browsing to see if someone else has already asked the same question, but that becomes very difficult when a post has multiple topics and especially when new topics are introduced several messages down in a thread.)

Good News.

The Alpha Accounting seems to be working of what I tested.

The DANIEL FAUST - SYSTEMS RESEARCH software seems to give an error message:
Lock board not installed in system, cannot execute program.

Stephen

I could understand that if the programs stayed on the original Alpha Micro, but the software has been on 4 other Alpha's, with out any problems and didn't have any chip associated with the package. Was The DANIEL FAUST - SYSTEMS RESEARCH that big of a package that everyone had a chip put in to lock it's use?

Unfortunately I am not familiar with the software from Dan Faust/Systems Research, so I can't say for sure. I was just guessing from the message "Lock board not installed in system" and from the fact that it was not uncommon for application developers in the AMOS world to either directly or indirectly use the SSD or other locking device, that the software is looking for such a device.

The term "lock board" made me think of the OmniLock board, which Dravac, aka d/Soft used in early releases of the Andi database product, which perhaps is used by the program in question. This might explain why the program was running on multiple machines, since perhaps all of those machines had a licensed copy of the database software.

But this is just speculation on my part. Is in not possible to contact Dan Faust to find out for sure? (As an aside, if you purchased the program from him, and it was locked to some "lock board", then it may be a violation of your license agreement to replicate it on multiple machines, whether or not it actually works. You might want to consult whatever agreements you may have or else an attorney.) As a purely technical matter, short of rewriting the program, you would probably need to locate a decompiler to be able to workaround the reference to the obsolete device. I suggest contacting the AMUS user's group or Alpha Micro to see if they know of any decompilers available for sale.

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

I moved your latest post above to a new topic "XCALL Subroutines - Locating Errors", since it seems to be the start of a new thread rather than a continuation of the previous one. - Jack