IBM Mainframe Forum

Hello,

I wonder how I can submit a job in C. The JCL to be submitted is in a file/dataset.

Is it possible to allocate -with dynalloc()- and open -with fopen()- a file called "DD:INTRDR" to be able to write to JES Internal Reader?

Any hint or suggestion would be highly appreciated.
Thanks.

Device independence is one of the paradigms of zOS
from the very first incarnations... OS/360,MFT,MVT,... , ..., ...

any DD referring to a dataset with DCB=(RECFM=FB,LRECL=80,BLKSIZE=80)
can be changed to a DD referring to SYSOUT=(<somesysoutclass>,INTRDR)
with the same DCB attributes

see the forum for examples

the programming language used is irrelevant, as long as it can write a dataset in the requested format.


but if the JCL in the dataset is ready to be submitted, no need to write a program,
the invocation of a simple utility like IEBGENER can do it.
or from TSO use the SUBMIT command

Performing fopen("DD:INTRDR", ...) does not necessarily require the use of dynamic allocation; a "file name" DD:dd name directs fopen to use an existing DD statement with the specified DD name; the JCL used to run the program might specify

//INTRDR DD SYSOUT=A,DCB=(RECFM=F,LRECL=80,BLKSIZE=80)

Of course, your program could use MVS dynamic allocation to allocate the internal reader and then use fopen to open the data set that was just allocated.

As Mr. Sorichetti says, writing -
when you can use a simple utility such as IEBGENER seems like overkill, but ...

Thanks for your quick responses.

I agree that it may be overkill to try to submit a JCL from C when one can use other, immediate and more flexible ways. However, I think I wasn't explicit enough. The idea of using C to submit a JCL is that the (sub)routine in C will be called by the FTP server, that is, it's an FTP exit, and the objective is to submit a JCL after an FTP transfer has completed. This is why I was interested in submitting a JCL from C. That exit will read a file where the JCL to be submitted is stored.

From your responses, I guess that it won't be necessary to dynamically allocate a dataset if in the FTP procedure (run as a started task) there's a DDNAME pointing to that file, so it would be accessible to the exit, and the exit would only need to fopen()-ing it.

So if the Internal Reader and the file with JCL source code are specified as DDNAMEs in the FTP start procedure, then no need to dynamically allocate them. Am I correct?

Thanks.

FTP can submit jobs directly to JES, so why not have your sequence of FTP commands transfer the data, then submit the job directly? That way you don't need any exit, nor a C program.

and the objective is to submit a JCL after an FTP transfer has completed.

then use Your scheduler facilities
when a dataset is created the scheduler has the capability to schedule for execution the jcl associated to the dataset creation

speak to Your operations support.

Yes, I'm aware that FTP can submit jobs, but for security reasons, that feature is disabled on purpose.

enrico-sorichetti wrote:then use Your scheduler facilities
when a dataset is created the scheduler has the capability to schedule for execution the jcl associated to the dataset creation
speak to Your operations support.

We don't have, for the time being, any scheduling facility/tool. The FTP user exit is the only short-term solution.

mendijur wrote:Yes, I'm aware that FTP can submit jobs, but for security reasons, that feature is disabled on purpose.

Then why are you attempting to "beat" it? Or do you dislike your job that much!

steve-myers wrote:Then why are you attempting to "beat" it? Or do you dislike your job that much!

I'm not trying to beat anything nor going against the current. The feature of submitting jobs through the FTP server is disabled. This shop doesn't want any client to submit "foreign" JCL code. Clients are only allowed to send files. Files that they want to process once they've arrived. However, as I said in previous posts, there is no scheduling facility for the time being, so to process received files, I was just exploring the possibility of implementing the FTP post-processing user exit.
Of course I like my job. Another different thing is the limited tools that this shop has.
Kind regards.