Date: Thu, 22 Feb 2001 22:19:42 +1300
Reply-To: Don Stanley <don_stanley@XTRA.CO.NZ>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Don Stanley <don_stanley@XTRA.CO.NZ>
Subject: Re: Remotely detecting batch failure
Content-Type: text/plain; charset=us-ascii
I think there is a much simpler approach. This is what I do for some of our jobs (UNIX to MVS, same principle).
Start with a new SAS step that FTPs a file to UNIX (NT). That step sends an empty file to UNIX. The filename is some standard set of qualifiers, followed by <mvs jobname><MVS jobnum>.STARTED.D<MVS timestamp>. Then another step with your usual JCL and code. No change required. You follow this with a separate step that runs only if the prior step finished RC=0. That step does nothing more than FTP a
file to UNIX. In fact the step is identical to the first, but issues a filename with ENDED.D<MVS timestamp>.
It becomes a simple matter to write some AF code that either at the click of a button, or upon user logon, checks for any jobs that only have a STARTED.<timestamp> file and reports any that are looking suspect -- eg have been running more than 30 minutes. You can even get flashy by creating a PARM file with each jobname and expected runtime (all on UNIX) and do a lookup on this, reporting when the
interval for that job has been exceeded.
In general remotely checking jobs isn't easy. In general, provided your remote platform can identify the job running, the above is a generic solution that should work everywhere. The equivalent of batch job steps may just be a SAS process that starts another SAS process, or a macro at the start and end of a job. I use JCL to do this because it nicely divides my logic into checking stuff and
You can get MVS jobnum from JFCB. Look for the JFCB paper at my SASTIPS site in the sig below. MVS jobname is &sysjobid. MVS timestamp should be available from SAS functions, a date should also ensure uniqueness unless you have a high batch turnover.
By the way, build some mechanism in to delete the empty FTP files that are building up. Eg part of the AF remote submission could be to check if any files with the same jobname exist and delete them, cos they are obsolete by then.
The above assumes that MVS jobnames are not repeated in different remotely submitted reports.
David Johnson wrote:
> Nalbo's (?) original question is below.
> testing for MVS batch jobs from a Windows AF application has been causing us
> some problems as well. The main one has been knowing the batch has
> finished. Here are some solutions we are trying:
> . Add a macro call to the start of each job to record the batch
> submission, with date/time, user, job name etc
> . Then add another to the end of the job to record completion of the
> batch. If done within the batch code, and the job abends, the macro won't
> run and you won't have a completion advice. Not necessarily ideal.
> . Since you are submitting batch, add something like the following
> (untested code) to your JCL:
> //RUNBATCH EXEC SAS
> //SYSIN DD DSN=SAS.USER.BATCH.CODE
> //CHKBATCH EXEC SAS,COND=(0,NE,RUNBATCH.SAS)
> //SYSIN DD DSN=SAS.USER.CHECK.RUN
> The RUNBATCH step is your usual program, the CHKBATCH is a check program to
> test completion. In this case, only successful completion of the RUNBATCH
> step will initiate the CHKBATCH step.
> Be aware of the need to identify the CHKBATCH condcode test with the SAS
> step indicator. What I don't remember is whether it succeeds the step name
> as shown, or precedes it.
> SAS-L Digest - 21 Feb 2001 - Special issue (#2001-237)
> Date: Wed, 21 Feb 2001 22:26:11 -0000
> From: Nalbo <nalbo@SPAM_NO.FREEUK.COM>
> Subject: Remotely detecting batch failure
> Running 6.12 on NT, soon to be 8.1, and 6.09E on OS390 MVS.
> We have an AF application from which users can submit remote batch jobs on
> MVS. Sometimes these jobs might fail. Is there a way to determine the
> success or failure of these and alert the user ? I think I need to be able
> to interrogate SDSF and also have SAS pick up the job number that gets
> allocated on submission. From there I might be able to read the log and
> look for a return code. And then again maybe not.
> I have no idea how to do any of this or if it is even possible. Can you
> help ?
> Many thanks for any assistance you can offer.
> David Johnson
> This message is attributable to the sender and does not necessarily reflect
> the view of Halifax Group plc or its subsidiaries.
> Part of the Halifax Group, Halifax plc, Registered in England No. 2367076. Registered Office: Trinity Road, Halifax, West Yorkshire HX1 2RG. Represents only the Halifax Financial Services Marketing Group for the purposes of advising on and selling life assurance, pensions and unit trust business. The Marketing Group is regulated by the Personal Investment Authority. Switchboard 01422 333333.
Don Stanley, B.SC, Dip O.R.S, MNZCS Director, Sysware Consulting Group
Box 634, Wellington, NEW ZEALAND
Author:: Beyond the obvious with SAS Screen Control Language.
Author:: Solutions for your GUI Applications Development Using SAS/AF FRAME Technology
SAS Tips:: http://www.geocities.com/don_stanley_nz/sastips.htm