D3 and mvBase

David Knight posted 04-19-2024 11:10

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 posted 04-19-2024 11:54

Hi

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

Stefano Gallotta posted 04-22-2024 06:14

I'm posting this as additional findings:

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

FSI:

Edit a small pgm in BPO called S2

:ed bp s2

top

.p

001 A = 'HELLO'

002 B = 'BYE'

003 DEBUG

004 CRT A

005 CRT B

eoi 005

.

Now compile it.

:compile bp s2

s2

.

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

:

Now run it:

:run bp s2

*I3

*/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:

*g HELLO

BYE

Whereas in the VME

:compile bp s1

s1

.

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

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

:run bp s1

*I3

*a  cmnd?

*/a hello=

*/b bye=

*l

0003 debug

*l1-20

0001 a='hello'

0002 b='bye'

0003 debug

0004 crt a

0005 crt b

*

Works as it should!

David Knight posted 04-22-2024 07:09

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.

Cheers,

David

Stefano Gallotta posted 04-22-2024 07:14

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.

Thanks

Stefano

David Knight posted 04-22-2024 07:21

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.

Chin-up!!

Cheers,

David

Brian Cram posted 04-22-2024 11:42

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

Bryan Buchanan posted 04-22-2024 16:59

Works fine on my system.

:COMPILE UTILS DEBUG.CHECK
DEBUG.CHECK
.
[241] Successful compile!   1 frame(s) used.
:RUN UTILS DEBUG.CHECK

*I3 
*/A HELLO=

*/B BYE=

*G HELLO
BYE
:CT MD UTILS
    UTILS
001 q
002 gst.base
003 utils

:CT GST.BASE,, UTILS
    UTILS
001 D
002 $(mds):$(MD)/utils/utils
003 3
004 
005 
006 
007 
008 
009 L
010 10

:WHICH CAD
                    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. . . . . . . 10.4.0.001; 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 posted 04-22-2024 17:06

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 posted 04-23-2024 04:16

@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

Stefano

Thanks all