On an IBM Mainframe running z/OS, you run a utility which copies a dataset (file) to another dataset (file). The input is the source of the JCL (Job Control Language) that you have submitted to cause it to run. The output is the Internal Reader (INTRDR). You will also need to ensure that your system does not allow the running of multiple identical jobnames. Good to use a job-class which only has one initiator (place where a JOB can run in batch).
There are no PIDs involved (in z/OS), so fails the challenge set.
You halt the process by draining and/or flushing. If something has gone wrong, by draining and/or flushing, swearing, kicking, attempting a warm-start and finally by a cold-start or hitting the Big Red Button (and shooting the programmer).
I may have exaggerated along the way, but don't try this at work...
Example using SORT. Details on the JOB card are very site-dependant. Site policy may either forbid or prevent the use of INTRDR. A specific class may be required to use the INTRDR. If your site policy forbids its use do not use it unless you want to take your belongings for a walk in a cardboard box.
Although there are good uses for the INTRDR, do not use it for this purpose. You won't even have a chance to get your box.
//jobname JOB rest is to your site standards
//STEP0100 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTOUT DD SYSOUT=(,INTRDR) minimum required, site may require more
//SYSIN DD *
//SORTIN DD DISP=SHR,DSN=YOUR.LIBRARY.WITHJOB(JOBMEMBR)
Other utilities are available. A quick program would be easy to do as well, just read a file, write a file.
If you want an example of this going wrong, try: http://ibmmainframes.com/viewtopic.php?p=282414#282414
The traditional way to copy a dataset is to use the IBM utility IEBGENER, as ugoren alludes in their comment.
However, these days, many sites will have IEBGENER "aliased" to ICEGENER. ICEGENER will, if it can, use IBM's DFSORT (or its rival SyncSort) to do a copy, because the SORT products are much more hihgly optimised for IO than IEBGENER is.
I'm just cutting out the middle-man by using SORT.
If you work at an IBM Mainframe site, you know the format of the JOB card that you should use. The minimal JOB card is as I have shown, without the comment. The comment will be important, because you may be supposed to be supplying accounting information, for instance. The jobname will likely have a site-specific format.
Some sites ban, or prevent, the use of the INTRDR. Be aware.
Some sites allow multiple jobs with the same name to run at the same time. Be aware.
Although unless you are a System's Programmer you can't set up such a class, you should look for a class which allows only one initiator. With that, the process is fairly safe - but be absolutely sure about that the class is working as described. Test. Not with this job.
If you are a System's Programmer, you know not to do anything outside of your remit. 'nuff said.
With one job with the same name allowed at the same time and a single initiator, this will be a constant stream of job start/finish next job start/finish - until you fill the spool (another bad thing to do) with the output from thousands of jobs (or run out of job numbers). Watch a JES Console for warning messages.
Basically, don't do this. If you do do it, don't do it on a Production machine.
With a little brushing up, I'll consider another Answer for how to do it on another IBM Mainframe operating system, z/VSE... z/VSE uses JCL. z/OS uses JCL. They are different :-)