I tried to compile a simple program I wrote, but I am getting the following error:
:compile chris_programs fileprinter
fileprinter
.
[235] attempt to write into update protected file!
The chris_programs file is a Q pointer to the directory /u/chris_programs.
# pwd
/u/chris_programs
# ls -al
total 16
drwxrwxrwx 2 root system 256 Jun 16 06:58 .
drwxrwxrwx 15 root system 4096 Jun 13 17:40 ..
-rw-rw-rw- 1 root system 72 Jun 16 07:03 fileprinter
Here is the md entry for the chris_programs file:
DICT md 'chris_programs' size = 45
01 Q
02
03 /u/chris_programs
Glad to see you're getting comfortable with those super q-pointers. The issue here is that the object module goes into the Dict of the file hosting the BASIC source. But when you're using a host OS path without specifying a dictionary, it doesn't know where to put the object code. For this I would recommend the following:
create-file dict chris_programs 3
(Copy your md q-pointer to a different name first or you won't be able to use the same name.)
There will be a default q-pointer put into that dict file, which points any references to the data file back upon the dict (so dict and data are the same space). You can then copy the q-pointer you already have (renamed per above) into the dict to replace that item:
copy md renamed_pointer (o
to: (dict chris_programs
So now your source will be in the host file system and the object will be in D3.
There is a way to have both dict and data in the host OS but I don't recall the syntax at this time. I'll try to update this later with that if I get the info.
I recommend against a follow-up of "but I really want everything in the host OS!" The object code serves no purpose outside of the DBMS so you might as well keep it there. As to the source, well, I put some source at the OS level too for source control (integration with Subversion), to use with other editors, and to share with other MV DBMS's. Unless you're doing something like this, I'd advise you to keep all source and object in the DBMS. If you want a better editor, AccuTerm wED (Windows Editor) is a GUI with syntax highlighting and many other features. We can discuss that separately if that's your goal.
EDIT : The following is intended to provide a solution to the desired problem, outside the limitations of the faulty steps already taken.
Let's go back to fundamentals: Source code is in the data file, object goes in the dictionary. Here's how you link OS-level source to DBMS-level object.
create-file dict bp1 3
There will be a default q-pointer put into that dict file, which points any references to the data file back upon the dict (so dict and data are the same space). You can replace that reflexive pointer with a new one to the host OS. Use ED or whatever editing tool you prefer but the idea is:
ed dict bp1 bp1
The pointer item in the dict has the same name as the dict. Replace that item with the following:
01 q
02
03 /path/foldername
The line numbers are only for reference, don't type those in. Substitute the path as required. Your D3 user (as specified in the pick0 OS file) must have r/w access to that path.
So now you should be able to do something like this:
ED BP1 TEST1
01 CRT "SUCCESS"
COMPILE BP1 TEST1
RUN BP1 TEST1
You'll find TEST1 in /path/foldername. If you LIST DICT BP1, you'll see the BP1 pointer to the data file as well as an item for the object module for TEST1.
Rather than retrofitting what you have, please just follow this and you should be successful within a few minutes.
See note above about "but I really want everything in the host OS!"
Another approach to source control (not the same but close): Keep everything in the DBMS. Periodically t-dump your source to an OS-level backup file, or copy to a folder. Then source-control that OS data. This eliminates the direct connection between the OS and the programs, which most D3 people don't understand anyway.