.HEADERS ON .DATE .SET DATE 21 4 1987 .FLAGS BOLD .FLAGS SUBSTITUTE .TITLE ^*$$MONTH $$DAY, $$YEAR - Tuesday\* .NO FLAGS SUBSTITUTE .FIRST TITLE .FILL .JUSTIFY .PAGE SIZE 55,68 .LEFT MARGIN 8 .RIGHT MARGIN 68 .FLAGS INDEX .XLOWER .FLAGS HYPHENATE .LO 2,2 .AUTOPARAGRAPH .SET PARA 3 1 2 .NUMBER PAGE 1 .CENTER ^*SKEDULE*\ .BLANK 2 SKEDULE is a Batch Queue Scheduler. It is a very simple system. It's not meant to be the ultimate. It was at one time. When I first wrote it, I thought it was slicker than snot on a doorknob. It was written in BASIC-Plus on PDP RSTS, and then I transfered it to the VAX in VAX BASIC. It did the job. Then I went to work on a VAXcluster, and it needed to be modified. I chose to write it in DCL, that way anyone can easily modify it to suit their own needs, without having to have this compiler or that compiler. If you're on a VAX, hopefully you do have DCL. This system is written in DCL for a two node VAXcluster. It runs on each node of the cluster. It can be easily modified to work on more than two nodes. Look at the code, and you'll see what I mean. I believe it's easy. It was written for that. I didn't do anything super-slick in the code. It is generic as possible. I'm sure you can modify it to suit your own needs. Consider it at the least, to be a model for your own SKEDULEr system. .LITERAL Les Stockton 1207 South Cheyenne Tulsa, Okla 74119 .END LITERAL .PAGE There are only two files associated with the SKEDULE system. They are SKEDULE.COM and SKEDULE.DAT. SKEDULE.COM is the driver for the system. It is just a very simple DCL command procedure that controls the SKEDULE system. It does most all of it for you. The first thing it does is find out what day of the week this day is. It determines the node that it is running on as well. Then, it begins reading the SKEDULE.DAT file one record at a time sequentially. The SKEDULE.DAT file is a text file that you can edit with any text editor. .LITERAL The format is: 1 - 60 Command file and any parameters (/USER=, /NOPRINT, etc) 61 - 63 The day of the week (MON, TUE, WED, etc) EVR means to run it every day. NXT means to queue up for the following day, not this one. WKD means to queue up MON thru FRI 64 - 68 Time of the day to execute (HH:MM) 69 - 88 Batch queue to execute from 89 - 92 Node to execute on .END LITERAL SKEDULE.COM sequentially records SKEDULE.DAT. It determines what day this particular command file is to be queued. If it is to run today, then it continues to process this record. If not, then it skips this record, and reads the next record in the SKEDULE.DAT file. If no nodename is specified, then it is determined that it doesn't matter which node it runs on. I assume that in this case, we only want it to run on one node, not all of them. If I want it to run on all nodes, I enter a specific record for each node. Anyway, if no nodename is specified, I determine if my other node is present in the cluster. If it is, then I want it to run on that node. If the other node (VAX1) isn't present in the cluster, then this node (VAX2) will go ahead and run it. I probably need some kind of common file, that each node can check, to determine if any of the other nodes have already run a certain command file today, or not. That's for the future release of SKEDULE. Next, it is time to queue the sucker up, so it gets the command filename, time, and queuename from the record. It logs the current time, and submits the command file to whatever queue it goes to, or to the default. Next, it goes to read another record from SKEDULE.DAT. When finished, it closes SKEDULE.DAT and does a SHOW QUEUE/ALL to log what is presently in the queue, what is executing, etc. This system has lots of room for improvement. I'm proud of it, but I know that it is only a model of things to come. The main thing is, that this system works, and it is reliable. I've used it every day for over two years. I figure that in the future, it should be made to be able to schedule things to run once a month (EX. 2nd Tuesday of each month or the 31st, etc.), to be able to determine if one of the other nodes has already run a command file or not, and anything else that you can think of. .PAGE .CENTER ^*REMINDER*\ The REMINDER system is a very simple system. It's not meant to be anything more than what it is. It utilizes VMS MAIL to send reminders of all sorts and sizes to any user listed in SYSUAF. The REMINDER system is written in DCL and in VAX BASIC. If you don't have BASIC, don't be alarmed. BASIC isn't that difficult to translate to FORTRAN, PASCAL, C, or anything else (yes, even COBOL!!! and God forbid MACRO!!). There are 6 files associated with the REMINDER system. This is counting only source files, not executables. I'm assuming that you'll probably want to translate this into your favorite language. .LITERAL The files associated with REMINDER are; 1. REMINDER.DAT This is an RMS Indexed file that contains the Reminder mail. 2. REMINDER.BAS This program asks the user who he is, who he wants to send a reminder to, and when he wants it sent. The program then takes the message, and stores it in REMINDER.DAT. 3. REMIND.BAS This program asks for the date. It defaults to today's date. It reads REMINDER.DAT. If a record has today's date on it, it spawns a job that uses VMS MAIL to send the reminder. 4. REMINDELETE.BAS This program asks for a date. It defaults to today's date. It reads REMINDER.DAT and deletes records with that date on them. 5. REMINDERS.COM This is the DCL command file that executes the REMIND program for today's date, then it runs REMINDELETE to delete those messages. 6. REMINDLIST.BAS This is a simple way to check REMINDER.DAT for problems. It is just a file dump. It writes to REMINDER.LIS. .END LITERAL .NOTE DATE FORMAT We will assume that the date format is DD-MMM-19YY. .END NOTE .PAGE .CENTER ^*IDLE*\ The IDLE program is written in FORTRAN. It is for people on VAXes, that don't have alot of memory on their system. Our system is has alot of users, and very little memory. When idle, we sometimes want to keep our WATCHDOG (AUTOLOGger) from logging us out. At the same time, we don't want to hog memory that other users need. Also, we are connected to a MICOM port selector that watches the crt line. If there is no activity within 5 minutes or so, it disconnects the line. IDLE was written to purge the working set, schedule a wakeup in 5 minutes, and then go to sleep. When it wakes up, it prints a dot on the screen (this is for the MICOM), and then it repeats the process. It does this for 30 minutes, and then it commits suicide. No one should be hogging the system that long without doing something. That's all there is. It's not a complicated program. It doesn't ask the user for anything. It's just a real small program when it runs. Some of this code could (or should) be included in menus and some other application programs that sit at a prompt, and the user only uses the program a few times during the day. The rest of the time, the program is idle, and is hogging memory. By including the part to purge the working set, the program will stay small until it is actually needed. This is a lifesaver for VAXes who don't have much memory. .PAGE .CENTER ^*LOGINS*\ LOGINS (name it what you will) reads the SYSUAF file, and sorts in order by last login date/time. It creates a report called LAST__LOGIN.LIS. This program is written in VAX BASIC, and links with a FORTRAN subroutine called GETPID. It gets the process Id (bet you couldn't figure that one out on your own). .PAGE .CENTER ^*LAST__LOGIN*\ This program is written in VAX BASIC. This program was modified to create the LOGINS program. LAST__LOGIN reads SYSUAF and creates a list file called LAST__LOGIN.LIS. It is in order by Username. It calls a FORTRAN subroutine called GETPID. It's a normal compile and link. Nothing fancy. .LITERAL BASIC LAST_LOGIN FORTR GETPID LINK LAST_LOGIN,GETPID .END LITERAL