Page 1 of 1

Check for ntimes the file existences onSFTP server using jcl

PostPosted: Thu Jun 30, 2016 4:13 pm
by Namrata_Singri
Lets say my file name is abc.txt.If the file is found in the server i need to execute another jcl named as jcl1.
If abc.txt file is not found in the server, i need to check after 1 hour for the availability of file.If found then need to execute jcl1. Like this i need to check for every 1 hour until the file is available.

Is it possible to declare time in the jcl or any other method.

Thanks .

Re: Check for ntimes the file existences onSFTP server using

PostPosted: Thu Jun 30, 2016 4:50 pm
by enrico-sorichetti
more and more the forums are becoming a catalog of WHAT SHOULD NEVER BE DONE in a proper IT environment.

wouldn' t it be simpler to let the other side ftp the dataset to the MF
and then use Your scheduler facilities to schedule the proper job on successful dataset transmission.

Re: Check for ntimes the file existences onSFTP server using

PostPosted: Thu Jun 30, 2016 4:55 pm
by steve-myers
No.

You're using at least one, probably more, false assumptions.
  • z/OS data sets retain 3 date (but not time) related attributes: creation date, expiration date, and reference date. They also have a modified flag that backup or archiving software can reset.
  • JCL does not have access to these values. The values are readily available to application programs, though I doubt either FTP or SFTP obtains or uses them. The API is only available to Assembler programs.
  • No unauthorized application can alter or or influence the contents of these attributes. The sole exception is an unauthorized application can prevent the reference date attribute from being updated by using a very obscure API. Only JCL or dynamic allocation can set the expiration date attribute when a data set is allocated. Once set, the expiration date cannot be altered.

Re: Check for ntimes the file existences onSFTP server using

PostPosted: Thu Jun 30, 2016 5:57 pm
by Aki88
Hello,

As Mr. sorichetti and Mr. myers have already stated, the requirement by design - is a bad idea.
Though, if you're still inclined on doing it, one way would be to utilize the 'job scheduler' system which you might be having at your site.

Schedule a job to execute hourly for a batch day, the sole purpose of this job would be to test if the file is available at the server; have another step in this job which executes depending upon the return code of the earlier file check step; this step will submit the JCL1 to INTRDR.

Please note that even though this is a solution, yet there are inherent problems with this approach too. For example:
--> Assuming, the file was present when the first job checked it, JCL1 would run. What will happen to the file at server after this? Will it still remain there or will it be removed? Reason for asking this is, because the execution of the next hourly job will depend on these questions. If the file remains there, then your next hourly job will pick it again and reprocess it.

Simply put, the design is very vague to provide a clean working solution. If you still want to proceed, the above approach will work for you; please speak to your local scheduling team to assist you on how to setup the above approach.

Hth.

Edit: And yeah, JCL alone wouldn't be able to cater to the requirement, you'll need to design a utility/or use an existing tool/utility which can be run through JCL to achieve what you want.

Re: Check for ntimes the file existences onSFTP server using

PostPosted: Thu Jun 30, 2016 7:55 pm
by Namrata_Singri
//JSTEP125 EXEC jcl0
//*
//D015200T EXEC D0152000,COND=((0,NE,JSTEP125.STEP013),
// (0,NE,JSTEP125.STEP13C))
//*
//DATAIN01 DD *
$SINCTL=jcl1,DOC=001,INP=CARD
/*

this is how i am trying, my jcl will first trigger the jcl0 and in jcl0 i have sftp steps which checks the availabilty of file.Later if that runs successfully than should trigger jcl1.
In case if file is not present it wont trigger the jcl1, so after 1 hour i need to check once again for the availability of file.

I have some other steps after this step. But those steps are not dependent on the result of this step.