An Endevor processor is executing ADRDSSU to dump a MFS into a PDSE loadlib (recfm U; recL 0; bLksize 27998).
This output member is not a real load module but a Dump DFDSS.
The move processor execute IEBGENER instead of BSTCOPY to copy this output component. BSTCOPY can't copy such member.
When we try to ship the package used to move the element, Shipment fails with message:
C1BMX39E STAGING DATASET COPY ERROR - RC=000004 and
C1G0191W MEMBER x COPY OPERATION COMPLETED. MEMBER NOT COPIED, REASON CODE 00000008.
The IEWDIAG messages are:
IEW2515W 4731 DIRECTORY ENTRY FOR MEMBER x IDENTIFIED BY DDNAME SYS00015 IS NOT MARKED AS LOAD MODULE.
IEW2522E 470E MEMBER x IDENTIFIED BY DDNAME SYS00015 WITH CONCATENATION NUMBER 1 IS NOT A LOAD MODULE.
How can we fix this?
There is logic in Ship that expects that all RECFM=U datasets being shipped are real load modules and builds COPYMOD instead of COPY statements for these items.
Enhancing the logic to detect if a PDS/E load member is actually a real load module is not likely to be a trivial task because of the way the staging and de-staging of libraries are handled, and if possible would certainly add processing overhead to the current ship process.
Understanding that this can't be a easy task, we have worked on a possible bypass that works in both processor and shipment.
Release: ENDAE.00200-18.0-Endevor-Software Change Manager
When recommend tho use the TSO TRANSMIT/RECEIVE to 'dump' the IMS Format components, instead of ADRDSSU
- this will preserve all the member data, including footprints, and would probably be easier to un-pack at the ship destination.
Here is a sample:
//XMIT EXEC PGM=IKJEFT01,REGION=4096K,DYNAMNBR=16
//SYSTSPRT DD SYSOUT=A
//FMTDSN DD DSN=&FMTDSN, * Format components
//XMIT DD DSN=&&XMIT,
//SYSTSIN DD *
XMIT node.userid +
DDNAME(FMTDSN) MEM(&C1ELEMENT) +
//MSGFILE DD *
The attached file contains element &C1ELEMENT / &C1ELTYPE.
As at date: &C1ADDMMYYYY