D3 and mvBase

 View Only

 Linux D3 10.4 "no source"

Stefano Gallotta's profile image
PARTNER Stefano Gallotta posted 04-19-2024 10:49

Hi all

I have a particularly disturbing situation that's just come about.
I have BASIC code (source) which I compile in which I purposely place a DEBUG statement.
Whereas before the DEBUGGER would provide me with the source code lines - I now am presented with the response:

no source

and sometimes get :

* remote file system error

Remote file has been moved or deleted

The D3 account is in the FSI portion and the code is simply:

1< >debug

<2 >crt 'hello'

Any ideas (please)?

p.s. Yes I bounced the D3 machine and the Linux machine and redid and got the same results.

David Knight's profile image
PARTNER David Knight

Hi Stefano,

Yes, that does sound worrisome. Perhaps the following MAY shed some light upon matters.

With d3 Linux 10.4 Rocket has essentially 'ported' d3/win v10.4 but specifically has introduced the idea of a vme [Virtual Machine Environment] and the FSI [File System Interface, which is the filesystem of the native host; in this case Linux's filesystem].

In this respect, my understanding is d3Linux v10.4 is entirely "new"; and so it is not surprising to hear there may be some gremlins.

When you operate a VME/FSI type system you are 'talking' to the VME which itself then 'talks' to the FSI element; which handles the actual file i/o.

So, what I am guessing you are seeing here is a breakdown of communication or some such between the two; hence the occasional 'remote filesystem error'. Because the fsi is 'remote' to the vme and stuff is going wrong.

It may also explain why the debugger cannot see the 'source' as that would be in the fsi.

Apart from this, is the overall system functional? Can you see the source at TCL? Can you even logon to an account held in the fsi? What about accounts held in the vme? Maybe this is just an issue with the debugger?

On a d3/win system it is possible to reload/reinstall the vme components only if it gets corrupted; maybe that is what is going on here? Maybe you should try a vme only restore?

I think you should take this up with Rocket via your support channels.

Sorry if that is not more helpful.

Here at H3O we decided to steer a little clear of d3/Linuxv10.4 because of these issues, waiting for the tech to settle down. I am sure it shall; and there are some great advantages to the vme/fsi model so hang in there!

Best wishes,

David Knight

Stefano Gallotta's profile image
PARTNER Stefano Gallotta


Thanks @David Knight

let me share some more weirdness.

TCL "sees' the code - the editor "sees" the code - the code runs "quite normally" EXCEPT when the debug editor (is called) and one wants to view the lines (l 1-20 or whatever)
especially after an E1 command is given (in debug).

I've even deleted the (my) program file entirely and re-created etc.

I've checked that the compile verb is updated (using the update-accounts)

The ONLY this I can think of is the fact that we have the FSI on a MOUNT volume (?)

I bounced Linux and checked that the mounts were there - saw the directories etc - and even used root (su) to launch D3Svr and a D3Tcl session because "perhaps" there were permission problems.

The fact that it's happened all of a sudden is disturbing. I was working on the same code all morning into the debugger etc - all working as it should.

Argrrr - I've always maintained that the worst thing they EVER did was give a CLOCK to the computers. They know EXACTLY when it is 5:00 PM on a Friday :(


Stefano Gallotta's profile image
PARTNER Stefano Gallotta

I'm posting this as additional findings:

Please someone advise me where I'm going wrong. [I'm NOT using Flash compile]


Edit a small pgm in BPO called S2

:ed bp s2



001 A = 'HELLO'

002 B = 'BYE'


004 CRT A

005 CRT B

eoi 005


Now compile it.

:compile bp s2



[241] Successful compile!   1 frame(s) used.


Now run it:

:run bp s2


*/a HELLO=

*/b BYE=

*l *** Remote File System Error ***

Read (s2) Remote File Has Been Moved or Deleted

O=Logoff / Q=Quit / R=Retry / C=Continue ?

User (my) input

O=Logoff / Q=Quit / R=Retry / C=Continue ? r

*** Remote File System Error ***

Read (s2) Remote File Has Been Moved or Deleted

O=Logoff / Q=Quit / R=Retry / C=Continue ? c

no source


It does in fact run when the ‘G’ option is used:



Whereas in the VME

:compile bp s1



[241] Successful compile!   1 frame(s) used.

[241] Successful compile!   1 frame(s) used.

:run bp s1


*a  cmnd?

*/a hello=

*/b bye=


0003 debug


0001 a='hello'

0002 b='bye'

0003 debug

0004 crt a

0005 crt b


Works as it should!

David Knight's profile image
PARTNER David Knight

Hi Stefano,

Good investigation/example.

Your addition detail/example merely proves what I referred to:

This is an issue [bug?] with the VME to FSI environment in respect of the debugger; and need to be reported to Rocket as a bug requiring urgent correction.

The ability to debug is a crucial aspect of any d3 system; and it clearly cannot cope!

What direct avenues do you have to raise this bug? Do you have an account with RBC's support side of things? If so, raise a ticket. If not, that means you must work through a VAR or some other 'layer' between you and Rocket; so report it to them.

No point in frustrating yourself further.



Stefano Gallotta's profile image
PARTNER Stefano Gallotta

Thanks once again @David Knight - for "somewhat" confirming my worst fear :(

I am dealing wit the distributor here in South Africa - which hopefully will report it to the correct channels.

If not then I have an alternative.



David Knight's profile image
PARTNER David Knight

Hi Stefano,

Let's look at the positives.

You've looked at and found a clear, yet reproduceable issue. In my experience Rocket themselves will be quiet willing and able to assist and get the issue resolved.

I have no comment to make on the SA distributor and their ability; as I do not know them.

That said, I know people like @Brian Cram monitor these threads and will assist if he is able. By which I mean the machinations/politics of going via your distributor. I have no idea what problems that may pose; but hope your distributor reads these boards; or that Rocket staff will read, appreciate the issue and take some time to provie it for themselves on their test systems. Which if they do, and confirm will result in a patch in a short period of time.

Rocket are good like that.




Brian Cram's profile image

Looks like a case got opened in Support for this. Will chase it there.

Bryan Buchanan's profile image
PARTNER Bryan Buchanan

Works fine on my system.

[241] Successful compile!   1 frame(s) used.


*/B BYE=

001 q
002 gst.base
003 utils

001 D
002 $(mds):$(MD)/utils/utils
003 3
009 L
010 10

                    System Release Information
     D3 Release Version  10.4.0.LINUX  rev 02/08/23

     Implementation. . . . . . LX64
     Software Serial Number. . 11031402
     System ID Number  . . . . 22482691
     Release . . . . . . . . . D3/UNIX: LINUX
     Unix Information. . . . . Linux;pick0:MultiThread;5.14.0-362.24.2.el9_3.x86_64;#1 SMP PREEMPT_DYNAMIC Sat Mar 30 14:11:54 EDT 2024;

     Boot Monitor. . . . . . .; 02 Aug 2023
     Boot ABS. . . . . . . . . 10.4.0.A0; 02 Aug 2023
     Boot ABS Data File. . . . 10.4.0.A0; 02 Aug 2023
     System Data Files . . . . 10.4.0.D0; 02 Aug 2023
     FlashBASIC Revision . . . 10.4.0.F1; 02 Aug 2023
     SQL Revision. . . . . . . 10.4.0.S1; 02 Aug 2023

     Current ABS . . . . . . . 10.4.0.A0; 02 Aug 2023
     Current ABS Data File . . ; 
     ABS Patch Level . . . . . no patches loaded
Brian Cram's profile image

When in the BASIC debugger and getting a "no source" prompt, do this:

Z BPfilename BPprogramname

This will load the source for you.

Stefano Gallotta's profile image
PARTNER Stefano Gallotta

@Brian Cram - that worked :) Thanks so much :

@Bryan Buchanan - respectfully i don't believe you read my entire example.

Yes, the contents of the variables were returned (as they should) HOWEVER when the "problem" was when issuing the L command which lists the source code. That was when the debugger went "pear-shaped".

@Brian Cram solved this by suggesting the Z command to provide the file and item name - which successfully returned the lines of source code.

And now to solve the steal-file verb 



Thanks all