IBM Mainframe Forum

what is difference btw In-steam and cataloged procedure?

If I need to use SYMBOLIC Variable in the PROC and pass al the variables from job.
Which is better option and why?

thank you

Hello,

In-stream is just as it says - it is in the submitted job. A cataloged procedure is stored in a pds (usually xx.yy.PROCLIB or similar).

Rethink your second question. . . What do you see as the "alternatives" from which to choose?

Generally, in my modest experience, all production procedures are in libraries and most testing procedures. For a start - if the procedure is in the library then everyone can use it (if authorised) whereas if it is instream only you can use it. I may, when developing procedures, use instream but once sorted I put them into the library.

cataloged procedure

Hello,

I went brain-blank earlier when thinking about alternatives. . . Other than when one is experimenting or working on a one-time requirement that needs to be run many, many times and can take advantage of symbolic parameters, overrides, etc my clients ALWAYS use PROCLIBs.

The better organized environments are configured with at least a PRODuction and a TEST proclib. Several have a library for QA and Production Repair. . .

The issue about "PROCLIBs" is actually more than a little confusing.

In the beginning there was SYS1.PROCLIB. Didn't like the name? Tough. It stayed that way until MVS. In stream procedures were added late in OS/360.

It started to get confusing with MVS.

• There was potentially a separate, moderately well hidden, library used to start MVS subsystems. Many shops used SYS1.PROCLIB, and continue to use it, but not all. Originally this was specified in a LNKLST load module that just had the JCL used to start the "master" subsystem; now it has been parameterized to a PARMLIB member that contains the JCL.
• The JES subsystems allowed specification of multiple proclibs, both as concatenations, and as a selectable library. In more recent MVS releases the PROCLIB definition was parameterized rather than specified in the JCL used to start JES. This was done because it was all too common for a JCL error in the proclib definition caused JES to not start. Oops. So in JES2, you have /*JESPARM PROC=nn. where the nn selected a proclib defined by the PROCnn DD statement in the JES2 startup JCL or established through JES2 initialization statements. As others have noted, many shops have established a library that us non-priviledged grunts can update, but this can be dangerous; the library can run out of space, or the directory can fill up. Another problem is the library can extend into an additional extent; members placed in the new extent may not be accessible right away.
• Many shops had a JES2 extension, such as the CA "Easy Proclib" product that provided a JES2 JECL control statement, /*PROCLIB dataset, that effectively inserted the dataset into the proclib definition for the job.
• The // JCLLIB ORDER=(dataset,...,dataset) JCL statement was added that provided functionality similar to the /*PROCLIB change in the previous bullet.

Now, of course, we have no idea about your system. You will have to figure out what you can do in your system all by your little self.