Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

JCL overriding concept

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
s.saranya srinivasan

New User


Joined: 25 Sep 2015
Posts: 9
Location: india

PostPosted: Wed Oct 07, 2015 4:07 pm    Post subject: JCL overriding concept
Reply with quote

can anyone explain the jcl overriding concept
Back to top
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Oct 07, 2015 4:17 pm    Post subject: Reply to: JCL OVERRIDING
Reply with quote

Read in the JCL Reference. If you still don't understand it completely, explain what you do understand, and ask a specific question.
Back to top
View user's profile Send private message
David Robinson

Active User


Joined: 21 Dec 2011
Posts: 175
Location: UK

PostPosted: Wed Oct 07, 2015 6:25 pm    Post subject: Reply to: JCL OVERRIDING
Reply with quote

Or just ask one of your colleagues. Far simpler than trying to explain it on a forum.
Back to top
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 437
Location: London

PostPosted: Thu Oct 08, 2015 7:51 pm    Post subject:
Reply with quote

simply put it allows a new piece of JCL to replace some that is already there, without actually altering the original piece of JCL. It is usually used as a temporary measure to overcome a specific issue.
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 460
Location: The Universe

PostPosted: Fri Oct 09, 2015 9:29 am    Post subject:
Reply with quote

When I first started with OS/360, a commonly used cataloged procedure was FORTGCL to compile and link edit a Fortran program. While the details may be incorrect, the procedure looked like this -
Code:
//FORT    EXEC PGM=IEYFORT,PARM='OBJECT,NODECK',
//             REGION=100K
//SYSPRINT DD  SYSOUT=*
//SYSLIN   DD  DISP=(MOD,PASS),UNIT=SYSDA,
//             DCB=(RECFDM=FB,LRECL=80,BLKSIZE=2960),
//             DSN=&&LOADSET
//LINK    EXEC PGM=IEWL,COND=(8,GE,FORT),REGION=100K,
//             PARM='SIZE=(100K,12K),MAP'
//SYSPRINT DD  SYSOUT=*
//SYSUT1   DD  UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSLIB   DD  DISO=(SHR,PASS),DSN=SYS1.FORTLIB
//SYSLMOD  DD  DISP=(MOD,PASS),UNIT=SYSDA,
//             SPACE=(CYL,(1,1,1)),DSN=&&GOSET(GO)
//SYSLIN   DD  DISP=(OLD,PASS),DSN=&&LOADSET
//         DD  DDNAME=SYSIN
The JCL to use the procedure would be something like this -
Code:
//... JOB ...
//... EXEC FORTGCL
//FORT.SYSIN DD *
... A Fortran program

There is one example of a JCL override in this JCL: //FORT.SYSIN DD *. The FORT. qualifier tells the JCL processor this DD statement belongs to the FORT step in the procedure.

A very common JCL override for this procedure was to update the SYSLMOD DD statement to store the load module in a permanent library; the JCL might look like this.
Code:
//... JOB
//... EXEC FORTGCL
//FORT.SYSIN DD *
... A Fortran program
//LINK.SYSLMOD DD DISP=OLD,DSN=library(program),
// SPACE=,UNIT=

Here the JCL override updates the SYSLMOD DD statement in the LINK step. We respecify essentially the entire DD statement. We specify SPACE= to nullify the SPACE parameter in the procedure so the secondary allocation in the SPACE parameter in the procedure is not used. Similarly, the UNIT parameter in the procedure is nullified so the unit implied by the catalog entry for the program library is used.

More details, including how to override elements of EXEC statements are in the JCL Reference manual for your z/OS release.
Back to top
View user's profile Send private message
Willy Jensen

New User


Joined: 01 Sep 2015
Posts: 94
Location: Switzerland

PostPosted: Sat Oct 10, 2015 12:01 am    Post subject:
Reply with quote

Maybe worthwhile mentioning is that JCL override is primarily used with procedures in a JESx proclib, or libraries defined through a JCLLIB statement. Though it works equally well with inline procedures.

Willy
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 460
Location: The Universe

PostPosted: Sun Oct 11, 2015 8:25 am    Post subject:
Reply with quote

Willy Jensen wrote:
Maybe worthwhile mentioning is that JCL override is primarily used with procedures in a JESx proclib, or libraries defined through a JCLLIB statement. Though it works equally well with inline procedures.

Willy
Mr. Jensen is correct, of course. Early versions of OS/360 did not have in line procedures, or, for that matter, the // PROC statement and JCL symbols, and // JCLLIB did not exist until well into MVS. User PROCLIBs were possible, though there was no formal, documented way to implement them until MVS. In fact, my example FORTGCL proc would not work until, I think, OS/360 Release 18.
Back to top
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 437
Location: London

PostPosted: Mon Oct 12, 2015 1:47 pm    Post subject:
Reply with quote

showing your age guys!

OS360 didn't even have JES2, it was HASP (or the OEM GRASP) in those days! Oh..and those horrible pre-ICF catalogs...DLBL's & TLBL's with specific UNIT and VOL...nightmare.

and when those punchcards got chewed up... icon_sad.gif
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Mon Oct 12, 2015 3:00 pm    Post subject: Reply to: JCL OVERRIDING
Reply with quote

I thought DLBL and TLBL were DOS. Might the reason that DOS and OS both have "JCL" be that they have a common ancestor?
Back to top
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 437
Location: London

PostPosted: Mon Oct 12, 2015 3:08 pm    Post subject:
Reply with quote

yes 360 was DOS, well the one I worked on was anyway...360/40. Pretty sure MVS didn't emerge until the early eighties...with MFT then OS/VS1&2 preceeding it.

Mind you those brain cells have taken a hammering so happy to be corrected!
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 460
Location: The Universe

PostPosted: Mon Oct 12, 2015 7:47 pm    Post subject:
Reply with quote

System/360 (the hardware) begat TOS/360, DOS/360 and OS/360. TOS/DOS were quickies because OS/360 was running late and because it was too big for systems most potential customers could afford, and IBM marketing desperately needed something for their lower end customers. DOS was not a true disk operating system. Like the disk SYSRES versions of 7090 IBSYS (another tape operating system), DOS was just TOS with a disk SYSRES, but it did not really exploit the capabilities of the disk.

As we all know, DOS/360 refused to die. It begat VSE and z/VSE.

I think Mr. Woodger is incorrect. All operating systems that support stacked job processing, like FMS and IBSYS, provided some sort of control language, though it was not called that until the System/360 operating systems. To the extent there was an “ancestor” of JCL in TOS/DOS and OS/360, it was the control language in IBSYS/IBJOB. To the best of my knowledge, there was never any commonality between TOS/DOS JCL, and OS/360 JCL other than the name. There was some talk about a “standardized” control language in the late 1960s and early 1970s, but nothing came of it.

Mr. Wilson, too, is incorrect.

There were three significant variants of OS/360: PCP (Primary Control Program), MFT (Multiprogramming with a Fixed number of Tasks), and MVT (Multiprogramming with a Variable number of Tasks). PCP and MFT were more closely related than most people now appreciate. In a very real sense, PCP was MFT with one task. MVT, on the other hand, was a much different animal.

In the 1970s, when IBM conceded paging hardware and virtual storage were the future, MFT begat OS/VS1, MVT begat OS/VS2 Release 1 and a whole new animal, OS/VS2 Release 2, later called MVS. Like TOS/DOS, VS1 and VS2 Release 1 were quickies to get some sort of virtual memory system into the hands of users.

The MVS animal of 1973/1974 was pretty bad. True, compared to VS2 Release 1, it was very stable, but it was very hard to control. In the late summer of 1974 I went to a 2 week MVS class. One of the class problems was to tweak the resource manager variables to see what would happen. The conclusion of this exercise is almost anything you did hurt, and it was generally uncontrollable. It took a major rewrite of the resource manager before MVS became truly controllable and usable in 1975 or so.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Mon Oct 12, 2015 8:29 pm    Post subject: Reply to: JCL OVERRIDING
Reply with quote

Not sure what you felt was incorrect. DLBL and TLBL are DOS for sure. The rest of the text was a question.
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 460
Location: The Universe

PostPosted: Mon Oct 12, 2015 9:05 pm    Post subject: Re: Reply to: JCL OVERRIDING
Reply with quote

Bill Woodger wrote:
Not sure what you felt was incorrect. DLBL and TLBL are DOS for sure. The rest of the text was a question.
I question whether JCL in TOS/DOS and JCL in OS/360 were related. Other than the unnamed control language in systems like FMS and IBSYS/IBJOB, which, in a sense, were JCL ancestors, there was no common ancestor to the two JCLs.
Back to top
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 437
Location: London

PostPosted: Tue Oct 13, 2015 12:56 am    Post subject:
Reply with quote

Gordonius Bennettus! You created a neuronal connection that I thought was lost forever in the mists of Islay there Steve, bringing up all those incarnations from DOS to MVS. I was never a TOSer although I have known a few, some of who I would call MFT's due to their advanced skills.
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 460
Location: The Universe

PostPosted: Tue Oct 13, 2015 8:18 am    Post subject:
Reply with quote

steve-myers wrote:
... There were three significant variants of OS/360: PCP (Primary Control Program), MFT (Multiprogramming with a Fixed number of Tasks), and MVT (Multiprogramming with a Variable number of Tasks). PCP and MFT were more closely related than most people now appreciate. ...
I think it worth while to amend the last sentence.

PCP and the original MFT were more closely related than most people now appreciate.

In a very real sense, there were two MFT versions: the second version was a toned down MVT that used what amounted to the MVT job manager. This is the MFT that most of us remember. The original MFT used the PCP job acheduler, which ran in just one partition at a time. The concept was to start a never ending job - like the original HASP - which released the scheduler to run regular batch jobs in another partition as HASP gave it the jobs.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Overriding the default Code page rikdeb PL/I & Assembler 2 Fri Aug 09, 2013 12:12 am
No new posts Overriding SYSOUT of IKJEFT01 to a da... enrico-sorichetti IBM Tools 8 Sun Apr 07, 2013 5:19 am
No new posts Overriding dd statements in cataloged... Harsha1525 JCL & VSAM 15 Thu Jul 26, 2012 3:04 pm
No new posts Image copy concept sravz chinnu DB2 6 Thu Apr 19, 2012 5:10 pm
No new posts SRRCMIT concept for MQ kunal jain COBOL Programming 6 Mon Mar 19, 2012 1:20 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us