SUBMIT command - VMS

This is a discussion on SUBMIT command - VMS ; "Richard B. Gilbert" wrote in message news:471F2692.7030500@comcast.net... > That is bull****! When you submit a job, the command file you submit is executed. If > that file no longer exists, the job fails. The system keeps track by File ID. ...

+ Reply to Thread
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast
Results 41 to 60 of 87

Thread: SUBMIT command

  1. Re: SUBMIT command


    "Richard B. Gilbert" wrote in message
    news:471F2692.7030500@comcast.net...

    > That is bull****! When you submit a job, the command file you submit is executed. If
    > that file no longer exists, the job fails. The system keeps track by File ID. I
    > suppose it is POSSIBLE to modify the file without creating a new version but you would
    > really have to work at it.


    It's not hard. EDIT, then COPY/OVERLAY.



  2. Re: SUBMIT command

    In article ,
    briggs@encompasserve.org wrote:

    > In article <4de54$471e57db$cef8887a$17324@TEKSAVVY.COM>, JF Mezei
    > writes:
    > > Doug Phillips wrote:
    > >> Absolutely! To run a job as another user on VMS, you must be
    > >> authorized to do so.

    > >
    > >
    > > Are there not any remnants of the punched card days where you could
    > > specify username/password to create a batch job running under that user
    > > ? (is it the $DECK stuff ?)

    >
    > $ help job
    > JOB
    >
    > Identifies the beginning of a batch job submitted through a card
    > reader. Each batch job submitted through the system card reader
    > must be preceded by a JOB card.
    >
    > JOB cannot be abbreviated.
    >
    > Format
    >
    > JOB user-name
    > [...]
    >
    > $ help password
    >
    > PASSWORD
    >
    > Provides the password associated with the user name that you
    > specify with the JOB card when you submit a batch job through a
    > card reader. Although the PASSWORD card is required, the password
    > on the card is optional if the account has a null password.


    Yes, but neither command is currently recognized by DCL, as tested on
    Alpha 8.3 and VAX 7.3:

    $ job fred
    %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
    \JOB\
    $ password xxxxxx
    %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
    \PASSWORD\

    --
    Paul Sture

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

  3. Re: SUBMIT command

    In article <_8CTi.12089$ZA.7955@newsb.telia.net>, =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes:
    > Ron Johnson wrote:
    >
    >>
    >> If it looks like a deck, acts like a deck and quacks like a deck,
    >> it's a card deck.
    >>

    >
    > Yes, but on MVS/zOS/whatever it is still a little different.
    > In the beginning the mainframes had mainly card-readers (input)
    > and lineprinters (output) devices. That's it. The MVS kernel
    > only understands 80 char record oriented input (card decks)
    > and 132 char output (lineprinters). Everything else is just
    > an emulation put on top of that, some one once said. :-)
    >
    > When you've edited a dataset with your JCL commands in TSO/ISPF,
    > and enter the SUBmit command to run it, it is actualy written
    > to the "internal reader", which is an emulated card reader
    > making the MVS kernel think that you've actualy put some
    > cards in a physical reader...
    >
    > I'm not sure if VMS still have something like that "inside".


    http://mvb.said.com/freeware/vax83c/...imcr/simcr.for

    The implementation details of the VMS card reader system are
    described in that program.

    JOB_CONTROL gets unsolicited notification in its mailbox when
    unsolicited input is received on any unallocated/unassigned
    input device.

    That's how you get a Username: prompt when you hit carriage return
    on a directly-connected terminal. JOB_CONTROL gets the unsolicited
    input notification and fires up a copy of LOGINOUT.EXE for you to
    log in with.

    In the case of a card reader, JOB_CONTROL will fire up a copy of INPSMB
    to start reading from the card reader that had the unsolicited input
    event.


    simcr exploits this by forging an unsolicited input message to
    the JOB_CONTROL mailbox so that JOB_CONTROL points INPSMB at
    a mailbox where a batch job is presented as if read from
    a card reader.

  4. Re: SUBMIT command

    In article , "P. Sture" writes:
    > In article ,
    > briggs@encompasserve.org wrote:
    >
    >> In article <4de54$471e57db$cef8887a$17324@TEKSAVVY.COM>, JF Mezei
    >> writes:
    >> > Doug Phillips wrote:
    >> >> Absolutely! To run a job as another user on VMS, you must be
    >> >> authorized to do so.
    >> >
    >> >
    >> > Are there not any remnants of the punched card days where you could
    >> > specify username/password to create a batch job running under that user
    >> > ? (is it the $DECK stuff ?)

    >>
    >> $ help job
    >> JOB
    >>
    >> Identifies the beginning of a batch job submitted through a card
    >> reader. Each batch job submitted through the system card reader
    >> must be preceded by a JOB card.
    >>
    >> JOB cannot be abbreviated.
    >>
    >> Format
    >>
    >> JOB user-name
    >> [...]
    >>
    >> $ help password
    >>
    >> PASSWORD
    >>
    >> Provides the password associated with the user name that you
    >> specify with the JOB card when you submit a batch job through a
    >> card reader. Although the PASSWORD card is required, the password
    >> on the card is optional if the account has a null password.

    >
    > Yes, but neither command is currently recognized by DCL, as tested on
    > Alpha 8.3 and VAX 7.3:


    Have you tried them in the context of a job submitted via a card
    reader?

    It's entirely plausible that they would be processed by INPSMB, not DCL.

    > $ job fred
    > %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
    > \JOB\
    > $ password xxxxxx
    > %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
    > \PASSWORD\


  5. Re: SUBMIT command

    In article ,
    VAXman- @SendSpamHere.ORG writes:
    > In article <5o7d9lFkmdm3U1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    > {...snip...}
    >>Well, sudo is for specific commands and not general use. But it
    >>wouldn't take much to provide a menu that had more than one command
    >>available at any given time. If you are looking for general command
    >>execution use plain "su".

    >
    > But that would mean handing out the root password to sudoers. Where's
    > the security in that?


    That's what I like about this newsgroup. If someone asks for something
    and you give it to them they will find a problem with it and if you then
    solve that problem they will find yet another unrelated fault with the
    solution.

    "Propose to an Englishman any principle, or any instrument,
    however admirable, and you will observe that the whole
    effort of the English mind is directed to find a difficulty,
    a defect, or an impossibility in it. If you speak to him of
    a machine for peeling a potato, he will pronounce it impossible:
    if you peel a potato with it before his eyes, he will declare
    it useless, because it will not slice a pineapple."

    Tell me exactly what you want to do and I will tell you how to do it
    or declare it impossible. But don't ask a question and then continually
    change the parameters of the problem.

    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

  6. Re: sudo

    On Oct 23, 9:47 pm, Ron Johnson wrote:
    > On 10/23/07 18:32, bradhamilton wrote:
    >
    >
    >
    > > VAXman- @SendSpamHere.ORG wrote:
    > >> In article , Ron Johnson
    > >> writes:

    > > [...]
    > >> I only wish that I could enter 'sudo' and type my password and then
    > >> stay in a context where I could do multiple commands with the 'sudo'
    > >> authorized privies.
    > >> i.e.

    >
    > >> % sudo
    > >> Password: ******
    > >> sudo% command
    > >> sudo% command
    > >> sudo% command
    > >> sudo% exit

    >
    > > On the Linux distro I use on my laptop (Ubuntu), I think that sudo is
    > > "timeout-controlled"; i.e., I can enter several "sudo" commands in quick
    > > succession without re-entering the password each time, but if I wait for
    > > a(n) (unknown) period of time, I have to enter a password on the
    > > subsequent "sudo" command.

    >
    > $ man 5 sudoers


    Why the 5?

    [...]

    AEF


  7. Re: SUBMIT command

    briggs@encompasserve.org wrote:
    > In article , "P. Sture" writes:
    >
    >>In article ,
    >> briggs@encompasserve.org wrote:
    >>
    >>
    >>>In article <4de54$471e57db$cef8887a$17324@TEKSAVVY.COM>, JF Mezei
    >>> writes:
    >>>
    >>>>Doug Phillips wrote:
    >>>>
    >>>>>Absolutely! To run a job as another user on VMS, you must be
    >>>>>authorized to do so.
    >>>>
    >>>>
    >>>>Are there not any remnants of the punched card days where you could
    >>>>specify username/password to create a batch job running under that user
    >>>>? (is it the $DECK stuff ?)
    >>>
    >>>$ help job
    >>>JOB
    >>>
    >>> Identifies the beginning of a batch job submitted through a card
    >>> reader. Each batch job submitted through the system card reader
    >>> must be preceded by a JOB card.
    >>>
    >>> JOB cannot be abbreviated.
    >>>
    >>> Format
    >>>
    >>> JOB user-name
    >>>[...]
    >>>
    >>>$ help password
    >>>
    >>>PASSWORD
    >>>
    >>> Provides the password associated with the user name that you
    >>> specify with the JOB card when you submit a batch job through a
    >>> card reader. Although the PASSWORD card is required, the password
    >>> on the card is optional if the account has a null password.

    >>
    >>Yes, but neither command is currently recognized by DCL, as tested on
    >>Alpha 8.3 and VAX 7.3:

    >
    >
    > Have you tried them in the context of a job submitted via a card
    > reader?


    Really! Does ANYBODY still have a card reader or a keypunch? I
    haven't seen either since the early 1990s!!

    If you do still have such things, they are probably too valuable as
    antiques to actually USE them!


  8. Re: sudo

    AEF wrote:
    > On Oct 23, 9:47 pm, Ron Johnson wrote:
    >
    >>On 10/23/07 18:32, bradhamilton wrote:
    >>
    >>
    >>
    >>
    >>>VAXman- @SendSpamHere.ORG wrote:
    >>>
    >>>>In article , Ron Johnson
    >>>> writes:
    >>>
    >>>[...]
    >>>
    >>>>I only wish that I could enter 'sudo' and type my password and then
    >>>>stay in a context where I could do multiple commands with the 'sudo'
    >>>>authorized privies.
    >>>>i.e.
    >>>
    >>>>% sudo
    >>>>Password: ******
    >>>>sudo% command
    >>>>sudo% command
    >>>>sudo% command
    >>>>sudo% exit
    >>>
    >>>On the Linux distro I use on my laptop (Ubuntu), I think that sudo is
    >>>"timeout-controlled"; i.e., I can enter several "sudo" commands in quick
    >>>succession without re-entering the password each time, but if I wait for
    >>>a(n) (unknown) period of time, I have to enter a password on the
    >>>subsequent "sudo" command.

    >>
    >>$ man 5 sudoers

    >
    >
    > Why the 5?
    >
    > [...]
    >
    > AEF
    >


    The "5" is the "Section" of the manual. Unix has something like seven
    different sections of the man pages. There's one for Administration
    (1M) one for user commands, one for library routines, etc, etc. There
    are cases when the Section differentiates between different subjects
    with the same name.


  9. Re: sudo

    On 10/24/07 07:20, Richard B. Gilbert wrote:
    > AEF wrote:
    >> On Oct 23, 9:47 pm, Ron Johnson wrote:

    [snip]
    >>>
    >>> $ man 5 sudoers

    >>
    >>
    >> Why the 5?
    >>
    >> [...]
    >>
    >> AEF
    >>

    >
    > The "5" is the "Section" of the manual. Unix has something like seven
    > different sections of the man pages. There's one for Administration
    > (1M) one for user commands, one for library routines, etc, etc. There
    > are cases when the Section differentiates between different subjects
    > with the same name.


    Correct. And I knew to type "man 5 sudoers" because down at the
    bottom of "man sudo" is a "SEE ALSO" section that references
    "sudoers(5)".

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

  10. Re: unix "batch processing"

    In article <5o6nn2Flf59dU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >In article ,
    > Rob Brown writes:
    >> On Tue, 23 Oct 2007, Bill Gunshannon wrote:
    >>
    >>> In article <4$VTv9Rz+Npg@eisner.encompasserve.org>,
    >>> briggs@encompasserve.org writes:
    >>>> In article <1193153254.512670.15500@t8g2000prg.googlegroups.co m>,
    >>>> a13365@yahoo.com writes:
    >>>>> What kind privileges I need to check?
    >>>>
    >>>> $ HELP SUBMIT /USER
    >>>> SUBMIT
    >>>>
    >>>> /USER
    >>>>
    >>>> /USER=username
    >>>>
    >>>> Requires CMKRNL (change mode to kernel) privilege and read (R)
    >>>> and write (W) access to the user authorization file (UAF).
    >>>
    >>> Ohmigod!!!! There is actually something that Unix can do that
    >>> VMS can't do (at least not without elevated priviledges on the
    >>> VMS side!!)

    >>
    >> I have never known how to do something in Linux that I would do in
    >> batch in VMS. Perhaps the UNIX facility you refer to exists in Linux?

    >
    >Of course it does.
    >
    >>
    >> What UNIX facility do you refer to?

    >
    >Actually, I was just refering to the ability to do it as another
    >user without elevated priviledges.
    >
    >> How is it similar to and
    >> different from from batch jobs in VMS.

    >
    >I guess I would need to know what you think of as "batch jobs". To
    >me that just means running non-interactive processes. That can be
    >done in Unix either with the "at" command for later execution or
    >with the "&" symbol to run the process in the background.
    >

    As I recall at and & just run under the account of the user submitting
    the job.
    I'm not aware of any qualifier to at which allows it to run under another user.
    To do that you would need to su to the user and then submit the job using at.

    See the at MAN page eg

    http://manpages.unixforum.co.uk/man-...-man-page.html

    su to the user is in effect logging into the users account. The same effect can
    be accomplished under VMS by using say set host 0 before submitting the job.

    David Webb
    Security team leader
    CCSS
    Middlesex University


    >> How would I have to change my
    >> thinking to recognize it? How and when is the specified user
    >> protected against unauthorized jobs run on his behalf?

    >
    >The same way he is protected from someone loggin in and running stuff
    >as him. Password is required. Now, granted, it is not a good thing
    >to give out yur password and is forbidden in many venue (like DOD) but
    >I can think of and come up with places where this could still be used
    >safely and would meet a need.
    >
    >>
    >> Thanks for educating me.

    >
    >Hope what I said above helps at least a littel, if you have any more
    >questions, feel free to email me directly as I am sure the majority
    >here have no desire to have their mistaken understanding of Unix
    >corrected.
    >
    >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


  11. Re: sudo

    On Oct 24, 8:20 am, "Richard B. Gilbert"
    wrote:
    > AEF wrote:
    > > On Oct 23, 9:47 pm, Ron Johnson wrote:

    >
    > >>On 10/23/07 18:32, bradhamilton wrote:

    >
    > >>>VAXman- @SendSpamHere.ORG wrote:

    >
    > >>>>In article , Ron Johnson
    > >>>> writes:

    >
    > >>>[...]

    >
    > >>>>I only wish that I could enter 'sudo' and type my password and then
    > >>>>stay in a context where I could do multiple commands with the 'sudo'
    > >>>>authorized privies.
    > >>>>i.e.

    >
    > >>>>% sudo
    > >>>>Password: ******
    > >>>>sudo% command
    > >>>>sudo% command
    > >>>>sudo% command
    > >>>>sudo% exit

    >
    > >>>On the Linux distro I use on my laptop (Ubuntu), I think that sudo is
    > >>>"timeout-controlled"; i.e., I can enter several "sudo" commands in quick
    > >>>succession without re-entering the password each time, but if I wait for
    > >>>a(n) (unknown) period of time, I have to enter a password on the
    > >>>subsequent "sudo" command.

    >
    > >>$ man 5 sudoers

    >
    > > Why the 5?

    >
    > > [...]

    >
    > > AEF

    >
    > The "5" is the "Section" of the manual. Unix has something like seven
    > different sections of the man pages. There's one for Administration
    > (1M) one for user commands, one for library routines, etc, etc. There
    > are cases when the Section differentiates between different subjects
    > with the same name.


    Repost: I don't see the original post:

    Sorry, I should have posted my output:

    bash-2.03$ man 5 sudoers
    No manual entry for 5.
    Reformatting page. Please Wait... done

    MAINTENANCE COMMANDS SUDOERS(4)

    NAME
    sudoers - list of which users may execute what

    DESCRIPTION
    The sudoers file is composed of two types of entries:
    ..
    ..
    ..

    So I get the pages, but the 5 is ignored. I guess your and his Unix is
    different from mine. (Mine is SunOS 5.8.) Or your sessions are
    configured differently? What's up?

    Thanks!


  12. Re: unix "batch processing"

    In article , Rich Alderson writes:
    > bill@cs.uofs.edu (Bill Gunshannon) writes:
    >
    >> In article ,
    >> Kilgallen@SpamCop.net (Larry Kilgallen) writes:

    >
    >>> If you want to fully share access, then create usernames with a shared
    >>> UIC. They have the same rights to data but separate audit identities.

    >
    >> If I am correct, that would be the same as a Unix Group. But that
    >> wasn't what the requestor was asking about. He wanted to run something
    >> as another user.

    >


    There's just about nothing that can be accomplished as another user
    that can't be accomplished via proper access controls. Assigning
    duplicate UICs is one such approach.

    A UNIX group or TOPS project is much like a VMS group, until you
    put a UNIX user in multiple groups, then its much like a VMS
    rightslist identifier.

    > Not quite the same as a Unix group, which functions much like an RSX-11 or
    > Tops-10 "project" (as in project-programmer number); I believe that VMS (used
    > to) call UIC's by that name, too.
    >
    > The Unix equivalent to Mr. Kilgallen's suggestion is assigning the same numeric
    > userid (uid) to two different usernames in the password file.


    Yes, the actual mapping is close to
    VMS UIC = [group,member] = UNIX user id
    VMS group = UNIX group

    Sometimes the VMS member number is compared to the UNIX user id, that
    is a much less accurate mapping. A VMS member number is unique
    across a group, VMS UIC and UNIX user id are unique across a system
    (unless duplicated intentionally).



  13. Re: SUBMIT command

    P. Sture wrote:
    > Yes, but neither command is currently recognized by DCL, as tested on
    > Alpha 8.3 and VAX 7.3:
    >
    > $ job fred
    > %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
    > \JOB\
    > $ password xxxxxx
    > %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
    > \PASSWORD\
    >


    You have to PUNCH the JOB and PASSWORD commands, and feed it to the
    cardreader, then they are recognized :-)


    --

    Joseph Huber - http://www.huber-joseph.de

  14. Re: SUBMIT command

    In article <1193149624.407810.325610@t8g2000prg.googlegroups.c om>, a13365@yahoo.com writes:
    > Hello,
    >
    > About Submit command, if I use /user=scott, dose VMS check user's
    > password?


    No. It checks the privileges of the user entering the submit
    command. Only a privileged user can submit a job under someone
    else's username.


  15. Re: unix "batch processing"

    In article ,
    david20@alpha2.mdx.ac.uk writes:
    > In article <5o6nn2Flf59dU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >>In article ,
    >> Rob Brown writes:
    >>> On Tue, 23 Oct 2007, Bill Gunshannon wrote:
    >>>
    >>>> In article <4$VTv9Rz+Npg@eisner.encompasserve.org>,
    >>>> briggs@encompasserve.org writes:
    >>>>> In article <1193153254.512670.15500@t8g2000prg.googlegroups.co m>,
    >>>>> a13365@yahoo.com writes:
    >>>>>> What kind privileges I need to check?
    >>>>>
    >>>>> $ HELP SUBMIT /USER
    >>>>> SUBMIT
    >>>>>
    >>>>> /USER
    >>>>>
    >>>>> /USER=username
    >>>>>
    >>>>> Requires CMKRNL (change mode to kernel) privilege and read (R)
    >>>>> and write (W) access to the user authorization file (UAF).
    >>>>
    >>>> Ohmigod!!!! There is actually something that Unix can do that
    >>>> VMS can't do (at least not without elevated priviledges on the
    >>>> VMS side!!)
    >>>
    >>> I have never known how to do something in Linux that I would do in
    >>> batch in VMS. Perhaps the UNIX facility you refer to exists in Linux?

    >>
    >>Of course it does.
    >>
    >>>
    >>> What UNIX facility do you refer to?

    >>
    >>Actually, I was just refering to the ability to do it as another
    >>user without elevated priviledges.
    >>
    >>> How is it similar to and
    >>> different from from batch jobs in VMS.

    >>
    >>I guess I would need to know what you think of as "batch jobs". To
    >>me that just means running non-interactive processes. That can be
    >>done in Unix either with the "at" command for later execution or
    >>with the "&" symbol to run the process in the background.
    >>

    > As I recall at and & just run under the account of the user submitting
    > the job.
    > I'm not aware of any qualifier to at which allows it to run under another user.
    > To do that you would need to su to the user and then submit the job using at.
    >
    > See the at MAN page eg
    >
    > http://manpages.unixforum.co.uk/man-...-man-page.html
    >
    > su to the user is in effect logging into the users account. The same effect can
    > be accomplished under VMS by using say set host 0 before submitting the job.


    "su" can be used to just run a command as another user without actually
    logging in. That, combined with "at" or "&" would have the effect of
    starting a "batch" job as another user. I was specifically addressing
    what I considerd the Unix equivalent of VMS "SUBMIT" above as that was
    what was being addressed in this specific message. Doing it as another
    user was a different message and was addressed in a reply to it.

    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: SUBMIT command

    In article <5o6nb1Flf59dU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    > In article <471E2341.30707@comcast.net>,
    > "Richard B. Gilbert" writes:
    >> Bill Gunshannon wrote:
    >>>
    >>> Ohmigod!!!! There is actually something that Unix can do that
    >>> VMS can't do (at least not without elevated priviledges on the
    >>> VMS side!!)
    >>>
    >>> bill
    >>>

    >>
    >> And just how does Unix run something as another user without being root
    >> (privelege equivalent)??
    >>

    >
    > Prompts for the password.
    >


    Password sharing is a violation of every security policy I've seen
    in the last ten years. But if you're using VMS and you do have
    someone else's password you can always log in as them, just like UNIX,
    so su isn't giving your a functionality VMS can't do, just an
    implementation that's different than UNIX.

    Lots of cross-references I've seen for VMS and UNIX commands simply
    list "set host 0" as the functional replacement for su. In fact the
    result is just about identical to "su -".



  17. Re: sudo

    In article <1193227597.050492.263230@z24g2000prh.googlegroups. com>,
    AEF writes:
    > On Oct 23, 9:47 pm, Ron Johnson wrote:
    >> On 10/23/07 18:32, bradhamilton wrote:
    >>
    >>
    >>
    >> > VAXman- @SendSpamHere.ORG wrote:
    >> >> In article , Ron Johnson
    >> >> writes:
    >> > [...]
    >> >> I only wish that I could enter 'sudo' and type my password and then
    >> >> stay in a context where I could do multiple commands with the 'sudo'
    >> >> authorized privies.
    >> >> i.e.

    >>
    >> >> % sudo
    >> >> Password: ******
    >> >> sudo% command
    >> >> sudo% command
    >> >> sudo% command
    >> >> sudo% exit

    >>
    >> > On the Linux distro I use on my laptop (Ubuntu), I think that sudo is
    >> > "timeout-controlled"; i.e., I can enter several "sudo" commands in quick
    >> > succession without re-entering the password each time, but if I wait for
    >> > a(n) (unknown) period of time, I have to enter a password on the
    >> > subsequent "sudo" command.

    >>
    >> $ man 5 sudoers

    >
    > Why the 5?


    "sudoers" is a file. Man Section 5 explains the format and function of
    Unix specific files.

    man 5 sudoers
    ^ ^ ^
    | | |
    | | item you want explained
    | |
    | Section of Manpages you want
    |
    man command

    Of course, this is only needed when an item with the same name appears
    in more than one section, like "passwd" or "crontab".

    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

  18. Re: SUBMIT command

    In article <4de54$471e57db$cef8887a$17324@TEKSAVVY.COM>, JF Mezei writes:
    >
    > Are there not any remnants of the punched card days where you could
    > specify username/password to create a batch job running under that user
    > ? (is it the $DECK stuff ?)
    >


    $DESK/$EOD is usefull in delimiting data in .COM files, especially
    if that data starts with "$".

    There are "DCL" USERNAME and PASSWORD commands, but they are actually
    implemented in the card reader input symbiont, not the DCL image,
    and thus are VAX only. And the only supported card reader was a
    UNIBUS device, so most VAXen don't actually support them, either.


  19. Re: SUBMIT command

    In article , VAXman- @SendSpamHere.ORG writes:
    >
    > I only wish that I could enter 'sudo' and type my password and then
    > stay in a context where I could do multiple commands with the 'sudo'
    > authorized privies.
    >


    I used to have two symbols in my login.com for the SYSTEM
    account. PRIV and NOPRIV turned on and off what I reguarded as the
    most dangerous privileges. Later I added a change of prompt, ala
    TOPS-20, so I could see imediatley whether I had the privileges
    enabled. The SYSTEM login.com (not sylogin) turned them off
    during interactive login, which interfered wiht nothing, and
    I'd login /nocommand if I was in a hurry to get them on.

    Nowdays I'm more likely just to log into my personnal account,
    which has lots of authorized privileges, but few default privileges,
    instead of SYSTEM, but that stuff didn't exist in VMS 2.5.

    Of course, we all know we could choose between one of the following
    to put in our login.com:

    su == "set host 0"
    su == "telnet 127.0.0.1"

    Although the behaviour more closely matches "su -" than "su", I
    almost always "su -" anyhow.


  20. Re: unix "batch processing"

    In article , Rob Brown writes:
    >
    > I have never known how to do something in Linux that I would do in
    > batch in VMS. Perhaps the UNIX facility you refer to exists in Linux?
    >


    The usual substitute for batch in UNIX is the "at" command, but it's
    up to you to create a log if you want to know what happened, and it
    can be very difficult to diagnose failure to create a log.

    Sometimes cron is the more appropriate utility.

    As I learned from AIX, it's also possible to setup a "print queue",
    but specify a shell as the "filter", then submit scripts to this real
    "batch" queue. Again getting logs can be a PITA.

    Some more modern "at" and cron may have built in logging capabilities;
    I learned all this painfully when someone dropped ULTRIX-MIPS into
    my all-VMS computer room.


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