Re: COBOL Transactions? - VMS

This is a discussion on Re: COBOL Transactions? - VMS ; >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++] = ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Re: COBOL Transactions?

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


  2. RE: COBOL Transactions?

    > -----Original Message-----
    > From: Paul Raulerson [mailtoaul@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 flattext 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?

    Is there a utility like Authorize that maintains concurrent accesses?

    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?

    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.



  3. Re: COBOL Transactions?

    In article ,
    "Main, Kerry" writes:
    >> -----Original Message-----
    >> From: Paul Raulerson [mailtoaul@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

  4. RE: COBOL Transactions?

    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.


  5. Re: COBOL Transactions?

    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

+ Reply to Thread