• Problems with events run

    From Mike Luther@1:117/100 to Sean Dennis on Saturday, February 19, 2011 22:38:08
    Another thought Sean ..

    What I do to accomplish this is sort of crud but has worked for a long time here. In the .CMD or .BAT file which has the job of doing things where the other tasks are to shut up, if they can be shut up by issuing a flag of some kind to them, then what I do is start a loop in my command file at the time I need to run the event which needs to silence the other events.

    I hit the top of this manual loop. It turns off task 1, 2, x and whatever. Then if goes and fires up the required maintenance task. Which is set to exit that task with an error level that the .CMD or .BAT file can see, *OR* write a little flag file on the hard disk which can become a logic part of the process.
    That appears and/or dissapears as needed.

    As well I also set another discrete flag file on the hard disk which, in effect, tells the whole operation that this master task is running as planned.

    OK, I then include a SLEEP task at the bottom of the loop, which does not affect the running of the master task. Following that sleep exit, the .CMD or .BAT file then has a reverse direction pointer that goes back to the start of the loop in it. OK, as long as the master pointer file code is found in the loop, it just hops of to the SLEEP call and, temporarily endlessly goes around and around the loop until ..

    When the master process is over, then both the error exit will be found,as well
    as the process will erase the marker file that causes the loop to go loop-ti-loop! At that point, since the master .BAT or .CMD file now knows that
    the critical process is finished, it sends the loop internally to restart or awaken the other tasks. And following that process, it jumps out of the master
    loop to a lower point in the .BAT or .CMD file and off we go into normal work again.

    The reason I use the SLEEP tool is that by doing this I don't take up a chunk of CPU time just to run romp-ity-romp around and around the loop,plus one more safety point. I have another vector enabled. If something jams up this whole process and a major event time has passed, that would tell the whole system that a jam has taken place, due again to the presence or absence of uet another
    little flag file name there, I can tell the whole .BAT or .CMD file to take off
    on a master fixit jump point in the whole process. Which can cure things and get the whole process going again without me being around .. except very rarely.

    A long time ago my friend Paul Sittler, who wrote the very first virus that ever appeared in the original FidoNet, which we were running on 300 and 1200 baud modems at the time, taught me something! Always do everything you can to let the operating system do the work. Grin!

    I've lived that way as best I can ever since. And, no, the virus deal was not deliberate! It was an accident. He wrote a CPM operating system program that figured out how I could isolate EchoMail messages to my 1:117/3000 private network addition to net 1:117 here. Then released it to all the then Fido operations. They were estatic! But he made an error. The message to each other node was a separate file on the hard disk .. or floppy. And he forgot to
    erase that message/file after it went out to the next place.

    In a week or so, the whole FidoNet system went down when all the servers ran out of disk space.

    Chuckle. So don't forget to erase the flag points on your hard drive after you
    play this cool stunt and they are no longer needed..

    ;)

    Mike @ 117/100



    ---
    * Origin: BV HUB CLL(979)696-3600 (1:117/100)
  • From Sean Dennis@1:18/200 to Mike Luther on Sunday, February 20, 2011 22:59:31
    Hello, Mike.

    Saturday February 19 2011 at 22:38, you wrote to me:

    Chuckle. So don't forget to erase the flag points on your hard drive after you play this cool stunt and they are no longer needed..

    What I may simply do is this: write a quickie Pascal program that monitors for the existance of a semaphore then calls up the BBS nodes to restart. It's fairly simple to do. I just have to do it. I did learn a bit though about dealing with Maximus and its events file though.

    Later,
    Sean

    ... There are people who have money and people who are rich. - Coco Chanel
    --- GoldED/2 3.0.1
    * Origin: Paragon BBS - 423.926.7999 - paragon.darktech.org (1:18/200)
  • From Mike Tripp@1:382/61 to Sean Dennis on Tuesday, February 22, 2011 21:20:36
    Hello Sean!

    17 Feb 11 22:39, Sean Dennis wrote to Mike Tripp:

    For some reason I was under the impression that EVENTS00.BBS was for
    all nodes, but since that's not the case, I just need one node to
    actually run the event but I need all of the nodes to shut down at
    once. Any idea how to do that?

    You could have a primary node that exit with an errorlevel that points to the real work. The rest exit with another errorlevel at the same time that either quits completely (to be restarted by the primary node at the end of the work routine) or goes into infinite loop on a semaphore that is create by the primary at the start of the work and deleted by the primary at the end of the work.


    .\\ike

    --- GoldED 2.50+
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)
  • From Sean Dennis@1:18/200 to Mike Tripp on Wednesday, February 23, 2011 00:27:13
    Hello, Mike.

    Tuesday February 22 2011 at 21:20, you wrote to me:

    You could have a primary node that exit with an errorlevel that points
    to the real work. The rest exit with another errorlevel at the same
    time that either quits completely (to be restarted by the primary node
    at the end of the work routine) or goes into infinite loop on a
    semaphore that is create by the primary at the start of the work and deleted by the primary at the end of the work.

    That's a good idea, thanks! I'll have to implement that.

    Later,
    Sean

    ... You're never too old to learn something new.
    --- GoldED/2 3.0.1
    * Origin: Paragon BBS - 423.926.7999 - paragon.darktech.org (1:18/200)
  • From Robert Wolfe@1:18/200 to Sean Dennis on Wednesday, February 16, 2011 11:14:04
    |-----------------|Sean Dennis wrote:
    I'm having problems with a single nightly event running at
    the wrong (very wrong!) time. I have but a single
    EVENTS00.BBS file for the entire system which is one dialup
    node and three telnet. The line in question:
    |-------------------------------------|

    Are you using anything like Internet Rex that can schedule events on its
    own? Just curious as that is what I used to use before going back to
    WINServer and using wcEvent.

    ... !ti tae t'nac llits uoy tub iUG eb yam ti
    ___
    * TLX v4.10 *

    --- Maximus/2 3.01
    * Origin: Paragon BBS - paragon.darktech.org - 423.926.7999 (1:18/200)
  • From Sean Dennis@1:18/200 to Robert Wolfe on Wednesday, February 16, 2011 12:10:31
    Hello, Robert.

    Wednesday February 16 2011 at 11:14, you wrote to me:

    Are you using anything like Internet Rex that can schedule events on
    its own? Just curious as that is what I used to use before going back
    to WINServer and using wcEvent.

    Yes, but this isn't what I need: I need Maximus to shut down /all nodes/ while
    I do nightly maintenance. Max itself is supposed to do that when you use the EVENTS00.BBS file.


    Later,
    Sean

    ... I cannot live without books. - Thomas Jefferson
    --- GoldED/2 3.0.1
    * Origin: Paragon BBS - 423.926.7999 - paragon.darktech.org (1:18/200)
  • From Mike Tripp@1:382/61 to Sean Dennis on Thursday, February 17, 2011 14:35:30
    Hello Sean!

    16 Feb 11 12:10, Sean Dennis wrote to Robert Wolfe:

    Yes, but this isn't what I need: I need Maximus to shut down /all
    nodes/ while I do nightly maintenance. Max itself is supposed to do
    that when you use the EVENTS00.BBS file.

    EVENTS00.BBS is intended for a single-node setup/no task number assigned. For multi-node, each node should have a unique task number, events file, log file etc. The instance that is assigned task# 1 will read EVENTS01.BBS, task#2 EVENTS02.BBS, etc. Things will probably behave when the sharing issues are resolved.

    .\\ike

    --- GoldED 2.50+
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)
  • From Sean Dennis@1:18/200 to Mike Tripp on Thursday, February 17, 2011 22:39:09
    Hello, Mike.

    Thursday February 17 2011 at 14:35, you wrote to me:

    EVENTS00.BBS is intended for a single-node setup/no task number
    assigned. For multi-node, each node should have a unique task number, events file, log file etc. The instance that is assigned task# 1 will read EVENTS01.BBS, task#2 EVENTS02.BBS, etc. Things will probably
    behave when the sharing issues are resolved.

    For some reason I was under the impression that EVENTS00.BBS was for all nodes,
    but since that's not the case, I just need one node to actually run the event but I need all of the nodes to shut down at once. Any idea how to do that?

    Later,
    Sean

    ... Trouble is only opportunity in work clothes. - Henry J. Kaiser
    --- GoldED/2 3.0.1
    * Origin: Paragon BBS - 423.926.7999 - paragon.darktech.org (1:18/200)
  • From Dallas Hinton@1:153/715 to Sean Dennis on Friday, February 18, 2011 00:24:12
    Hi Sean -- on Feb 17 2011 at 22:39, you wrote:

    For some reason I was under the impression that EVENTS00.BBS was for
    all nodes, but since that's not the case, I just need one node to
    actually run the event but I need all of the nodes to shut down at
    once. Any idea how to do that?

    I hadn't thought of that, but of course it's correct:

    touch c:\flags\events00.bbs
    touch c:\flags\events01.bbs
    touch c:\flags\events02.bbs
    touch c:\flags\events03.bbs
    call Maint.bat
    del c:\flags\events*.bbs


    Cheers... Dallas

    --- timEd/386 1.10.y2k+
    * Origin: The BandMaster, CANADA [telnet: bandmaster.tzo.com] (1:153/715)
  • From Sean Dennis@1:18/200 to Dallas Hinton on Friday, February 18, 2011 11:43:47
    Hello, Dallas.

    Friday February 18 2011 at 00:24, you wrote to me:

    touch c:\flags\events00.bbs

    I'm not understanding why "touching" a text file would cause Maximus to shut down each node? It's not a semaphore file...

    Later,
    Sean

    ... There's no future in time travel.
    --- GoldED/2 3.0.1
    * Origin: Paragon BBS - 423.926.7999 - paragon.darktech.org (1:18/200)
  • From Dallas Hinton@1:153/715 to Sean Dennis on Friday, February 18, 2011 14:01:08
    Hi Sean -- on Feb 18 2011 at 11:43, you wrote:

    I'm not understanding why "touching" a text file would cause Maximus
    to shut down each node? It's not a semaphore file...

    Damn, you're right. I've GOT to stop thinking about Binkley! :-)

    The docs say (as I'm sure you know):
    Each node on a multinode system must have a separate events
    file. However, all of the event files use the same format, so
    you can simply copy a master events file to events01.bbs,
    events02.bbs, and so on. (If Maximus cannot find the event
    file for a specific node, it will try to read default event
    information from events00.bbs, regardless of the node number
    of the current session.)

    So without having tried it, it should work with just one events00.bbs
    file. However, have you tried just copying that file to 01, 02, etc?

    It's also worth reminding you that Max must NOT be running when you
    change the events*.bbs files.

    Good luck!


    Cheers... Dallas

    --- timEd/386 1.10.y2k+
    * Origin: The BandMaster, CANADA [telnet: bandmaster.tzo.com] (1:153/715)
  • From Sean Dennis@1:18/200 to Dallas Hinton on Friday, February 18, 2011 19:19:19
    Hello, Dallas.

    Friday February 18 2011 at 14:01, you wrote to me:

    So without having tried it, it should work with just one events00.bbs file. However, have you tried just copying that file to 01, 02, etc?

    No, not yet, but I will...

    It's also worth reminding you that Max must NOT be running when you
    change the events*.bbs files.

    I didn't realize that...maybe that's what the problem was.

    Good luck!

    Thanks. I'll try it once I can figure out how to shut down the other nodes at once but only have one node actually run the event. :)

    Later,
    Sean

    ... A hero is one who knows how to hang on one minute longer. - Norwegian proverb

    --- GoldED/2 3.0.1
    * Origin: Paragon BBS - 423.926.7999 - paragon.darktech.org (1:18/200)
  • From Richard Webb@1:116/901 to Sean Dennis on Saturday, February 19, 2011 02:36:21
    HI SEan,

    On Fri 2039-Feb-18 19:19, Sean Dennis (1:18/200) wrote to Dallas Hinton:

    Thanks. I'll try it once I can figure out how to shut down the
    other nodes at once but only have one node actually run the event.
    :)

    IN case it gets sticky here's another idea for you that
    might work.

    Create the event you wish to have the logs copied, it
    branches to appropriate place in your 8cmd file where it
    deletes a certain semaphore. NOw bear with me, because
    you're going to use whatever means are at your disposal to
    reboot the system, which effectively shuts down all three
    nodes. Before they start up, your autoexec or equivalent
    looks for that semaphore you deleted. IF found you bypass
    the code which deals with your log files. If flag not
    found, invoke that piece of code, slice dice and puree log
    files as desired, create semaphore file.

    IF something else causes an unscheduled reboot semaphore
    exists, logs won't be touched until the event, which will
    then cause them to be processed because at invocation of the event the semaphore is deleted.

    NOt very elegant I know, but if you get stuck that might be
    one cure for you.


    Regards,
    Richard
    --- timEd 1.10.y2k+
    * Origin: (1:116/901)
  • From mark lewis@1:3634/12 to Sean Dennis on Saturday, February 26, 2011 11:09:11

    Chuckle. So don't forget to erase the flag points on your hard drive after you play this cool stunt and they are no longer needed..

    What I may simply do is this: write a quickie Pascal program that
    monitors for the existance of a semaphore then calls up the BBS
    nodes to restart. It's fairly simple to do. I just have to do it.
    I did learn a bit though about dealing with Maximus and its events
    file though.

    is there not a semaphore that you can write to have MAX simply exit and then catch that in a loop in the .BAT file?

    another thought would be something like what i do with my FD nodes and that is that they all exit via an event with a specific errorlevel... like my suggestion above, i catch that and simply loop the .BAT file until another semaphore is removed...

    trying to clarify...

    my main node that does the maint exits with an errorlevel and create a maint.sem semaphore... then it loops until all of the other nodes have exited and created or removed their "i'm up" semaphore files... the other nodes then loop until the maint.sem semaphore is removed... when the main node sees that all the other nodes are down, then it runs the maint and the last thing done is
    to remove the maint.sem semaphore before reloading to the top of the .BAT... all the other nodes jump to the top of the .BAT for their restart, too...

    the problem may be the semaphores and exit errorlevels that you can access and catch, though...

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Mike Tripp on Saturday, February 26, 2011 11:15:28

    For some reason I was under the impression that EVENTS00.BBS was for
    all nodes, but since that's not the case, I just need one node to
    actually run the event but I need all of the nodes to shut down at
    once. Any idea how to do that?

    You could have a primary node that exit with an errorlevel that
    points to the real work. The rest exit with another errorlevel at
    the same time that either quits completely (to be restarted by the
    primary node at the end of the work routine) or goes into infinite
    loop on a semaphore that is create by the primary at the start of
    the work and deleted by the primary at the end of the work.

    that's what i do... you just stated it better than i ;)

    )\/(ark


    * Origin: (1:3634/12)
  • From Mike Tripp@1:382/61 to mark lewis on Saturday, February 26, 2011 11:56:48
    Hello mark!

    26 Feb 11 11:15, mark lewis wrote to Mike Tripp:

    that's what i do... you just stated it better than i ;)

    :)

    As much as Scott loved Vince and Binkleyterm, I'm surprised he didn't copy the concept of the forced exit flag semaphore into Maximus. It is simple to send the kill command to any chosen node in Binkley, but depending on what you're doing, you may the need the belt+suspenders you mentioned with FD to make sure that the node has detected and responded to the flag.

    .\\ike

    --- GoldED 2.50+
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)
  • From Sean Dennis@1:18/200 to mark lewis on Saturday, February 26, 2011 13:31:53
    Hello, mark.

    Saturday February 26 2011 at 11:09, you wrote to me:

    the problem may be the semaphores and exit errorlevels that you can
    access and catch, though...

    Max simply exits via an errorlevel and that's the end of its involvement until it's called back to start again. What I've done is written a little Pascal program that will cause the node to "sleep" until the semaphore file that is specified when it's called is deleted.

    Here's the program:

    === Cut ===
    Program WaitFor;

    Uses
    SysUtils;

    Begin
    Repeat
    SysCtrlSleep(10);
    Until Not FileExists(ParamStr(1));
    End.
    === Cut ===

    Since all of my BBS nodes run off of a single batch file, here's the part that matters (it's called via an errorlevel exit):

    === Cut ===
    :Nightly
    echo . > maint.run
    if %1 == 2 goto runmaint
    waitfor maint.run
    goto loop
    :runmaint
    rem ** Run Scrabble nightly maintenance
    cd\doors\scrab
    sdmaint 2
    cd\max\drom
    checkreq
    cd\max
    call scores.cmd 32
    call scores.cmd 33
    call scores.cmd 34
    rem ** Purge inactive (no calls in 60 days) BBS users ***
    rem muep /p
    rem *** Rebuild the file base indices ***
    fbp -a
    del maint.run
    goto Loop
    === Cut ===

    "Loop" is the top of the batch file that will call each node back up. This is untested as of yet but I'll work on it later tonight hopefully.

    Later,
    Sean

    ... Experience is a good school. But the fees are high. - Heinrich Heine
    --- GoldED/2 3.0.1
    * Origin: Paragon BBS - 423.434.0851 - paragon.darktech.org (1:18/200)
  • From mark lewis@1:3634/12 to Sean Dennis on Saturday, February 26, 2011 20:22:13

    the problem may be the semaphores and exit errorlevels that you can
    access and catch, though...

    Max simply exits via an errorlevel and that's the end of its
    involvement until it's called back to start again.

    right... what i am/was looking at was having the ability of causing it/them to exit with a specific errorlevel that can be caught and acted upon...

    What I've done is written a little Pascal program that will cause
    the node to "sleep" until the semaphore file that is specified
    when it's called is deleted.

    that should work as well as what i suggested... as long as the nodes release all files and reload them when called upon... i don't see any problems with that ;)

    Here's the program:

    that look svery similar to my operation over here :)

    )\/(ark


    * Origin: (1:3634/12)
  • From Sean Dennis@1:18/200 to mark lewis on Saturday, February 26, 2011 22:32:18
    Hello, mark.

    Saturday February 26 2011 at 20:22, you wrote to me:

    that look svery similar to my operation over here :)

    We'll see if it works tonight. :)

    Later,
    Sean

    ... Getting ready is the secret of success. - Henry Ford
    --- GoldED/2 3.0.1
    * Origin: Paragon BBS - 423.434.0851 - paragon.darktech.org (1:18/200)