you can send object code as IBM and other vendors does and let SMP link it. Another option is to name the cobol source as Assembler, and replace the assembler processor to IGYCRCTL. The only problem i see is the many work files the Cobol compiler uses and wouldn't be allocated by the "assembler", but you can permanently allocate them via JCL. I would give it a try.
ITschak ITschak Mugzach Z/OS, ISV Products and Application Security & Risk Assessments Professional On Sun, Sep 13, 2015 at 7:38 PM, Paul Gilmartin < [email protected]> wrote: > On Sun, 13 Sep 2015 13:19:19 -0300, Clark Morris wrote: > > > >If you are only supplying load modules/program objects, it could work > >but if there are any source COBOL members I doubt SMP/E would work > >unless SMP/E has expanded to handle languages other than COBOL. ... > > > It hasn't. Is there a COBOL source element type nowadays? A desirable > enhancement would be a customer-extensibie build utility set. Think > Makefile: the standard element types and the utilities for building are > defined in /etc/startup.mk; the customer is free to add as many others > as needed. > > If the compiler generates Private Code sections, SMP/E can never replace > these with service; they simply accumulate with each APPLY or RESTORE. > IIRC, VS/Pascal was (is?) a notorious offender here. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
