Re: BUILDMCS fallout

2017-05-09 Thread Jesse 1 Robinson 
In my previous reply, I was going to mention UCL but removed that reference. 
UCL is a great hammer that hits what you aim it at but cannot tell you what 
else you should be pounding as well. That's why I prefer to (re)traverse the 
SMPE path RECEIVE and APPLY to get all the related pieces in sync. 

My preference for the usermod would be 

-- Rework/rewrite the usermod for the new environment, including DISTLIB even 
though you don't plan to ACCEPT it. Give it a current rework date to make sure 
it gets RECEIVEd. Most important, PRE all the PTFs that have hit the COBOL 
options module during the life of the FMID. 

-- RECEIVE and APPLY the updated usermod. At this point all relevant entries 
should be correct without further tweaking. 

-- If you need to install a subsequent PTF that hits the options module, rework 
the usermod again with a new REWORK date and a PRE for the new PTF. This 
procedure can be used for any normal install.

.
.
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 Jousma, David
Sent: Tuesday, May 09, 2017 9:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: BUILDMCS fallout

Yea, I think you are correct Rob.

_
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 Rob Schramm
Sent: Tuesday, May 09, 2017 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BUILDMCS fallout

There is a warning that the target and dist should be at the same level.
Which makes me think that anyth Maybe just backing off the usermod, and then 
receive / apply after the buildmcs is complete.


Rob Schramm

On Tue, May 9, 2017, 10:49 AM Allan Staller <allan.stal...@hcl.com> wrote:

> 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

Rob Schramm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BUILDMCS fallout

2017-05-09 Thread Jousma, David 
Yea, I think you are correct Rob.

_
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 Rob Schramm
Sent: Tuesday, May 09, 2017 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BUILDMCS fallout

There is a warning that the target and dist should be at the same level.
Which makes me think that anyth Maybe just backing off the usermod, and then 
receive / apply after the buildmcs is complete.


Rob Schramm

On Tue, May 9, 2017, 10:49 AM Allan Staller <allan.stal...@hcl.com> wrote:

> 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
>
> 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
>
>
> ::DISCLAIMER::
>
> --
> --
> 
>
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as 
> information could be intercepted, corrupted, lost, destroyed, arrive 
> late or incomplete, or may contain viruses in transmission. The e mail 
> and its contents (with or without referred errors) shall therefore not 
> attach any liability on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of 
> the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, 
> copying, disclosure, modification, distribution and / or publication 
> of this message without the prior written consent of authorized 
> representative of HCL is strictly prohibited. If you have received 
> this email in error please delete it and notify the sender 
> immediately.
> Before opening any email and/or attachments, please check them for 
> viruses and other defects.
>
>
> -

Re: BUILDMCS fallout

2017-05-09 Thread Rob Schramm 
There is a warning that the target and dist should be at the same level.
Which makes me think that anyth Maybe just backing off the usermod, and
then receive / apply after the buildmcs is complete.


Rob Schramm

On Tue, May 9, 2017, 10:49 AM Allan Staller  wrote:

> 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
>
> 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
>
>
> ::DISCLAIMER::
>
> 
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability
> on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error
> please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
>
>
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BUILDMCS fallout

2017-05-09 Thread Jousma, David 
I scanned the SMPPUNCH of the BUILDMCS and found these:

++MOD(IGYCDOPT) DISTLIB(AIGYMOD1) FROMDS(DSN(IGY.AIGYMOD1) NUMBER(2)
 VOL(DLB01A) UNIT(3390)) RMID(MCOB001) LMOD(IGYCDOPT) .  
++SRC(IGYCDOPT) DISTLIB(AIGYSRC1) FROMDS(DSN(IGY.AIGYSRC1) NUMBER(1)  
VOL(DLB01A) UNIT(3390)) RMID(MCOB001) SYSLIB(SIGYSAMP).   

I suspect this is how COB FMID came to supercede the usermod.  I also had done 
a DEL on the SRC/MOD entries to remove the RMID

_
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: Jousma, David 
Sent: Tuesday, May 09, 2017 11:33 AM
To: 'IBM Mainframe Discussion List'
Subject: RE: BUILDMCS fallout

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 
f

Re: BUILDMCS fallout

2017-05-09 Thread Jousma, David 
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

Re: BUILDMCS fallout

2017-05-09 Thread Jesse 1 Robinson 
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

Re: BUILDMCS fallout

2017-05-09 Thread Allan Staller 
My bad.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, May 9, 2017 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BUILDMCS fallout

Sorry, DDDEF DDnames are the same between releases, and the apply of HADB610 
contains ++DELETES for the old releases.

HADB400  DELETED   FUNCTION
   
HADB420  DELETED   FUNCTION
   
HADB510  DELETED   FUNCTION
   
HADB520  DELETED   FUNCTION
   
HADB610  APPLIED   FUNCTION  HADB610  IFREQUI43370



I was able to fix the problem however with some simple UCLIN.

UCLIN .
   DEL SYSMOD(MCOB001). 
 ENDUCL .   
 SET   BOUNDARY (MVSCBD).   
 UCLIN .
   DEL SYSMOD(MCOB001). 
 ENDUCL .   


After which I was able to receive, and apply.   So life is good.
_
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 Allan Staller
Sent: Tuesday, May 09, 2017 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
may contain viruses in transmission. The e mail and its contents (with or 
without referred errors) shall therefore not attach any liability on the 
originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the views or opinions of HCL or its 
affiliates. Any form of reprod

Re: BUILDMCS fallout

2017-05-09 Thread Jousma, David 
Sorry, DDDEF DDnames are the same between releases, and the apply of HADB610 
contains ++DELETES for the old releases.

HADB400  DELETED   FUNCTION
   
HADB420  DELETED   FUNCTION
   
HADB510  DELETED   FUNCTION
   
HADB520  DELETED   FUNCTION
   
HADB610  APPLIED   FUNCTION  HADB610  IFREQUI43370



I was able to fix the problem however with some simple UCLIN.

UCLIN .
   DEL SYSMOD(MCOB001). 
 ENDUCL .   
 SET   BOUNDARY (MVSCBD).   
 UCLIN .
   DEL SYSMOD(MCOB001). 
 ENDUCL .   


After which I was able to receive, and apply.   So life is good.
_
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 Allan Staller
Sent: Tuesday, May 09, 2017 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
may contain viruses in transmission. The e mail and its contents (with or 
without referred errors) shall therefore not attach any liability on the 
originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the views or opinions of HCL or its 
affiliates. Any form of reproduction, dissemination, copying, disclosure, 
modification, distribution and / or publication of this message without the 
prior written consent of authorized representative of HCL is strictly 
prohibited. If you have received this email in

Re: BUILDMCS fallout

2017-05-09 Thread Allan Staller 
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

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN