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.