Re: COBOL Transactions? - VMS

This is a discussion on Re: COBOL Transactions? - VMS ; On 08/24/07 18:41, Dr. Dweeb wrote: > Larry Kilgallen wrote: >> In article , Ron Johnson >> writes: >>> On 08/24/07 16:11, John Santos wrote: >>> [snip] >>>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed >>>> ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 44

Thread: Re: COBOL Transactions?

  1. Re: COBOL Transactions?

    On 08/24/07 18:41, Dr. Dweeb wrote:
    > Larry Kilgallen wrote:
    >> In article , Ron Johnson
    >> writes:
    >>> On 08/24/07 16:11, John Santos wrote:
    >>> [snip]
    >>>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed
    >>>> file. :-)
    >>> I was delighted the first time I opened SYSUAF in EDT, and learned
    >>> the interesting lesson (*not* on SYSUAF!) that saving an indexed
    >>> file converts it into a flat file...

    >> I know of at least six sites where privileged users did that to
    >> SYSALF.DAT and then exited, meaning even their existing entries
    >> no longer worked.
    >>

    >
    > File versioning to the rescue ?


    Great minds think alike.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  2. Re: COBOL Transactions?

    In article <8nKzi.20836$Pv4.10871@newsfe19.lga>, Ron Johnson writes:
    > On 08/24/07 18:41, Dr. Dweeb wrote:
    >> Larry Kilgallen wrote:
    >>> In article , Ron Johnson
    >>> writes:
    >>>> On 08/24/07 16:11, John Santos wrote:
    >>>> [snip]
    >>>>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed
    >>>>> file. :-)
    >>>> I was delighted the first time I opened SYSUAF in EDT, and learned
    >>>> the interesting lesson (*not* on SYSUAF!) that saving an indexed
    >>>> file converts it into a flat file...
    >>> I know of at least six sites where privileged users did that to
    >>> SYSALF.DAT and then exited, meaning even their existing entries
    >>> no longer worked.
    >>>

    >>
    >> File versioning to the rescue ?

    >
    > Great minds think alike.


    But not the great minds that failed to realize what they had broken
    until a security assessment several years later.

  3. Re: COBOL Transactions?

    On 08/24/07 19:12, Larry Kilgallen wrote:
    > In article <8nKzi.20836$Pv4.10871@newsfe19.lga>, Ron Johnson writes:
    >> On 08/24/07 18:41, Dr. Dweeb wrote:
    >>> Larry Kilgallen wrote:
    >>>> In article , Ron Johnson
    >>>> writes:
    >>>>> On 08/24/07 16:11, John Santos wrote:
    >>>>> [snip]
    >>>>>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed
    >>>>>> file. :-)
    >>>>> I was delighted the first time I opened SYSUAF in EDT, and learned
    >>>>> the interesting lesson (*not* on SYSUAF!) that saving an indexed
    >>>>> file converts it into a flat file...
    >>>> I know of at least six sites where privileged users did that to
    >>>> SYSALF.DAT and then exited, meaning even their existing entries
    >>>> no longer worked.
    >>>>
    >>> File versioning to the rescue ?

    >> Great minds think alike.

    >
    > But not the great minds that failed to realize what they had broken
    > until a security assessment several years later.


    But how do you log in or run MCR AUTHORIZE on a flat-file SYSUAF?

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  4. Re: COBOL Transactions?

    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.


    User authorization is one of those applications that does not really
    lend itself to sequential access!


  5. Re: COBOL Transactions?

    On 08/24/07 20:29, Richard B. Gilbert wrote:
    [snip]
    >
    > 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.
    >
    >
    > User authorization is one of those applications that does not really
    > lend itself to sequential access!


    But how often do people actually log in? Twice (morning and after
    lunch) a day, if you've beaten your users into submission.

    And during that time when there's heavy login activity, /etc/passwd
    & /etc/shadow should be buffered by the first few accesses.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  6. Re: COBOL Transactions?

    In article , Ron Johnson writes:

    > But how often do people actually log in? Twice (morning and after
    > lunch) a day, if you've beaten your users into submission.


    Once per subprocess creation (to get the quotas).

  7. Re: COBOL Transactions?

    In article , Ron Johnson writes:
    > On 08/24/07 19:12, Larry Kilgallen wrote:
    >> In article <8nKzi.20836$Pv4.10871@newsfe19.lga>, Ron Johnson writes:
    >>> On 08/24/07 18:41, Dr. Dweeb wrote:
    >>>> Larry Kilgallen wrote:
    >>>>> In article , Ron Johnson
    >>>>> writes:
    >>>>>> On 08/24/07 16:11, John Santos wrote:
    >>>>>> [snip]
    >>>>>>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed
    >>>>>>> file. :-)
    >>>>>> I was delighted the first time I opened SYSUAF in EDT, and learned
    >>>>>> the interesting lesson (*not* on SYSUAF!) that saving an indexed
    >>>>>> file converts it into a flat file...
    >>>>> I know of at least six sites where privileged users did that to
    >>>>> SYSALF.DAT and then exited, meaning even their existing entries
    >>>>> no longer worked.
    >>>>>
    >>>> File versioning to the rescue ?
    >>> Great minds think alike.

    >>
    >> But not the great minds that failed to realize what they had broken
    >> until a security assessment several years later.

    >
    > But how do you log in or run MCR AUTHORIZE on a flat-file SYSUAF?


    You don't. The case I was talking about was SYSALF.DAT, where you run
    for years thinking that autologin is a VMS feature that "doesn't work".

  8. RE: COBOL Transactions?

    > -----Original Message-----
    > From: Ron Johnson [mailto:ron.l.johnson@cox.net]
    > Sent: August 24, 2007 11:21 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: COBOL Transactions?
    >
    > On 08/24/07 20:29, Richard B. Gilbert wrote:
    > [snip]
    > >
    > > 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.
    > >
    > >
    > > User authorization is one of those applications that does not really
    > > lend itself to sequential access!

    >
    > But how often do people actually log in? Twice (morning and after
    > lunch) a day, if you've beaten your users into submission.
    >
    > And during that time when there's heavy login activity, /etc/passwd
    > & /etc/shadow should be buffered by the first few accesses.
    >


    Depends on application and environment. ISP's often have greater than 100K users spread
    across a number of systems all of which not only require access to their web based info
    but also require FTP authentication whenever they upload files to their website.

    A great deal of design work will typically go into such an environment as the default
    sequential searches were a non-starter.

    Also, keep in mind that you have a great deal of User updating and pwd re-setting in large
    user environments, so you also need a strategy that allows concurrent access to the user
    authorization file(s).

    Regards


    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.





  9. Re: COBOL Transactions?

    In article ,
    Ron Johnson wrote:

    > On 08/24/07 16:11, John Santos wrote:
    > [snip]
    > >
    > > Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-)

    >
    > I was delighted the first time I opened SYSUAF in EDT, and learned
    > the interesting lesson (*not* on SYSUAF!) that saving an indexed
    > file converts it into a flat file...


    You only make that mistake once though.

    Once it is programmed into your fingers that .LIS is the default file
    type for the input file, you do thinks like this:

    UAF> list
    %UAF-I-LSTMSG1, writing listing file
    %UAF-I-LSTMSG2, listing file SYSUAF.LIS complete
    $ print sysuaf

    Oops. If you have SYSUAF defined as a logical name, you print the
    authorization file, and your printer chokes on the binary data therein.

    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

  10. Re: COBOL Transactions?

    On 08/25/07 07:02, Larry Kilgallen wrote:
    > In article , Ron Johnson writes:
    >> On 08/24/07 19:12, Larry Kilgallen wrote:
    >>> In article <8nKzi.20836$Pv4.10871@newsfe19.lga>, Ron Johnson writes:
    >>>> On 08/24/07 18:41, Dr. Dweeb wrote:
    >>>>> Larry Kilgallen wrote:
    >>>>>> In article , Ron Johnson
    >>>>>> writes:
    >>>>>>> On 08/24/07 16:11, John Santos wrote:
    >>>>>>> [snip]
    >>>>>>>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed
    >>>>>>>> file. :-)
    >>>>>>> I was delighted the first time I opened SYSUAF in EDT, and learned
    >>>>>>> the interesting lesson (*not* on SYSUAF!) that saving an indexed
    >>>>>>> file converts it into a flat file...
    >>>>>> I know of at least six sites where privileged users did that to
    >>>>>> SYSALF.DAT and then exited, meaning even their existing entries
    >>>>>> no longer worked.
    >>>>>>
    >>>>> File versioning to the rescue ?
    >>>> Great minds think alike.
    >>> But not the great minds that failed to realize what they had broken
    >>> until a security assessment several years later.

    >> But how do you log in or run MCR AUTHORIZE on a flat-file SYSUAF?

    >
    > You don't. The case I was talking about was SYSALF.DAT, where you run
    > for years thinking that autologin is a VMS feature that "doesn't work".


    Ah.

    Autologin? Isn't that... insecure?

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  11. Re: COBOL Transactions?

    On 08/25/07 09:06, Main, Kerry wrote:
    >> -----Original Message----- From: Ron Johnson
    >> [mailto:ron.l.johnson@cox.net] Sent: August 24, 2007 11:21 PM
    >> To: Info-VAX@Mvb.Saic.Com Subject: Re: COBOL Transactions?
    >>
    >> On 08/24/07 20:29, Richard B. Gilbert wrote: [snip]
    >>> 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.
    >>>
    >>>
    >>> User authorization is one of those applications that does not
    >>> really lend itself to sequential access!

    >> But how often do people actually log in? Twice (morning and
    >> after lunch) a day, if you've beaten your users into
    >> submission.
    >>
    >> And during that time when there's heavy login activity,
    >> /etc/passwd & /etc/shadow should be buffered by the first few
    >> accesses.
    >>

    >
    > Depends on application and environment. ISP's often have greater
    > than 100K users spread across a number of systems all of which
    > not only require access to their web based info but also require
    > FTP authentication whenever they upload files to their web site.
    >
    > A great deal of design work will typically go into such an
    > environment as the default sequential searches were a
    > non-starter.
    >
    > Also, keep in mind that you have a great deal of User updating
    > and pwd re-setting in large user environments, so you also need a
    > strategy that allows concurrent access to the user authorization
    > file(s).


    I don't know why it didn't occur to me last night (probably because
    most of my brain was thinking about work), but PAM has an LDAP
    module, and LDAP can use an index file store.

    So.... any ISP that keeps 100K users in a flat file shouldn't be in
    business.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  12. Re: COBOL Transactions?

    In article , Ron Johnson writes:
    > On 08/25/07 07:02, Larry Kilgallen wrote:
    >> In article , Ron Johnson writes:


    >>> But how do you log in or run MCR AUTHORIZE on a flat-file SYSUAF?

    >>
    >> You don't. The case I was talking about was SYSALF.DAT, where you run
    >> for years thinking that autologin is a VMS feature that "doesn't work".

    >
    > Ah.
    >
    > Autologin? Isn't that... insecure?


    There is no notion of security absent an application context.

    For a badge reader that is only smart enough to send a carriage return
    down a dedicated line, autologin may be appropriate.

    For a lobby terminal intended to let an outsider send a message to
    an employee, autologin into a username that is locked into that "send
    a message" screen may be appropriate.

    For a system manager who tries EDT on an indexed file, having autologin
    become mystically disabled may be the safest behaviour.

  13. Re: COBOL Transactions?

    Ron Johnson wrote:
    > Autologin? Isn't that... insecure?



    Consider a captive account that starts some application. In a shop
    floor, there is a terminal, and anyone can press enter to get into the
    application. and have access to nothing else but that application.


  14. Re: COBOL Transactions?

    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

  15. Re: COBOL Transactions?

    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

  16. Re: COBOL Transactions?

    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.


  17. Re: COBOL Transactions?

    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!


  18. Re: COBOL Transactions?

    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


  19. Re: COBOL Transactions?

    In article ,
    david20@alpha2.mdx.ac.uk writes:
    > In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >>
    >> 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


    I assume your refering to my comment "because you pay for everything that
    comes with the system". But that was in relation to VMS and not Unix.
    TCPIP has been a part of the kernel and not "bundled" at all in every
    unix other than very old SYSV systems (at least since networking became
    common). And Sendmail is not really a part of Unix and has been free
    since it was written. I usually do not even install it. Of course,
    depending on how you look at it, TCPIP and Sendmail cost at least as
    much as the OS for me. :-)

    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

  20. Re: COBOL Transactions?

    In article <5jgi9hF3td690U1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >In article ,
    > david20@alpha2.mdx.ac.uk writes:
    >> In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >>>
    >>> 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

    >
    >I assume your refering to my comment "because you pay for everything that
    >comes with the system". But that was in relation to VMS and not Unix.
    >TCPIP has been a part of the kernel and not "bundled" at all in every
    >unix other than very old SYSV systems (at least since networking became
    >common). And Sendmail is not really a part of Unix and has been free
    >since it was written. I usually do not even install it. Of course,
    >depending on how you look at it, TCPIP and Sendmail cost at least as
    >much as the OS for me. :-)
    >

    But you "pay for everything that comes with the system". VMS shows that you do
    not necessarily have to bundle the TCPIP stack in the OS (or build it into the
    kernel). Hence since it is not strictly necessary to include it and some few
    users may not want to use it - by your logic Unix should not include a TCPIP
    stack with the OS.
    Your comment "But that was in relation to VMS and not Unix" seems to imply that
    Unix has some special privilege in this regard so that you can criticise VMS
    for including facilities but that similar criticisms of Unix regarding it's
    facilities are out of bounds.


    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


+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast