XXFILE
larsbrinkhoff opened this issue · 10 comments
XXFILE .insrts the file TAA; UUOS >, but there is no such file anywhere.
Disassembly reveals that TAA probably were at DM, so we're most likely out of luck.
@eswenson1 wrote:
Look in sysen1;mudinq.43. You will find definitions for UUOH,
OCTLP, OASC, and other symbols that are undefined when you replace
taa;uuos > with a dummy (empty) file. You’ll see all the undefined
symbols you need to get resolved. I found a bunch of them in
mudinq.43.
And since TAA (Tim Anderson) was a Muddle hacker on DM, I wouldn’t
be surprised if he wrote MUDINQ (MUDDLE INQUIR) and used some of the
same macros in multiple programs (like XXFILE).
From comments in MUDINQ, it seems like the UUO macros were lifted from
DIRED. I saw some of the same macros in that source when I was
browsing around.
@taa01776, I don't suppose you have a copy of your UUOS file?
Perhaps? I have to look on some other machines to see what's still around.
@taa01776 Thank you!
I read there were backups made when DM were shut down. I sure hope someone took care of those.
I can't seem to make XXFILE work. I'm trying something very simple, almost straight out of XXFILE INFO, but I get an error:
*:xxfile tty:_[:listf^m]
STYOPN LARS 11 XXFILE
ERROR: Requesting input when none available.
DB ITS.1647. DDT.1546.
TTY 11
2. Lusers, Fair Share = 100%
If I type :PEEK here, I get
Index Uname Jname Sname Status TTY
2 LARS HACTRN LARS HANG >
6 LARS XXFILE LARS *+TTYSO T0
7 ___007 HACTRN 0 HANG >
10 ___007 PEEK 0 +TTYBO T11 C
So it seems XXFILE opened the pseudo-TTY T11, but failed to log in. And then it didn't process the input from the JCL. I'm left in HACTRN.
@taa01776 If you have some hints, that would be much appreciated.
Sending output to a file instead: :xxfile xx out_[:listf^m]. XX OUT is created, but is zero size and locked. :PEEK says
Index Uname Jname Sname Status TTY
2 LARS HACTRN LARS HANG >
6 LARS XXFILE LARS *OPEN <
10 LARS PEEK LARS +TTYBO T0 C
7 ___007 HACTRN ___007 TTYI T11
I've got this to compile with a reconstructed TAA; UUOS > -- ats/xxfile. I'm seeing the same behaviour as @larsbrinkhoff above, I think:
*:print simple xx
:$This is a simple test.$
:listf taa;
*:xxfile simple out_simple xx
STYOPN ATS 12 XXFILE 20:01:43
:PROCED
* LOGIN ATS0 12 20:01:44
LOGOUT ATS0 12 20:01:45
Job XXFILE interrupted: .VALUE;
If you $p it at this point, it completes successfully and the output file is correct. I'm not sure if that's the intended behaviour or not?
I also have a reconstructed TAA; UUOS, but I didn't get as far as verifying it by comparing an assembled binary. I see there are some differences between yours and mine, so maybe we can merge them together.
EDIT: In the lars/taa-uuos branch.
I think your test worked better than mine. ATS0 was logged in and out, so that seems like a completed run. I don't think I got to that valret.
I don't know if the valret is intended behaviour or not. I don't think it's mentioned in the manual.
I've merged your UUOS and mine together; thanks for your suggestions!
I'm now pretty convinced that it's working as intended. If XXFILE's output isn't to a DSK: file, then it valrets :PROCED to detach from the TTY, but it still needs to valret again upon exiting to turn off ..SAFE -- so DDT has to ask you to reattach it as above.
:xxfile tty:_simple xx works fine for me; it runs the commands from the file (without detaching), and :KILLs cleanly when done. If you say :xxfile /p tty:_simple xx, then the STY emulates a printing terminal and it doesn't clear the screen on logout, etc., so that's probably more appropriate if we wanted to use it in build.tcl.