FTP to JES used much?

[Tzadik Vanderhoof]

I just discovered the ability of FTP to submit a JCL file to a mainframe and then get access to the output. It seems really elegant and potentially very powerful. There could be all kinds of possibilities of easily integrating programs running on other systems with the mainframe using that feature.

It could be back-end processes (I.e. a program running on a Linux web server could under certain circumstances kick off a job on the mainframe) or even GUI related (i.e. a program editor running on windows could let you click a Build button, then ship the program off to the mainframe to be compiled and tested).

Does anyone know if this FTP to JES feature is being used much, in ways such as this or otherwise?

[dick scherrer]

Hello,

It is gaining in popularity.

I've heard of it used more to retrieve output than to submit jobs. More and more the scheduling software is used to initiate production jobs. Having the "regular" jobs centrally managed provides better system resource control and planning.

[MrSpock]

Personally, in a production, well-managed and well-secured enterprise, I doubt it. Most, if not all, of the modern Job Scheduling Systems have the ability to reach across the entire enterprise and run jobs, look for events or messages, watch for files, and make predecessor and successor requirement matches.

[Tzadik Vanderhoof]

OK, but at least admit that it's pretty cool

[dick scherrer]

Oh, yes, i'll grant it is pretty cool

So far, i'm not ready to "turning everybody loose" with it so far.

If someone made a business case for submitting jobs via ftp, i'd surely be glad to talk about it. If the need could not be met by existing standard practices, i might be swayed to using it. So far, i've not seen one (with the exception of a few cases where output was "picked up" via ftp).

[Tzadik Vanderhoof]

What about a plug-in to a PC-based Integrated Development Environment (IDE), such as Eclipse (or even VIM or Emacs)? The plug-in would allow you to edit your mainframe source code (COBOL or whatever) on your PC instead of directly on the mainframe. When you click the "build" button in your IDE, it would use FTP to submit your code for compilation (and even testing) then download and display the results in a pane of the IDE. It would appear very similar to developing on the PC itself. You would be able to leverage all the features of the IDE, such as the ability to see more lines on the screen, see multiple views of a file (or multiple files) at the same time, click on a compiler error and have it bring you to the affected line of code, etc.

[dick scherrer]

Hello,

Many (even most) organizations do not want their source "running all over the place".

If everyone migrates source to whatever platform/editor they prefer, source management becomes a nightmare. Management no longer has any idea where the "real" source is.

[Tzadik Vanderhoof]

Good point.

[salltm]

Ibm tool: RDZ

[dick scherrer]

Hello and welcome to the forum,

Please keep in mind this is not a chat room. . .

If you have a contribution you need to use complete thoughts. Thoughts that have something to do with the current topic.

RDZ has nothing to do with submitting production jobs via FTP. It also has nothing to do with scattering source from the central source repository to some "editor of choice."