d3 pick attempt to write into update protected file

Question

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

TonyG · Accepted Answer · 2014-07-16T19:28:04.313

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.

I have a file in the os called fileprinter, located in d3 as a q-pointer called chris_programscopy. I got rid of the q-pointer chris_programs, and then made an ordinary file called chris_programs. Then I did create-file dict chris_programs 3, and did copy md chris_programscopy (o (dict chris_programs. I am still getting the same error, any idea what I did wrong? — zelinka, Jun 18 '14 at 13:34
There's a lot going wrong there. Let's back up. Why are you trying to use the host OS for programs: If you keep it all in D3 hashed files then all of this goes away. Copy your source fileprinter code into a Data file item, then compile it. The object module gets created in the Dict. You can run from there. — TonyG, Jun 30 '14 at 22:08
I want to store the program in the host OS so I can use version control on it and edit it using a real text editor. Unfortunately the sysadmin won't put wED on the server, so the only practical way to edit files on a large scale is to put the program source in the host OS. — zelinka, Jul 10 '14 at 14:05
OK: "So now your source will be in the host file system and the object will be in D3." The answer provided solves the problem. You can operate on the data file in D3 like it's a hashed file even though the data is stored in the host OS - And you can edit it with any external tool too. I do exactly this, and the host folder is mapped to a subversion repo. — TonyG, Jul 11 '14 at 15:51
I am still having trouble making this work. Here are the steps I did from the beginning: 1) make a Q pointer as above called chris_programs 2) create-file dict chris_programsbin 3 3) :copy md CHRIS_PROGRAMS (o to :(DICT CHRIS_PROGRAMSBIN 4) :compile chris_programs fileprinter then I get the same error from the beginning. — zelinka, Jul 14 '14 at 12:13
In the scenario you've created above, you should have copied your CHRIS_PROGRAMS item to Dict CHRIS_PROGRAMSBIN CHRIS_PROGRAMSBIN. This renames the pointer so that dict and data are the same, even though the actual OS location of the data is named differently. Then you want "compile CHRIS_PROGRAMSBIN fileprinter" And you don't need the ":" before copy or compile. You'll also want to Run from CHRIS_PROGRAMSBIN and optionally catalog from there as well. — TonyG, Jul 14 '14 at 18:50
I got this now: :compile chris_programs fileprinter fileprinter . [235] attempt to write into update protected file! :compile chris_programsbin fileprinter [202] 'fileprinter' not on file. The : came from copying out of the environment I was working in. — zelinka, Jul 15 '14 at 14:45
I think it would be helpful to detail the steps one at a time because there is definitely something I am missing. Suppose there is a Q pointer called chris_programs, but nothing else is there (chris_programsbin has been deleted). What do I need to do to link the two of those? — zelinka, Jul 15 '14 at 14:46
I edited my response to take you through the steps from scratch, ignoring the steps you've already taken. This simple issue gets way too complicated when we confuse it with copying/editing an existing pointer and dealing with names like "chris_programs" and "chris_programsbin". I'm hoping the revised response will be accepted as an answer. Really, this should have only taken a couple minutes. (Grrr, I should have just posted another answer...) — TonyG, Jul 16 '14 at 19:31
Sorry it took so long for me to get back to this, had to do a whole bunch of non-d3 related things. I really appreciate the help! — zelinka, Jul 29 '14 at 16:37

d3 pick attempt to write into update protected file

1 Answers1