I was also going down that same path while looking at it. Now, how to fix without changing the DDDEFs, which was the entire point behind using DD overrides. I just might open a ticket with SMP/e support and get their take on the situation.
Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&[email protected] ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, March 23rd, 2021 at 2:38 PM, Pommier, Rex <[email protected]> wrote: > Short answer is that yes it should cause a concern. Will SMP/E drop something > into one of those libraries then go get it to perform a link or something > later in the apply? I wouldn't trust it if I had some parts of SMP/E pointing > to overrides and other parts of SMP/E not using the same libraries when it > expects them to be the same. > > Just my opinion. > > Rex > > -----Original Message----- > > From: IBM Mainframe Discussion List [email protected] On Behalf Of > Mark Jacobs > > Sent: Tuesday, March 23, 2021 11:18 AM > > To: [email protected] > > Subject: [External] Re: SMP/e Dataset allocation question > > It is, yes. > > SMP00001 > > SCEEOBJ SMP00001 PERM CEE.SCEEOBJ Z24A01 3390 SHR > > SCEELKEX SMP00002 PERM CEE.SCEELKEX Z24A01 3390 SHR > > SCEELKED SMP00003 PERM CEE.SCEELKED Z24A01 3390 SHR > > CSSLIB SMP00004 PERM SYS1.CSSLIB Z24A01 3390 SHR > > SEUVFLIB SMP00005 PERM EUVF.SEUVFLIB Z24A01 3390 SHR > > SMP00006 > > SCEEOBJ SMP00006 PERM CEE.SCEEOBJ Z24A01 3390 SHR > > SCEELKEX SMP00007 PERM CEE.SCEELKEX Z24A01 3390 SHR > > SCEELKED SMP00008 PERM CEE.SCEELKED Z24A01 3390 SHR > > CSSLIB SMP00009 PERM SYS1.CSSLIB Z24A01 3390 SHR > > Many more. > > But as I said, they're showing the volumes that are in the DDDEF(s), not the > ones I've specified in the overrides. I don't know if that's a concern though. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&[email protected] > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Tuesday, March 23rd, 2021 at 11:55 AM, Dana Mitchell [email protected] > wrote: > > > Mark, > > > > Thats probably part of a dynamic concatenation that SMP/E did for a SYSLIB > > sort of a input DD name. Is the DDDEF part of a concatenation similar to > > this?: > > > > DDNAME DDDEFNAM SMPDDNAM TYPE -----------------------DATA SET OR > > > > PATH----------------------- > > > > SMP00048 > > > > SCEEOBJ SMP00048 PERM SYS1.SCEEOBJ Z22RSB 3390 SHR > > > > SCEELKEX SMP00049 PERM SYS1.SCEELKEX Z22RSB 3390 SHR > > > > SCEELKED SMP00050 PERM SYS1.SCEELKED Z22RSB 3390 SHR > > > > CSSLIB SMP00051 PERM SYS1.CSSLIB Z22RSB 3390 SHR > > > > SEUVFLIB SMP00052 PERM SYS1.SEUVFLIB Z22RSB 3390 SHR > > > > Dana > > > > On Tue, 23 Mar 2021 14:43:02 +0000, Mark Jacobs [email protected] > > wrote: > > > > > I'm running an apply check with dataset overrides, same DSN, different > > > volume. Here's one example. > > > > > > //CSSLIB DD DISP=SHR,UNIT=3390,VOL=SER=Z24AM1,DSN=SYS1.CSSLIB > > > > > > The SM APPLY CHECK FILE ALLOCATION REPORT shows that my override is > > > > > > being used, > > > > > > SYS1.CSSLIB Z24AM1 SHR > > > > > > But in the dynamic allocation processes, it's showing the volume > > > specified in the DDDEF, not the one specified in my override. > > > > > > CSSLIB SMP00004 PERM SYS1.CSSLIB Z24A01 > > > > > > is this a concern? > > > > 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 > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to this message and destroy the material in its entirety, whether in > electronic or hard copy format. Thank you. > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > 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
