Convert normal pi-folder to rsx11 disk or tape

[stephan küppers]

Hello!

I have a normal pi-folder with different files (source , objects etc.) witch i will read into my pidp-11/rsx11 as disk or tape. Are there any tool to do that or toconvert it to disk- or tape-images?

Stephan

[Johnny Billquist]

ftp?

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/6e0d81fe-2031-49d7-98ae-b23f5ce0d168n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/6e0d81fe-2031-49d7-98ae-b23f5ce0d168n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Johnny Billquist]

The process, although maybe a bit clunky, certainly works. The problem
is that there are no good ways to create a tape image that is usable
under RSX in general. So that process is mostly just usable for Unix to
Unix.

But to make some general comments. For unix, I would also just use ftp.
I don't see the point or value in going via tape or disk images. It's
just extra steps that don't add any value. But if you already have the
steps down and memorized, you might as well continue using them just as
well as you change anything.

But RSX have this extra complication about binary files that there is
various metadata attached to the file under RSX, which is not preserved
when passign by a Unix system. So binary files can be pretty tricky to
get across and still be the correct format, whatever that might be.
Text files are a bit easier, since that is at least a defined format
that is somewhat easy to understand. But it's still not a case that they
will appear the same as a text file under Unix. Which is why I really
suggest using ftp, and just transfer text files. Because that will get
across and be correct on both sides, since ftp will do the translations
for you.

If people really insist on using tape or disk images, then I would
suggest RT-11 file systems for disks, and DOS-11 format for tapes. Both
can be read by pretty much all DEC OSes, and there are tools under Unix
to deal with these formats. However, you will probably still get into
trouble with binary files to RSX.

Johnny

On 2024-06-11 14:13, Neil Webber wrote:
> I wrote this python program that will read/write simh tape files; I use
> this as part of a clunky solution to your question.
>
> I don't know RSX; for Unix to get files onto my PiDP I make a tar
> archive of them, lets say "foo.tar" ... then I do this:
>
>          bytes2simh --in foo.tar --out xfer.tap
>
> This makes a tape image file (xfer.tap) that contains (raw) foo.tar
>
> I put this into my boot.ini:
> att tm0 xfer.tap
>
>
> and I boot up unix. At that point I can dd off the tape device and then
> use unix tar to extract the files.
>
> Did I mention this was clunky? But it works. There's probably a better
> way but here's my bytes2simh python program anyway. Note that if you
> save this as "bytes2simh" it will do the conversion as described above
> by default. If you save it as "simh2bytes" it will go the other way.
> There is also a --direction argument to explicitly choose.
>
> I would imagine there are analogs of tar for the RSX side, though then
> your problem simply changes to "how do I make such a file on the Linux
> side". I can't help you (because: no RSX knowledge) with that part.
>
>                    -neil

>
>
>
> On Tue, Jun 11, 2024 at 4:38 AM Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
> ftp?
>
>    Johnny
>
> On 2024-06-11 08:40, stephan küppers wrote:
> > Hello!
> > I have a normal pi-folder with different files (source , objects
> etc.)
> > witch i will read into my pidp-11/rsx11 as disk or tape. Are
> there any
> > tool to do that or toconvert it to disk- or tape-images?
> > Stephan
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "[PiDP-11]" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11%2Bunsu...@googlegroups.com>
> > <mailto:pidp-11+u...@googlegroups.com
> <mailto:pidp-11%2Bunsu...@googlegroups.com>>.

> > To view this discussion on the web visit
> >

> https://groups.google.com/d/msgid/pidp-11/6e0d81fe-2031-49d7-98ae-b23f5ce0d168n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/6e0d81fe-2031-49d7-98ae-b23f5ce0d168n%40googlegroups.com> <https://groups.google.com/d/msgid/pidp-11/6e0d81fe-2031-49d7-98ae-b23f5ce0d168n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pidp-11/6e0d81fe-2031-49d7-98ae-b23f5ce0d168n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip

> email: b...@softjar.se <mailto:b...@softjar.se>             ||

> Reading murder books
> pdp is alive!                    ||  tryin' to stay hip" - B. Idol
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/313e0c11-3bc7-4291-86dc-8c61987fed52%40softjar.se <https://groups.google.com/d/msgid/pidp-11/313e0c11-3bc7-4291-86dc-8c61987fed52%40softjar.se>.

[Neil Webber]

I wrote this python program that will read/write simh tape files; I use this as part of a clunky solution to your question.

I don't know RSX; for Unix to get files onto my PiDP I make a tar archive of them, lets say "foo.tar" ... then I do this:

         bytes2simh --in foo.tar --out xfer.tap

This makes a tape image file (xfer.tap) that contains (raw) foo.tar

I put this into my boot.ini:

      att tm0 xfer.tap

and I boot up unix. At that point I can dd off the tape device and then use unix tar to extract the files.

Did I mention this was clunky? But it works. There's probably a better way but here's my bytes2simh python program anyway. Note that if you save this as "bytes2simh" it will do the conversion as described above by default. If you save it as "simh2bytes" it will go the other way. There is also a --direction argument to explicitly choose.

I would imagine there are analogs of tar for the RSX side, though then your problem simply changes to "how do I make such a file on the Linux side". I can't help you (because: no RSX knowledge) with that part.

                   - neil

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/313e0c11-3bc7-4291-86dc-8c61987fed52%40softjar.se.

[Anton Lavrentiev]

>           bytes2simh --in foo.tar --out xfer.tap

Newer open-simh can convert a list of files to a tape image, like that:

sim> attach TM -F DOS11 *.LDA,FILE1.TXT,FILE2.TXT,*.C

Under OS, the TM device (MT in RSX) would look like a DOS-formatted tape (so one can use FLX to extract

the files).  Alternatives to the DOS11 switch value are ANSI-RSX11, ANSI-VMS or ANSI-RT11, any of which

can be used to read the tape directly by PIP, if in RSX (but for binary files, it can be challenging)...

For UNIX, -F TAR creates a TAR-formatted tape from the list of files on the fly.

The same works for any tape drive (TQ = DU in RSX, TS = MS in RSX etc).

While this feature does not seem to be supported by the version of simh included with PiDP11 simulator (client11),

it can be used to prep a disk image offline (in a separate instance, with newer simh), then to attach it to PiDP11,

and copy files over, from disk to disk.

HTH

P.S. Help from SIMH:

Attach command switches

    -R          Attach Read Only.

    -E          Must Exist (if not specified, the default behavior is to

                attempt to create the indicated virtual tape file).

    -N          Create a new empty tape container file.

    -Q          Suppress informative messages during attach activities.

    -F          Open the indicated tape container in a specific format

                (default is SIMH, alternatives are E11, TPC, P7B, AWS, TAR,

                ANSI-VMS, ANSI-RT11, ANSI-RSX11, ANSI-RSTS, ANSI-VAR, FIXED,

                DOS11)

    -B          For TAR format tapes, the record size for data read from the

                specified file.  This record size will be used for all but

                possibly the last record which will be what remains unread.

                The default TAR record size is 10240.  For FIXED format tapes

                -B specifies the record size for binary data or the maximum

                record size for text data

    -V          Display some summary information about the record structure

                observed in the tape image observed during the attach

                validation pass

    -L          Display detailed record size counts observed during attach

                validation pass

    -D          Causes the internal tape structure information to be displayed

                while the tape image is scanned.

    -C          Causes FIXED format tape data sets derived from text files to

                be converted from ASCII to EBCDIC.

    -X          Extract a copy of the attached tape and convert it to a SIMH

                format tape image.

Notes:  ANSI-VMS, ANSI-RT11, ANSI-RSTS, ANSI-RSX11, ANSI-VAR formats allows

        one or several files to be presented to as a read only ANSI Level 3

        labeled tape with file labels that make each individual file

        accessible directly as files on the tape.

        FIXED format will present the contents of a file (text or binary) as

        fixed sized records/blocks with ascii text data optionally converted

        to EBCDIC.

        DOS11 format will present the contents of a file preceeded by a DOS11

        14-byte header. All files will be owned by [1,1], have a default

        protection of <233> and a date in the range 1972 - 1999 with the

        month/day layout as the current year. The file name on the tape

        will be sanitized to contain only alphanumeric characters from the

        original source file name. Characters 7 - 9 of the file name will be

        placed in an otherwise unused word in the header which some DEC

        operating systems will be able to process. If the resulting

        filename is NULL, a filename in the range 000000 - 999999 will be

        generated based of the file position on the tape.

Examples:

  sim> ATTACH TM -F ANSI-VMS Hobbyist-USE-ONLY-VA.TXT

  sim> ATTACH TM -F ANSI-RSX11 *.TXT,*.ini,*.exe

  sim> ATTACH TM -FX ANSI-RSTS RSTS.tap *.TXT,*.SAV

  sim> ATTACH TM -F ANSI-RT11 *.TXT,*.TSK

  sim> ATTACH TM -FB FIXED 80 SOMEFILE.TXT

  sim> ATTACH TM -F DOS11 *.LDA,*.TXT

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/e961f21a-c537-4285-8293-825f91f36572%40softjar.se.

[Neil Webber]

Different strokes ... I kind of like my process (because of course I do :)) because I can keep a bunch of .tap files around, kind of like having a physical shelf full of actual magtape.

The new SIMH features are very cool!

                   - neil

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/e961f21a-c537-4285-8293-825f91f36572%40softjar.se.

[Michael Harpe]

As I always say, it has the saving grace of working! Nice little hack.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/CACMVouResBNPEMr7j90wtnS0pQYMtZBrOdY%2BLS5NdmKpaye2pA%40mail.gmail.com.

[Jonathan Harston]

I use putr to programatically create RT11 disk images.
putr < scriptfile with scriptfile containing a list of commands
A quick skim through the documentation says it does RSX11
disk images.

jgh

[Johnny Billquist]

PUTR supposedly can read Files-11, but not write.

But it don't really matter. Just write an RT11 format disk, and you can
read that in RSX. But for binary files that still leaves you with some
information missing. Basically no program can solve this, as the
information was most likely lost when the file was transferred out of
RSX already.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/8f760367-6754-48bd-a727-cf33950db206n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/8f760367-6754-48bd-a727-cf33950db206n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jonathan Harston]

I've been reading the File-11 Wikipedia article and the linked DEC documentaion.
What metadata is stored in the directory and not the file that is needed for the
contents of a file to still be usable?

(Eg on Acorn systems there's a load address and execution address in the
directory, without which you don't know how to execute a header-less binary
file. is it something like that?)

[Anton Lavrentiev]

Metadata is stored in the file header (a file header is about the same purpose as an i-node in a unix file system), which itself is stored in the index file -- the main file of the entire volume, [0,0]INDEXF.SYS.

Directories merely keep pointers to the file headers.

When you read from a file, e.g. for the contents, you don't see the metadata.  So once the contents alone was taken out of the volume, the metadata, which are record attributes of the file, basically, is lost.

It can be re-created, though, but for that you need to know what it was when the file existed natively on an RSX volume.  Otherwise, the file is just an unstructured heap of bits.  Which is okay if that's a text file,

but may be problematic if the file had a more complex structure.

HTH

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/09b98221-4d86-4b11-9ef1-6c5aebe2ea97n%40googlegroups.com.

[Anton Lavrentiev]

Here's an example how to see a file header:

$ dump helloseq.txt/head/blo:0

Dump of DU0:[USER]HELLOSEQ.TXT;1 - File ID 4616,13,0

                                         File header

HEADER AREA

        H.IDOF          027

        H.MPOF          056

        H.FNUM,

        H.FSEQ          (4616,13)

        H.FLEV          401

        H.FOWN          [200,001]

        H.FPRO          [RWED,RWED,RWED,R]

        H.UCHA          000 =

        H.SCHA          000 =

        H.UFAT          (File Control Services, FCS)

                F.RTYP  003 = F.SEQ!R.PRN

                F.RATT  002 =   FD.CR

                F.RSIZ  120 = 80.

                F.HIBK  H:0 L:000003 = 3.

                F.EFBK  H:0 L:000003 = 3.

                F.FFBY  136 = 94.

                (REST)

                000000 000000 000000 000000 000000 000000 000000 000000

                000000

IDENTIFICATION AREA

        I.FNAM,

        I.FTYP,

        I.FVER          SEQ.TMP;1

        I.RVNO          1

        I.RVDT          18-MAY-2024

        I.RVTI          11:15:46

        I.CRDT          18-MAY-2024

        I.CRTI          11:15:46

        I.EXDT          --

MAP AREA

        M.ESQN          000

        M.ERVN          000

        M.EFNU,

        M.EFSQ          (0,0)

        M.CTSZ          001

        M.LBSZ          003

        M.USE           002 = 2.

        M.MAX           314 = 204.

        M.RTRV

        SIZE    LBN

        3.      H:004 L:104040 = 296992.

CHECKSUM

        H.CKSM          160065

So, "helloseq.txt" is my "special" file.  It's a segmented record file that was created by a fortran application.

Under the H.UFAT (File control Services) section you can see the attributes.

This information is not stored in the file itself, though.

The metadata tells FCS how to actually read the file, as the F.SEQ and R.PRN bits have a special meaning as to

how the records are organized within the file.

FD.CR is also important as it tells FCS how records are structured for printing, for example.

FFBY gives you the EOF (so whatever is beyond that point is meaningless, and is not the contents, which was

stored in file -- remember, RSX stores file in blocks, 512 bytes each, so naturally, many files do not end

on the block boundary).  Luckily, most of the time the unused portion of the file is all 0 bytes so can be

easily distinguished, but it may not always be guaranteed.

HTH

[Johnny Billquist]

Good reply, Anton. I'll just add a few more bits.

On 2024-06-14 22:39, Anton Lavrentiev wrote:
> Metadata is stored in the file header (a file header is about the same
> purpose as an i-node in a unix file system), which itself is stored in
> the index file -- the main file of the entire volume, [0,0]INDEXF.SYS.

Yes, file ids are basically the same idea as inode numbers. And if you
have the file id, you can find the file by looking at the appropriate
block in INDEXF.SYS. Basically, each file header takes one block, so
it's simple to figure out which block to read to get the file header for
a specific file id. (Basically file id 1 is at block N, file id 2 is at
block N+1, and so on...)

And INDEXF.SYS is the one file that can be found without knowing
anything about how the blocks are allocated on the disk.

Also, there are five files that are "known" in the sense that they have
defined file ids that are guaranteed to be for that specific file.

INDEXF.SYS is file id (1,1)
BITMAP.SYS is file id (2,2)
BADBLK.SYS is file id (3,3)
000000.DIR is file id (4,4)
CORIMG.SYS is file is (5,5)

> Directories merely keep pointers to the file headers.

Right. Directories are really simple. You have the file id (3 words),
and the file name (5 words) for a total of 8 words for each directory entry.

And in order to find a file you basically starts with file id (4,4),
which is the master directory, and then you search for the next
directory in there, and repeat until you've gone through the whole file
specification. (And yes, RSX normally only have a 2 level directory
structure, but Files-11 impose no such limit. I've patched RSX to allow
several levels of subdirectories...)

> When you read from a file, e.g. for the contents, you don't see the
> metadata.  So once the contents alone was taken out of the volume,the
> metadata, which are record attributes of the file, basically, is lost.

Yes. There are special I/O functions to read the meta data.

> It can be re-created, though, but for that you need to know what it was
> when the file existed natively on an RSX volume.  Otherwise, the file is
> just an unstructured heap of bits.  Which is okay if that's a textfile,
> but may be problematic if the file had a more complex structure.

It can sometimes be recreated through heuristics, but it's not always
easy, or sometimes even possible. Text files are usually simple. Most
other things maybe not.

Johnny

>
> HTH
>
> On Fri, Jun 14, 2024, 4:31 PM Jonathan Harston <j...@mdfs.net
> <mailto:j...@mdfs.net>> wrote:
>
> I've been reading the File-11 Wikipedia article and the linked DEC
> documentaion.
> What metadata is stored in the directory and not the file that is
> needed for the
> contents of a file to still be usable?
>
> (Eg on Acorn systems there's a load address and execution address in the
> directory, without which you don't know how to execute a header-less
> binary
> file. is it something like that?)
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/09b98221-4d86-4b11-9ef1-6c5aebe2ea97n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/09b98221-4d86-4b11-9ef1-6c5aebe2ea97n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr3Zfo6oRihCgExCAGOt2%2By9XphhVLT%2BP3NNa6dSqwYKDA%40mail.gmail.com <https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr3Zfo6oRihCgExCAGOt2%2By9XphhVLT%2BP3NNa6dSqwYKDA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Anton L.]

>  is it something like that?

For runnable files (task images) in RSX, the files must be contiguous (that is another attribute) -- i.e. the contents stored in the sequential disk blocks so it can be swooped up into memory in one go.

These files are structured as "sequential" with 512-byte fixed size records, or (the same) are unstructured (i.e. the sequence of blocks -- which they basically are).  The information about startup address and stuff like that for the loader is located inside the file, in the first two blocks, called task header.  The remaining blocks are the snapshot of memory contents, to be loaded with, to begin the execution of the code.

[Johnny Billquist]

On 2024-06-14 23:30, Anton L. wrote:
> > is it something like that?
>
> For runnable files (task images) in RSX, the files must be contiguous
> (that is another attribute) -- i.e. the contents stored in the
> sequential disk blocks so it can be swooped up into memory in one go.

Yes. But that is somewhat different than metadata about the file that
gets lost. This is more like a property of the file, and as such it's
something that you just need to know, and if your task is not
contiguous, you need to create a copy that is. Which is trivial.

> These files are structured as "sequential" with 512-byte fixed size
> records, or (the same) are unstructured (i.e. the sequence of blocks --
> which they basically are).  The information about startup address and
> stuff like that for the loader is located inside the file, in the first
> two blocks, called task header.  The remaining blocks are the snapshot
> of memory contents, to be loaded with, to begin the execution of the code.

Sortof, but not fully. The first two blocks of a task image holds
something called the label block group. In there you have some basic
information about memory layout of the image.

After that comes an optional checkpoint area, which is where to the task
will be swapped in case you want to have it providing its own swapping
area. This obviously means that only one copy of the task can be
running, and it can't deal with tasks that change their dynamic memory
usage, so it's an option that isn't used very often.

After that comes the task header area, which holds things like the start
address, LUN assignments, and other metadata for the task as such. Also
initial register contents, and also some extra information about debug
transfer vectors if that exist, and shared libraries mappings and whatnot.

After that comes actual memory content. But it's potentially multiple
chunks, depending on the task. (Obviously something like a split I/D
space task have a minimum of two chunks for example.) But if you have
overlaid tasks, this can become rather complex.

But all of this is just "normal" data within the file, so there is no
problems with transferring the tasks as such.

The metadata of a file is separate from this kind of stuff.

Johnny

> https://groups.google.com/d/msgid/pidp-11/09b98221-4d86-4b11-9ef1-6c5aebe2ea97n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/09b98221-4d86-4b11-9ef1-6c5aebe2ea97n%40googlegroups.com> <https://groups.google.com/d/msgid/pidp-11/09b98221-4d86-4b11-9ef1-6c5aebe2ea97n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pidp-11/09b98221-4d86-4b11-9ef1-6c5aebe2ea97n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "[PiDP-11]" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to pidp-11+u...@googlegroups.com
> > <mailto:pidp-11+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >

> https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr3Zfo6oRihCgExCAGOt2%2By9XphhVLT%2BP3NNa6dSqwYKDA%40mail.gmail.com <https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr3Zfo6oRihCgExCAGOt2%2By9XphhVLT%2BP3NNa6dSqwYKDA%40mail.gmail.com> <https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr3Zfo6oRihCgExCAGOt2%2By9XphhVLT%2BP3NNa6dSqwYKDA%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr3Zfo6oRihCgExCAGOt2%2By9XphhVLT%2BP3NNa6dSqwYKDA%40mail.gmail.com?utm_medium=email&utm_source=footer>>.

>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/61011da9-ff36-4b6b-a449-1dd6f3f30906n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/61011da9-ff36-4b6b-a449-1dd6f3f30906n%40googlegroups.com?utm_medium=email&utm_source=footer>.