"COBOL V5 executables are Program Objects that can only resided in PDSE"
there has been an evolution in terminology...
the cobol ( or any compiler ) produces an object deck;
the linkage editor combines the object decks to get a load module,
the binder does the same producing program objects
but a program object might be needed because of the compiler rules
( so it is some kind of chicken and egg war )
the load modules can reside in a PDS
but program objects can reside only in PDSE.
the process is transparent to the user, the user still invokes IEWL,
but when the output resides in a PDSE the binder gets invoked under the covers
and produces a program object
so the process has not changed, the requirements are more stringent
due to the changed structure of COBOL 5 compiler output
at the end You will still be handling executable things...
No, it is not like that. I think the term "Program Objects" comes from outside of COBOL and other Mainframe languages (DLLs are Program Objects. DLLs needn't be COBOL, but can be with earlier Enterprise COBOL, for example). It does cause some confusion when we already have Object Programs.
An Object Program is the result of the compile which can become an executable program (by being processed by the linker/binder). Back in the past, an object program would be/could be physically punched on cards (an Object Program is in 80-character card format) and later presented for input many times. You may still hear references to the "Object Deck". The deck there means cards. Object Deck is the Object Program.
A Program Object, a completely different thing, is a fancier loadmodule. If using C/C++ within your linked/binded program, you must create a Program Object, not a loadmodule. If you are using Enverprise COBOL V5.x (and you should be using V5.2, not V5.1, if you are migrating or have just migrated, I would have thought) then you are using C/C++ within your linked/binded program, so you have a Program Object.
Program Objects cannot be stored on a PDS. They must instead be stored on a PDSE.
You need to clarify with your technical people if Object Programs will now be catalogued whereas previously they were not (it is common to see a temporary dataset of the Object Program output from the compiler and input to the linker/binder - although I prefer catalogued objects) or if it is some confusion of the terms Program Object and Object Program at some point.
I should have been clearer: a compile-link-and-go (affected by 70's advertising of hair-care products, I colloquially refer to these as a Wash'n'Go) produces a loadmodule on a temporary library. At the end of the JOB, the loadmodule disappears because the temporary library does.