- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: submit causing infinite loop
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-07-2011 02:12 PM
тАО04-07-2011 02:12 PM
Re: submit causing infinite loop
> there's an invalid comment in the Friday section
That would do it. But there should be an error message in the log file:
%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
Looking at your script, here's a few suggestions that may make debugging easier (though, being a programming language, there will be many alternative opinions).
I try to avoid hard coded file specifications. F$PARSE is your friend. If you're talking about the procedure itself, use:
$ self=F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))
The semi colon is to remove the version number. This will remain correct regardless of where you move the procedure, or even if you rename it.
You can then use "self" to locate related files if they live in the same directory. For example:
$ arc_files=F$PARSE("convert_lockbox_arc_files",self)
$ @'F$PARSE("DISTRIB_MAIL",self)' SYS$SCRATCH:TRANSMITTAL_MSG.TXT
This kind of coding becomes natural, and it makes it trivially easy to move code around, or between systems, as it removes local dependencies.
When dealing with different actions depending on the day of the week, the easiest construct is:
$ GOSUB 'F$CVTIME(,,"WEEKDAY")'
$! Other stuff
$ EXIT
$
$ Monday:
$ Tuesday:
$ Wednesday:
$ Thursday:
$
$ ! Processing for Mon-Thur
$
$ RETURN
$
$ Friday:
$ ! Processing for Fri
$ RETURN
$
$ Saturday:
$ Sunday:
$ RETURN
You could do something similar with "DAY" but that would be rather a lot of labels. Maybe turn it around and use GTS instead of individual tests?
$ IF 'F$CVTIME(,,"DAY").GTS."04"
$ THEN
$ ! stuff to do > 04
$ ENDIF ! Your label end_process
3) Perhaps overkill in this case, but when you have something selectable from a small set, like a day name, a table can sometimes be clearer and easier to maintain than an IF-THEN tree. For example:
$ OnMonday="TOMORROW+2-02:00"
$ OnTuesday=OnMonday
$ OnWednesday=OnMonday
$ OnThursday=OnMonday
$ OnFriday="TOMORROW+02:00"
$ OnSaturday=""
$ OnSunday=""
Now, let the code select itself:
$ after=On'F$CVTIME(,,"WEEKDAY")'
$ IF after.NES."" THEN SUBMIT 'self' /AFTER="''after'" /whatever
This may not be the correct logic for your job, but hopefully you get the idea. You only write one SUBMIT command, and it's very easy to have different times depending on the day. We can also block resubmission on particular days.
That said, rather than try to code the execution schedule in advance by submitting jobs at different intervals, it's often easier to just run the job at the same time every day, and decide if something should be done when it starts to execute. That means it's safe to submit at any time.
I also do my resubmit at the becinning of the job. This helps reduce the risk of something going wrong during the job causing it to abort before the resubmit and breaking the chain. Thus:
$ IF F$MODE().EQS."BATCH" THEN SUBMIT 'self'/AFTER="TOMORROW+02:00"
$
$ ! Work out circumstances, date, day etc...
$ ! maybe use GOTO 'F$CVTIME(,,"WEEKDAY")
$ ! or:
$ IF NothingToDo THEN EXIT
$
$ ! Do stuff
To determine if there's another copy of yourself already scheduled you don't need to scan the whole queue. For the case of jobs owned by yourself DISPLAY_ENTRY is a shortcut. Consider:
$ me=F$GETQUI("DISPLAY_ENTRY","ENTRY_NUMBER",,"THIS_JOB")
$ myname=F$GETQUI("DISPLAY_ENTRY","JOB_NAME",,"THIS_JOB")
$ IF myname.EQS."" THEN myname=F$PARSE(self,,,"NAME")
$ CheckLoop: e=F$GETQUI("DISPLAY_ENTRY","ENTRY_NUMBER",myname,"WILDCARD")
$ IF e.NES."".AND.e.NE.me THEN GOTO CheckLoop
$ IF e.EQS.""
$ THEN
$ ! No matching job scheduled
$ ELSE
$ ! Found job with entry number e
$ ENDIF
Note that this code doesn't hardcode the job name. It also works for interactive mode as "me" will be blank, and we've assumed the job name will be the same as the procedure name.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-07-2011 02:35 PM
тАО04-07-2011 02:35 PM
Re: submit causing infinite loop
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-07-2011 02:42 PM
тАО04-07-2011 02:42 PM
Re: submit causing infinite loop
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-07-2011 03:09 PM
тАО04-07-2011 03:09 PM
Re: submit causing infinite loop
With that in mind the bogus "goto" line can cause the loop.
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-07-2011 03:41 PM
тАО04-07-2011 03:41 PM
Re: submit causing infinite loop
ON ERROR catches ERROR and SEVERE (FATAL) errors.
ON WARNING catches WARNING, ERROR, and SEVERE/FATAL.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-08-2011 07:37 AM
тАО04-08-2011 07:37 AM
Re: submit causing infinite loop
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-08-2011 06:10 PM
тАО04-08-2011 06:10 PM
Re: submit causing infinite loop
I thought this was going to go in the que, holding for two weeks from now, but it acted as if it was probably just waiting till one PM -- and, since it was already after 1 PM when I submitted it, it just kept resubmitting itself.
Doesn't the "+13" mean 13 days?
===========================================
strsrv> type test1.com
$ submit test1.com/notify/noprint/keep/que=sys$batch/log=star_log/-
after="today+13"
$ exit
==========================================
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-08-2011 06:43 PM
тАО04-08-2011 06:43 PM
Re: submit causing infinite loop
Apparently not. Remember this?:
> I just checked your time string via lexical
> f$cvtime()and it returned the time I would
> expect.
That could have been taken as educational.
For example:
alp $ write sys$output f$cvtime( "today")
2011-04-08 00:00:00.00
alp $ write sys$output f$cvtime( "today+13")
2011-04-08 13:00:00.00
Seems to be +13 hours. On the other hand:
alp $ write sys$output f$cvtime( "today+13-")
2011-04-21 00:00:00.00
HELP Date_Time
Pay particular attention to "Combination" and
"Delta".
And, of course:
HELP Lexicals F$CVTIME
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-09-2011 06:57 AM
тАО04-09-2011 06:57 AM
Re: submit causing infinite loop
And John G, also, thanks for the tip on how to test and break the loop. Not being sure exactly what was going to happen, I've always been a little scared to use this parameter. One of those things I thought I didn't even want to test, simply because of what could happen when the test failed. You guys have given me the tools I need on this now, tho, so many thanks!
- « Previous
-
- 1
- 2
- Next »