Professional Web Applications Themes

To use "at" vs. "crontab", that is the question - SCO

Yes yes, I'm sure someone will have a laugh or two, but FoxPro is still being used and I'm not knowledgeable enough with SCO. Although I'm absorbing what I can about SCO when I have time, I wanted to once again get the advice from those with the experience. Trying to determine the best choice for my automated process. The manual process goes like this: Login to SCO server cd /datafiledirectory foxpro something1 foxpro something2 So something1 and something2 are foxpro programs which require foxpro.pr to execute? my guess is yes Since a simple DOS/Windows batch file, accessing the visionfs ...

  1. #1

    Default To use "at" vs. "crontab", that is the question

    Yes yes, I'm sure someone will have a laugh or two, but FoxPro is still
    being used and I'm not knowledgeable enough with SCO. Although I'm absorbing
    what I can about SCO when I have time, I wanted to once again get the advice
    from those with the experience.

    Trying to determine the best choice for my automated process. The manual
    process goes like this:

    Login to SCO server
    cd /datafiledirectory
    foxpro something1
    foxpro something2

    So something1 and something2 are foxpro programs which require foxpro.pr to
    execute? my guess is yes

    Since a simple DOS/Windows batch file, accessing the visionfs share on the
    SCO box and attempting to perform the process that way doesn't work, I
    presume it relates to the foxpro environment variables and not technically
    being logged into the shell, true? (accessing the share with su credentials
    on the SCO box doesn't cut it, obviously)

    From what I know, the environment, variables, and path all come into play
    when determining using "at" vs. "crontab", since "at" takes on the shell
    environment and "crontab" utilizes a different environment unless specified.

    With the default SCO shell, do I need to put a .sh on the end of the script
    name, or just ensure permissions include execute?

    I'm leaning towards using "at", with adding a line to the end of my script
    such as below to get it to put itself back in the schedule:

    echo "sh shellfile" | at 1630 +1 day

    Another question I have is in regards to output generated. Supposedly a log
    may be written, and I will need to curb the limit of this log to keep from
    the file growing too large. Since there is no resulting "output" when I
    manually process the commands, no other output should be generated by
    running them in script form, correct?

    Once I decide which format of scheduling to use, where does the script have
    to be placed? I have an idea, but I want to get it right.

    Since I cannot get at that system now and I'm hoping to go in with full
    knowledge (ha ha), I thought one (or more as often is the case) could clear
    up any mis/disinformation I have and pass along your recommendation.

    TIA

    Dave


    Dave Guest

  2. #2

    Default Re: To use "at" vs. "crontab", that is the question

    Dave <net> wrote: 
     
     
     

    Right.
     
     

    Correct: see http://aplawrence.com/Unixart/cron.html
     

    Just perms. See http://aplawrence.com/Basics/scripting.html
     
     

    Fine. No reason not to use cron though; see the article referenced
    above for how.
     

    Unless they fail..
     

    Doesn't "have" to be anywhere. If your cron or at calls it by
    entire path: /usr/joe/mystuff/deepkyburied/treasure/hereitis/command
    is fine.

     

    I'd use cron.

    --
    com Unix/Linux/Mac OS X resources: http://aplawrence.com
    Get paid for writing about tech: http://aplawrence.com/publish.html

    tony@aplawrence.com Guest

  3. #3

    Default Re: To use "at" vs. "crontab", that is the question


    "Dave" <net> wrote in message
    news:Wl2mb.3904$P%news.prodigy.com... 
    absorbing 
    advice 

    If they laugh, I'll get the garden hose, foxpro is one fine product. Too bad
    Microsoft killed it, an obvious monopoly abuse.

    If you are going to run foxpro with 'at' or cron, you may need to modify
    your code so it doesn't do any screen output, except error and quit. I'll
    never forget one of my first foxpro cron jobs, I redirected stderr and
    stdout to a /tmp file. It then proceeded to hit a foxpro error and fill up
    the root filesystem and crash. You'll have to redirect stdin and set TERM or
    foxpro will error out.


    Bob Guest

  4. #4

    Default Re: To use "at" vs. "crontab", that is the question

    Thanks for the tip Bob,

    that's what I thought was a possibility if I had log files being generated.
    I know of other situations where the drive was gobbled up before it was
    caught and messed many a thing up.

    From what I remember of the process, it never produces output to the screen,
    it just returns the prompt upon completion. Essentially process 1 is
    collecting files to be sent through EDI based on a flag in the file. Process
    2 does the actual sending of the file.

    One thing I should have asked is: Will the two foxpro actions be
    sequentially processed-the 2nd will not start until the first finishes using
    a script & cron? (I presume it should work that way)

    I'm sorry my first post jumped around like mad-that is an affliction I can't
    dodge, but I usually take the time to organize it so things come out so
    others can follow. I'd just been collecting/reading info for a few nights
    and losing my opportunity to ask the group here, and despite knowing someone
    could have hollered at me for not reading a FAQ somewhere, I had to chance
    it.

    Thanks again

    Dave

    "Bob Meyers" <com> wrote in message
    news:bnbg94$uqtbj$news.uni-berlin.de... 
    > absorbing 
    > advice 
    >
    > If they laugh, I'll get the garden hose, foxpro is one fine product. Too[/ref]
    bad 
    or 


    Dave Guest

  5. #5

    Default Re: To use "at" vs. "crontab", that is the question

    Thank you Tony for the confirmation and links; I have visited that site on
    more than one occasion, and may have skipped over the scripting details. I
    pulled some other info from the man pages on a caldera link.

    I will look it over more and see if I can't get it figured out. I like that
    by running "at", you can pilfer the script it makes and turn it into your
    own for crontab to run. Pretty slick. I was concerned I would be fighting
    all the environment settings I'm unfamiliar with, but the way I read that it
    essentially takes care of my worries.

    I've always wanted to use cron, ever since the days of my Amiga ;)

    Dave


    <com> wrote in message news:bnb3km$t2i$std.com... [/ref]
    absorbing [/ref]
    advice 


    > [/ref]
    to 
    >
    > Right.
    > [/ref]
    the [/ref]
    technically [/ref]
    credentials 
    > [/ref]
    specified. [/ref]
    script 
    >
    > Just perms. See http://aplawrence.com/Basics/scripting.html
    > [/ref]
    script 

    >
    > Fine. No reason not to use cron though; see the article referenced
    > above for how.
    > [/ref]
    log [/ref]
    from 
    >
    > Unless they fail..
    > [/ref]
    have 
    >
    > Doesn't "have" to be anywhere. If your cron or at calls it by
    > entire path: /usr/joe/mystuff/deepkyburied/treasure/hereitis/command
    > is fine.
    >
    > [/ref]
    clear 
    >
    > I'd use cron.
    >
    > --
    > com Unix/Linux/Mac OS X resources: http://aplawrence.com
    > Get paid for writing about tech: http://aplawrence.com/publish.html
    >[/ref]


    Dave Guest

  6. #6

    Default Re: To use "at" vs. "crontab", that is the question


    "Dave" <net> wrote in message
    news:haimb.3989$P%news.prodigy.com... 
    using 

    You'll need to pass a parameter flag of some tye to make it dynamic, or just
    make it one, big PRG and quit if first part errors. You can just test
    success in the first, if yes "do prg2" else "quit". Let the frst program
    invoke the second - only one cron entry for the first.


    Bob Guest

  7. #7

    Default RE: To use "at" vs. "crontab", that is the question


    I have found that I need to add a

    TERM=ansi;export TERM

    line to the script that calls the foxbase program from cron or at...

    Fabio
     
    > FoxPro is still 
    > absorbing 
    > again get the
    > advice 
    >
    > If they laugh, I'll get the garden hose, foxpro is one fine
    > product. Too bad
    > Microsoft killed it, an obvious monopoly abuse.
    >
    > If you are going to run foxpro with 'at' or cron, you may
    > need to modify
    > your code so it doesn't do any screen output, except error
    > and quit. I'll
    > never forget one of my first foxpro cron jobs, I redirected stderr and
    > stdout to a /tmp file. It then proceeded to hit a foxpro
    > error and fill up
    > the root filesystem and crash. You'll have to redirect stdin
    > and set TERM or
    > foxpro will error out.
    >
    >[/ref]
    Fabio Guest

Similar Threads

  1. Replies: 1
    Last Post: April 24th, 01:27 PM
  2. CFINPUT type="radio" w/ "value" requires "label"
    By Iceborer in forum Macromedia ColdFusion
    Replies: 2
    Last Post: February 21st, 06:16 PM
  3. Question about "Public Sub" vs "Private Sub" vs "Sub"
    By michaaal in forum ASP Database
    Replies: 1
    Last Post: October 18th, 07:15 PM
  4. "Start" "Program" "Menu" list is empty
    By Pete in forum Windows XP/2000/ME
    Replies: 2
    Last Post: July 10th, 10:42 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139