Cron/2

Versione: 
1.41
Data rilascio: 
Martedì, 31 Gennaio, 1995

Licenza:

Interfaccia:

Port del programma UNIX cron. Cron/2 può interfacciarsi con Syslogd/2.

Questo software è distribuito come pacchetto compresso, da scaricare e installare manualmente; se ci sono prerequisiti da soddisfare, andranno anch'essi scaricati e installati manualmente.

Installazione manuale

Il programma è distribuito come pacchetto ZIP: scaricare in una cartella temporanea e scompattare nella cartella di destinazione. Vedi sotto per il(i) link di download.

E' possibile installare i prerequisiti con rpm, eseguendo la stringa seguente in una finestra comandi:

yum install emxrt RXU

Documentazione in linea

Qui di seguito trovi i link di download per l'installazione manuale del software:

Cron/2 (1/9/2024, Anton Monroe) Readme/What's new
A third generation of the Cron.cmd daemon started by Jeroen Hoppenbrouwers and improved by Paul Ratcliffe. This version fixes a few bugs, is more Unix-like, and adds support for ranges, lists, step values, and names of days and months. The Cron daemon can be paused for a given number of minutes, running the delayed jobs when it resumes. Comes with a startup script that lets you start, stop, query, pause, and resume the Cron daemon from the command line. ------------------------------------------------------------- Cron.cmd is the Cron daemon that runs scheduled jobs. It is normally launched by typing StartCron.cmd START You can stop the daemon with StartCron.cmd STOP Any customizing you might want to do can be done by editing the Setup section at the beginning of StartCron.cmd. In most cases you will not need to do even that. The usual configuration is Unix-like. If you have a %Unixroot variable, Cron.cmd will read a crontab file at %etc\crontab or %unixroot\etc\crontab, log messages to %unixroot\var\log\<logfile>, and create a PID file at %unixroot\var\run\cron.pid. If you do not have a Unixroot, everything will be in the same directory as StartCron.cmd. There are a couple of things I added for my own convenience. If a directory called \var\run\init\ exists, Cron.cmd will use that for its PID file instead of \var\run\; and if a directory \var\log\cron\ exists, it will be used for log file(s) instead of \var\log\. To see the available commands and current configuration, type StartCron.cmd HELP Normally the Cron.cmd daemon is a detached session. For testing you can type StartCron.cmd START -foreground which will run it in a VIO window with logging to the screen. Cron.cmd will start a new log file at the beginning of each month. The files will have names like "cron-2024-08-Aug.log". To change that, you will need to edit the Setup section of StartCron.cmd where it says renamelog = 'month' the other choices are renamelog = 'day' renamelog = 'never' For the format of the crontab file, see the comments in the example crontab included here. It provides most but not all of the features of Unix cron. Bug reports and suggestions are welcome. Anton Monroe
 www.hobbesarchive.com/Hobbes/pub/os2/util/schedule/CronCmd_3.zip  local copy
Cron (3/10/2003, Jeroen Hoppenbrouwers, Paul Ratcliffe) Readme/What's new
Simple but efficient and functional UNIX Cron clone for OS/2 ============================================================ This program got written in a hurry since the available Cron clones for OS/2 didn't do what I needed: dispatch jobs in the background while running *invisibly* on my system. What is Cron? ------------- Cron (the name is a UNIX relic) is a process that gets started when your machine boots and never stops until you shutdown. During its life, it checks the contents of a certain disk file every minute (you can easily change the timing granularity e.g. to 5 minutes). If it finds that the current time and date are matched by an entry in the file, Cron starts up the process also named in the file. This sounds boring but in practice, Cron is the most handy tool for repetitive background scheduling I ever encountered. Controlling Cron: the CRONTAB file ---------------------------------- The CRONTAB file (UNIX relic again) contains the control lines for Cron. Each line contains six elements: m h d m w command The first five elements are time and date patterns. A star '*' here means "always fits". So, if you want to run a certain program each day at noon, you enter 0 12 * * * command in the CRONTAB file. This line means: "if Cron detects that the current time and date equal zero minutes, 12 hours, any day-of-the-month, any month-of-the-year, and any day-of-the-week, it starts 'command'". In the same way, you can specify e.g. a backup program that runs on Mondays at 01:00 hours: 0 1 * * 1 command (1 = Monday, 7 = Sunday etc.). To be more flexible, Cron also accepts multiple values. A simple driver for a cuckoo clock program might contain: 0,30 * * * * command to fire up 'command' at each full and half hour. Ranges are also possible; to have the cuckoo keep its mouth shut during the night, you enter: 0,30 8-20 * * * command and you can combine both individual values and ranges as in 0,30 0,8-20 * * 1-5 command Comments can also be entered into the CRONTAB file; just start them with a # (in fact, Cron treats everything as a comment if it does not start with a number). Starting Cron ------------- Here the difficulty starts. The available Crons for OS/2 had to be started in a session of their own, because of the way in which they started the processes in the CRONTAB file. Running a program in a session however: A) Gives you an icon and an entry in the Window List B) Asks you to close the window at system shutdown C) Costs you more (memory) resources A) and B) especially troubled me. I wanted Cron to run completely invisibly, and to die without making trouble. This is only possible if you detach a program under OS/2 instead of start it. Unfortunately, detached programs cannot 'start' other programs (DosStartSession) and the available Crons did exactly this. To start CRON, type "detach cron". That's it. You get the PID of Cron back and could use that for a KILL command later on. Running Cron directly from a command prompt by just typing "cron" works as well and now you can follow Cron's output messages. Ctrl-C ends Cron. The CRONTAB file is located in the same directory as CRON.CMD If you want Cron to start up at each boot (the way it is intended to be run), be careful. You cannot just put Cron into your CONFIG.SYS file (with a "RUN=" command), since Cron uses some REXX functions that cannot be used if PM is not running. Don't ask me why; it just happened to be this way. So you either have to run Cron from your STARTUP.CMD file or from your Startup folder. In STARTUP.CMD, just add "detach cron". In your Startup folder, create a Program Object or shadow CRON.CMD to do the same. Personally I prefer the STARTUP.CMD file. You can log Cron activities and errors by making use of the OS/2 stdout and stderr redirection capabilities. Do something like: detach cron > cron.log 2> cron.err and you get two files usually with meaningful output. General ------- Cron was written in surprisingly few lines of REXX, OS/2's command script interpreter/compiler. Therefore the program is the source. You can modify everything you like. On my system, Cron's activities are barely noticeable (one flick of the disk, no CPU spike on PULSE). Instead of using SysSleep (a RexxUtil function) I could have used my self-written SLEEP program (five lines of C code) that would have enabled Cron to be started from the CONFIG.SYS. I didn't because SLEEP is not part of any standard distribution and I wanted to be as general as possible. Jeroen Hoppenbrouwers (hoppie@kub.nl) Infolab, Tilburg University The Netherlands
 hobbes.nmsu.edu/download/pub/os2/util/schedule/cron.zip  local copy
Cron/2 v. 1.41 (8/3/2001, Detlef Graef) Readme/What's new
CRON/2 Client/server-based timed program execution version 1.41 A program by Bob Hood Copyright (C) 1993-1994 Bob Hood CRON/2 is a copyrighted program. You may use CRON/2 in any environment for any purpose. You may not sell CRON/2, nor charge a fee for CRON/2 except where a nomimal charge would be applicable for electronically transferring CRON/2 any selected medium. Program and documentation Copyright (C) 1993-1994 Bob Hood. All Rights Reserved. OS/2 and products marked (TM) are trademarks or registered trademarks of IBM Corporation CRON/2 --------------------------------------------------------------------------- CRON/2 is another in a series of UNIX cron clones to the OS/2 platform. I didn't write CRON/2 to compete with any of the others; instead, I wrote CRON/2 to give me more control over my applications than the others. I missed the ability to specify the launching of applications to the degree afforded me by the UNIX version. Most clones for OS/2 I've seen (and I'm sure I've not seen them all) were not as closely modelled after the UNIX version as CRON/2. However, you can judge for yourself. CRON/2 adds a new (and perhaps worthless) twist in that it can be used for networking timed launches between systems. Utilizing TCP/IP, CRON/2 can act as a client, a server, or both in the same application by allowing CRON/2 to launch applications on remote systems at a time of its choosing. This allows a central machine to control the running of processes based upon factors that it alone is aware of (such as a central file server initiating individual machine backups when network load is minimal). CRON/2 provides both network and non-network versions in the same distribution. The non-network version, denoted by the lack of an "N" on the executable name (i.e., CRON2.EXE), is provided for those individuals without IBM's TCP/IP product installed. CRON/2 also offers the convenience of a second UNIX utility: the UNIX at command. The at command not only provides a quick method of launching a process once, it also provides a command-line interface to CRON/2 for other applications. If you like CRON/2, that's fantastic! It's my first OS/2 application. If you don't like CRON/2, that's fantastic too! Go find (or write) another that more closely suits your needs. I wrote CRON/2 to suit mine. WHO CAN USE CRON/2 ---------------------------------------------------------------------- Anybody. Anywhere. Anytime. This is a FreeWare product. The first of many of my contributions back to IBM for making its development environment easily accessable to developers. Thanks, Big Blue. You still have a lot of suprises left for us... THE FUTURE ---------------------------------------------------------------------- I plan to develop a PM version of CRON/2 that supports drag-and-drop and utilizes some container classes. Other additions will likely only be user-interface-related: I like CRON/2's mechanics of specifying and launching applications just the way it is. USING CRON/2 --------------------------------------------------------------------------- As I stated previously, I wrote CRON/2 for my own needs and edification. Because of this, you may find the documentation spartan (and then again, you may not; what I consider "spartan" others consider verbose). I will, however, explain enough to use the application. Please note that this documentation covers all aspects of the CRON/2 system (TCP/IP, non-TCP/IP, and at). If you have a version that does not utilize all of CRON/2's available functionality, simply skip those sections that aren't applicable. STARTING CRON/2 ---------------------------------------------------------------------- CRON/2 can be started with a number of command-line switches. The syntax appears as: CRON2N [[-n[s[0/1]]] [-s[0/1]] [-p<port>]] [-l[<logfile>]] for the TCP/IP version, or simply CRON2 [-l[<logfile>]] for the non-TCP/IP version. Each option is explained below: -n enables networking. this option will cause CRON/2 to initialize TCP/IP for use with entries in CRON2.DAT that specify a host name with braces ({}). Not specifying this option when CRON2.DAT contains remote launches, or a missing TCP/IP installation on your machine, will cause CRON/2 to ignore those entries. -s enables the built-in TCP/IP server. this server runs as a separate thread within CRON/2, and is required to allow remote CRON/2 process to launch applications locally on your machine. this parameter can be followed by an optional digit in the range 0 to 1. a value of 0 indicates that there will be no security for launching local processes initiated remotely. Any application that a remote CRON/2 process requests will cause the local CRON/2 to attempt to launch it. a value of 1 activates security on the local process. launch requests made by remote processes MUST appear identically in the local process's CRON2.DAT file, or the launch request will not be serviced. as illustrated, this parameter can be attached to the "-n" option to enable both client and server portions of CRON/2 in the same process using separate threads. -p specifies the TCP/IP port to use for initializing sockets. this value defaults to port 10000 if not specified. -l activates activity logging. this options creates the file "CRON2.LOG" in the same drive/directory that CRON/2 was started from. DIRECTING CRON/2: THE CRON2.DAT FILE ---------------------------------------------------------------------- Unlike UNIX, CRON/2 uses a single command file for specifying applications and launch times. This file is called CRON2.DAT, and MUST reside in the directory where the CRON/2 executable is started from. A sample CRON2.DAT file is provided in the distribution with sample entries commented out. With few execptions, the CRON2.DAT file appears and behaves identically to any UNIX cron files you may have worked with before: o Comments are denoted by a pound sign (#) in column one o Command entries appear one to a line o A virtually-unlimited number of entries may appear o Each entry contains the usual cron fields: o minute o hour o day o month o day of the week o executable file and options Beyond these items, the CRON2.DAT file contains some OS/2-specific entries necessary for controlling the types and appearance of applications when they are launched. Four additional fields appear in each application record: o Application type: "VDM", "OS2", or "PM" o Process priority: "FG" for foreground, "BG" for background) o Appearance of application: "WIND" for windowed, "FULL" for full screen The fourth field, not highlighted above, is optional, and preceeds the path/executable entry in the CRON2.DAT file. This field is denoted by braces ({}), and specifies the name of a remote system on which this application should be launched. Addtionally, each appearance token (WIND or FULL) may be followed by a minus sign (-) to indicate that the application should be started as a minimized icon. Appearing at the extreme bottom of the CRON2.DAT file is the "at" delimeter, represented by the at sign (@). It is extremely important that all of your normal CRON/2 entries appear in the CRON2.DAT file before this token. CRON/2 uses the entries following the @ token in of the CRON2.DAT file to house the at command's entries (see the at command later in this document). Be warned that entries in this section come and go without warning. Treat the @ symbol as an electric fence around a off-limits area. Also, CRON/2 will function with or without the @ token appearing in the file, however the at command will not. If you remove the @ token, using the at command will produce undefined results (so just leave it there ;-). The following are example CRON/2 entries that I use to control my USENET news feed from OS/2: 0 1 * * * VDM BG WIND c:\usenet\snews\expire.bat | 25,55 0-6 * * * VDM BG WIND c:\usenet\snews\sendbtch.bat 0,30 * * * * OS2 BG FULL- c:\uucp_os2.cmd 0 2 * * * OS2 FG WIND del c:\os2\locks\*.lck For those of you unfamiliar with cron, the first entry launches the MS-DOS batch file "expire.bat" in the "c:\usenet\snews" directory at 1:00 am each day. It runs in a Virtual DOS Machine session, in the background, in a PM window. | The second entry is different in that it runs an MS-DOS batch file at | 25 and 55 after each hour between midnight and six (00:00-06:00). The third entry operates on an OS/2-specific command file. This command file is initiated at the top of, and half past, each hour. It is run in an OS/2 text session, in the background, in a full-screen window that is minimized to a Presentation Manager icon as soon as it starts. You can specify multiple entries for minute, day, hour, month, and day-of-the-week by separating them with commas. You can find additional information about cron by consulting a UNIX manual or man page. DEALING WITH NON-FILES ---------------------------------------------------------------------- When CRON/2 processes CRON2.DAT, it performs a verification of each executable to make sure that it exists and can be found where you've indicated it should be (if a drive/path is included with the name). However, if CRON/2 cannot verify the program's existence, it will assume that it is not smart enough to determine your intent. It will assume that the command processor you are using (CMD.EXE, 4OS2-32.EXE, etc.) IS smart enough and will submit it directly. Using this method, it is possible to embed built-in shell commands in CRON2.DAT instead of having to preface the entry with the name of your command processor, or creating another command file to perform the function. All non-file entries in CRON2.DAT are set to execute as OS/2 applictions. DYNAMIC SYNCHRONIZING ---------------------------------------------------------------------- To avoid having to stop and re-start CRON/2 when changes are made to CRON2.DAT, CRON/2 will check CRON2.DAT each minute to see if it has been changed since CRON/2 was started (or since the last time it processed CRON2.DAT). CRON/2 checks the size and date/time stamp of the CRON2.DAT file. If the file has changed since CRON/2 started or the last synchronize, CRON/2 will release it's internal list of processes, and create a new list with the altered contents of CRON2.DAT. DIRECTING ANOTHER CRON/2: REMOTE TIMED LAUCHING ---------------------------------------------------------------------- In the TCP/IP version (CRON2N.EXE), CRON/2 has the ability to launch applications on other TCP/IP-networked OS/2 systems running another CRON/2 process with its TCP/IP server activated. To utilize this feature, you must have acquired and sucessfully installed IBM's TCP/IP 1.2 (TM) product on each system that you plan to run the CRON/2 server on. You specify this unique cron feature in two ways: first, you must activate CRON/2's TCP/IP support when it is started by one or a combination of the -n or -s command-line paramaters; second, you can optionally select entries in CRON2.DAT to launch on remote systems by prefixing the executable name with the name of the remote system. Here is an example entry: 11,38,42,59 * * * * PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe This entry in CRON2.DAT will launch the OS/2 PM Jigsaw application in a full-screen Presentation Manager window as the foreground application at 11, 38, 42, and 59 minutes after each hour. The difference in this entry is that it doesn't launch on the local machine, but on the remote machine named "bhlocal1". If you use domain names to specify remote machines, the domain name must reside in your TCPIP\ETC\hosts file. You may also elect to specify remote hosts in dotted-decimal format to avoid domain name resolving (i.e., {192.100.100.2} instead of {bhlocal1}). Needless to say, the application (and path) you specify for the remote machine should actually exist. If security has been activated on the remote machine (i.e., -s1 or -ns1), with the exception of the time/date/dow information, the application entry fields in the local CRON2.DAT file must match EXACTLY with those contained in the remote machine's CRON2.DAT file for the application to be successfully launched remotely. The following examples illustrate a local and remote CRON2.DAT entry. Each entry will fail remote execution (note that time/date/dow information is not illustrated because is has no impact): PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe PM BG FULL {bhlocal1}c:\os2\apps\jigsaw.exe -- PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe PM FG FULL- {bhlocal1}c:\os2\apps\jigsaw.exe ----- PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe PM FG FULL {bhlocal1}c:\os2\apps\jigsaw ---------- However, the next two entries WILL successfully compare because options are not taken into consideration (note that the illustrated options to Jigsaw are bogus): PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe -3 -new Formatting of fields is not important, so spaces and tabs between fields in the CRON2.DAT will not be taken into consideration when security is active. LOG-ABLE COMMENTS --------------------------------------------------------------------------- It is sometimes useful to accompany log files with comments. For this reason, CRON/2 allows "logable" comments to be included in the CRON2.DAT file. Normal comments in the CRON2.DAT file are denoted by the pound sign (#) in the first column a CRON2.DAT line. Logable comments denoted by a pound sign followed by a dollar sign (#$). Logable comments must immediately preceed their CRON2.DAT entries. For example, #$ Ensure that all local articles are forwarded! 25,55 * * * * VDM BG WIND d:\usenet\snews\sendbtch.bat would result in a log file entry like # Ensure that all local articles are forwarded! Launching sendbtch.bat 8.03.1993 @ 00:55...done! "AT" YOUR COMMAND --------------------------------------------------------------------------- CRON/2 now sports a new, single-launch system that duplicates the functionality of the UNIX at command. The command is, in fact, called "at", and is a completely separate executable. Like CRON/2, the at sub-command of CRON/2 duplicates the operation of it's UNIX counterpart as closely as possible. And, like CRON/2, the CRON/2 at sub-command has both UNIX-specific and OS/2-specific parts. The CRON/2 at command has the following input parameters: at [-m] [-l] time [date] [[next | +increment] time_designation] job With the exception of the "-l" and "job" parameters, CRON/2's at command is identical to UNIX's. You can simply reference a UNIX man page for the at command for more information. The -l option allows you to get a quick look at what "job"s have been queued (keep in mind that if a queued job has launched, it will no longer be in the queue). The -m option, while it sends mail to the submitter when a queued job has been processed, does nothing (yet) under CRON/2. The remaining extension, "job", represents the parameters that must be provided to CRON/2's at command to complete the queuing of a job. The items are essentially identical to those that are placed into the CRON2.DAT file (sans the time/date information). For instance, here are the CRON/2 entries given previously as examples, represented in both CRON2.DAT and CRON/2 at format: 25,55 * * * * VDM BG WIND c:\usenet\snews\sendbtch.bat would become at now + 10 minutes vdm bg wind c:\usenet\snews\sendbtch.bat As a further example, 0,30 * * * * OS2 BG FULL- c:\uucp_os2.cmd could be used as at 9:30am tomorrow os2 bg full- c:\uucp_os2.cmd Another example: at 5am tuesday + 2 weeks vdm bg wind c:\usenet\snews\expire.bat Other combinations are left as an exercise for the reader =|^). COMMUNICATING WITH CRON/2 ---------------------------------------------------------------------- The CRON/2 at sub-command communicates with an operating CRON/2 process via a named piped. CRON/2 must be operational before you invoke the at command. Also, because the at command communicates through a named pipe, it can be run from literally anywhere (it doesn't have be in the same directory as CRON/2). GOTCHAS (non-bugs) --------------------------------------------------------------------------- o CRON/2 will barf if you specify either -ns1 or -s1 and there is no local CRON2.DAT file... o Starting CRON/2 with an empty CRON2.DAT file will generate a richly-deserved insult about your questionable parentage... o System error messages detected by CRON/2 are displayed as decimal only o If you are running any .CMD files from CRON2.DAT, you MUST have COMSPEC set in your OS/2 environment (this is usually automatic) o You can't fool OS/2 into running a minimized process as the foreground process...it knows you're only human... WHAT THE ... ?! (known bugs) --------------------------------------------------------------------------- o Starting applications with the FG token, either locally or remotely, will occasionally generate a 457 (ERROR_SMG_START_IN_BACKGROUND) error...I don't know why yet. Your process will run, however. o CRON/2 was developed using a beta compiler on a beta platform... so there... BUG REPORTS, QUESTIONS, COMMENTS, ATTA-BOYS... --------------------------------------------------------------------------- Bob Hood Mailnet : 1217 S. Independence Street Lakewood, CO 80232 | Internet : rhood@nyx.cs.du.edu <--- preferred!! | bbh@csci.csc.com AT&Tnet : (303) 980-8392 HISTORY --------------------------------------------------------------------------- 1.0 - Initial release 1.1 05.19.93 - added activity logging - added dynamic synchronizing of the CRON2.DAT file 1.2 05.26.93 - corrected a bug introduced in 1.1 that suspended the update of the on-screen date/time - corrected a problem with dynamic synchronizing that disabled the feature after the first process is launched - re-designed logging mechanism to allow access to the log file with any file viewer/editor while CRON/2 is running - added a mechanism to push log messages onto a FIFO queue when CRON/2 cannot access the log file - removed the option to specify a different log file as a result of CRON/2 changing drive/paths 1.3 08.06.93 - Corrected a bug that prevented CMD.EXE from launching processes correctly. CRON/2 was developed using 4OS2, which behaves differently. (Sorry Todd) - Added more fault tolerance for the handling of non-fatal errors - Altered CRON/2's behaviour with non-existent programs. Instead of issuing a warning and ignoring an entry if it cannot be physically located during CRON2.DAT processing, CRON/2 now marks the entry as a CMD file and submits it directly to %COMSPEC%. This allows built-in shell commands ("del", "copy", "move", etc.) to be used instead in place of executable programs. - Added logable comments to the CRON2.DAT file. Comments starting with "#$" are saved and associated with the entries they immediately preceed. These comments are then posted to the log file immediately preceeding the processes launch log. (Jon Hacker) - Split CRON/2 into network and non-network versions. Starting with this version, client/server versions of CRON/2 will contain an `n' after their version numbers (i.e., 1.3n). - Added the external `at' command. - Changed the misspelled word "questionalble" in the doc ;-) - Began including change-bars to illustrate new sections of the document between versions for veteran CRON/2 users. 1.4 ??.??.?? - Added the range operator (-) to the CRON2.DAT file. - Released the complete source code to the system. 1.41 02.2001 - Source can be compiled with IBM VAC++ 3.0 - minor changes to the source has been made dgraef@altavista.de
 hobbes.nmsu.edu/download/pub/os2/util/schedule/cron2141.zip  local copy
Cron v. 1.41 (24/1/2001, Bob Hood) Readme/What's new
CRON/2 Client/server-based timed program execution version 1.4 A program by Bob Hood Copyright (C) 1993-1994 Bob Hood CRON/2 is a copyrighted program. You may use CRON/2 in any environment for any purpose. You may not sell CRON/2, nor charge a fee for CRON/2 except where a nomimal charge would be applicable for electronically transferring CRON/2 any selected medium. Program and documentation Copyright (C) 1993-1994 Bob Hood. All Rights Reserved. OS/2 and products marked (TM) are trademarks or registered trademarks of IBM Corporation CRON/2 --------------------------------------------------------------------------- CRON/2 is another in a series of UNIX cron clones to the OS/2 platform. I didn't write CRON/2 to compete with any of the others; instead, I wrote CRON/2 to give me more control over my applications than the others. I missed the ability to specify the launching of applications to the degree afforded me by the UNIX version. Most clones for OS/2 I've seen (and I'm sure I've not seen them all) were not as closely modelled after the UNIX version as CRON/2. However, you can judge for yourself. CRON/2 adds a new (and perhaps worthless) twist in that it can be used for networking timed launches between systems. Utilizing TCP/IP, CRON/2 can act as a client, a server, or both in the same application by allowing CRON/2 to launch applications on remote systems at a time of its choosing. This allows a central machine to control the running of processes based upon factors that it alone is aware of (such as a central file server initiating individual machine backups when network load is minimal). CRON/2 provides both network and non-network versions in the same distribution. The non-network version, denoted by the lack of an "N" on the executable name (i.e., CRON2.EXE), is provided for those individuals without IBM's TCP/IP product installed. CRON/2 also offers the convenience of a second UNIX utility: the UNIX at command. The at command not only provides a quick method of launching a process once, it also provides a command-line interface to CRON/2 for other applications. If you like CRON/2, that's fantastic! It's my first OS/2 application. If you don't like CRON/2, that's fantastic too! Go find (or write) another that more closely suits your needs. I wrote CRON/2 to suit mine. WHO CAN USE CRON/2 ---------------------------------------------------------------------- Anybody. Anywhere. Anytime. This is a FreeWare product. The first of many of my contributions back to IBM for making its development environment easily accessable to developers. Thanks, Big Blue. You still have a lot of suprises left for us... THE FUTURE ---------------------------------------------------------------------- I plan to develop a PM version of CRON/2 that supports drag-and-drop and utilizes some container classes. Other additions will likely only be user-interface-related: I like CRON/2's mechanics of specifying and launching applications just the way it is. USING CRON/2 --------------------------------------------------------------------------- As I stated previously, I wrote CRON/2 for my own needs and edification. Because of this, you may find the documentation spartan (and then again, you may not; what I consider "spartan" others consider verbose). I will, however, explain enough to use the application. Please note that this documentation covers all aspects of the CRON/2 system (TCP/IP, non-TCP/IP, and at). If you have a version that does not utilize all of CRON/2's available functionality, simply skip those sections that aren't applicable. STARTING CRON/2 ---------------------------------------------------------------------- CRON/2 can be started with a number of command-line switches. The syntax appears as: CRON2N [[-n[s[0/1]]] [-s[0/1]] [-p<port>]] [-l[<logfile>]] for the TCP/IP version, or simply CRON2 [-l[<logfile>]] for the non-TCP/IP version. Each option is explained below: -n enables networking. this option will cause CRON/2 to initialize TCP/IP for use with entries in CRON2.DAT that specify a host name with braces ({}). Not specifying this option when CRON2.DAT contains remote launches, or a missing TCP/IP installation on your machine, will cause CRON/2 to ignore those entries. -s enables the built-in TCP/IP server. this server runs as a separate thread within CRON/2, and is required to allow remote CRON/2 process to launch applications locally on your machine. this parameter can be followed by an optional digit in the range 0 to 1. a value of 0 indicates that there will be no security for launching local processes initiated remotely. Any application that a remote CRON/2 process requests will cause the local CRON/2 to attempt to launch it. a value of 1 activates security on the local process. launch requests made by remote processes MUST appear identically in the local process's CRON2.DAT file, or the launch request will not be serviced. as illustrated, this parameter can be attached to the "-n" option to enable both client and server portions of CRON/2 in the same process using separate threads. -p specifies the TCP/IP port to use for initializing sockets. this value defaults to port 10000 if not specified. -l activates activity logging. this options creates the file "CRON2.LOG" in the same drive/directory that CRON/2 was started from. DIRECTING CRON/2: THE CRON2.DAT FILE ---------------------------------------------------------------------- Unlike UNIX, CRON/2 uses a single command file for specifying applications and launch times. This file is called CRON2.DAT, and MUST reside in the directory where the CRON/2 executable is started from. A sample CRON2.DAT file is provided in the distribution with sample entries commented out. With few execptions, the CRON2.DAT file appears and behaves identically to any UNIX cron files you may have worked with before: o Comments are denoted by a pound sign (#) in column one o Command entries appear one to a line o A virtually-unlimited number of entries may appear o Each entry contains the usual cron fields: o minute o hour o day o month o day of the week o executable file and options Beyond these items, the CRON2.DAT file contains some OS/2-specific entries necessary for controlling the types and appearance of applications when they are launched. Four additional fields appear in each application record: o Application type: "VDM", "OS2", or "PM" o Process priority: "FG" for foreground, "BG" for background) o Appearance of application: "WIND" for windowed, "FULL" for full screen The fourth field, not highlighted above, is optional, and preceeds the path/executable entry in the CRON2.DAT file. This field is denoted by braces ({}), and specifies the name of a remote system on which this application should be launched. Addtionally, each appearance token (WIND or FULL) may be followed by a minus sign (-) to indicate that the application should be started as a minimized icon. Appearing at the extreme bottom of the CRON2.DAT file is the "at" delimeter, represented by the at sign (@). It is extremely important that all of your normal CRON/2 entries appear in the CRON2.DAT file before this token. CRON/2 uses the entries following the @ token in of the CRON2.DAT file to house the at command's entries (see the at command later in this document). Be warned that entries in this section come and go without warning. Treat the @ symbol as an electric fence around a off-limits area. Also, CRON/2 will function with or without the @ token appearing in the file, however the at command will not. If you remove the @ token, using the at command will produce undefined results (so just leave it there ;-). The following are example CRON/2 entries that I use to control my USENET news feed from OS/2: 0 1 * * * VDM BG WIND c:\usenet\snews\expire.bat | 25,55 0-6 * * * VDM BG WIND c:\usenet\snews\sendbtch.bat 0,30 * * * * OS2 BG FULL- c:\uucp_os2.cmd 0 2 * * * OS2 FG WIND del c:\os2\locks\*.lck For those of you unfamiliar with cron, the first entry launches the MS-DOS batch file "expire.bat" in the "c:\usenet\snews" directory at 1:00 am each day. It runs in a Virtual DOS Machine session, in the background, in a PM window. | The second entry is different in that it runs an MS-DOS batch file at | 25 and 55 after each hour between midnight and six (00:00-06:00). The third entry operates on an OS/2-specific command file. This command file is initiated at the top of, and half past, each hour. It is run in an OS/2 text session, in the background, in a full-screen window that is minimized to a Presentation Manager icon as soon as it starts. You can specify multiple entries for minute, day, hour, month, and day-of-the-week by separating them with commas. You can find additional information about cron by consulting a UNIX manual or man page. DEALING WITH NON-FILES ---------------------------------------------------------------------- When CRON/2 processes CRON2.DAT, it performs a verification of each executable to make sure that it exists and can be found where you've indicated it should be (if a drive/path is included with the name). However, if CRON/2 cannot verify the program's existence, it will assume that it is not smart enough to determine your intent. It will assume that the command processor you are using (CMD.EXE, 4OS2-32.EXE, etc.) IS smart enough and will submit it directly. Using this method, it is possible to embed built-in shell commands in CRON2.DAT instead of having to preface the entry with the name of your command processor, or creating another command file to perform the function. All non-file entries in CRON2.DAT are set to execute as OS/2 applictions. DYNAMIC SYNCHRONIZING ---------------------------------------------------------------------- To avoid having to stop and re-start CRON/2 when changes are made to CRON2.DAT, CRON/2 will check CRON2.DAT each minute to see if it has been changed since CRON/2 was started (or since the last time it processed CRON2.DAT). CRON/2 checks the size and date/time stamp of the CRON2.DAT file. If the file has changed since CRON/2 started or the last synchronize, CRON/2 will release it's internal list of processes, and create a new list with the altered contents of CRON2.DAT. DIRECTING ANOTHER CRON/2: REMOTE TIMED LAUCHING ---------------------------------------------------------------------- In the TCP/IP version (CRON2N.EXE), CRON/2 has the ability to launch applications on other TCP/IP-networked OS/2 systems running another CRON/2 process with its TCP/IP server activated. To utilize this feature, you must have acquired and sucessfully installed IBM's TCP/IP 1.2 (TM) product on each system that you plan to run the CRON/2 server on. You specify this unique cron feature in two ways: first, you must activate CRON/2's TCP/IP support when it is started by one or a combination of the -n or -s command-line paramaters; second, you can optionally select entries in CRON2.DAT to launch on remote systems by prefixing the executable name with the name of the remote system. Here is an example entry: 11,38,42,59 * * * * PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe This entry in CRON2.DAT will launch the OS/2 PM Jigsaw application in a full-screen Presentation Manager window as the foreground application at 11, 38, 42, and 59 minutes after each hour. The difference in this entry is that it doesn't launch on the local machine, but on the remote machine named "bhlocal1". If you use domain names to specify remote machines, the domain name must reside in your TCPIP\ETC\hosts file. You may also elect to specify remote hosts in dotted-decimal format to avoid domain name resolving (i.e., {192.100.100.2} instead of {bhlocal1}). Needless to say, the application (and path) you specify for the remote machine should actually exist. If security has been activated on the remote machine (i.e., -s1 or -ns1), with the exception of the time/date/dow information, the application entry fields in the local CRON2.DAT file must match EXACTLY with those contained in the remote machine's CRON2.DAT file for the application to be successfully launched remotely. The following examples illustrate a local and remote CRON2.DAT entry. Each entry will fail remote execution (note that time/date/dow information is not illustrated because is has no impact): PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe PM BG FULL {bhlocal1}c:\os2\apps\jigsaw.exe -- PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe PM FG FULL- {bhlocal1}c:\os2\apps\jigsaw.exe ----- PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe PM FG FULL {bhlocal1}c:\os2\apps\jigsaw ---------- However, the next two entries WILL successfully compare because options are not taken into consideration (note that the illustrated options to Jigsaw are bogus): PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe PM FG FULL {bhlocal1}c:\os2\apps\jigsaw.exe -3 -new Formatting of fields is not important, so spaces and tabs between fields in the CRON2.DAT will not be taken into consideration when security is active. LOG-ABLE COMMENTS --------------------------------------------------------------------------- It is sometimes useful to accompany log files with comments. For this reason, CRON/2 allows "logable" comments to be included in the CRON2.DAT file. Normal comments in the CRON2.DAT file are denoted by the pound sign (#) in the first column a CRON2.DAT line. Logable comments denoted by a pound sign followed by a dollar sign (#$). Logable comments must immediately preceed their CRON2.DAT entries. For example, #$ Ensure that all local articles are forwarded! 25,55 * * * * VDM BG WIND d:\usenet\snews\sendbtch.bat would result in a log file entry like # Ensure that all local articles are forwarded! Launching sendbtch.bat 8.03.1993 @ 00:55...done! "AT" YOUR COMMAND --------------------------------------------------------------------------- CRON/2 now sports a new, single-launch system that duplicates the functionality of the UNIX at command. The command is, in fact, called "at", and is a completely separate executable. Like CRON/2, the at sub-command of CRON/2 duplicates the operation of it's UNIX counterpart as closely as possible. And, like CRON/2, the CRON/2 at sub-command has both UNIX-specific and OS/2-specific parts. The CRON/2 at command has the following input parameters: at [-m] [-l] time [date] [[next | +increment] time_designation] job With the exception of the "-l" and "job" parameters, CRON/2's at command is identical to UNIX's. You can simply reference a UNIX man page for the at command for more information. The -l option allows you to get a quick look at what "job"s have been queued (keep in mind that if a queued job has launched, it will no longer be in the queue). The -m option, while it sends mail to the submitter when a queued job has been processed, does nothing (yet) under CRON/2. The remaining extension, "job", represents the parameters that must be provided to CRON/2's at command to complete the queuing of a job. The items are essentially identical to those that are placed into the CRON2.DAT file (sans the time/date information). For instance, here are the CRON/2 entries given previously as examples, represented in both CRON2.DAT and CRON/2 at format: 25,55 * * * * VDM BG WIND c:\usenet\snews\sendbtch.bat would become at now + 10 minutes vdm bg wind c:\usenet\snews\sendbtch.bat As a further example, 0,30 * * * * OS2 BG FULL- c:\uucp_os2.cmd could be used as at 9:30am tomorrow os2 bg full- c:\uucp_os2.cmd Another example: at 5am tuesday + 2 weeks vdm bg wind c:\usenet\snews\expire.bat Other combinations are left as an exercise for the reader =|^). COMMUNICATING WITH CRON/2 ---------------------------------------------------------------------- The CRON/2 at sub-command communicates with an operating CRON/2 process via a named piped. CRON/2 must be operational before you invoke the at command. Also, because the at command communicates through a named pipe, it can be run from literally anywhere (it doesn't have be in the same directory as CRON/2). GOTCHAS (non-bugs) --------------------------------------------------------------------------- o CRON/2 will barf if you specify either -ns1 or -s1 and there is no local CRON2.DAT file... o Starting CRON/2 with an empty CRON2.DAT file will generate a richly-deserved insult about your questionable parentage... o System error messages detected by CRON/2 are displayed as decimal only o If you are running any .CMD files from CRON2.DAT, you MUST have COMSPEC set in your OS/2 environment (this is usually automatic) o You can't fool OS/2 into running a minimized process as the foreground process...it knows you're only human... WHAT THE ... ?! (known bugs) --------------------------------------------------------------------------- o Starting applications with the FG token, either locally or remotely, will occasionally generate a 457 (ERROR_SMG_START_IN_BACKGROUND) error...I don't know why yet. Your process will run, however. o CRON/2 was developed using a beta compiler on a beta platform... so there... BUG REPORTS, QUESTIONS, COMMENTS, ATTA-BOYS... --------------------------------------------------------------------------- Bob Hood Mailnet : 1217 S. Independence Street Lakewood, CO 80232 | Internet : rhood@nyx.cs.du.edu <--- preferred!! | bbh@csci.csc.com AT&Tnet : (303) 980-8392 HISTORY --------------------------------------------------------------------------- 1.0 - Initial release 1.1 05.19.93 - added activity logging - added dynamic synchronizing of the CRON2.DAT file 1.2 05.26.93 - corrected a bug introduced in 1.1 that suspended the update of the on-screen date/time - corrected a problem with dynamic synchronizing that disabled the feature after the first process is launched - re-designed logging mechanism to allow access to the log file with any file viewer/editor while CRON/2 is running - added a mechanism to push log messages onto a FIFO queue when CRON/2 cannot access the log file - removed the option to specify a different log file as a result of CRON/2 changing drive/paths 1.3 08.06.93 - Corrected a bug that prevented CMD.EXE from launching processes correctly. CRON/2 was developed using 4OS2, which behaves differently. (Sorry Todd) - Added more fault tolerance for the handling of non-fatal errors - Altered CRON/2's behaviour with non-existent programs. Instead of issuing a warning and ignoring an entry if it cannot be physically located during CRON2.DAT processing, CRON/2 now marks the entry as a CMD file and submits it directly to %COMSPEC%. This allows built-in shell commands ("del", "copy", "move", etc.) to be used instead in place of executable programs. - Added logable comments to the CRON2.DAT file. Comments starting with "#$" are saved and associated with the entries they immediately preceed. These comments are then posted to the log file immediately preceeding the processes launch log. (Jon Hacker) - Split CRON/2 into network and non-network versions. Starting with this version, client/server versions of CRON/2 will contain an `n' after their version numbers (i.e., 1.3n). - Added the external `at' command. - Changed the misspelled word "questionalble" in the doc ;-) - Began including change-bars to illustrate new sections of the document between versions for veteran CRON/2 users. 1.4 ??.??.?? - Added the range operator (-) to the CRON2.DAT file. - Released the complete source code to the system.
 hobbes.nmsu.edu/download/pub/os2/util/schedule/cron214.zip  local copy
Cron/2 v. 2.0.3 (20/6/1997, Rony G. Flatscher) Readme/What's new
Infos on CRONRGF.CMD ==================== CRONRGF.CMD was modelled after the "cron"-utility of Unix. It allows you to specify in a control files on which times and dates a command should be executed repeatedly. CRONRGF.CMD starts and runs forever, dispatching the commands at the given times. Please check ATRGF.CMD which was modelled after the OS/2-LAN-command "at" for another variant having features not found in CRONRGF.CMD. Usage ===== CRONRGF [/T] [/M] [/R[nn]] [/B] cronfile Reads file 'cronfile' and executes command[s] repeatedly according to it. 'cronfile' has to be formatted like in Unix; unlike the Unix-version a '%' is treated like any other character; empty lines and ones starting with a semi-colon (;) or a (#) are ignored. Switch '/T[estmode]': the cronfile is read and the user is presented with the date/times and commands to be executed upon them. The planned and truly scheduled times are written to the log-file. Switch '/M[idnight]': all commands which were scheduled the same day, starting from midnight to the time of first invocation are executed once. Switch '/R[nn]': check cronfile at least every 'nn' (default 60) minutes whether it changed; if so, reread it immediately and set the new schedule-times. If set, the cronfile will be checked for changes after executing commands Switch '/B[lackAndWhite]': do not colorize output strings (e.g. for usage in more, less etc.). This switch merely suppresses the ANSI-color-sequences attached to the strings. example: CRONRGF /TEST testcron execute statements in file 'testcron' in testmode example for a control-file: ; Sample file for CRONRGF.CMD ; ; This is a comment (starts with a semicolumn) # This is a comment too (starts with the Unix-comment symbol) ; empty lines are ignored too... ; LAYOUT OF THE CRON-FILE: ; * * * * * command ; or ; minute hour day month weekday command ; where minute ranges from 0-59, ; hour ranges from 0-23, ; day ranges from 1-31, ; month ranges from 1-12, ; weekday ranges from 1-7 (1 = Monday, 2 = Tuesday, ..., 7 = Sunday) ; ; you can give a list of values, separated by a comma (,), e.g. "1,3,7" ; you can give a range of values, separated by a dash (-), e.g. "1-5" ; you can give a star (*) instead of a value, meaning entire range of all valid values ; ; the given command is only executed when all criteriae are fullfilled ! ; ; restriction: unlike to Unix, the percent-sign (%) is treated like any other character and ; not as a new-line ; # the following command "@ECHO HI, I am Nr. 1 to be echoed every minute" would be # executed every minute * * * * * @ECHO Hi, I am Nr. 1 to be echoed every minute & pause 59 23 31 12 5 command, one minute before year's end, and only if the last day is a Friday ; comment: every year at 17:45 on June 7th: 45 17 7 6 * dir c:\*.exe ; comment: on every full quarter of an hour ; at midnight, 6 in the morning, noon, 6 in the evening ; on the 1st, 15th and 31st of ; every month on 0,15,30,45 0,6,12,18 1,15,31 * * backup c:\*.* d:\ /s ; at noon on every day, if it is a weekday (Mo-Fri): 0 12 * * 1-5 XCOPY Q:\* D:\ /s ; every minute in January, March, May, July, September and November: * * * 1,3,5,7,9,11 * dir c:\*.cmd # at the last day of the year at 23:01, 23:02, 23:03, 23:05, 23:20, 23:21, # 23:22, 23:23, 23:24, 23:25, 23:30, 23:31, 23:32, 23:33, 23:34, 23:35, # 23:59 1,2,3,5,20-25,30-35,59 23 31 12 * COPY D:\*.log E:\backup ; make backups of OS2.INI and OS2SYS.INI on every first monday of a month, ; at 9 o'clock in the morning 0 9 1-7 * 1 showini /bt d:\os2\os2.ini 0 9 1-7 * 1 showini /bt d:\os2\os2sys.ini ; at midnight on every month: 0 0 1 * * tapebackup /all ; execute every minute, no restrictions: * * * * * @ECHO Hi, I am Nr. 2 to be echoed every minute & pause # execute every minute in January, February, March only ! * * * 1,2,3 * any-command any-arguments # execute every day at midnight 0 0 * * * any-command any-arguments # execute every wednesday at midnigth ! 0 0 * * 3 any-command any-arguments # this is a comment which concludes the sample file =========================== Rony G. Flatscher, Vienna/Austria/Europe, Wirtschaftsuniversitaet Wien 1992-11-08 ---------------------------------------------------- 3.05.97 22.08 39675 CRONrgf.cmd ... cronrgf-executable (REXX) 8.11.93 18.25 5161 cronrgf.txt ... explanation of cronrgf 3.03.94 12.14 10245 ScrColor.cmd ... utility to set ANSI-colors (REXX) 18.05.95 00.00 219648 cronedit.EXE ... cronedit-executable (REXX with DrDialog) 18.05.95 00.00 48890 cronedit.RES ... DrDialog-source (REXX embedded in a DrDialog-Dialog) 30.04.95 22.45 4026 cronedit.ico ... icon to associate with cronedit 20.06.97 21.54 928 cronedit.txt ... brief description of cronedit (this file) 1.05.95 3.17 3048 crontest ... cronfile to test cronedit (contains intentional errors) 30.04.96 11.55 40524 datergf.cmd ... utility to do date-arithmetic (REXX) 3.03.94 12.13 31197 dateshow.cmd ... demo for datergf-functionality (REXX) 1997-06-20, Rony G. Flatscher, WU-Wien, Vienna/Austria (heart of Europe)
 hobbes.nmsu.edu/download/pub/os2/util/schedule/cronrgf4.zip  local copy
PMCron v. 1.21 (9/5/1996, Florian Große-Coosmann) Readme/What's new
Presentation Manager implementation Cron, Version 1.21 It runs only with EMX 0.9a (or above?). Needed DLLs are EMX and EMXLIBCM. The new DLLs with the fixes from EMXFIX04 of EMX 0.9b are included. Related files: crond.exe Yes, This is the new PM cron daemon. cronddeu.hlp The extensive help to the cron daemon in german. crondeng.hlp The extensive help to the cron daemon in english. crondfra.hlp The extensive help to the cron daemon in french. crontab.exe Self documenting. Simply, call "crontab". With this program commands are send to the daemon. crontab DOESN'T manipulate the Crontabs file, this is done by the daemon itself. Alternatively, you can use the daemon itself. The second page of the "settings..." notebook allows all changes. Crontabs Probably, there is a little example file. You can use it. More and in different languages explained examples will be found in the online help of crond. (Others) The source code of the program. Florian Groáe-Coosmann, coosman@uni-muenster.de Code changes: Don't use ANY tabulators (excepting in makefile). I don't like them. Use CRLF at end-of-line and don't use ^Z at end-of-file. You may use diff if you want. The programs are tested, they work very well. The daemon doesn't eat much memory even when running long times, although the statical size reaches about 512K (EMXLIBCM and EMX are hungry). Good: The daemon awakes only one time a hour if nothing is to do. It will be swapped out by the system. Who is like to translate this stuff into netherlands, italian, spanish etc.?
 hobbes.nmsu.edu/download/pub/os2/util/schedule/pmcron03.zip  local copy
Scheda aggiornata l'ultima volta il: 04/09/2024 - 08:27

Aggiungi un commento