INFO-VAX Mon, 27 Aug 2007 Volume 2007 : Issue 470 Contents: Re: Alan Winston, when are you correcting your WASD book? Re: Alan Winston, when are you correcting your WASD book? Re: Alan Winston, when are you correcting your WASD book? Re: Alan Winston, when are you correcting your WASD book? Re: Alan Winston, when are you correcting your WASD book? Can't copy compressed savesets to tape Re: COBOL Transactions? Re: COBOL Transactions? Re: COBOL Transactions? Re: COBOL Transactions? Re: COBOL Transactions? Re: COBOL Transactions? Re: COBOL Transactions? RE: COBOL Transactions? Re: COBOL Transactions? RE: COBOL Transactions? Re: COBOL Transactions? Re: DECnet-Plus for a hobbyist Re: DECnet-Plus for a hobbyist Re: Here's one for Bob (hope it makes your head spin) Re: Here's one for Bob (hope it makes your head spin) Re: Here's one for Bob (hope it makes your head spin) Re: Here's one for Bob (hope it makes your head spin) Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question Re: Itanium Port Question ---------------------------------------------------------------------- Date: Mon, 27 Aug 2007 17:41:54 +0930 From: Mark Daniel Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: <13d51rcd6pl6b59@corp.supernews.com> Steven M. Schweda wrote: > From: Mark Daniel > >>Larry Kilgallen wrote: >> >>>In article <07082521421814_2022C7FA@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: >>> >>> >>>>From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) >>>> >>>> >>>>>>>$ unzip "-v" htrootxxx.zip >>>>>>>$ unzip "-v" opensslwasdxxxx >>>>>>> >>>>>>>well, it should read >>>>>>> >>>>>>>$ unzip "-v" htrootxxx.zip >>>>>>>$ set def [.ht_root] >>>>>>>$ unzip "-v" [-]opensslwasdxxx >>>> >>>> My question would be, 'Why the quotation of "-v"?' I can see why >>>>"-V" might need quotation, but not "-v". >>> >>>Absent quotation marks, DCL will upcase letters. >> >>The C-RTL complicates that by ensuring the command-line arguments passed >>to main() have been lower-cased hence quoting preserves upper-case. > > > In fact, newer C RTL versions can be made to do pretty much anything > you want, as shown below. > > >>>Thus -v or -V will be seen by the program as -V. >>> >>>I don't know what -v or -V means, and I try to avoid using programs >>>that do not "speak" DCL, but that is how character processing works >>>on a vanilla VMS account. > > > The Info-ZIP programs offer optional CLI front-ends for the > hyphen-challenged. > > >>As the original context was a WASD related posting ... >> >> $ UNZIP -H >> >>describes it as >> >> -V retain VMS version numbers >> >>in contrast to >> >> -v list verbosely/show version info >> >>while >> >> $ ZIP -H >> >>describes it more accurately >> >> "-V" save VMS file attributes > > > AIEEEE!!! "zip -h" describes Zip (more or less) accurately, while > "unzip -h" describes UnZip (more or less) accurately. The "-V" options > for the two programs do different things, which is the primary reason > that the descriptions in the two help reports are different. > > >>So the "-V" is specified by the WASD install instructions ensures the >>original file attributes stored when ZIPed using "-V" are reflected in >>the files created by the UNZIP. The quotes are required to preserve the >>upper-case of the option. > > > No, and no. The "-v" adds verbosity to UnZip, and never needs > quotation. What upper-case option? "-V" would cause UnZip to restore > VMS version numbers (if they were stored in the archive, typically as a > result of using "zip -w") when it extracts files from the archive. When > VMS file attributes are stored in an archive, typically as a result of > using 'zip "-V"', _no_ special UnZip command-line options are needed to > get the attributes restored when the files are extracted on a VMS > system. That is, in general, all you need to do is: > > zip "-V" archive.zip file_spec > unzip archive.zip ! No "-V'. No "-v". > > As for case, when in doubt, ask the program(s). On a VAX, or on a > non-VAX system with SET PROCESS /PARSE_STYLE = TRADITIONAL: > > alp $ zip -v > Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license. > This is Zip 2.32 (June 19th 2006), by Info-ZIP. > [...] > > alp $ zip "-v" > Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license. > This is Zip 2.32 (June 19th 2006), by Info-ZIP. > [...] > > alp $ zip -V > Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license. > This is Zip 2.32 (June 19th 2006), by Info-ZIP. > [...] > > alp $ zip "-V" > > zip error: Invalid command arguments (cannot write zip file to terminal) > > Here, '-v', '"-v"', and '-V' are equivalent, while '"-V"' is different. > > On a (non-VAX) system with SET PROCESS /PARSE_STYLE = EXTENDED: > > alp $ zip -v > Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license. > This is Zip 2.32 (June 19th 2006), by Info-ZIP. > [...] > > alp $ zip "-v" > Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license. > This is Zip 2.32 (June 19th 2006), by Info-ZIP. > [...] > > alp $ zip -V > > zip error: Invalid command arguments (cannot write zip file to terminal) > > alp $ zip "-V" > > zip error: Invalid command arguments (cannot write zip file to terminal) > > Here, command-line case is preserved (as if by magic). (Or, as if by > using DECC$ARGV_PARSE_STYLE.) With versions older than UnZip 5.52 and > Zip 2.32, SET PROCESS /PARSE_STYLE may have no effect, but that doesn't > change the (lack of) need to quote '-v'. > > Now, if you _want_ what 'unzip -v' does, it's ok with me, but it > seems unlikely, and, in any case, you should never need to quote '-v'. > If your reality differs from mine, feel free to demonstrate. Cheese. I don't think I'm built of stern-enough stuff to take even a small serve like this. I'm going to take my "-V" and go home. > ------------------------------------------------------------------------ > > Steven M. Schweda sms@antinode-org > 382 South Warwick Street (+1) 651-699-9818 > Saint Paul MN 55105-2547 Seriously ... could this have been discovered without asking someone or examining the code-base? I can only assume this is not common knowlege because I'm sure someone would have pointed it out in over a decade of WASD distribution. Of course it's really so trivial that nobody might bother. But then the trivial is often grist to the c.o.v. mill :-) So, as I'm uninterested in versions and am interested in file attributes, I can take the "-V" out of the archive restore instructions and rely on using it at archive creation. Thanks. -- Boris: Isn't all mankind ultimately executed for a crime it never committed? The difference is that all men go eventually, but I go six o'clock tomorrow morning. I was supposed to go at five o'clock, but I have a smart lawyer. Got leniency. [Woody Allen; Love and Death] ------------------------------ Date: 27 Aug 2007 11:33:49 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: <5jfr4tF3tvmitU1@mid.individual.net> In article <13d3pv3rp0rnd3c@corp.supernews.com>, Mark Daniel writes: > Larry Kilgallen wrote: >> In article <07082521421814_2022C7FA@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: >> >>>From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) >>> >>> >>>>>>$ unzip "-v" htrootxxx.zip >>>>>>$ unzip "-v" opensslwasdxxxx >>>>>> >>>>>>well, it should read >>>>>> >>>>>>$ unzip "-v" htrootxxx.zip >>>>>>$ set def [.ht_root] >>>>>>$ unzip "-v" [-]opensslwasdxxx >>> >>> My question would be, 'Why the quotation of "-v"?' I can see why >>>"-V" might need quotation, but not "-v". >> >> >> Absent quotation marks, DCL will upcase letters. > > The C-RTL complicates that by ensuring the command-line arguments passed > to main() have been lower-cased hence quoting preserves upper-case. > Can't blame that in C's Unix heritage. On Unix it would have been left alone, as it should be!! :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 27 Aug 2007 07:36:27 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: In article , Kilgallen@SpamCop.net (Larry Kilgallen) writes: > > Absent quotation marks, DCL will upcase letters. Absent quotation marks, the C RTL will lowercase them, thus "-V" needs to be quoted and not "-v", unless features introduced several years ago are employed, causing C code to get the original case. ------------------------------ Date: Mon, 27 Aug 2007 11:06:16 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: <07082711061629_20230F60@antinode.org> From: Mark Daniel > Seriously ... could this have been discovered without asking someone or > examining the code-base? I can only assume this is not common knowlege > because I'm sure someone would have pointed it out in over a decade of > WASD distribution. Of course it's really so trivial that nobody might > bother. But then the trivial is often grist to the c.o.v. mill :-) VMS-related Info-ZIP documentation has been, I'd say, somewhat deficient, which has led me to rewrite some of it, and add more to it. Sadly, the bulk of the change affects versions which will follow the current released versions (UnZip 6.0, Zip 3.0). It may be possible to extract all the facts from the current docs, but I doubt it. However, the "-h" info is essentially correct. As for "common knowledge", it seems that over time, a myth has evolved which says that you want to use "-V" with UnZip if you used it with Zip. It's not (and never was) true, it's not (and never was) documented that way, but the belief persists. "Commonly held" and "True" are not synonymous. > So, as I'm uninterested in versions and am interested in file > attributes, I can take the "-V" out of the archive restore instructions > and rely on using it at archive creation. Sounds right to me. (Only one way to find out.) Life is _so_ educational. (I hate educational.) I assume that when the next editions of the Info-ZIP programs emerge, everyone here will be scouring the documentation, searching for problems, and suggesting improvements. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Mon, 27 Aug 2007 10:58:45 -0600 From: Mark Berryman Subject: Re: Alan Winston, when are you correcting your WASD book? Message-ID: <46d2a056$1@mvb.saic.com> Mark Daniel wrote: > Larry Kilgallen wrote: > >> In article <07082521421814_2022C7FA@antinode.org>, sms@antinode.org >> (Steven M. Schweda) writes: >> >>> From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central >>> Computing) >>> >>> >>>>>> $ unzip "-v" htrootxxx.zip >>>>>> $ unzip "-v" opensslwasdxxxx >>>>>> >>>>>> well, it should read >>>>>> >>>>>> $ unzip "-v" htrootxxx.zip >>>>>> $ set def [.ht_root] >>>>>> $ unzip "-v" [-]opensslwasdxxx >>> >>> >>> My question would be, 'Why the quotation of "-v"?' I can see why >>> "-V" might need quotation, but not "-v". >> >> >> >> Absent quotation marks, DCL will upcase letters. > > > The C-RTL complicates that by ensuring the command-line arguments passed > to main() have been lower-cased hence quoting preserves upper-case. > >> Thus -v or -V will be seen by the program as -V. >> >> I don't know what -v or -V means, and I try to avoid using programs >> that do not "speak" DCL, but that is how character processing works >> on a vanilla VMS account. > > > As the original context was a WASD related posting ... > > $ UNZIP -H > > describes it as > > -V retain VMS version numbers > > in contrast to > > -v list verbosely/show version info > > while > > $ ZIP -H > > describes it more accurately > > "-V" save VMS file attributes > > So the "-V" is specified by the WASD install instructions ensures the > original file attributes stored when ZIPed using "-V" are reflected in > the files created by the UNZIP. The quotes are required to preserve the > upper-case of the option. That would not be correct. -V is used by ZIP to preserve file attributes. It has an entirely different meaning in UNZIP (where it means to preserve version numbers). Preserving file attributes is controlled entirely by the ZIP file creation process. If the attributes are saved, they will be restored by UNZIP. No switch in UNZIP is required to (or can) cause this. Quoting switches to preserve case is required only in fairly ancient versions of VMS. I haven't quoted unix-style arguments for a number of years now. Mark Berryman ------------------------------ Date: Mon, 27 Aug 2007 13:25:41 -0400 From: "Scott Greig" Subject: Can't copy compressed savesets to tape Message-ID: Hello all: Whenever I try to copy a compressed saveset to tape (using COPY) I get: $ copy nv.bck mka600:/log %COPY-E-OPENOUT, error opening MKA600:[SCOTT.CLIENTS.DND]NV.BCK;1 as output -RMS-E-CRE, ACP file create failed -SYSTEM-F-BADATTRIB, bad attribute control list %COPY-W-NOTCOPIED, DISK$USER:[SCOTT.CLIENTS.DND]NV.BCK;1 not copied I've dumped the saveset, and all records are longer than 14 bytes. Any ideas about what's wrong? Scott ------------------------------ Date: 27 Aug 2007 12:07:05 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: COBOL Transactions? Message-ID: <5jft38F3u0ul3U1@mid.individual.net> In article <8a9c4$46cf7205$cef8887a$6008@teksavvy.com>, JF Mezei writes: > Bill Gunshannon wrote: >> RMS may be great at what it does but for a very large number of tasks >> it is just overhead. > > Before you declare RMS "overhead", you would need to look into the code > that allows you to read "lines" of text in Unix (fgets for instance). > > VMS doesn't need to scan the data for cr/lfs, it looks at the 2 byte > record header and knows exactly how many bytes of data are in that record. OK, Let's look at some pseudo-code. Unix: while (char != newline) read(char); RMS: Index= Record_Length; for (i = 1 to Record_Length) read(char); Not sure how you measure overhead, but the Unix solution only requires one compare per character. The RMS requires a Load and then a math operation per character. (The math operation could be an increment or a decrement but the code fragment still ends out being more for the RMS solution.) > > > And when you look at the many Unix/windows applications that work only > on sequential files, Could that be because they were designed to work on sequential files? I have written applications that used ISAM and direct access in C on Unix. I have written programs on Unix in other languages that worked with all different file types. > many end up reading the whole file in memory and > the scanning in memory (but that in the end results in a lot of paging > to the pagefile). You mean like EMACS which I would bet does exactly the same thing on VMS that it does on Unix and every other OS it runs on. > Also, whenever you change a preference, it has to > rewrite the whole config file instead of just changing one record. Depends on what you mean by a "config file" and how the programmer set it up to work. In most cases, because the files are small the fastest way to do it is to read the whole file into memory, change it, and write it back out. Doesn't mean it can't be done otherwise, but another part of the Unix paradigm is KISS. Why make any task more complicated than is absolutely necessary? > And > this has interesting consequences in a multi-user system due to file > locking and other processes that may have the cofig file already in > memory when when they update their configs, they will overwrite > previously modified files without the changes that had been made by > other processes. Again, what do you mean by "config files"? Why are multiple people changing them at the same time? And why do you think file locking won't prevent that problem from occuring? People here seem to think that Unix is at about the same state of development as CPM. Just because Unix does it different and you don't like the Unix way, doesn't mean it's wrong. I think the industry has pretty much spoken on this. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 27 Aug 2007 12:14:17 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: COBOL Transactions? Message-ID: <5jftgpF3u0ul3U2@mid.individual.net> In article <46CF8605.7080709@comcast.net>, "Richard B. Gilbert" writes: > Bill Gunshannon wrote: >> In article , >> John Santos writes: >> >>>Bob Koehler wrote: >>> >>>>In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>>> >>>> >>>>>I have never used RMS on VMS. >>>>>explicitly. I can't think of anything I have done that actually >>>>>needed it. >>>> >>>> >>>> You only program in C,C++,Java and you never view your files on a >>>> terminal (type or edit) or printer? You never perused a directory? >>>> >>>> Yes, those can be done without RMS, UNIX and DOS are examples. As >>>> long as someone provided the missing component somewhere. Your >>>> terminal and printer didn't come out of the box thinking LF implied >>>> CR, although some hardware is settable to provide that. >>>> >>> >>>Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-) >> >> >> I login to lots of systems everyday without the help of RMS. Tell me again >> why it is "needed" for this task? >> >> RMS may be great at what it does but for a very large number of tasks >> it is just overhead. >> >> bill >> > > RMS is "needed" to access an Indexed Sequential file! In Unix you have > to do a sequential search of /etc/passwd and/or /etc/shadow to find the > user name. It's no problem if you have ten or fifteen users. If you > have 1500 users it could get a little slow. I have one server here with 2556 users (and that number goes up at the rate of 400-600 every semester with the top likely to be close to 8000). I can't measure the amount of time it takes to access an entry in the password file as it happens instantly. Guess it depends on your concept of slow. > > > User authorization is one of those applications that does not really > lend itself to sequential access! Works fine on Unix. Even with the added overhead of Radius my PC users can login just as fast using authorization from a Unix server than they can using local accounts on the PC itself. Being as the whole system was revamped about the time they added shadow password files if this really were seen as a problem I am sure it would have been re-done. Apparently it is only the outsiders who see this as a pot4ential problem. Go figure. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 27 Aug 2007 07:24:38 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: COBOL Transactions? Message-ID: In article , Ron Johnson writes: > > VMS83$IPL is a perfectly adequate name. No need to change! > IPL is certainly a term inherited from IBM mainframes. $ is reserved to registered facilities to prevent future conflicts. ------------------------------ Date: 27 Aug 2007 07:32:38 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: COBOL Transactions? Message-ID: In article , "P. Sture" writes: > > Does that imply that they ported RMS to Tru64? If left to themselves DEC engineers might have eventually figured out that separate and not completely compatable RMS were in the COBOL and other language libraries, and like they did for TOPS-20 replace those with a single common RMS. But I think DEC died while digital UNIX was just an updated BSD with whatever was inheritted from OSF in this area. After renaming it Tru64, Compaq showed no real initiative along UNIX lines until Curly decided he'd rather sell HP-UX. ------------------------------ Date: 27 Aug 2007 08:04:11 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: COBOL Transactions? Message-ID: In article , Ron Johnson writes: > > Autologin? Isn't that... insecure? Autologin depends in large part on physical security, and can be used to enhance the security of a system since it pretty much prevents any other username for using the terminal. ------------------------------ Date: 27 Aug 2007 08:12:22 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: COBOL Transactions? Message-ID: In article <5jft38F3u0ul3U1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > > OK, Let's look at some pseudo-code. > > Unix: > > while (char != newline) read(char); > > RMS: > > Index= Record_Length; > for (i = 1 to Record_Length) read(char); > > Not sure how you measure overhead, but the Unix solution only requires > one compare per character. Guesss again. Both UNIX and VMS read and write disk sectors. The overhead is in finding out what part of the sector the user want's in the user buffer. To find the length, for any stream file system, whether UNIX, DOS, or stream files in RMS, it's like: for (length = 0; buffer[length] != newline; length++); For RMS doing variable length records you were right that you started out with the record length, no work need be done! ------------------------------ Date: Mon, 27 Aug 2007 13:56:51 +0000 From: "Paul Raulerson" Subject: Re: COBOL Transactions? Message-ID: ----=_vm_0011_W2237418621_7431_1188223011 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >OK, Let's look at some pseudo-code. > >Unix: > >while (char != newline) read(char); > >RMS: > >Index= Record_Length; >for (i = 1 to Record_Length) read(char); A slighty better comparison might be: Unix: while (c=fgetc(fp) != "\n") { line[counter++] = c; } RMS: counter = fread(&recsize,1,2,fp); counter = fread(&line,1,recsize,fp); Given that you can use buffered stream calls for either one, they are >roughly< equivalent, but only roughly. The RMS like processing is going to to be slighlty more efficient, and that can be telling in situations with a lot of I/O. Function calls are efficient, but they do execute a lot of instructinos. And of course, both solutions have a little overhead for setup. The UNIX solution probably ties up more registers and/or stack areas, so there are also more loads and saves than in the RMS solution. -Paul ----=_vm_0011_W2237418621_7431_1188223011-- ------------------------------ Date: Mon, 27 Aug 2007 15:15:00 +0000 From: "Main, Kerry" Subject: RE: COBOL Transactions? Message-ID: > -----Original Message----- > From: Paul Raulerson [mailto:paul@raulersons.com] > Sent: August 27, 2007 9:57 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: COBOL Transactions? > > >OK, Let's look at some pseudo-code. > > > >Unix: > > > >while (char !=3D newline) read(char); > > > >RMS: > > > >Index=3D Record_Length; > >for (i =3D 1 to Record_Length) read(char); > > A slighty better comparison might be: > > Unix: > while (c=3Dfgetc(fp) !=3D "\n") { > line[counter++] =3D c; > } > > RMS: > counter =3D fread(&recsize,1,2,fp); > counter =3D fread(&line,1,recsize,fp); > > Given that you can use buffered stream calls for either one, > they are >roughly< equivalent, but only roughly. The RMS like > processing is going to to be slighlty more efficient, and that > can be telling in situations with a lot of I/O. Function calls > are efficient, but they do execute a lot of instructinos. > > And of course, both solutions have a little overhead for setup. > The UNIX solution probably ties up more registers and/or stack areas, > so there are also more loads and saves than in the RMS solution. > > -Paul Well, since we are talking about password files as an example, being a flat= text file, how do multiple end users (self pwd reset) and/or help desk support types all u= pdate the same pwd file concurrently in the UNIX world? Is there a utility like Authorize that maintains concurrent accesses? And forgive my na=EFve question, and I am sure there is a simple answer, bu= t does one also not have to worry about file corruption and/or stale data in a flat file when m= ultiple users / support types are updating the pwd file at the same time? Thx Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: 27 Aug 2007 15:41:33 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: COBOL Transactions? Message-ID: <5jg9ldF3u4gi6U1@mid.individual.net> In article , "Main, Kerry" writes: >> -----Original Message----- >> From: Paul Raulerson [mailto:paul@raulersons.com] >> Sent: August 27, 2007 9:57 AM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Re: COBOL Transactions? >> >> >OK, Let's look at some pseudo-code. >> > >> >Unix: >> > >> >while (char != newline) read(char); >> > >> >RMS: >> > >> >Index= Record_Length; >> >for (i = 1 to Record_Length) read(char); >> >> A slighty better comparison might be: >> >> Unix: >> while (c=fgetc(fp) != "\n") { >> line[counter++] = c; >> } >> >> RMS: >> counter = fread(&recsize,1,2,fp); >> counter = fread(&line,1,recsize,fp); >> >> Given that you can use buffered stream calls for either one, >> they are >roughly< equivalent, but only roughly. The RMS like >> processing is going to to be slighlty more efficient, and that >> can be telling in situations with a lot of I/O. Function calls >> are efficient, but they do execute a lot of instructinos. >> >> And of course, both solutions have a little overhead for setup. >> The UNIX solution probably ties up more registers and/or stack areas, >> so there are also more loads and saves than in the RMS solution. >> >> -Paul > Well, since we are talking about password files as an example, being a > flat text file, how do multiple end users (self pwd reset) and/or help > desk support types all update the same pwd file concurrently in the > UNIX world? Assuming no one is cheating by directly accessing the password file locking takes care of all that, as you wuold expect. > Is there a utility like Authorize that maintains concurrent accesses? There are a few programs involved all of which do differnt things and all of which are aware of each other and know about locks. > And forgive my naïve question, and I am sure there is a simple answer, > but does one also not have to worry about file corruption and/or stale > data in a flat file when multiple users / support types are updating the > pwd file at the same time? Being a flat file has nothing to do with it. The same problems exist in direct access and indexed files. The same can exist in a database. It is all of matter of how the updates are being done. If I (as root) use vi to edit the password file then the other applications (like passwd which is how the usera change their password) will not be aware of my screwing with the file and the results may be detrimental to good system operations. :-) If the right tools are used, there are no problems and no corruptionr or race conditions will develop. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 27 Aug 2007 12:27:39 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: RE: COBOL Transactions? Message-ID: In article , "Main, Kerry" writes: > > Well, since we are talking about password files as an example, being a flat= > text file, how > do multiple end users (self pwd reset) and/or help desk support types all u= > pdate the same > pwd file concurrently in the UNIX world? There are a variety of ways to lock files. Unlike VMS files are not locked by default. You have the problem of getting all utilities to use the same lock name, and the problem of getting all utilities to use the same locking mechanism. Of course in VMS since the file system locks files by default everyone is going through the same code and uses the same lock. If you setup a shareable file and use RMS to coordinate record access then everyone goes the same code and uses the same lock. But in UNIX you best be off fnding out what happens to be the convention on the particular file before you write a utility to mess with it, or choose a utility that was written for some other purpose. ------------------------------ Date: Mon, 27 Aug 2007 17:54:48 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: COBOL Transactions? Message-ID: In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >In article , > Kilgallen@SpamCop.net (Larry Kilgallen) writes: >> In article , "Paul Raulerson" writes: >> >>> COBOL (and I assume PL/I :) running under UNIX has to supply a record ori= >>> ented file system layered over the UNIX filesystem. >> >> As do Ada implementations. >> >> There is a distinct problem with an operating system written by folks >> who think the lowest common denominator programming language is the >> only one. > >Once again, don't assume your worldview is the only one. The entire >paradigm underlying Unix was "The Software Tools" paradigm in which >things are reduced to their simplest form and complexity is created >by adding layers. Thus the "pipe" concept as used by things like >troff which required other utilities like col, eqn, greek and tbl >in order to create more complex documents. > >C-ISAM was around and available for Unix since at least the early to >mid 80's. I first used a database and COBOL on Unix in the mid 80's. >One advantage to the Unix paradigm is you don't end out paying for >features you neither need nor want. I have never used RMS on VMS. >explicitly. I can't think of anything I have done that actually >needed it. And don't say "you don't pay for it because it is >bundled in" because you pay for everything that comes with the system >wether it is listed on the invoice or not. > By that argument Unix should not come bundled with a TCPIP stack or Sendmail etc etc David Webb Security team leader CCSS Middlesex University >bill > >-- >Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves >bill@cs.scranton.edu | and a sheep voting on what's for dinner. >University of Scranton | >Scranton, Pennsylvania | #include ------------------------------ Date: 27 Aug 2007 07:18:36 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DECnet-Plus for a hobbyist Message-ID: In article , "Robert Jarratt" writes: > > I successfully ran DVSCONFIG.COM to configure the DECserver firmware > download, but the DECserver fail to download it. I am having other console > issues with the DECserver so I don't know if it works, but it may be that > there is something else that I have to start on the VMS side, what do I need > to check is running? This is VMS 7.3. And this is the output of SH SYS: From following this thread, I think you now have DECnet Phase IV up and have configured the MOP protocol using DSVCONFIG. There are two things you can look for: In NCP, verify that the ethernet circuit shows "service = enabled", if not the define and set it to enabled. The default OPCOM settings are pretty noisy, but good for debugging this issue. Enable an operator's terminal and/or look in operator.log . (Those of us using DECnet Phase V have entirely different default noise going into OPCOM.) ------------------------------ Date: 27 Aug 2007 07:20:09 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DECnet-Plus for a hobbyist Message-ID: In article , "Robert Jarratt" writes: > > So what happens if I use an SCSSYSTEMID of 1025 and then I set a DECnet > address of 1.2 (say)? If you have clustering on then the hardware address set during boot will prevent DECnet from starting. If you don't have clustering on the hardware address might not be changed before DECnet gets to it, I don't recall ever trying that. ------------------------------ Date: 27 Aug 2007 07:43:30 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: In article <1188044051.913796.228860@r23g2000prd.googlegroups.com>, Neil Rieck writes: > > Talk to anyone who was an adult during World War 2 and you'll find > that many common folk were anti-Semitic even though they called > themselves Christians. (The people telling you these facts will always > tell you it was the other guy). Today, anyone who holds anti-Semitic > biases is usually considered backwards. Yes, and in North America today Christians are accepted fairly well even if they are of slightly different denominations and Jews are considered OK, let them get by. But there are still a great many people who don't really want religious freedom. Note the protest staged when a Muslim was allowed to open a session of Congress and the lack of condemnation of the protesters. Once upon a time Jews and Catholics were both outcasts in the American colonies; these days had anyone protested a Preist or a Rabbi opening a session of Congress there would have been much to do about it. ------------------------------ Date: 27 Aug 2007 07:46:53 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: In article , Dirk Munk writes: > > The Western allieds knew all to well what was going on in Auschwitz, but > they never tried to bomb the gas chambers etc. You wanted to save the Jews in Auschwitz by dropping bombs on them? Bombing accuracy at that time was not sufficient to isolate the gas chambers from the surrounding camp, mostly filled with prisoners in forced labor. ------------------------------ Date: 27 Aug 2007 07:49:05 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: In article , Dirk Munk writes: > > Keep in mind the way Auschwitz worked. A train came in, and the majority > of the people on the train were murdered the same day. Even if bombing > the railroad and the gaschambers would have killed prisoners etc. , it > would have stopped the mass murder. Bombing the fuel plants also killed > al lot of prisoners. And I doubt if Auschwitz was defended by FLAK, so > the bombers could have made a low altitude attack. I think the Nazi's would have reacted by opening fire on the remaining prisoners, and sending further victims to other deaths. Taking out the gas chambers would not be sufficient to stop them. ------------------------------ Date: 27 Aug 2007 13:01:22 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Here's one for Bob (hope it makes your head spin) Message-ID: <5jg092F3u66a0U1@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , Dirk Munk writes: >> >> The Western allieds knew all to well what was going on in Auschwitz, but >> they never tried to bomb the gas chambers etc. > > You wanted to save the Jews in Auschwitz by dropping bombs on them? > Bombing accuracy at that time was not sufficient to isolate the gas > chambers from the surrounding camp, mostly filled with prisoners in > forced labor. Armed-chair Generals are amazing. So many keep trying to second-guess Vietnam and Iraq and yet even 60 years after the fact and with all of the necessary data published they can't even understand WWII. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Mon, 27 Aug 2007 04:36:46 -0700 From: FrankS Subject: Re: Itanium Port Question Message-ID: <1188214606.109402.87580@w3g2000hsg.googlegroups.com> On Aug 26, 8:45 pm, "Paul Raulerson" wrote: > Are you saying the compile does not pad that out correctly? That should not > be a problem in COBOL so far as I know. By default, the HP COBOL compiler does not insert padding into a data structure in order to align all the elementary data items. You can read the HP COBOL User's Manual for all the gory details of how the / ALIGNMENT qualifier and/or compiler directives are used to modify this behavior. Having done a number of migrations to OpenVMS from other platforms, and ported applications from VAX to Alpha, I can tell you that the default is really appropriate. Particularly in those cases where data structures are written directly to an RMS file where disk space was at a premium (old thinking since disk is relatively inexpensive now, but I've been at this for a long time). ------------------------------ Date: Mon, 27 Aug 2007 20:10:37 +0800 From: "Richard Maher" Subject: Re: Itanium Port Question Message-ID: Hi Frank, > There comes a point where the compiler writers need > to stop being the data police for users that don't do their own > performance analysis. /OPTIMIZE must really do your head in hey? Cheers Richard Maher "FrankS" wrote in message news:1188174360.239654.298340@o80g2000hse.googlegroups.com... > On Aug 26, 8:04 pm, "Richard Maher" > wrote: > > Forgot to mention that COBOL, like all other compilers, has the /alignment > > qualifiers if you're happy for it to pad 3 bytes between data_item_1 and > > data_item_3. > > >From a porting perspective, though, I would expect the default > qualifiers (no alignment) would be used, particularly if data > structures are being used to read/write from files that already > exist. That is, if files already exist with records that were not > padded then the /ALIGNMENT qualifier wouldn't come into play. (Yes, > yes, I know you can use compiler directives to selectively align > structures. That's getting way off stream from the question of > whether or not alignment faults are more likely to occur in Macro .vs. > COBOL.) > > I'm aware that the compiler will generate instructions to manipulate > bytes within an aligned quadword, but I didn't think it would generate > instructions to manipulate all data items so that alignment faults are > always avoided. There comes a point where the compiler writers need > to stop being the data police for users that don't do their own > performance analysis. > ------------------------------ Date: 27 Aug 2007 07:58:10 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Itanium Port Question Message-ID: In article , Evert van Dijken writes: > Depends on you programming language, Only macro needs to be rewritten. Most macro does not need to be rewritten. Especially if its Macro-32 that already been ported from VAX to Alpha, the Itanium Macro-32 compiler should be able to handle it. ------------------------------ Date: 27 Aug 2007 08:00:09 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Itanium Port Question Message-ID: In article , "Tom Linden" writes: > On Sun, 26 Aug 2007 17:50:13 -0700, Richard B. Gilbert > wrote: > >> Alignment faults are basically caused by how you arrange and declare >> your structures. This was a problem long before there was a VAX or >> VMS. We worried about it in IBM/360 Fortran IV. If you failed to put >> your REAL*8 variables first in your COMMON blocks, you could get >> alignment faults. Fixing them up slowed execution and the machines of >> yesteryear were slow to begin with. Doing anything to make them slower >> was anathema!! >> > IIRC, PL/I on 360 didn't have that problem, afterall it was a byte > addressable > machine, as is the VAX. FORTRAN-H Extended Enhanced for the 360 and 370 would point out alignment problems, but generate the code anyhow. ------------------------------ Date: Mon, 27 Aug 2007 13:27:48 -0400 From: John Reagan Subject: Re: Itanium Port Question Message-ID: Let's see if I can answer all the questions I spotted in this thread. 1) If the compiler knows that a particular data item is unaligned, (ie, 3 bytes from the beginning of the structure), we will generate instructions to access the data in pieces and reassemble it in registers. We won't "give up". If you see the compiler generating aligned code for known-to-be-unaligned data, it is a compiler bug. Period. Tell us. 2) Speaking of compiler bugs, COBOL prior to V2.9 had several bugs where it generated aligned code for known-to-be-unaligned data items. V2.9 fixes all of them. 3) COBOL does not align/pad data items by default due to various language issues. Look at /ALIGN and /ALIGN=PADDED for ways to get COBOL to align items. Note that this will not (or at least should not) change the amount of alignment faults. Poorly aligned data items are accessed with multiple instructions that should not fault. Properly aligned data items are accessed with single instructions that should not fault. -- John Reagan OpenVMS Pascal/Macro-32/COBOL Project Leader Hewlett-Packard Company ------------------------------ End of INFO-VAX 2007.470 ************************