/* is really not the null stmt, // is. If you code // after a step, you'll see that the "reader" will stop reading JCL in your job at that point.
/* does seem to be useless since the next DD stmt or EOF will trigger EOF on the "card" I/P.
in the absence of a JCL forum as Kurup stated, this might be one of the best "host" forums for JCL, since many COBOL programmers (at least the ones on a mainframe environment) come into contact with it regularly.
It is possible but I have not a warm feeling about this. COBOL is COBOL. I even think that you should separate COBOL and algorithms.
On the MVSHELP forum, JCL is a separate subject. I think that JCL on its own is not something that will have a lot of members. If you add SORT, ISPF and IBM utilities like IEBCOPY, IEBGENER, IEBPTPCH, and perhaps also AFP and things like that, you will find interested people.
The forum name could be IBM mainframe tools...
That would be a forum that I like.
Perhaps this is something for the Round Table...
So if anyone likes the 'IBM mainframe tools' forum, let it know and I will suggest this in the Round Table forum....
Hi Crox,
It would be a great idea to go for 'IBM Mainframe Tools' forum but at present as there is no other alternative we can post JCL in this section itself
Regards
Kurup
IEBCOPY,IEBGENER are a set of utility programs used in JCL. A UTILITY is a set of used and tested programs that perform a variety of functions.Utility Programs fall into 3 classes:
System Utility Programs
Data Set Utility Programs
Independent Utility Programs
Some of the Data set utility programs are
IEBGENER
IEBCOMPR
IEBCOPY
IEBIMAGE
IEBUPDATE
IEBGENER is Used to create, copy or print sequential or partitioned datasets.
IEBCOPY provides the following functions:
Backup(unload)
Restore(reload)
Copy
Compress
Updates
Did you know that there were APARs issued against IEFBR14? APARs are IBM "trouble reports".
Originally, IEFBR14 was a BR 14 assembler instruction. This branched back immediately to the caller (the OS), hence the name IEFBR14. However, since this didn't clear register 15 (that's where the step return code goes), Reg 15 sometimes contained "garbage". A SR 15,15 instruction was added.
I've heard other APARs have been generated since, but I don't know the details.
IN my place of business, we use IEFBR14 in JCL simply to create "new" Data sets, or delete current data sets. eg:
//STEP0 EXEC PGM=IEFBR14,
// REGION=64K
//DD1 DD DSN=TN0100.A143800.SR26547.ETRM.FINDER,
// UNIT=SYSDA,
// DISP=(MOD,DELETE,DELETE),
// SPACE=(CYL,(5,5),RLSE)
Just curious Crox, How does a COBOL "GOBACK" do that for you?
As a mainframe, COBOL and Easytrieve Plus programmer, I use JCL every day. This seems to be an appropriate place for JCL questions.
It is the Job Entry System (JES) that processes all your Job Control statements.
This site has not a JCL forum. I guess there will not be that many questions to make an unique forum for that.
Also not all COBOL programmers are on the mainframe. There are enough people working on a PC. Why would they be glad with JCL? I don't think so.
So what we need is something like MVS or IBM mainframe tools or something like that as a new forum. But in the round table forum people don't have that feeling I am afraid.
I hope now that you understand what an IEFBR14 does....
Ofcourse you can also make an IEFBR14 by coding one STOP RUN statement. But in my environment here we all use GOBACK all the time...
i heard a story one time that it took IBM quite a bit of trouble to write a program that actually, really does nothing, like IEFBR14 is intended to. I'm no expert on this subject matter, but there seems to be a lot more to it than just the branch it derives its name from.
Heleng,
that is the whole point about IEFBR14; you need a EXEC statement, and IEFBR14 gives the opportunity to code one that does nothing, so you'll have something to code your DD statement under.
I spoke someone whom disassembled the IEFBR14 and he said that it is just a GOBACK. I am not specialized in this matter, just telling what other people told me. I am quite sure that the smallest COBOL program possible with one GOBACK does exactly what you need when you want to immitate an IEFBR14.
The reason I asked was that I recently started on a new consultig assignment and haven't been given my TSO id and Pwd yet, so I can't do it myself.
I'd guess that IEFBR14 is under 10 bytes long. The COBOL GOBACK, I'd guess, would be considerably larger. I know, from looking at the beginning of a cobol pgm, that there are a few hundred bytes of assembler code and data generated before the Proc Div is executed. Not that it really matters, as long as you get what you want out of it, and I'm sure that it'll work. I'm just curious.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.