01-21-2014 04:41 AM - edited 01-21-2014 04:43 AM
Im trying to learn this new OpenVMS. Im very new, and it is my first time.
I have start this conversation a long time ago. Now im in deep of this problem and i would like to solve it.
I have one procedure that have to be execute every day. Is there any kind of scheduler for OpenVMS system?
The procedure that is i execute like this:
"submit /noprint <name_procedure>"
the procedure is .com extension.
so this would be like: "submit /noprint backup.com"
when i execute this there is a log file crated and i want this log file to be send on e-mail when its finish. How can i do this ?
Im running OpenVMS V7.3-2
Solved! Go to Solution.
01-21-2014 06:10 AM
The task you request is completed using DCL code within the procedure. Essentially you re-submit the same job with a scheduled runtime as shown below. Place this code at the beginning of the procedure and it will submit itself for execution at 1/2 hour after midnight.
$ SUBMIT -
As far as sending an Email, place the following line within the procedure after the work is completed and before the procedure exits.
$ mail -
Hope this helps,
01-21-2014 10:37 AM
Thanks for reply / help.
So lets say that im having procedure where i will create a file and says "hello ivan"
If i want every day to make a file saying Hello Ivan, i will do this:
$ SUBMIT - /restart - /AFTER="TOM+13:30:00" - /LOG_FILE=DAY.LOG - DAY.COM $ OPEN/WRITE test HelloTest.dat $ WRITE OUTPUT_FILE "Hello Ivan" $ CLOSE OUTPUT_FILE $ mail - /sub="message log_file.log smtp%"firstname.lastname@example.org"
and all this will be in the file called "TestScheduler"
or should i have make DAY.com be the file that will contain the
$ OPEN/WRITE test HelloTest.dat $ WRITE OUTPUT_FILE "Hello Ivan" $ CLOSE OUTPUT_FILE
:D OMG im soo noob im loost here i have excellent experience in Linux but with this im NOOB :D
01-21-2014 05:00 PM
Re: Steve's post
>>but the last thing it does is re-sumbit itself:
I recommend that a recurring batch job resubmit itself as the FIRST step, rather than the last, that way the job will always be resubmitted regardless of what happens in the body of the procedure. There are valid arguments both ways.
A job resubmitting itself is a very common requirement. There are many pitfalls involved in losing the thread, creating multiple threads, version changes (take note of Steve's F$PARSE(";")), handling qualifiers and parameters, running the job ad-hoc, etc... Unfortunately DCL doesn't have any generic tools for easily managing recurring jobs.
Mailing a jobs own log file can be tricky, as you're still executing (and thus potentially still writing the log file). One method is to jacket your procedure:
$ @REAL_PROCEDURE/OUT=logfile $ MAIL/SUBJECT="log file" logfile distribution-list
You can capture a copy of the current live log file which can be mailed:
$ tmp=F$PARSE(F$UNIQUE(),"SYS$SCRATCH:.TMP;") $ mylog=F$PARSE(F$GETQUI("DISPLAY_ENTRY","LOG_SPECIF
ICATION",,"THIS_JOB"),"SYS$LOGIN:.LOG;",- F$GETQUI("DISPLAY_ENTRY", "JOB_NAME",,"THIS_JOB")) $ TYPE/OUTPUT='tmp' 'mylog' $ MAIL/SUBJECT="Log file to date" 'tmp' distribution list $ IF F$SEARCH(tmp).NES."" THEN DELETEX 'tmp'
Note that LOG_SPECIFICATION only returns a non-null value if there was a log file explicitly named in the SUBMIT command, so the F$PARSE will fill in a default. TYPE is happy to read the contents of a file open for write by another process (or self), but MAIL isn't. That's why we need the temporary file.
Note that there are further assumptions here - for example, if there are two instances of the same job running, this will capture the log file of the most recent job, which is not necessarily the current job. If this is an issue, you'll need to back translate the file name from SYS$OUTPUT, which is not something you can do directly in DCL (I can post a program to do it if required).
01-21-2014 10:14 PM
>I recommend that a recurring batch job resubmit itself as the FIRST step,
Good point. This would be equivalent to UNIX's cron(1m).
Of course with at(1), you can resubmit at first or last steps.
01-22-2014 07:27 AM
Thanks to all for replying !
I realy need this.
I see that you all start conversation about resubmit the job. If the system goes down or restart itself the job will start. I dont want to do this. I just want typical scheduler job. Every day in 08:00 PM to start this procedure and when its finish to send me the log file. Every day i start this procedure like this: "submit /noprint backup" --- where backup is the procedure named "backup.com". Here is what have in backup.com
set ver set noon rmu /show user rmu /repa/abm dkb6:[vg]vg.rdb show time sql export data file dkb6:[vg]vg.rdb into dkb9:[back]vg.rdr; show time purge dkb9:[*....] back/log/media=comp dkb9:[back]*.* mka500:backup.bck dismount mka500: !back/log/over/ignor=inter dkb6:[vg]vg.rdb dkb9:[backi]vg.rdb @dkb4:[ivan]imptt purge dkb9:[*....]
and this is not my. I didnt make this file, but i have to execute every day. So my job for now is to make this file execute every working day in 08:00 PM ( mon-frid), and when its finis to send me tthe mail , the mail can contain the log file that it is created ( becouse when i execute this procedure it create the log file named backup.log in the default directory, im guessing, the log file is created because i executed with submit/noprint ... but i dont know realy :) ).
01-22-2014 12:53 PM
>I failed to mention that the _first_ thing my script does is:
> $ SET NOON
Of course. That will deal with errors, unexpected or otherwise in the body of the procedure, but it doesn't help for system crash, power fail, normal shutdown, STOP commands (internal or external), infinite loops, lock conflicts/deadlocks, future edits which bypass the exit path, or any of the other gazillion things that might cause a process to stop, hang or be excessively delayed between the start and your (re)SUBMIT at the end. The longer running the job, the wider the timing window.
Resubmission at the top still has a small timing window where there is no pending job. I like to have a "watchdog" type process which knows which jobs should be scheduled and can alert or resubmit anything missing (and yes, it also watches itself by having backup "deadman" copies of itself waiting to take over). The system startup process just need to make sure the watchdog is running, and everything else cascasdes from there.
In a lot of ways the Unix cron model makes this kind of task a lot easier to manage (but then it has the problem of tracking the job - "did it run?" and "where the &^%&^% did my log file go?")
01-23-2014 10:29 AM
>but then it has the problem of tracking the job - "did it run?" and "where the &^%&^% did my log file go?"
Oh? Look at the cron logfile. :-)
It's either mailed to you or it the place where your scripts or crontab entry left it.
01-23-2014 10:58 AM
Its realy difficult to understand this system :D ... any way im now trying to make a simple script that will run every day and make a dat file that say Hello World :) ... every day in 3:00 PM and send me the log file to mail. After that i will continut for my real procedure that i need ... try to integrate. I will contact you for every progres that i will made here :) ...
i realy dont know from where to start :D becouse this writing also start to look very hard :D
01-24-2014 06:54 AM
It is not difficult at all, if you avail yourself of even a fraction of the helpful information available.
First, all of the VMS documentation is available on-line at http://h71000.www7.hp.com/doc/index.html. You can download PDF versions of most any document you'd want for nearly any release in the past decade. And VMS documentation is high quality by most folks standards.
Next, there are many good example and useful utility procedures available, many of which address the issue you appear to be trying to solve. Looking at someone else's approach is a great way to learn. And stealing code is the highest form of flattery.
I'd start with the OpenVMS Freeware page at http://h71000.www7.hp.com/openvms/freeware/, and there are a lot of useful procedures at http://dcl.openvms.org/ and also look in http://www.eight-cubed.com/articles/dcl_standards.
Don't forget the rich HELP environment, various books (e.g., "Writing Real Programs in DCL") that may be available on Amazon, et al., and what you can probably find with a simple google or bing search.
There used to be some fairly reasonable self-paced training around, but I haven't looked for it in a long time.
And as Hein would probably point out, if you don't want to do it in DCL, you might want to tackle it in perl or Python or GNV/bash if you have them on your system.
01-25-2014 03:13 PM - edited 01-25-2014 03:14 PM
In no particular order...
The OpenVMS operating system is ~35 years old, and most problems and questions have already been discussed and solved, bugs and oddities already posted, example code posted, docs are online, and all of these resources are readily available via Google or Bing searches, and (not in the main Google search engine) via the Usenet comp.os.vms newsgroup archives (c.o.v. is still active) available via the Google Groups search engine:
For comp.os.vms, free usenet accounts are available via Eternal September, or you can try to use the (somewhat problematic) Google Groups posting web-based mechanisms:
Do not assume OpenVMS is anything like Unix. It's not. The quicker you forget how Unix or Linux does stuff and learn how OpenVMS implements the particular task, the better off you will be. The other path leads to confusion and frustration. In the interim, here is a bash DCL command comparison:
As for DCL programming and periodic DCL resubmission -- home-grown scheduling, as OpenVMS lacks an integrated cron or other scheduler -- you'll be able to use any of the various DCL template procedures around. Here are two examples:
In your case, the SUBMIT command will involve /AFTER=TOMORROW+15:00 for the resubmission, if that's when you want the next batch job to run.
Sending MAIL from DCL is feasible, and here are four example commands:
MAIL filename username/SUBJECT="Hello"
MAIL NLA0: username/SUBJECT="Hello"
MAIL filename "email@example.com" /SUBJECT="Hello"
MAIL NLA0: "firstname.lastname@example.org" /SUBJECT="Hello"
NLA0: is the null device (akin to /dev/null on Unix; can be written or read on OpenVMS), so you'll not need to specify a filename for those particular commands. Otherwise, you'll need a file as the contents of the mail message. You'll need to quote user specifications containing an @ sign or other special characters, due to the rules of DCL.
To read or write a file from within DCL:
Mike has already posted a link to http://decuslib.com, and that is a massive archive of OpenVMS applications and tools and documentation. Use the Google or Bing site:decuslib.com keyword to target your search there. There's a similar but somewhat smaller archive at the http://www.digiater.nl site.
To learn OpenVMS and writing DCL procedures, start by reading the User's Manual, and then skimming the Programming Concepts or the System Manager's manuals for more information and also depending on your particular goals:
Also see the OpenVMS Beginner's FAQ and the OpenVMS FAQ (mentioned earlier):
Also read the current OpenVMS roadmap, as HP has plans to continue OpenVMS support for some years, but with no new releases or particular new features planned, no new platform support, and with application and platform migrations expected. Here's the OpenVMS roadmap and the roadmap FAQ:
Edit: Watch that second URL, as Lithium is being as dumb as a bag of hammers about that HP URL.
Random grumping: I'd forgotten how awful the iconography is in this Lithium tool. Crayon-caliber. Oh, and I'd forgotten the "Your post has been changed because invalid HTML was found in the message body. The invalid HTML has been removed. Please review the message and submit the message when you are satisfied." messages. Not sure what got eaten there. Oh, well.
01-26-2014 11:08 PM
I don't know what to say ... THANKS A LOOT !!!
I really don't expect this kind of answers ... excelent support !
I just want to say that I am in progress of making this stuff work ..When I finished definitively will shear the good job ( if it be a good :P ) ...
Again thank a loot for this help and effort you all make to explain to me !!!
03-04-2014 09:47 AM
I just want to informed you that all stuff you all told me it works fantastic ! As "abrsvc" and "John Gillings" say i did that and work great ...
I add this lines at the end of the procedure that im executing and after it end or at the end of the job, the same job resubmit itself..
this is the code iv add:
$ mail/sub="mailjob" ivan.log "email@example.com"
$ submit -
and that is all ... im now trying to figure out to be activate just working days mon-friday