Re: PDP-11 tape question
On 6/24/2020 2:12 PM, Chuck Guzis via cctalk wrote: On 6/24/20 1:23 PM, Jon Elson via cctalk wrote: The 1052 Selectric console on the 360's were not on a channel, but driven via direct I/O directly from the CPU microcode. (Yes, the console has a pseudo channel address that made you THINK it was on a channel, but it actually wasn't.) One prank to pull on an operator was to write a CCW chain to ring the 1052 bell and then to a TIC back to the bell ring CCW. At least on DOS/360, pretty much impossible to kill without doing an IPL, as the keyboard would be locked. Fun from my younger days. --Chuck One of my buddies had a football game, sort of like the logic of basic games that came along, but was written in Cobol. was about 3 or 4 inches of cards and a nice game. The thing was written to use WTO and WTOR which isn't that big a deal in a lot of shops. However when you've got a lot of jobs running and need the console, having to play a game of football to get back access to the console wasn't amusing. We (students, users) all looked at each other, and figured they'd have a way around that, wouldn't they, and he ran it. Also regardless the retries and the tape channel were intertwined and when the tape was retrying the console I/O was locked up. Channel attach or not. The other useless bit (going way off the subject of tape) the system used HASP for a lot of the job scheduling on the site with a lot of mods to HASP and the system initiator code. Relative to the cobol football game, i discovered from reading the initiator code that one could issue console commands from any reader attached to an initiator by putting a / in front of the command and having it be valid. I was nice and told the operators and the system programmer guys it was active. I got to do a couple of simple display commands and kept it to myself while they fixed the initiators to not accept commands. The bad news was that was a couple weeks before my other friend decided to run football. thanks Jim
Re: PDP-11 tape question
On 06/24/2020 04:12 PM, Chuck Guzis via cctalk wrote: On 6/24/20 1:23 PM, Jon Elson via cctalk wrote: The 1052 Selectric console on the 360's were not on a channel, but driven via direct I/O directly from the CPU microcode. (Yes, the console has a pseudo channel address that made you THINK it was on a channel, but it actually wasn't.) One prank to pull on an operator was to write a CCW chain to ring the 1052 bell and then to a TIC back to the bell ring CCW. At least on DOS/360, pretty much impossible to kill without doing an IPL, as the keyboard would be locked. Yup, the only way to stop that would be to do a halt IO instruction or press system reset. Jon
Re: PDP-11 tape question
Sometimes I had only lunch hour to do PMs, and one office worker always ate into my time because she had to 'finish something'. Pretty soon I found that [ 2 ; 9 y would put all ANSI terminals into continuous self-test, and that solved the problem:-) Those were the days! cheers, Nigel On 24/06/2020 17:12, Chuck Guzis via cctalk wrote: On 6/24/20 1:23 PM, Jon Elson via cctalk wrote: The 1052 Selectric console on the 360's were not on a channel, but driven via direct I/O directly from the CPU microcode. (Yes, the console has a pseudo channel address that made you THINK it was on a channel, but it actually wasn't.) One prank to pull on an operator was to write a CCW chain to ring the 1052 bell and then to a TIC back to the bell ring CCW. At least on DOS/360, pretty much impossible to kill without doing an IPL, as the keyboard would be locked. Fun from my younger days. --Chuck -- Nigel Johnson, Sc., MIEEE, VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.john...@ieee.org
Re: PDP-11 tape question
On 6/24/20 1:23 PM, Jon Elson via cctalk wrote: > The 1052 Selectric console on the 360's were not on a channel, but > driven via direct I/O directly from the CPU microcode. (Yes, the > console has a pseudo channel address that made you THINK it was on a > channel, but it actually wasn't.) One prank to pull on an operator was to write a CCW chain to ring the 1052 bell and then to a TIC back to the bell ring CCW. At least on DOS/360, pretty much impossible to kill without doing an IPL, as the keyboard would be locked. Fun from my younger days. --Chuck
Re: PDP-11 tape question
On 06/23/2020 09:09 PM, jim stephens via cctalk wrote: Short story of crashing the 360 MVT system. We had IBM reels we reused which IBM used for patches called DTRs. they had 50 or 100' max length tape. We had a guy muck up a program to send a file off our system to the mainframe, and he forgot to break up the file into records. So he ended up with an entire tape with one big physical record. what happened was our code didn't properly terminate, so when the IBM job was run with the tape as input it read the entire tape and got a tape error. then printed a spew on the console. repeat 10 times. Problem, tape drive and console was on the same channel. With normal size records even up to 64k long the tape didn't busy the channel up for very long. The 1052 Selectric console on the 360's were not on a channel, but driven via direct I/O directly from the CPU microcode. (Yes, the console has a pseudo channel address that made you THINK it was on a channel, but it actually wasn't.) I'm kind of surprised, as the tape controller had a record length count, and should just terminate with an error if the record was longer than the count specified. You HAD to do that, as otherwise you could overrun the user's buffer and write tape data onto system control blocks or even another user's partition. Exactly how the tape controller handled these insanely long records, however, is another matter, and I can imagine the controller might try to reach the end of the record before turning around to backspace over it so it didn't run over to another record. And, that could tie up the channel for a minute or more. Sharing devices, control units and channels on the 360 was NOT a really well thought-out mechanism. Searching a data set of several cylinders for a specific key on a 2314 drive could bring the whole system to a halt for many seconds. Jon
Re: Future of cctalk/cctech - text encoding
On 6/24/2020 10:02 AM, Curious Marc via cctalk wrote: But I would strongly suggest that we limit it to using characters from the Baudot set. If not they don’t print right on my 1930 Teletype. I can peruse the list on my Teletype ASR-32(s). Can archive the list with the 5 level paper tape (at least till the three rolls of tape run out).
Re: Changing the number of file headers on an RSX volume
I did get an answer from Johnny B, and it makes sense why I couldn't figure it out: In order to increase the file handles significantly you have to either dismount with "dmo du0:/dev/lock=v" to lock tasks in memory then mount foreign and back it up or just put BRU64K on an RX01 floppy with VMRV48 and boot from that. Then after the volume is backed up to tape you clobber it by using BRU to restore it and set the /MXF parameter on that line. Otherwise BRU keeps the same value for MXF and the files limit is still there. The neat part (and why I couldn't remember) is I used to use DSC to back up my RL02's and RM02's to other RL/RM disk packs. DSC did a pretty much image copy while BRU actually creates a new file system and then copies the files and the boot information. I didn't use BRU at the time because I didn't have a tape drive. Modern technology marches on. I'm waiting on a pair of TK50 tapes to arrive from TrashBay, once I have those checked out I'll do the backup and restore and get myself back in business. C * Dismounting the system volume on RSX11 is tricky. You can just dismount it, but then the system will lock you out of installed tasks and you'll be dead in the water. The /dev/lock=v holds the tasks in memory so you can still run your tools with the disk dismounted. A quick way to do this is to bring up the system, then shutdown and when you get to ODT type P to proceed. The system will come up with the shell but no volumes. Using HOM can increase the number of files or directories but only up to a point. Also with home you need to first set the device to private (only do-able when you do the shutdown and resume with P trick) then allocate the disk, then mount it foreign. It's never dull in pdp11 world. CZ On 6/24/2020 12:57 PM, Kenneth Gober wrote: On Tue, Jun 23, 2020 at 9:03 PM Chris Zach via cctalk mailto:cctalk@classiccmp.org>> wrote: So I'm working on this RSX11M+ system here and while working I ran myself out of file headers. Using the HOME /MXF command I was able to increase the number of headers, but only up to 4090. or so. Trying to go to 4100 gave me an error saying there were not enough system blocks or something. Currently I have 830 headers, but that's not enough in the long term. I've never actually used RSX-11 myself, all I know about it is what I read in the ODS-1 spec, but I'm guessing the issue here is that the volume is set up with only 1 block allocated for the index file bitmap, and growing the number of file headers beyond 4096 would require growing the index file bitmap to 2 blocks (or more, depending on how many file headers you expect to need). Since the first 16 file headers must follow directly after the index file bitmap, growing the bitmap requires moving those first 16 file headers as well, which in turn requires moving whatever may currently be in the way. None of this of course is something I'd expect the system to be able to do while the volume is mounted. What precisely you have to do to achieve the goal of having a volume with more file headers I can't say, sorry, but I thought I could at least provide some extra context for other readers on why it's not as trivial to do as one might guess. -ken
Re: Future of cctalk/cctech - text encoding
Someone whose name might be Marc might have written: Peter Coghlan wrote: Does anyone use ASCII anymore? >>> >>> I read and write my email with Emacs running in a terminal emulator. >>> I rarely need anything beoynd codepoint 126. >> >> I vote we move the list to an Exchange server behind a SSL VPN and mandate >> the use of Outlook, then force all messages to be in quoted-printable >> encoding. This way nobody “wins” and everyone is equally miserable. >> It’s only fair. > C'mon, quoted-printable is usually fairly readable. How about base-64? Or if this is regarded as too modern or too universal, how about uuencoding? > > +1 on the Exchange server. You might even be able to have more than 2 people > connected to it at the same time without crashing, if you put enough admins > on the problem. > You can't use an Exchange server. I believe Exchange servers silently discard messages whose message-id it has previously seen. This would solve (actually hide) the duplicated messages problem and we can't have that! > > But I would strongly suggest that we limit it to using characters from the > Baudot set. If not they don’t print right on my 1930 Teletype. > > Also Darwin recently wrote a paper about us, and revoked his theory of > evolution. > > Unlike the God-awfull Yahoo Groups, Groups.io works OK for the other lists > I follow. Meaning it’s functional and tolerable, and only moderately > infuriating. But it is certainly not as clean and efficient as this list > by a good margin. It would be good if we could preserve this. > > Maybe evolve to the use of pictures or attachments, just to prove Darwin > wrong? Limited to ASCII art only pictures, of course. > Hang on, what about those who prefer their art in upper case EBCDIC only? Regards, Peter Coghlan > > Marc
Re: Future of cctalk/cctech - text encoding
>>> Peter Coghlan wrote: >>> Does anyone use ASCII anymore? >> >> I read and write my email with Emacs running in a terminal emulator. >> I rarely need anything beoynd codepoint 126. > > I vote we move the list to an Exchange server behind a SSL VPN and mandate > the use of Outlook, then force all messages to be in quoted-printable > encoding. This way nobody “wins” and everyone is equally miserable. It’s only > fair. +1 on the Exchange server. You might even be able to have more than 2 people connected to it at the same time without crashing, if you put enough admins on the problem. But I would strongly suggest that we limit it to using characters from the Baudot set. If not they don’t print right on my 1930 Teletype. Also Darwin recently wrote a paper about us, and revoked his theory of evolution. Unlike the God-awfull Yahoo Groups, Groups.io works OK for the other lists I follow. Meaning it’s functional and tolerable, and only moderately infuriating. But it is certainly not as clean and efficient as this list by a good margin. It would be good if we could preserve this. Maybe evolve to the use of pictures or attachments, just to prove Darwin wrong? Limited to ASCII art only pictures, of course. Marc
Re: Changing the number of file headers on an RSX volume
On Tue, Jun 23, 2020 at 9:03 PM Chris Zach via cctalk wrote: > So I'm working on this RSX11M+ system here and while working I ran > myself out of file headers. Using the HOME /MXF command I was able to > increase the number of headers, but only up to 4090. or so. Trying to go > to 4100 gave me an error saying there were not enough system blocks or > something. Currently I have 830 headers, but that's not enough in the > long term. > I've never actually used RSX-11 myself, all I know about it is what I read in the ODS-1 spec, but I'm guessing the issue here is that the volume is set up with only 1 block allocated for the index file bitmap, and growing the number of file headers beyond 4096 would require growing the index file bitmap to 2 blocks (or more, depending on how many file headers you expect to need). Since the first 16 file headers must follow directly after the index file bitmap, growing the bitmap requires moving those first 16 file headers as well, which in turn requires moving whatever may currently be in the way. None of this of course is something I'd expect the system to be able to do while the volume is mounted. What precisely you have to do to achieve the goal of having a volume with more file headers I can't say, sorry, but I thought I could at least provide some extra context for other readers on why it's not as trivial to do as one might guess. -ken
Re: PDP-11 tape question
> On Jun 23, 2020, at 9:57 PM, Chuck Guzis via cctalk > wrote: > > I've been processing some PDP-11 9 track (800 NRZI) tapes and run across > something that I don't recognize. > > Every file on the tape consists of a number of 512 byte blocks (okay, > that's normal) but at the head of each file, there's a short block of 14 > bytes. > > Usually, a short record like this is discarded as "noise" on many > mainframe tape systems, but here it's consistently present. Here's what > one of the records looks like: > > 15 34 fe 51 fe 76 01 01 00 00 01 80 10 00 > > Doesn't seem like a file name in RAD50 format, so I'm puzzled. > > Inquiring minds want to know... > > Thanks, > Chuck As others have answered, that's a DOS file label, used in PDP-11 magtapes since the beginning. Most PDP-11 operating systems also support ANSI labels, but DOS labels are the most common on RSTS (except for V9 and later backup tapes which are always ANSI). Bootable tapes are DOS labeled. I remember that OS/360 documentation stated < 18 bytes would be treated as noise but that's not precisely true. The accurate description is that a record encountering a read error but < 18 bytes long would be silently discarded as noise rather than being reported as a real block with a read error. But error free 14 byte blocks can be read just fine. I wrote an OS/360 utility (now long lost unfortunately) that would read DOS-11 format tapes so we could print large files (our RSTS/E system didn't have a line printer but the 360/44 did). No problem there. It used EXCP to allow reading across tape marks, and possibly that made handling the 14 byte records easier but I don't remember that it was required for that purpose. paul
Re: PDP-11 tape question
At 12:50 AM 6/24/2020, Chuck Guzis via cctalk wrote: >Thanks for straightening that out--all I know is that the tapes are from >an 11/70, which isn't much information, admittedly. A few months ago, I was re-rescuing some files that a friend had once read from a RSTS tape. He gave two sets of files. I'm not sure what tool or system he was using, but it probably was newer than the RSTS. One grabbed the files with the 14 bytes prepended to every file but without correct filenames, the other rescued the files with the filenames but without the correct dates. Once I figured out the nameless files had the 14 byte DOS-11 tape header, I wrote a little C tool that gave the files their proper filename and date. You're welcome to it. For Windows at least and probably Unix. My deeper goal was to rescue the files well enough to get them running again under SIMH and/or one of the JavaScript-based in-browser emulators. The programs wanted the FORTRAN compiler environment and BASIC-PLUS, and finding all those installers of the right version and combination, learning how to get it all right... whew, I wasn't sysop-level back then, and so much time has passed, it's quite a puzzle. - John
