Skip, Thanks for the response. I thought I had done everything right, including all the nuances of BUILDMCS. I had accepted all maintenance to the COBOL FMID's prior to the BUILDMCS. The usermod was NOT accepted. As for ongoing maint, we will probably be in a converting mode for a year or longer, that’s why I chose to move it to its own zone, so that I can still install maintenance, but when we are truly done with the conversion, the removal/cleanup will be just as easy. For us, (well our application teams) it will be an especially difficult migration. I think there are a lot of old "sins" lying around yet, in the form of old modules that were compiled under OS/VS cobol, etc. We've converted most of their load libraries to PDS-E with a few exceptions.
As you say, it's all cleaned up now, and in the moment, it was more of an OCD thing, and having everything neat and tidy. It's more of a curiosity thing at this point, but in the end, really doesn’t matter. Thanks, Dave _________________________________________________________________ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, May 09, 2017 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BUILDMCS fallout Leaving aside for the moment the question of whether it's really necessary to 'move' COBOL 4.2 to a separate environment, the SMPE anomalies cited are due mostly to how BUILDMCS works. That process is based on dlibs, not on targets, so any sysmod that is applied but not accepted will not be picked up. That's why it's critical to accept all installed IBM maintenance before running BUILDMCS. Usermods are a special problem. Every sentient voice in the SMPE world says *never* to accept a usermod. But if it's not accepted, then it will get dropped by BUILDMCS. A couple of solutions: -- Accept the usermod before BUILDMCS. IMHO not a good idea because, well, see above. -- Do just what you did, then reinstall the usermod in the new zone. Which is what you did. In order to reinstall, you need to treat it just as you would in a 'normal' environment. However you would handle a PTF that conflicts with a usermod, use the same technique here. I have my own preference for that process, but you should do what makes sense. I think you're OK now. Another question is whether you plan to continue with regular maintenance to COBOL 4.2. Depending your timeline calendar, that might be prudent. Or you could freeze it as is and plow forward; only an issue if a serious problem develops in 4.2 that you have to fix before 6.1 is ready for prime time. The status of MCOB001 is a result of your BUILDMCS procedure. I think it's purely cosmetic. If you reinstall MCOB001 to resolve the MODID conflict, it will look prettier but function the same. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, May 09, 2017 7:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: BUILDMCS fallout Different FMID's. IIRC, different DDDEFs. Should not be any conflict with both compilers in the same zone. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, May 9, 2017 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BUILDMCS fallout All, Maybe a SMPE guru can help me. We are starting to work on conversion project to move from Enterprise COBOL 4.2 to 6.1 and as part of the installation, I did a BUILDMCS on the FMID's for V4.2 so that I could move it into its own set of zones, so that I could install V6.1 into my z/OS zones. The BUILDMCS, and follow-on's to receive and apply into the new zones went fine. However, my usermod for setting default options(MCOB001) somehow got SUP'd by FMID for COBOL. I've been able to overcome this by coming up with a new usermod name, and having it PRE(MCOB001), but if at all possible, I'd like to get this fixed. The usermod wasn't ACCEPTED in its prior zones, so not exactly sure how this happened. From the target zone, and oddly, shows the same for the COBOL DLIB zone as well. Is there a way to remove this relationship? MCOB001 is not applied. Primary Command: FIND Entry Type: SYSMOD Zone Name: MVSCBT Entry Name: MCOB001 Zone Type: TARGET Description: Type: Status: FMID: SUPBY HADB420 Date/Time: _________________________________________________________________ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
