Re: [Simh] Transferring the licence file to the VAX emulator
> On Dec 18, 2018, at 9:20 PM, Larry Baker wrote: > > My 2¢ from the Way Back Machine: > > I don't know what programmer's used before Fortran. But, all these OS/360 > features (and, likely earlier IBM OS's) were accessible from Fortran, the > first commercially available high-level computer language. Human input, > including source code, was typically typed onto an 80-column card with a > keypunch. Such text "files" were read using 80 character "fixed-length" I/O. > Also, in those days, disk sectors were not fixed lengths. Think of them as > tiny strips of magnetic tape. Just like tape, there is a physical record > written and read by the hardware—what is now called a sector for fixed-length > geometries—packed with embedded logical record(s) with a structure defined by > software. ... > > I don't recall when or why fixed-sector disks began to be required, and by > which O/S's. There would certainly have been a cost savings motive, both in > the device electronics, and in the attachments, which could be much simpler > than channel attachments. "little strips of tape" is a good way to look at it. I have the impression that this approach is specific to IBM. Not that I know all the computer makers from that era. But at least CDC had fixed size data-only sectors in the 6000 series, that would be around the same time as the IBM 360. Those sectors didn't contain 8 bit bytes and weren't a power of two in length, but they were fixed. In theory the disk controllers could create other formats (the controller had something like channel programs to parse the sector layout) but that wasn't used in practice. Come to think of it, the IBM 1620 also had fixed length sectors (200 digits in the model 1311, if memory serves). There are some other variants around: the EL-X8 had disks with per-track selectable sector size, from a list of 6 or so choices (non-power of two multiples of 27 words). paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator - THE FIX
On 18/12/18 13:56, Armistead, Jason wrote: Maybe a brief discussion of this topic could be added to the SIMH FAQ. It seems like a key piece of information to help others kick-start their attempts to run VMS/OpenVMS under SIMH. concur and agree. Dott. Piergiorgio. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
My 2¢ from the Way Back Machine: I don't know what programmer's used before Fortran. But, all these OS/360 features (and, likely earlier IBM OS's) were accessible from Fortran, the first commercially available high-level computer language. Human input, including source code, was typically typed onto an 80-column card with a keypunch. Such text "files" were read using 80 character "fixed-length" I/O. Also, in those days, disk sectors were not fixed lengths. Think of them as tiny strips of magnetic tape. Just like tape, there is a physical record written and read by the hardware—what is now called a sector for fixed-length geometries—packed with embedded logical record(s) with a structure defined by software. Such "files" were read using "fixed-length" or "variable-length" I/O to match the desired record structure. I say "files", because I/O could be done on an IBM OS/360 to just about any device, whether it incorporated a file system (disks did) or not (labeled tapes did, unlabeled tapes and card readers and printers did not), Fortran supported text or binary I/O. Binary I/O was done using variable-length record format. Fortran imposed no limit to the size of a variable-length record. To escape the limitation of the hardware, "spanned" record format was created which splits and merges arbitrary length Fortran records into segments, which are then passed on as "normal" fixed- or variable-length records to the software layer which assembles and disassembles physical records for device I/O. The richness of file formats available in Fortran was directly mapped to the hardware capabilities. ISAM I am sure must have come about when IBM introduced their first DBMS. As with the file formats needed/used by Fortran, the ISAM software undoubtedly made direct use of the hardware features. Recall, in those days I/O to devices like disks and tapes was done through "channels", which themselves were actually small computers. Operations requested by software that made use of these features were performed by channel programs; thus, were processed in parallel while the CPU was relieved to work on other things (in a multi-programming O/S like OS/360; not all O/S's were). I don't recall when or why fixed-sector disks began to be required, and by which O/S's. There would certainly have been a cost savings motive, both in the device electronics, and in the attachments, which could be much simpler than channel attachments. It would not surprise me if Multics was influential. A stream of blocks (sectors) or bytes are not that different, other than at the device I/O level. Ergo the need to differentiate block devices from character devices in Unix. When the device I/O was controlled by the record format of the program, as in the original Fortran, it was done by the O/S (using the appropriate channel program). When the device was only capable of delivering fixed-length blocks of data (sectors), a software layer had to perform the equivalent record formatting operations. That is where we are today. RSX, VMS, Unix all perform "file" I/O (after passing through an optional file system layer) through the operating system; they perform record I/O through user-mode libraries. The C library implements the illusion of a stream of bytes, including the notion of an "end of record" for text I/O using a metacharacter marker (\n, the newline character, which is NOT a line-feed in EBCDIC). RSX and VMS embed structure within the data blocks of a file, and encode that information in metadata fields provided by the file system. The appropriate FCS (RSX) or RMS (RSX and VMS) libraries do the work. Not all the file systems supported by VMS support all the RMS file types (record formats), such as the ISO-9660 CD-ROM file system. Absent any hints, the VMS file system layer assumes the record format is the same as the "standard" disk format, 512-byte sectors (even though a CD-ROM has 2048-byte sectors). And, that is why Brian's Unix CD-ROM was misread on VMS. The File Types available in the ISO-9660 file system metadata read like a POSIX file system specification. That is, very Unix-like. I don't know why the RMS default file attributes are not STREAM_LF. That would make more sense to me. Anyway, the default can be changed by the /UNDEFINED_FAT option in the MOUNT /MEDIA_FORMAT=CDROM command. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov > On 17 Dec 2018, at 12:06:57 PM, simh-requ...@trailing-edge.com wrote: > > -- > > Message: 3 > Date: Mon, 17 Dec 2018 14:56:30 -0500 > From: Paul Koning mailto:paulkon...@comcast.net>> > To: Phil Budne mailto:p...@ultimate.com>> > Cc: dave_list_a...@verizon.net <mailto:dave_list_a...@verizon.net>, > cl...@ccc.co
Re: [Simh] Transferring the licence file to the VAX emulator
Brian, It is much simpler to use the /UNDEFINED_FAT option in the MOUNT /MEDIA_FORMAT=CDROM command. That is what it does for you. As Johnny said, the problem is not the bytes in your file, but the mismatched file attributes that describe the bytes in your file that is the problem. Your CD-ROM does not contain enough metadata to describe the files contents. (File systems have metadata; that doesn't seem to bother anyone. Why files have abandoned metadata and forced programmers and users to deduce file formats from magic numbers encoded at the front of a file or arbitrary file naming conventions is beyond me.) Here's the HELP screen output from OpenVMS/Alpha 7.2-1: > BAKER SAMOA> help mount /undefined_fat > > > MOUNT > > /UNDEFINED_FAT > >Establishes default file attributes to be used for records on ISO >9660 media for which no record format has been specified. > >Format > > /UNDEFINED_FAT=record-format:[record-attributes:][record-size] > > > > > Additional information available: > > Parameters Description Example > > MOUNT /UNDEFINED_FAT Subtopic? example > > > > > > MOUNT > > /UNDEFINED_FAT > > Example > > >$ MOUNT/MEDIA_FORMAT=CDROM/UNDEFINED_ > FAT=(FIXED:CR:80) DBA1: OFFENS STRAT > >In this example, the volume labeled OFFENS is mounted on DBA1 >and all files on the volume are defined to be fixed length, >carriage return, and 80 bytes in length. MOUNT also assigns the >logical name STRAT. > > > The one caveat is that the FAT attributes apply to every file on the CD-ROM, so you have to remount it to transfer different kinds of files, e.g., text files, object files, executables. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov > On 18 Dec 2018, at 9:00:02 AM, simh-requ...@trailing-edge.com wrote: > > -- > > Message: 3 > Date: Mon, 17 Dec 2018 23:52:05 -0500 > From: Brian mailto:b_li...@patandbrian.org>> > To: SIMH@trailing-edge.com <mailto:SIMH@trailing-edge.com> > Subject: Re: [Simh] Transferring the licence file to the VAX emulator > - THE FIX > Message-ID: <mailto:aa86081a-7b16-7308-b69a-e6c207156...@patandbrian.org>> > Content-Type: text/plain; charset=utf-8 > > On 12/17/18 8:28 AM, Brian wrote: > > OK, thanks to all who helped. As I found from a website to which I was > directed, and as Mark also said, the solution was to copy the file off > the CD-ROM and then > > SET FILE/ATTRIBUTE=(RFM=STM) VMSLICENCES.COM <http://vmslicences.com/> > > Then run the commands again, and it all worked perfectly. > > I guess I've forgotten a lot more about VMS than I thought in 30-odd > years. :( This could be an interesting (re-)learning curve... > > Brian. > > smime.p7s Description: S/MIME cryptographic signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator - THE FIX
Maybe a brief discussion of this topic could be added to the SIMH FAQ. It seems like a key piece of information to help others kick-start their attempts to run VMS/OpenVMS under SIMH. -Original Message- From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Brian Sent: Monday, 17 December 2018 11:52 PM To: SIMH@trailing-edge.com Subject: [External] Re: [Simh] Transferring the licence file to the VAX emulator - THE FIX On 12/17/18 8:28 AM, Brian wrote: OK, thanks to all who helped. As I found from a website to which I was directed, and as Mark also said, the solution was to copy the file off the CD-ROM and then SET FILE/ATTRIBUTE=(RFM=STM) VMSLICENCES.COM Then run the commands again, and it all worked perfectly. I guess I've forgotten a lot more about VMS than I thought in 30-odd years. :( This could be an interesting (re-)learning curve... Brian. > Hi all, > > Please bear with me for what I'm sure is a beginner question, but it > has me beat. :( > > I've set up SIMH, built it all, got my kits for OpenVMS and have > installed the system. So far, so good. > > The problem I'm having is in getting the licence file I received under > the Hobbyist scheme onto the VAX. I had thought that 'burning' it into > an ISO on my Linux box and then mounting that image would work. It > does, but not completely. > > According to the e-mail, the licence file is in the form of a VMS > command file. On my Linux box, this looks just fine. However, > irrespective of whether I use Linux or Windows line endings, when I > transfer the file onto the VAX as above, all the lines run together > and the file format is trashed. If I edit the file on the VAX, I can > see the LF or CR/LF characters in the editor, just as they should be. > > Maybe I've forgotten more about the VAX than I think. WHAT does it > expect to see as a line terminator? If I know, then I can fix the file > on my Linux box and transfer it over again, but if neither Linux nor > Windows line endings work, I've no idea what I need to try. Or am I > missing something, and there's some fundamental flaw with the whole > idea of transferring text files via an ISO image? > > I really don't want to have to enter all the licence data > interactively, or fix a couple of thousand line endings in the editor! > There must be SOME way of getting the file onto a new setup? > > Thanks for any assistance, > > Brian. > ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator - THE FIX
On 12/17/18 8:28 AM, Brian wrote: OK, thanks to all who helped. As I found from a website to which I was directed, and as Mark also said, the solution was to copy the file off the CD-ROM and then SET FILE/ATTRIBUTE=(RFM=STM) VMSLICENCES.COM Then run the commands again, and it all worked perfectly. I guess I've forgotten a lot more about VMS than I thought in 30-odd years. :( This could be an interesting (re-)learning curve... Brian. > Hi all, > > Please bear with me for what I'm sure is a beginner question, but it > has me beat. :( > > I've set up SIMH, built it all, got my kits for OpenVMS and have > installed the system. So far, so good. > > The problem I'm having is in getting the licence file I received under > the Hobbyist scheme onto the VAX. I had thought that 'burning' it into > an ISO on my Linux box and then mounting that image would work. It > does, but not completely. > > According to the e-mail, the licence file is in the form of a VMS > command file. On my Linux box, this looks just fine. However, > irrespective of whether I use Linux or Windows line endings, when I > transfer the file onto the VAX as above, all the lines run together > and the file format is trashed. If I edit the file on the VAX, I can > see the LF or CR/LF characters in the editor, just as they should be. > > Maybe I've forgotten more about the VAX than I think. WHAT does it > expect to see as a line terminator? If I know, then I can fix the file > on my Linux box and transfer it over again, but if neither Linux nor > Windows line endings work, I've no idea what I need to try. Or am I > missing something, and there's some fundamental flaw with the whole > idea of transferring text files via an ISO image? > > I really don't want to have to enter all the licence data > interactively, or fix a couple of thousand line endings in the editor! > There must be SOME way of getting the file onto a new setup? > > Thanks for any assistance, > > Brian. > > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
On 2018-12-17 22:54, Paul Koning wrote: On Dec 17, 2018, at 3:04 PM, Johnny Billquist wrote: Actually, VMS don't natively have any record terminators for text files. So lines terminated by CR, LF, CR+LF or whatever, are all wrong. Huh? For VMS, "native" is any file format that RMS32 supports. In VMS V1, that means either fixed or variable length records, but sometime later stream-CR, stream-LF, and stream-CRLF record format support was added both to RMS32 and RMS11. Right. I put that a bit wrong. Traditionally, the normal text file format was/is variable length records with implied CRLF. I should have said that rather than "natively". Johnny -- 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 ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
> On Dec 17, 2018, at 3:04 PM, Johnny Billquist wrote: > > Actually, VMS don't natively have any record terminators for text files. > So lines terminated by CR, LF, CR+LF or whatever, are all wrong. Huh? For VMS, "native" is any file format that RMS32 supports. In VMS V1, that means either fixed or variable length records, but sometime later stream-CR, stream-LF, and stream-CRLF record format support was added both to RMS32 and RMS11. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
On 2018-12-17 21:34, Phil Budne wrote: I wasn't saying RMS was anything new to the world in general, but that VMS was the first system to make it the preferred way to access disks. DEC was not always thus. I'm pretty sure my first exposure to RSX-11M was using F11ACP, I don't think RSX was BORN with RMS as the primary method of file access, it was born as a real-time system. To clarify a couple of things here. F11ACP is the low level file system processor. Both RSX and VMS have this one. (In VMS, you have different flavors to handle ODS-1, ODS-2 and ODS-5, and also the water got muddled by the addition of the XQP in order to reduce the number of context switches when trivial file operations were being performed.) The ACP have nothing to do with what RMS does. RMS is a layer above the ACP. In the old days, RSX used a library called FCS. FCS can be called more or less a subset of RMS. Both FCS and RMS provide similar capabilities, such as viewing files as a stream of records or bytes, instead of just being a bunch of disk blocks, which is all that the ACP gives you. And the formats FCS use on the disk are compatible with, or a subset of the formats RMS use. RMS was definitely an option in RSX. Probably even before VMS was born. But it was an option. When you do a system generation of RSX-11M, you get asked if you want to include RMS or not. There are some functionality that is provided by the ACP, which RMS needs, but FCS do not, so therefore it matters at system generation time. But otherwise, RMS, just like FCS, is just a user level library in RSX. I sortof doubt you ever used F11ACP without FCS, even though it is definitely possible. But DEC never documented the ACP interface very well, so it's a bit tricky to use it. And then of course, you also need to write all the annoying bits that FCS already implemented for you. Clem wrote: As Dennis Ritchie once said to me, the whole idea behind a byte stream was for the OS to just get the bits and then user code do the interpretation This was pretty much the norm at DEC before RMS. Disk blocks contained streams of bytes. Legend is the original name of PIP was ATLATL (anything lord to anything lord). I wouldn't say so. It depends on the OS. TOPS-10 and Tops-20 are both rather stream like I seem to remember. RSTS/E is a bit of a hybrid, I think. (If I remember right) Same for RT-11, as well as OS/8. You address things in blocks, and you have to fiddle around with the bytes yourself, but the normal convention is that you just add CR+LF in the file when there is a new line. And you have something like ^Z to indicate the end of file, since file sizes are actually expressed in blocks, and not bytes. And RMS was the successor to FCS, which have a very similar paradigm. But I think most agree that RSX was sortof the odd one out compared to most of the other systems at the time at DEC. But you always had some library to be able to just read/write data to a file, and that library blocked and deblocked the data for you. It's just that FCS (and later RMS) had a much more complex (and rich) set of formats on the disk for it. Good and bad... Johnny -- 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 ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
I wasn't saying RMS was anything new to the world in general, but that VMS was the first system to make it the preferred way to access disks. DEC was not always thus. I'm pretty sure my first exposure to RSX-11M was using F11ACP, I don't think RSX was BORN with RMS as the primary method of file access, it was born as a real-time system. Clem wrote: > As Dennis Ritchie once said to me, the whole idea behind a byte stream was > for the OS to just get the bits and then user code do the interpretation This was pretty much the norm at DEC before RMS. Disk blocks contained streams of bytes. Legend is the original name of PIP was ATLATL (anything lord to anything lord). As has been pointed out, IBM access methods were (often) implemented as "channel programs", and some history of DEC pointed out that Ken et al were aware that PDP-1 was closer in complexity and cost to the small "channel" computers IBM was using at the time than to the actual IBM computer. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
On Mon, 17 Dec 2018 20:16:19 -, Johnny Billquist wrote: And then I have my possibly very sneaky alternative: TECO. TECO usually swallows and does the right thing for very many things, and if not, it's very easy to correct, and then let TECO write the file out, and you'll have a file with the right format and attributes. Johnny ah I can never remember TECO now, but SOS has stuck with me from RSTS/E days, in VMS pretty much the same as EDT in line mode so I often revert there when I need to do anything fancy :-) Came in well handy when I had to resolve an issue on a unix platform where some kind soul unset all the sticky bits. I just pulled the directory lists from that and an unharmed system over to VMS and manipulated there with DCL and "SOS" to generate the required NIX scripts to fix things back the way they needed to be. Yeah vi etc can do that too but I've far more experience on the VMS side so why risk screwing up on when doing a remote fix on a clients system ;-) -- ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
yeah true, variable with fixed headers, you're right there I remember that
now, been a while :-)
On Mon, 17 Dec 2018 20:04:31 -, Johnny Billquist
wrote:
Actually, VMS don't natively have any record terminators for text files.
So lines terminated by CR, LF, CR+LF or whatever, are all wrong.
The natural format is variable length records with implied CRLF. Which
means that on the disk, the records are prefixed by a length, and no CR
or LF are actually present at all.
But of course, such a format is not something a 9660 file system can
have, so you'll instead have to tell VMS that the files on that CD
should be interpreted as stream-lf, if they are in fact Unix text files.
Exactly how you get VMS to actually interpret the files on the CD that
way though, I can't remember. Maybe there is some mount option?
Otherwise copy the files over to a normal disk, and then change the file
attributes to be stream-lf.
Johnny
On 2018-12-17 16:15, Dave L wrote:
Likely the issue is that the *nix system presents the text file as
stream-LF format which VMS won't understand as a standard text file
which it would expect to be CR-LF terminated records. VMS convert
utility would be able to fix that as already mentioned, tho you may
need to tell it what record format you want on the output file, can't
recall now (or use an FDL to define the output file format).
Alternatively you can just cut and paste from your host into the
terminal session to get the initial licenses set up and go from there,
either direct to the VMS prompt to action the commands or capture into
a command file ("$ copy TT: license.com" might work, then ctrl/Z when
finished).
HTH
Dave
On Mon, 17 Dec 2018 14:02:24 -, Brian
wrote:
On 12/17/18 8:44 AM, Wilm Boerhout wrote:
Brian schreef op 17-12-2018 om 14:28
[snip]
I really don't want to have to enter all the licence data
interactively, or fix a couple of thousand line endings in the
editor!
There must be SOME way of getting the file onto a new setup?
Thanks for any assistance,
Brian.
What usually works for me:
* open the license command file file in your mail program / in a
notepad on your Linux host.
* Open a TPU editor session on your OPA0 simh console terminal
* Copy/Paste the License file text into the TPU editor window.
If you get buffer overflows on VMS, try it with just the TCP/IP
license (called UCX for hysterical reasons), then setup IP networking
and ftp on VMS.
OK, thanks, I'll give it a try later today and report back. If anybody
can tell me in simple terms, though, I would like to understand why
the route of going via an ISO didn't work. Is it not possible to
transfer text files to the VAX other than via cut-and-paste without
the line endings getting mangled?
Brian.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
-- ___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
--
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
ahh good old ISAM, yeah I wrote something similar on a commodore pet system that I was tasked with writing a hospital lab data analysis suite for in the early 80s. It had the ability to random access the FDD's so it made sense to tag and allocate blocks rather than have to rewrite sequential access files for even a minor field change in a record. Would have run out of disk space to do that once you'd hit 50% on the data FDD as well as taking far too long. You'd make a specific call to acquire a random block and the OS would give you a block ID to use from free pool. You could then direct access that block ID and once the record was written update the index block you'd pre-allocated so you could go find it again later. Was an "interesting" experience doing that right at the start of my programming career. Was written in basic on a 32KB machine and having to still fit the actual application into the same memory ( no overlays etc). Added fun was the graphic codes for the screen/form displays were different to what the printer needed so any time someone wanted to print the app would have to pull those codes in off FDD, overlaying the screen ones and then revert once the print had completed. Not enough memory to hold both sets of codes. I later went on to messing about writing a pascal compiler for the Acorn Atom (6502 CPU) I used to have, just for fun... after modding the mobo to carry 32KB ram and upping clock speeds, oh the good old days, long gone now its all surface mount and my eyes are not up to messing about at that level now :-( One odd thing about IBM is that some of the access method mechanisms relied on hardware capabilities. For ISAM files, you'd write the file data with key fields in each sector, and use the search for key match feature in the disk drives (to find the matching sector so long as you knew on which track to look). That seems to be pretty unusual, though I've also seen it done by Electrologica in Holland in the mid 1960s. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh -- ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
On 2018-12-17 18:40, Paul Koning wrote: On Dec 17, 2018, at 12:29 PM, Clem Cole wrote: The problem is the license manager code you are running into is expecting an RMS file, not a Stream I/O. In the old days, the idea of 'access methods' was the natural ways OS's did I/O and RMS was VMS's answer. Since today's programmers tend to have grown up with C/C++/Java and stream I/O, you need to think in terms of a programming 'Framework' that is inflicting some level structure on the file. FWIW: Stream style I/O and the STREAM-LF file format was added to VMS to support VAX11/C, and normal programmers (correctly) started to avoid RMS (it was funny how quickly the compiler runtime teams abandoned RMS, but I digress). But if the code was written assuming RMS (which was all VMS had for many years), the files need RMS. That's odd, I thought that (on VMS) you didn't have any choice about using RMS. Well, not unless doing raw block I/O. Correct. And I seriously doubt the license manager is trying to go out of its way to make it hard here. Stream is one of the formats supported by RMS, exactly as fixed and variable records (with prefix length) are. Actually, stream comes in three flavors, depending on whether the record delimiter is LF, CR, or CR/LF. RMS-11 also supports these, FWIW. Well, RMS-11 actually only supports Stream, which is the same as Stream_CRLF under VMS. Stream_LF and Stream_CR more or less works fine reading with RMS-11, but the formats as such does not exist. And to comment to Clem, the length field is 16 bits and have been so since RMS first saw the light. So the maximum length is 65535 bytes, not 255. And counted strings in Pascal have nothing to do with it. So unless license manager goes out of its way to enforce a particular record format for its input files, I would think it "should just work", RMS should read the on-disk format and deliver the records (lines) according to the encoding described by the file attributes. It should work, assuming that the file attributes are correct, which is where I strongly suspect the problem lies. A CD with ISO 9660 file system just don't have VMS file attributes on the files, so you need some way of telling the system that the files actually are in stream_lf format. Finally, one suggestion was to transfer the file by cut & paste into a VMS editor; in that case the record format is chosen by the editor when creating the file, and the fact you're pasting from a Unix system is not a factor. That is also an option. And then I have my possibly very sneaky alternative: TECO. TECO usually swallows and does the right thing for very many things, and if not, it's very easy to correct, and then let TECO write the file out, and you'll have a file with the right format and attributes. Johnny -- 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 ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
I try one more time on list, but if you want to discuss more, let's go off-list. On Mon, Dec 17, 2018 at 2:56 PM Paul Koning wrote: > > Not unique to VMS nor even to DEC. I agree - that is exactly what I was saying. It was the way I/O was done in the 60s - which seems to have had a rebirth as part of modern Frameworks. And if you are programmer that grew up with I/O byte streams, then you think in terms of line terminators for text files; not variable length records. As Dennis Ritchie once said to me, the whole idea behind a byte stream was for the OS to just get the bits and then user code do the interpretation (which of course can be in a library). But don't make the OS need to know much -- just get the bits from storage and shove it into memory and let user interrept them. My guess is this is one of those cyclical arguments. Before the OSses of the 60s, when code ran raw on the HW, a programmer needed to add those libraries in your runtime deck. Putting 'record management' into the OS was seen as easier and made progammng simplier and fast. The problem of course is it was different for different systems and languages. So one person's easy, became another person's burden. By the time of Dennis and Ken are doing their thing -- they are fighting the native system I/O. Streams was a lot easier in Dennis's mind (and I tend to agree - I came up on IBM systems from the 60s, then PDP-10's, and VMS before UNIX). Eventually, as C and UNIX spread, what OSses followed and languages made easy followed that vision. And today most programmers have not seen the 'old ways.' FWIW: Years later, we start creating all these different ways of packaging up libraries and methods (a.k.a. programming frameworks) to hide the byte structure of files. So instead of learning ISAM/VSAM etc... you used some different set if API's that called sql-lite, *etc.*.. Who knows what will be 'natural' in the future. Clem ᐧ ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
Actually, VMS don't natively have any record terminators for text files.
So lines terminated by CR, LF, CR+LF or whatever, are all wrong.
The natural format is variable length records with implied CRLF. Which
means that on the disk, the records are prefixed by a length, and no CR
or LF are actually present at all.
But of course, such a format is not something a 9660 file system can
have, so you'll instead have to tell VMS that the files on that CD
should be interpreted as stream-lf, if they are in fact Unix text files.
Exactly how you get VMS to actually interpret the files on the CD that
way though, I can't remember. Maybe there is some mount option?
Otherwise copy the files over to a normal disk, and then change the file
attributes to be stream-lf.
Johnny
On 2018-12-17 16:15, Dave L wrote:
Likely the issue is that the *nix system presents the text file as
stream-LF format which VMS won't understand as a standard text file
which it would expect to be CR-LF terminated records. VMS convert
utility would be able to fix that as already mentioned, tho you may need
to tell it what record format you want on the output file, can't recall
now (or use an FDL to define the output file format).
Alternatively you can just cut and paste from your host into the
terminal session to get the initial licenses set up and go from there,
either direct to the VMS prompt to action the commands or capture into a
command file ("$ copy TT: license.com" might work, then ctrl/Z when
finished).
HTH
Dave
On Mon, 17 Dec 2018 14:02:24 -, Brian wrote:
On 12/17/18 8:44 AM, Wilm Boerhout wrote:
Brian schreef op 17-12-2018 om 14:28
[snip]
I really don't want to have to enter all the licence data
interactively, or fix a couple of thousand line endings in the editor!
There must be SOME way of getting the file onto a new setup?
Thanks for any assistance,
Brian.
What usually works for me:
* open the license command file file in your mail program / in a
notepad on your Linux host.
* Open a TPU editor session on your OPA0 simh console terminal
* Copy/Paste the License file text into the TPU editor window.
If you get buffer overflows on VMS, try it with just the TCP/IP
license (called UCX for hysterical reasons), then setup IP networking
and ftp on VMS.
OK, thanks, I'll give it a try later today and report back. If anybody
can tell me in simple terms, though, I would like to understand why
the route of going via an ISO didn't work. Is it not possible to
transfer text files to the VAX other than via cut-and-paste without
the line endings getting mangled?
Brian.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
--
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
--
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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
> On Dec 17, 2018, at 2:44 PM, Phil Budne wrote: > > Clem Cole wrote: >> In the old days, the idea of 'access >> methods' was the natural ways OS's did I/O and RMS was VMS's answer. > > Using RMS as the primary way to do file access was dain bramage unique > (at DEC) to VMS, no? Not unique to VMS nor even to DEC. There was RMS-11 in PDP-11 operating systems. I have the impression that predated VMS, though I may be off a bit. RMS-11 always felt like an extension of FCS-11, the RSX file structure library that introduced such things as file attributes and variable length records. But this stuff is much older. RMS feels a lot like the various "access methods" IBM created in OS/360. Fixed length records, variable length records, the notion of "spanned" records (records that cross block boundaries) and indexed files all appear in OS/360 well before VMS appeared. I think similar stuff existed elsewhere. CDC had record stuff in the 6000 series mainframes, though that felt more like an add-on, one I never used. But apart from that, they did have files with internal structure, called "records" and "files", rather different from what OS/360 did. So the notion of a file being a lot more than just a vector of bytes is quite old. One odd thing about IBM is that some of the access method mechanisms relied on hardware capabilities. For ISAM files, you'd write the file data with key fields in each sector, and use the search for key match feature in the disk drives (to find the matching sector so long as you knew on which track to look). That seems to be pretty unusual, though I've also seen it done by Electrologica in Holland in the mid 1960s. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
A couple other hints: Notepad++ or Notepadqq converts the feeds quite easily and I have found that on some Linux distros that you have to widen the Terminal Window or the license will truncate causing problems. Ray On Mon, Dec 17, 2018, 2:31 PM Mark Pizzolato DCL will handle the Stream file just fine AS LONG AS the file attributes > explicitly identify the correct Stream record attributes. DIR/FULL will > display the current record format. > > If the file was transferred in binary mode, it will likely end with "Fixed > length 512 byte records". Even if not, you should be able to set the > record format correctly with: > >$ set file/attribute=rfm:stmlf > Or >$ set file/attribute=rfm:stm > > - Mark > > On Dec 17, 2018 9:49 AM, Dave L wrote: > > the issue here tho is more that the license file is in fact a DCL script > and not input into LMF itself, and DCL doesn't handle the stream-LF files > it'll just barf on command line input too long... > > > > On Mon, 17 Dec 2018 17:40:04 -, Paul Koning > wrote: > > > > > > >> On Dec 17, 2018, at 12:29 PM, Clem Cole wrote: > >> > >> The problem is the license manager code you are running into is > >> expecting an RMS file, not a Stream I/O. In the old days, the idea of > >> 'access methods' was the natural ways OS's did I/O and RMS was VMS's > >> answer. Since today's programmers tend to have grown up with > >> C/C++/Java and stream I/O, you need to think in terms of a programming > >> 'Framework' that is inflicting some level structure on the file. > FWIW: > >> Stream style I/O and the STREAM-LF file format was added to VMS to > >> support VAX11/C, and normal programmers (correctly) started to avoid > >> RMS (it was funny how quickly the compiler runtime teams abandoned > RMS, > >> but I digress). But if the code was written assuming RMS (which was > >> all VMS had for many years), the files need RMS. > > > > That's odd, I thought that (on VMS) you didn't have any choice about > > using RMS. Well, not unless doing raw block I/O. > > > > Stream is one of the formats supported by RMS, exactly as fixed and > > variable records (with prefix length) are. Actually, stream comes in > > three flavors, depending on whether the record delimiter is LF, CR, or > > CR/LF. RMS-11 also supports these, FWIW. > > > > So unless license manager goes out of its way to enforce a particular > > record format for its input files, I would think it "should just work", > > RMS should read the on-disk format and deliver the records (lines) > > according to the encoding described by the file attributes. > > > > Finally, one suggestion was to transfer the file by cut & paste into a > > VMS editor; in that case the record format is chosen by the editor when > > creating the file, and the fact you're pasting from a Unix system is > not > > a factor. > > > >paul > > > > > > ___ > > Simh mailing list > > Simh@trailing-edge.com > > http://mailman.trailing-edge.com/mailman/listinfo/simh > > > -- > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > > > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
Clem Cole wrote: > In the old days, the idea of 'access > methods' was the natural ways OS's did I/O and RMS was VMS's answer. Using RMS as the primary way to do file access was dain bramage unique (at DEC) to VMS, no? Maybe some fancier versions of RSX-11M double plus good went that way afterwards Maybe it was DEC, sorry digital trying to go the IBM route (THIMK and all that) The logo went grey at about the time Jupiter was killed, and I certainly look at that as the beginning of the end (one company, one egg, one basket) of the transformation of a company run by engineers for engineers (not that KO had a clue that people wanted/needed computrons at home), but I suppose the seed may have been planted earlier when a number of IBM managers joined the company p ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
DCL will handle the Stream file just fine AS LONG AS the file attributes explicitly identify the correct Stream record attributes. DIR/FULL will display the current record format. If the file was transferred in binary mode, it will likely end with "Fixed length 512 byte records". Even if not, you should be able to set the record format correctly with: $ set file/attribute=rfm:stmlf Or $ set file/attribute=rfm:stm - Mark On Dec 17, 2018 9:49 AM, Dave L wrote: the issue here tho is more that the license file is in fact a DCL script and not input into LMF itself, and DCL doesn't handle the stream-LF files it'll just barf on command line input too long... On Mon, 17 Dec 2018 17:40:04 -, Paul Koning wrote: > > >> On Dec 17, 2018, at 12:29 PM, Clem Cole wrote: >> >> The problem is the license manager code you are running into is >> expecting an RMS file, not a Stream I/O. In the old days, the idea of >> 'access methods' was the natural ways OS's did I/O and RMS was VMS's >> answer. Since today's programmers tend to have grown up with >> C/C++/Java and stream I/O, you need to think in terms of a programming >> 'Framework' that is inflicting some level structure on the file. FWIW: >> Stream style I/O and the STREAM-LF file format was added to VMS to >> support VAX11/C, and normal programmers (correctly) started to avoid >> RMS (it was funny how quickly the compiler runtime teams abandoned RMS, >> but I digress). But if the code was written assuming RMS (which was >> all VMS had for many years), the files need RMS. > > That's odd, I thought that (on VMS) you didn't have any choice about > using RMS. Well, not unless doing raw block I/O. > > Stream is one of the formats supported by RMS, exactly as fixed and > variable records (with prefix length) are. Actually, stream comes in > three flavors, depending on whether the record delimiter is LF, CR, or > CR/LF. RMS-11 also supports these, FWIW. > > So unless license manager goes out of its way to enforce a particular > record format for its input files, I would think it "should just work", > RMS should read the on-disk format and deliver the records (lines) > according to the encoding described by the file attributes. > > Finally, one suggestion was to transfer the file by cut & paste into a > VMS editor; in that case the record format is chosen by the editor when > creating the file, and the fact you're pasting from a Unix system is not > a factor. > >paul > > > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh -- ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
From: Paul Koning Sent: Monday, December 17, 2018 12:40 That's odd, I thought that (on VMS) you didn't have any choice about using RMS. Well, not unless doing raw block I/O. That is how I recall it; it was RMS or else use ACP/XQIOP block I/O. Stream is one of the formats supported by RMS, exactly as fixed and variable records (with prefix length) are. Actually, stream comes in three flavors, depending on whether the record delimiter is LF, CR, or CR/LF. RMS-11 also supports these, FWIW. So unless license manager goes out of its way to enforce a particular record format for its input files, I would think it "should just work", RMS should read the on-disk format and deliver the records (lines) according to the encoding described by the file attributes. Inasmuch as I correctly recall all these arcana, it *should* just work. I'm guessing that the problem we're discussing is that the RMS format and attribute fields are not set correctly for the file's actual content; e.g., RMS thinks it's VAR-CR but there are nevertheless embedded LFs. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
the issue here tho is more that the license file is in fact a DCL script and not input into LMF itself, and DCL doesn't handle the stream-LF files it'll just barf on command line input too long... On Mon, 17 Dec 2018 17:40:04 -, Paul Koning wrote: On Dec 17, 2018, at 12:29 PM, Clem Cole wrote: The problem is the license manager code you are running into is expecting an RMS file, not a Stream I/O. In the old days, the idea of 'access methods' was the natural ways OS's did I/O and RMS was VMS's answer. Since today's programmers tend to have grown up with C/C++/Java and stream I/O, you need to think in terms of a programming 'Framework' that is inflicting some level structure on the file. FWIW: Stream style I/O and the STREAM-LF file format was added to VMS to support VAX11/C, and normal programmers (correctly) started to avoid RMS (it was funny how quickly the compiler runtime teams abandoned RMS, but I digress). But if the code was written assuming RMS (which was all VMS had for many years), the files need RMS. That's odd, I thought that (on VMS) you didn't have any choice about using RMS. Well, not unless doing raw block I/O. Stream is one of the formats supported by RMS, exactly as fixed and variable records (with prefix length) are. Actually, stream comes in three flavors, depending on whether the record delimiter is LF, CR, or CR/LF. RMS-11 also supports these, FWIW. So unless license manager goes out of its way to enforce a particular record format for its input files, I would think it "should just work", RMS should read the on-disk format and deliver the records (lines) according to the encoding described by the file attributes. Finally, one suggestion was to transfer the file by cut & paste into a VMS editor; in that case the record format is chosen by the editor when creating the file, and the fact you're pasting from a Unix system is not a factor. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh -- ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
> On Dec 17, 2018, at 12:29 PM, Clem Cole wrote: > > The problem is the license manager code you are running into is expecting an > RMS file, not a Stream I/O. In the old days, the idea of 'access methods' > was the natural ways OS's did I/O and RMS was VMS's answer. Since today's > programmers tend to have grown up with C/C++/Java and stream I/O, you need to > think in terms of a programming 'Framework' that is inflicting some level > structure on the file. FWIW: Stream style I/O and the STREAM-LF file format > was added to VMS to support VAX11/C, and normal programmers (correctly) > started to avoid RMS (it was funny how quickly the compiler runtime teams > abandoned RMS, but I digress). But if the code was written assuming RMS > (which was all VMS had for many years), the files need RMS. That's odd, I thought that (on VMS) you didn't have any choice about using RMS. Well, not unless doing raw block I/O. Stream is one of the formats supported by RMS, exactly as fixed and variable records (with prefix length) are. Actually, stream comes in three flavors, depending on whether the record delimiter is LF, CR, or CR/LF. RMS-11 also supports these, FWIW. So unless license manager goes out of its way to enforce a particular record format for its input files, I would think it "should just work", RMS should read the on-disk format and deliver the records (lines) according to the encoding described by the file attributes. Finally, one suggestion was to transfer the file by cut & paste into a VMS editor; in that case the record format is chosen by the editor when creating the file, and the fact you're pasting from a Unix system is not a factor. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
The problem is the license manager code you are running into is expecting an RMS file, not a Stream I/O. In the old days, the idea of 'access methods' was the natural ways OS's did I/O and RMS was VMS's answer. Since today's programmers tend to have grown up with C/C++/Java and stream I/O, you need to think in terms of a programming 'Framework' that is inflicting some level structure on the file. FWIW: Stream style I/O and the STREAM-LF file format was added to VMS to support VAX11/C, and normal programmers (correctly) started to avoid RMS (it was funny how quickly the compiler runtime teams abandoned RMS, but I digress). But if the code was written assuming RMS (which was all VMS had for many years), the files need RMS. [As my old friend and officemate Tom Teixera once said so wisely, it was not so bad that RMS had thousands of options, but the OS had to check every one of them on each operation]. Anyway, if you can, you might try: dir/full filespec command on another license file, looking at 'Record format' and 'Record attributes' fields in the results to give you a hint. On Mon, Dec 17, 2018 at 10:18 AM dave porter wrote: > > Probably nothing. The 'natural' format would have been > RMS VAR-CR records (if I recall the terminology) where > the line termination character is implicit rather than > being in the record data. > Pulling very old bits from the my brain's 'deep-freeze' memory, that sounds close - 'RMS VAR records', if the 'format' is 'Variable Length' I believe that there was originally a of 255 IIRC, becauses it stuffs a Pascal String (IBM 360 style) one byte record length before start of the data, but that may have been relaxed in later versions after I stopped dealing with VMS. If 'attributes' is 'Carriage return' then RMS will add the from earlier DEC OS's output, although it will not store them on disk like some systems did. > > STREAM-LF may work, but I assume the trick is to get > the record-type for the file to match what you've put > in the file. > Check out http://neilrieck.net/docs/openvms_notes_text_files.html ᐧ ᐧ ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
> I really don't want to have to enter all the licence data > interactively, or fix a couple of thousand line endings in the editor! > There must be SOME way of getting the file onto a new setup? > > Thanks for any assistance, > > Brian. As others have indicated, you need to install the licenses for UCX manually. I think that you might need to also install the VAX license but I'm not sure. Once that's there, you can use FTP to transfer the license file to the VAX as a text file. I wonder if you could just munge the date on the SIMH host machine so that the license is still valid. Either way, once you have the text file in the VAX, you need to fix the line ends. To do that, I use the VMS editor, EDIT LICENSE.TXT as follows: Prompt Keystroke(s) Explanation none F12 Enter command mode Command: REPLACE Enter the REPLACE command Old String: Used to enter control characters Press the key to be added: Enter CR as data Terminate the old string New String: Terminate the new string Replace? Type Yes, No, All, Last, or Quit: AReplace all instances Write new file and exit Now, rename the .TXT file to .COM and then do @filespec.com to execute it. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
From: Brian To: SIMH@trailing-edge.com Subject: [Simh] Transferring the licence file to the VAX emulator Maybe I've forgotten more about the VAX than I think. WHAT does it expect to see as a line terminator? Probably nothing. The 'natural' format would have been RMS VAR-CR records (if I recall the terminology) where the line termination character is implicit rather than being in the record data. STREAM-LF may work, but I assume the trick is to get the record-type for the file to match what you've put in the file. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
FWIW, I've been running simh for ages and periodically I forget to renew my hobbyist licenses before they expire. It happened again just last week. I usually go through the following song and dance routine in this scenario: 1. Get new hobbyist licenses in attached .COM file 2. Transfer from Windows (where my mail lives) to Linux (where everything fun occurs) 3. Run "dos2unix" to replace DOS line endings with Unix line endings 4. Working on side-by-side windows, find the "VAX-VMS" and "UCX" licenses in the file ... 5. ... and manually enter the LICENSE REGISTER and LICENSE LOAD commands on the VAX console 6. Use FTP to transfer the file from Linux to VMS (remember to use ASCII mode!!) 7. Execute the full script to load all of the other licenses (and harmlessly barf on the two you did manually) Cheers, Scott DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
Likely the issue is that the *nix system presents the text file as
stream-LF format which VMS won't understand as a standard text file which
it would expect to be CR-LF terminated records. VMS convert utility would
be able to fix that as already mentioned, tho you may need to tell it what
record format you want on the output file, can't recall now (or use an FDL
to define the output file format).
Alternatively you can just cut and paste from your host into the terminal
session to get the initial licenses set up and go from there, either
direct to the VMS prompt to action the commands or capture into a command
file ("$ copy TT: license.com" might work, then ctrl/Z when finished).
HTH
Dave
On Mon, 17 Dec 2018 14:02:24 -, Brian wrote:
On 12/17/18 8:44 AM, Wilm Boerhout wrote:
Brian schreef op 17-12-2018 om 14:28
[snip]
I really don't want to have to enter all the licence data
interactively, or fix a couple of thousand line endings in the editor!
There must be SOME way of getting the file onto a new setup?
Thanks for any assistance,
Brian.
What usually works for me:
* open the license command file file in your mail program / in a
notepad on your Linux host.
* Open a TPU editor session on your OPA0 simh console terminal
* Copy/Paste the License file text into the TPU editor window.
If you get buffer overflows on VMS, try it with just the TCP/IP
license (called UCX for hysterical reasons), then setup IP networking
and ftp on VMS.
OK, thanks, I'll give it a try later today and report back. If anybody
can tell me in simple terms, though, I would like to understand why
the route of going via an ISO didn't work. Is it not possible to
transfer text files to the VAX other than via cut-and-paste without
the line endings getting mangled?
Brian.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
--
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
I'm pretty sure I used VMS CONVERT to fix the licence file. Another easy way is to use FTP, if you have a server available. This is vaguely how I did it: Get an existing file that is a VMS text file: $ ANAL/RMS/FDL/OUTPUT=XYZ textfile This creates a file called XYZ.FDL that describes the records in the text file (just a typical text file). It needs to have lines as long as those in the file to be converted, or just edit XYZ.FDL to change the max record size. $ CONVERT/FDL=XYZ.FDL inputfile outputfile (the first being the file off your CD, and the second the converted version) My memory is hazy so you might have to fiddle a bit. On Mon, 17 Dec 2018 09:02:24 -0500 Brian wrote: > On 12/17/18 8:44 AM, Wilm Boerhout wrote: > > Brian schreef op 17-12-2018 om 14:28 > > > > [snip] > >> I really don't want to have to enter all the licence data > >> interactively, or fix a couple of thousand line endings in the > >> editor! There must be SOME way of getting the file onto a new > >> setup? > >> > >> Thanks for any assistance, > >> > >> Brian. > > > > What usually works for me: > > > > * open the license command file file in your mail program / in a > > notepad on your Linux host. > > * Open a TPU editor session on your OPA0 simh console terminal > > * Copy/Paste the License file text into the TPU editor window. > > > > If you get buffer overflows on VMS, try it with just the TCP/IP > > license (called UCX for hysterical reasons), then setup IP > > networking and ftp on VMS. > > > > OK, thanks, I'll give it a try later today and report back. If anybody > can tell me in simple terms, though, I would like to understand why > the route of going via an ISO didn't work. Is it not possible to > transfer text files to the VAX other than via cut-and-paste without > the line endings getting mangled? > > Brian. > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
Make iso image with license paks and attached it to SIMH. It worked great for me. Tim -Original Message- From: Simh On Behalf Of Brian Sent: Monday, December 17, 2018 9:02 AM To: SIMH Subject: Re: [Simh] Transferring the licence file to the VAX emulator On 12/17/18 8:44 AM, Wilm Boerhout wrote: > Brian schreef op 17-12-2018 om 14:28 > > [snip] >> I really don't want to have to enter all the licence data >> interactively, or fix a couple of thousand line endings in the editor! >> There must be SOME way of getting the file onto a new setup? >> >> Thanks for any assistance, >> >> Brian. > > What usually works for me: > > * open the license command file file in your mail program / in a >notepad on your Linux host. > * Open a TPU editor session on your OPA0 simh console terminal > * Copy/Paste the License file text into the TPU editor window. > > If you get buffer overflows on VMS, try it with just the TCP/IP > license (called UCX for hysterical reasons), then setup IP networking > and ftp on VMS. > OK, thanks, I'll give it a try later today and report back. If anybody can tell me in simple terms, though, I would like to understand why the route of going via an ISO didn't work. Is it not possible to transfer text files to the VAX other than via cut-and-paste without the line endings getting mangled? Brian. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
On 12/17/18 8:44 AM, Wilm Boerhout wrote: > Brian schreef op 17-12-2018 om 14:28 > > [snip] >> I really don't want to have to enter all the licence data >> interactively, or fix a couple of thousand line endings in the editor! >> There must be SOME way of getting the file onto a new setup? >> >> Thanks for any assistance, >> >> Brian. > > What usually works for me: > > * open the license command file file in your mail program / in a > notepad on your Linux host. > * Open a TPU editor session on your OPA0 simh console terminal > * Copy/Paste the License file text into the TPU editor window. > > If you get buffer overflows on VMS, try it with just the TCP/IP > license (called UCX for hysterical reasons), then setup IP networking > and ftp on VMS. > OK, thanks, I'll give it a try later today and report back. If anybody can tell me in simple terms, though, I would like to understand why the route of going via an ISO didn't work. Is it not possible to transfer text files to the VAX other than via cut-and-paste without the line endings getting mangled? Brian. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Transferring the licence file to the VAX emulator
Brian schreef op 17-12-2018 om 14:28 [snip] I really don't want to have to enter all the licence data interactively, or fix a couple of thousand line endings in the editor! There must be SOME way of getting the file onto a new setup? Thanks for any assistance, Brian. What usually works for me: * open the license command file file in your mail program / in a notepad on your Linux host. * Open a TPU editor session on your OPA0 simh console terminal * Copy/Paste the License file text into the TPU editor window. If you get buffer overflows on VMS, try it with just the TCP/IP license (called UCX for hysterical reasons), then setup IP networking and ftp on VMS. /Wilm ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] Transferring the licence file to the VAX emulator
Hi all, Please bear with me for what I'm sure is a beginner question, but it has me beat. :( I've set up SIMH, built it all, got my kits for OpenVMS and have installed the system. So far, so good. The problem I'm having is in getting the licence file I received under the Hobbyist scheme onto the VAX. I had thought that 'burning' it into an ISO on my Linux box and then mounting that image would work. It does, but not completely. According to the e-mail, the licence file is in the form of a VMS command file. On my Linux box, this looks just fine. However, irrespective of whether I use Linux or Windows line endings, when I transfer the file onto the VAX as above, all the lines run together and the file format is trashed. If I edit the file on the VAX, I can see the LF or CR/LF characters in the editor, just as they should be. Maybe I've forgotten more about the VAX than I think. WHAT does it expect to see as a line terminator? If I know, then I can fix the file on my Linux box and transfer it over again, but if neither Linux nor Windows line endings work, I've no idea what I need to try. Or am I missing something, and there's some fundamental flaw with the whole idea of transferring text files via an ISO image? I really don't want to have to enter all the licence data interactively, or fix a couple of thousand line endings in the editor! There must be SOME way of getting the file onto a new setup? Thanks for any assistance, Brian. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
