Date:         Tue, 6 Oct 2009 09:10:28 -0700
Reply-To:     "Richard A. DeVenezia" <rdevenezia@GMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Richard A. DeVenezia" <rdevenezia@GMAIL.COM>
Organization: http://groups.google.com
Subject:      Re: Pausing the execution of "Submit Continue" Statements.
Comments: To: sas-l@uga.edu
Content-Type: text/plain; charset=ISO-8859-1

On Oct 6, 4:42 am, ukulorevalley <dmesot...@yahoo.com> wrote:
> Hi,
>
> We are using a SASAF-application to submit JCL-code.
>
> This is done in 2 consecutive steps (submit-blocks):
> - in the first we create a flatfile and a new JCL-program (to export
> this flatfile as .csv)
> - in the second we execute this new JCL-program
>
> Our problem now is that SAS tries to execute the second step before
> the first step is completely terminated.
> It seems to us that SAS submits the first step to the JCL-environment,
> and continues immediately to the second submit-block (because for SAS
> the code in the first Submit-vlock is complete).
>
> We see two solutions for this problem, but haven't found a way to
> program them.
> We coud let SAS wait with the execution of the second Submit-block
> 1) until the new JCL-code is created (we could check this by checking
> the existence of a dataset on the mainframe).
> or
> 2) for a certain time: pause the execution of the code.
>
> Has anyone any experience with manipulating the execution of Submit-
> blocks in this way?

Yes, Your AF will need to have a notifier in order to time things.
Notifier will typically be 'existence of something created by
generated program run in step 1'

A simple way to loop politley is to use SLEEP.

exists = <mainframe-table-existence-state>;
do guard = 1 to 80 while (not exists)
  call SLEEP (25,.01); * politely sleep for 1/4 sec;
  exists = <mainframe-table-existence-state>;
end;

SLEEP will cause SAS to let the rest of the operating system function
normally while the SAS thread is sleeping.  The problem with this is
that the SAS session UI goes unresponsive until
1. the guard time expires (20sec = 80*.25), or
2. the mainframe step 1 completes.

The unresponsiveness is due to the single threaded nature of SAS
Display Manager and SAS/AF executor.

For an example of an AF UI program with time-slicing and event
testing, see
  http://devenezia.com/papers/sugi-30/012-30%20(Tetris).pdf

--
Richard A. DeVenezia
http://www.devenezia.com