Re: COBOL Transactions? #9

----=_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--

> -----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.

In article <C72D63EB292C9E49AED23F705C61957BDE935D9871@g1w0487.americas.hpqcorp.net>, "Main, Kerry" <Kerry.Main@hp.com> 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 <std.disclaimer.h>

In article <C72D63EB292C9E49AED23F705C61957BDE935D9871@G1W0487.americas.hpqcorp.net>, "Main, Kerry" <Kerry.Main@hp.com> 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.

Paul Raulerson wrote: > > 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. I/O data transfers of known bytecounts can be passed directly to the DMA hardware of the I/O device, which makes things even more efficient. I do not know if the high level languages on VMS that know about records can set all the RMS parameters. If you program to the RMS API for some types of transfers, you can request that your application do disk I/O directly from the application memory to the device, with no O/S buffering, provided that there is support in the driver for that device for it. > 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. So for some types of transactions, the overhead for VMS can be very low. -John wb8tyw@qsl.network Personal Opinion Only