Re: SMP/E question of the day

On Mon, 18 Dec 2023 08:12:33 -0600, Paul Gilmartin wrote: >In , >the entire description of the MAME parameter syntax is:name >There is no mention of a limit of length. You're making that up. The SMP/e programming API tells you

Re: SMP/E question of the day

Oops. I have a REXX exec that creates a TSO alias on command, just because I don't do it often enough to remember the syntax at the time. I named it TALIAS. Maybe I'd better find another name...at least I should if I put it in a team library. If it's my own SYSPROC or SYSEXEC PDS I don't

Re: SMP/E question of the day

List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Sunday, December 17, 2023 12:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question of the day On Sun, 17 Dec 2023 15:12:59 +, Seymour J Metz wrote: >Given that a csect may be included in

Re: SMP/E question of the day

On Mon, 18 Dec 2023 13:39:09 +, Kurt Quackenbush wrote: NAME ABCDITSK ABCPROC#C C_CODE > >>> I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and >>> CLASS names specified on the IMASPZAP NAME statement. CSECT name ABCPROC#C >>> is 9 characters. > >> You're

Re: SMP/E question of the day

>>> NAME ABCDITSK ABCPROC#C C_CODE >> I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and >> CLASS names specified on the IMASPZAP NAME statement. CSECT name ABCPROC#C >> is 9 characters. > You're making that up. I'm making that up? I don't think so, I counted

Re: SMP/E question of the day

On Sun, 17 Dec 2023 14:10:51 -0600, Paul Gilmartin wrote: >On Sun, 17 Dec 2023 12:52:49 -0600, Jon Perryman wrote: >> >>++ZAP does not document limitations already described in ++MOD and ++JCLIN. >> >And yet it says: > > >name >

Re: SMP/E question of the day

On Sun, 17 Dec 2023 11:01:23 -0600, Paul Gilmartin wrote: >The CSECT() option of the ++MOD MCS should clarify this. But it's optional, >and I don't know that it's verified, even if present. CSECT defaults to ++MOD name which generates BINDER REPLACE statements. Specifying additional CSECT

Re: SMP/E question of the day

On Sun, 17 Dec 2023 12:52:49 -0600, Jon Perryman wrote: > >He's not making it up the 8 char limit. ++MOD and ++JCLIN create those SMP/e >entries. ++ZAP does not document limitations already described in ++MOD and >++JCLIN. > And yet it says:

Re: SMP/E question of the day

M-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question of the day On Sun, 17 Dec 2023 15:12:59 +, Seymour J Metz wrote: >Given that a csect may be included in multiple program objects (is there a >generic term for LM & PO), I don't see whwre you would need an lmod parameter >on the NAME stat

Re: SMP/E question of the day

On Sun, 17 Dec 2023 15:12:59 +, Seymour J Metz wrote: >Given that a csect may be included in multiple program objects (is there a >generic term for LM & PO), > I don't see whwre you would need an lmod parameter on the NAME statement. It's rare but a ++ZAP circumvents a problem that the

Re: SMP/E question of the day

On Sun, 17 Dec 2023 09:02:37 -0600, Paul Gilmartin wrote: >On Thu, 14 Dec 2023 22:22:51 +, Kurt Quackenbush wrote: > >>> NAME ABCDITSK ABCPROC#C C_CODE >>I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and >>CLASS names > specified on the IMASPZAP NAME statement.

Re: SMP/E question of the day

On Sun, 17 Dec 2023 15:12:59 +, Seymour J Metz wrote: >Given that a csect may be included in multiple program objects (is there a >generic term for LM & PO), I don't see whwre you would need an lmod parameter >on the NAME statement. Allowing SMP to zap one instance in the target >libraries

Re: SMP/E question of the day

Sent: Saturday, December 16, 2023 5:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question of the day On Thu, 14 Dec 2023 11:54:28 -0500, Phil Smith III wrote: >++VER(Z038) FMID(VABC840) . >++ZAP(ABCDITSK) . >NAME ABCDITSK ABCPROC#C C_CODE >--NAME ABCDITSK ABCPROC#C C_

Re: SMP/E question of the day

On Thu, 14 Dec 2023 22:22:51 +, Kurt Quackenbush wrote: >> NAME ABCDITSK ABCPROC#C C_CODE > >I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and >CLASS names specified on the IMASPZAP NAME statement. CSECT name ABCPROC#C is >9 characters. > You're making that up.

Re: SMP/E question of the day

On Thu, 14 Dec 2023 11:54:28 -0500, Phil Smith III wrote: >++VER(Z038) FMID(VABC840) . >++ZAP(ABCDITSK) . >NAME ABCDITSK ABCPROC#C C_CODE >--NAME ABCDITSK ABCPROC#C C_CODE. >GIM23101E ** THERE IS A SYNTAX ERROR IN A ZAP CONTROL STATEMENT FOR MODULE > ABCDITSK IN SYSMOD

Re: SMP/E question of the day

>> name ABCPROC#C is 9 characters. > Right, but that's the generated name-the module is ABCPROC, written in C. How > does one get around this? As a circumvention you can create a ++MOD to replace the entire module instead of using a ++ZAP to zap the load module. If you require SMP/E to

Re: SMP/E question of the day

On Fri, 15 Dec 2023 11:53:03 -0500, Phil Smith III wrote: > >Right, but that's the generated name-the module is ABCPROC, written in C. How >does one get around this? As Gil suggests, this seems like an SMP/E >bug/failing. > I'll generalize: It's improper for middleware, in this case SMP/E, to

Re: SMP/E question of the day

Kurt Quackenbush wrote, re: >> NAME ABCDITSK ABCPROC#C C_CODE >I believe SMP/E supports a maximum of 8 characters for the LMOD, >CSECT, and CLASS names specified on the IMASPZAP NAME statement. CSECT >name ABCPROC#C is 9 characters. Right, but that's the generated name-the module is

Re: SMP/E question of the day

On Thu, 14 Dec 2023 22:22:51 +, Kurt Quackenbush wrote: >> NAME ABCDITSK ABCPROC#C C_CODE > >I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and >CLASS names specified on the IMASPZAP NAME statement. CSECT name ABCPROC#C is >9 characters. > If the section name was

Re: SMP/E question of the day

> NAME ABCDITSK ABCPROC#C C_CODE I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and CLASS names specified on the IMASPZAP NAME statement. CSECT name ABCPROC#C is 9 characters. Kurt Quackenbush IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Re: SMP/E question of the day

Binyamin wrote: >Unless you are sending this via teletype or FAX, I question why you >would provide a zap rather than a module replacement. Well, we've been discussing that already. But we'd like to understand it at least. Meanwhile, Tom Marchant's suggestion sounded helpful, except it's C

Re: SMP/E question of the day

Unless you are sending this via teletype or FAX, I question why you would provide a zap rather than a module replacement. On Thu, 14 Dec 2023 11:54:28 -0500 Phil Smith III wrote: :>From a coworker, who tried to post but it seems to have vanished-not even a bounce?! If it just got stuck

Re: SMP/E question of the day

Does this help, from the SMP/E User's Guide: The superzap control statements are the same as you would use if you were calling the superzap utility. The only exception is that on the NAME statement, you should specify only the CSECT name within the distribution library module, rather than

SMP/E question of the day

>From a coworker, who tried to post but it seems to have vanished-not even a >bounce?! If it just got stuck somewhere, this might be a duplicate, sorry. I am having problems trying to convert a normal ZOS AMASPZAP to a SMPE ++ZAP. When I run the zap through a standalone AMASPZAP

Re: Next SMP/E question

> ADD DDDEF(VSHZFSX) PATH'/u/some/directory') . > So it doesn't validate access to or even existence of that directory. APPLY CHECK does indeed check for the existence of the directory, but it does not check a user's permissions to update files in that directory. Kurt Quackenbush IBM

Re: Next SMP/E question

Hi Phil, That is true provided the DDDEFs are instead coded as JCL. Regards, David On 2023-09-05 20:47, Phil Smith III wrote: Mark Jacobs wrote: Apply check doesn't open any target traditional datasets, or Unix System Services paths, so it's WAD. Whether it should is a different question.

Re: Next SMP/E question

The rationale is simple: the target libraries may not be accessible on the system performing the APPLY CHECK ... for example, golden master environment, where APPLY CHECK is to validate the fix pre/coreq before distribution. Another example is security rights, APPLY cauld run under a more

Re: Next SMP/E question

Mark Jacobs wrote: >Apply check doesn't open any target traditional datasets, or Unix >System Services paths, so it's WAD. Whether it should is a different >question. And in my experience (limited, obviously) with traditional target data sets, you'll get a JCL error earlier. So this may just be

Re: Next SMP/E question

Apply check doesn't open any target traditional datasets, or Unix System Services paths, so it's WAD. Whether it should is a different question. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key -

Next SMP/E question

I have a statement in the allocate job: ADD DDDEF(VSHZFSX) PATH'/u/some/directory') . The later Apply Check job just does: //SMPCNTL DD * SET BOUNDARY(TARGET) . APPLY S(VVSH840) CHECK . So it doesn't validate access to or even existence of that directory.

Re: SMP/E question

Clone or take backups of the SMP/E environment, and apply to cloned SYSRES's and/or target libraries. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Friday, December 14, 2018 9:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question [External

Re: SMP/E question

Other than doing backups, I would also do a SMP/e BUILDMCS. Here is an example: SET BDY(FROMDLB) /* DLIB zone where HMP1E00 is installed */. BUILDMCS /* Build the MCS and JCLIN */ FORFMID(HMP1E00) /* for the FMID HMP1E00 */.

Re: SMP/E question

It is quite typical that new version replaces (deletes) the old one. Usually SMP/E APPLY can be reverted by SMP/E, but ...I wouldn't rely on that. Even regular PTF with DELETE cannot be reverted. What to do? make copy of CSF.** datasets. -- Radoslaw Skorupka Lodz, Poland W dniu

Re: SMP/E question

-Original Message- From: IBM Mainframe Discussion List On Behalf Of Lopez, Sharon Sent: Friday, December 14, 2018 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMP/E question **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** We want

SMP/E question

We want to install the new ICSF HCR77C1 to pick up the new function but we have HCR77C0 installed. Why does HCR77C1 delete HCR77C0 and would I be able to back HCR77C1 off if we need to. The information in this transmission may contain proprietary and non-public information of BB or its

Re: Kind of lame SMP/E question

- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, September 19, 2018 9:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Kind of lame SMP/E question Thanks, that is the direction I have asked them to pursue. It sounds

Re: Kind of lame SMP/E question

of lame SMP/E question Thanks, that is the direction I have asked them to pursue. It sounds like working around SMP/E is possible but not one's first choice (as I suspected). Thanks, all. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU

Re: Kind of lame SMP/E question

Hoelscher Sent: Tuesday, September 18, 2018 8:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Kind of lame SMP/E question The SMP/E libraries may be gone - but are the dataset/members to create/populate them still present ?? Chris Hoelscher Technology Architect, Database Infrastructure Services

Re: Kind of lame SMP/E question

-Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Tuesday, September 18, 2018 10:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Kind of lame SMP/E question For any product install, the SMPE Libraries are critical. I do not think you

Re: Kind of lame SMP/E question

ember 18, 2018 5:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Kind of lame SMP/E question > > "Readily" and "relatively easy" will probably not apply here, so the answers > are not likely and nope. > > You could dummy up a function/functions and receiv

Re: Kind of lame SMP/E question

sion List On Behalf Of Charles Mills Sent: Tuesday, September 18, 2018 6:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Kind of lame SMP/E question [External Email] I have a client who is licensed for and has installed a particular IBM software product on z/OS. The product is out of marketing

Kind of lame SMP/E question

I have a client who is licensed for and has installed a particular IBM software product on z/OS. The product is out of marketing but still in service. They have all the actual product libraries but managed apparently to delete the SMP/E datasets some time ago. They now need to apply a set of PTFs

Re: smp/e question - PTF relinks, but missing CSECTs.

edu> on behalf of Edward Gould <edgould1...@comcast.net> Sent: Friday, May 25, 2018 8:38 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: smp/e question - PTF relinks, but missing CSECTs. > On May 25, 2018, at 12:39 PM, Jesse 1 Robinson <jesse1.robin...@sce.com> > wrote: > > I

Re: smp/e question - PTF relinks, but missing CSECTs.

> On May 25, 2018, at 12:39 PM, Jesse 1 Robinson > wrote: > > I'm sympathetic to the argument that new stuff should be investigated, but > the problem is whether that really happens in practice. We've all met the > sysprog who meticulously codes parameter defaults as

Re: smp/e question - PTF relinks, but missing CSECTs.

] On Behalf Of Paul Gilmartin Sent: Friday, May 25, 2018 11:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: smp/e question - PTF relinks, but missing CSECTs. On Fri, 25 May 2018 17:39:03 +, Jesse 1 Robinson wrote: > >As for getting inconsistent results, I suspect that SMP/E resul

Re: smp/e question - PTF relinks, but missing CSECTs.

On Fri, 25 May 2018 17:39:03 +, Jesse 1 Robinson wrote: > >As for getting inconsistent results, I suspect that SMP/E results can be >influenced by the particular mix of elements being processed in a given run. >That is, applying SYSMOD-A and SYSMOD-B in the same step might uncover a

Re: smp/e question - PTF relinks, but missing CSECTs.

On Fri, May 25, 2018 at 12:43 PM Seymour J Metz wrote: > My song "PUT Process" was motivated by real incidents. JES2 service was > especially bad; they would issue a PTF with a packaging error and the fix > would again have a packaging error. > ​Yeah, I remember "JES2 level

Re: smp/e question - PTF relinks, but missing CSECTs.

On Fri, May 25, 2018 at 12:39 PM Jesse 1 Robinson wrote: > I'm sympathetic to the argument that new stuff should be investigated, but > the problem is whether that really happens in practice. We've all met the > sysprog who meticulously codes parameter defaults as a kind

Re: smp/e question - PTF relinks, but missing CSECTs.

From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Jesse 1 Robinson <jesse1.robin...@sce.com> Sent: Friday, May 25, 2018 1:39 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: smp/e question - PTF relinks, but missing CSECTs. I'm sympathetic to the argument

Re: smp/e question - PTF relinks, but missing CSECTs.

-MAIN@LISTSERV.UA.EDU Subject: (External):Re: smp/e question - PTF relinks, but missing CSECTs. (It's Friday; SPAM is above suspicion.) On Fri, 25 May 2018 16:41:56 +, Jesse 1 Robinson wrote: >I don't see any problem with the BYPASS statement except that it's needlessly >specific.

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Fri, 25 May 2018 11:19:58 -0500, Paul Gilmartin wrote: >SYSLIB? SYSLMOD? Whatever. I don't believe SMP/E cares about SYSLIB >DD statement images in Binder JCLIN. It does with CALLLIBS. -- Tom Marchant -- For IBM-MAIN

Re: smp/e question - PTF relinks, but missing CSECTs.

(It's Friday; SPAM is above suspicion.) On Fri, 25 May 2018 16:41:56 +, Jesse 1 Robinson wrote: >I don't see any problem with the BYPASS statement except that it's needlessly >specific. BYPASS(HOLDSYSTEM) without the list of types should not only >suffice--it does for me--but also hedges

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

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 John McKown Sent: Friday, May 25, 2018 9:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: [SUSPECTED SPAM] smp/e

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Friday, May 25, 2018 12:19 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs. On Fri, 25

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Fri, May 25, 2018 at 10:41 AM Seymour J Metz wrote: > What was on the APPLY statement? > ​It is my standard. The BYPASS _might_ be part of the problem, but I really don't see why it would cause _this_ error. SETBOUNDARY (MVST100) . APPLY

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Fri, 25 May 2018 07:37:53 -0500, John McKown wrote: >On Fri, May 25, 2018 at 7:26 AM Tom Marchant wrote: > >> On Fri, 25 May 2018 12:20:18 +, Allan Staller wrote: >> >> >Check the releted DDDEF's and the SYSLIB/CALLLIB concat. >> >> SYSLIB? The SYSLIB DDDEF is for assemblies, not for link

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

3 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs. URL to a Github "gist" with the output that the Listserv rejected. https://secure-web.cisco.com/1Gz91TSt9ItPQtPLAij5Im4PzjOnDpPoeJEyHyHuCN9yw-f50iRHiTJJySBmfW7ssRLowZz

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Fri, May 25, 2018 at 7:26 AM Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > On Fri, 25 May 2018 12:20:18 +, Allan Staller wrote: > > >Check the releted DDDEF's and the SYSLIB/CALLLIB concat. > > SYSLIB? The SYSLIB DDDEF is for assemblies, not for link edits. >

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Fri, 25 May 2018 12:20:18 +, Allan Staller wrote: >Check the releted DDDEF's and the SYSLIB/CALLLIB concat. SYSLIB? The SYSLIB DDDEF is for assemblies, not for link edits. -- Tom Marchant -- For IBM-MAIN subscribe /

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Fri, May 25, 2018 at 7:21 AM Allan Staller wrote: > Sounds like a SMP/E Configuration error. Check the releted DDDEF's and the > SYSLIB/CALLLIB concat. > Other SMP/E error messages? > ​That is the only error message. Not really an SMP/E error, just an unacceptable RC

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

-MAIN@LISTSERV.UA.EDU Subject: Fwd: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs. Message below, with attached output, was reject by the Listserv because it had too many lines (>1000) -- Forwarded message - From: John McKown <john.archie.mck...@gmail.com

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Thu, 24 May 2018 12:55:01 -0500, Tom Marchant wrote: > >>OK, y'all probably know that I'm on a very back level system -- z/OS 1.12 >>and we're even back level on maintenance. I'm trying to get more up to >>date, mainly for "fun & profit". Anyway. There are a number of RACF modules >>which were

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

> > > From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of > John McKown <john.archie.mck...@gmail.com> > Sent: Thursday, May 24, 2018 10:14 AM > To: IBM-MAIN@listserv.ua.edu > Subject: [SUSPECTED S

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

URL to a Github "gist" with the output that the Listserv rejected. https://gist.github.com/JohnArchieMckown/20d995cce8e2f201a4cf9725c4932092 On Thu, May 24, 2018 at 3:30 PM Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > On Thu, 24 May 2018 15:58:54 -0400, John Eells

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Thu, 24 May 2018 15:58:54 -0400, John Eells wrote: >Tom Marchant wrote: >> On Thu, 24 May 2018 13:30:20 -0500, John McKown wrote: >> >>> On Thu, May 24, 2018 at 12:40 PM Seymour J Metz wrote: >>> Have you looked at the MOD entries for the missing csects? >>> >>> ​Yes,

Fwd: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

Message below, with attached output, was reject by the Listserv because it had too many lines (>1000) -- Forwarded message - From: John McKown <john.archie.mck...@gmail.com> Date: Thu, May 24, 2018 at 3:19 PM Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, bu

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

Tom Marchant wrote: On Thu, 24 May 2018 13:30:20 -0500, John McKown wrote: On Thu, May 24, 2018 at 12:40 PM Seymour J Metz wrote: Have you looked at the MOD entries for the missing csects? ​Yes, they look correct to me. The entries for each MOD (missing & not missing)

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

Of Tom Marchant Sent: Thursday, May 24, 2018 2:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs. On Thu, 24 May 2018 13:35:06 -0500, John McKown wrote: >I'm going to do a complete disk-level restore of the target system >(s

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Thu, 24 May 2018 13:35:06 -0500, John McKown wrote: >I'm going to do a complete disk-level restore of the target system >(sandbox). And the Global zone as well, I hope. Otherwise you will have a global out of sync with the target zone. >I had a number Sx37 abends which may be the main

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Thu, 24 May 2018 13:30:20 -0500, John McKown wrote: >On Thu, May 24, 2018 at 12:40 PM Seymour J Metz wrote: > >> Have you looked at the MOD entries for the missing csects? > >​Yes, they look correct to me. The entries for each MOD (missing & not >missing) points to AOSBN as

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

A MOD entry represents a member of a DLIB data set. Each DLIB data set member may contain one or more sections, like CSECTs. (Those CSECTs residing in a particular DLIB member might or might not be known to SMP/E, depending on how the product was packaged. But SMP/E really acts on the

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

scussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, May 24, 2018 1:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs. On Thu, May 24, 2018 at 12:40 PM Seymour J Metz <sme...@gmu.edu> wrot

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

Thanks to all. After all this work, my boss has informed me that everything I have done is unnecessary. I was looking at this to stage up to our (hopefully) getting a z12BC and a new version of z/OS (probably the lowest version which can still be ordered "to minimize changes"). Of course, a big

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Thu, May 24, 2018 at 12:40 PM Seymour J Metz wrote: > Did you do anything equivalent to NCAL? > ​No, but why would IBM do INCLUDE statements for some MODS but not others in the same distribution library (AOSBN)?​ > > Have you looked at the MOD entries for the missing

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

On Thu, 24 May 2018 09:14:20 -0500, John McKown wrote: >OK, y'all probably know that I'm on a very back level system -- z/OS 1.12 >and we're even back level on maintenance. I'm trying to get more up to >date, mainly for "fun & profit". Anyway. There are a number of RACF modules >which were hit

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of John McKown <john.archie.mck...@gmail.com> Sent: Thursday, May 24, 2018 10:14 AM To: IBM-MAIN@listserv.ua.edu Subject: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs. OK, y'all probably know that I'm on a very back

[SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

OK, y'all probably know that I'm on a very back level system -- z/OS 1.12 and we're even back level on maintenance. I'm trying to get more up to date, mainly for "fun & profit". Anyway. There are a number of RACF modules which were hit and SMP/E tries to relink them. The problem seems to be that

Re: SMP/E question

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tom Marchant > Sent: Saturday, April 23, 2016 9:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMP/E question > > On Fri, 22 Apr 2016 15:41:23 -0700,

Re: SMP/E question

On Fri, 22 Apr 2016 15:41:23 -0700, retired mainframer wrote: >Since you should restore before reject... Really? That's news to me. AFAIK it makes no difference. Why do you say that? -- Tom Marchant -- For IBM-MAIN subscribe

Re: SMP/E question

https://www.youtube.com/watch?v=aRMlHRo7eAE In a message dated 4/22/2016 5:41:35 P.M. Central Daylight Time, retired-mainfra...@q.com writes: We can't help if you tell us what the problem is. -- For IBM-MAIN subscribe /

Re: SMP/E question

On Fri, 22 Apr 2016 22:18:07 +, Hardee, Chuck wrote: >Hello Everyone, > >I am having an issue with doing a RESTORE/REJECT on some mods that were last >applied with the SMP/e that came with z/OS 1.13. >I am now on z/OS 2.2 and this is the first RESTORE/REJECT I am trying to >execute in order

Re: SMP/E question

-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hardee, Chuck Sent: Friday, April 22, 2016 3:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):SMP/E question Hello Everyone, I am having an issue with doing a RESTORE/REJECT on some mods

Re: SMP/E question

UA.EDU] On > Behalf Of Hardee, Chuck > Sent: Friday, April 22, 2016 3:18 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SMP/E question > > Hello Everyone, > > I am having an issue with doing a RESTORE/REJECT on some mods that were last applied > with the SMP/e that came with

SMP/E question

Hello Everyone, I am having an issue with doing a RESTORE/REJECT on some mods that were last applied with the SMP/e that came with z/OS 1.13. I am now on z/OS 2.2 and this is the first RESTORE/REJECT I am trying to execute in order to reengineer a usermod. Thanks, Chuck Charles (Chuck)

Re: SMP/E question

...I need an easy solution to report the DDDEFs which belong to a specific FMID... As you have discovered, there is no LIST or REPORT command that will do what you want. However, use the BUILDMCS command for your desired FMID, then check out the BUILDMCS Entry Summary Report, as it will

Re: SMP/E question

Feel free to post the code when written! :-) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Juergen Kehr Sent: Thursday, July 23, 2015 11:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question Thanks for all the replies

Re: SMP/E question

Thanks for all the replies. The last messages which recommend to use BUILDMCS (or GENERATE) to get the required information are solving my problem. With the BUILDMCS ENTRY SUMMARY REPORT and a few fairly easy REXX procedures, i should be able to produce a report to identify those z/OS libraries

Re: SMP/E question

AFAIK, there is no way to get the list you want (other than manual cross reference). As best as I can recall: There are *VERY FEW* SMP/E DDDEFS use by more than one component. Those that are used by more than one component (the DDDEF for SYS1.CNMLINK comes to mind) there is only *ONE* owner

SMP/E question

Hello, at this time we're migrating from z/OS 1.13 to 2.1. In order to restructure our SMP/E environment I need an easy solution to report the DDDEFs which belong to a specific FMID or a report which gives me all DDDEFs for all installed FMIDs, but only those DDDEFs which are used as output

Re: SMP/E question

@LISTSERV.UA.EDU Subject: SMP/E question Hello, at this time we're migrating from z/OS 1.13 to 2.1. In order to restructure our SMP/E environment I need an easy solution to report the DDDEFs which belong to a specific FMID or a report which gives me all DDDEFs for all installed FMIDs, but only

Re: SMP/E question

Thanks for your reply, but LIST FORFMID(...) doesn't do the job. AFAIK it's because DDDEFs are not directly assigned to FMIDs like SYSMOD (for example PTF) entries. So LIST FORFMID(...) does not list any DDDEF related information. The only idea I had was, to walk thru the CSI starting with an

Re: SMP/E question

-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question Thanks for your reply, but LIST FORFMID(...) doesn't do the job. AFAIK it's because DDDEFs are not directly assigned to FMIDs like SYSMOD (for example PTF) entries. So LIST FORFMID(...) does not list any DDDEF related information. The only idea I

Re: SMP/E question

I don't think, that checking Program Directories is a real good solution. Even more our CSI contains several fairly old products, for which it is really difficult to find a copy of the program directory. On the other hand I believe, that an automated solution is possible, because SMP/E itself

Re: SMP/E question

[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Juergen Kehr Sent: Wednesday, July 22, 2015 1:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question I don't think, that checking Program Directories is a real good solution. Even more our CSI contains several fairly old products, for which

Re: SMP/E question

Yes, you're right, but if I only specify LIST FORFMID(...) only, I'll get only the name of the elements which belong to the specified FMID, but not the DDDEFs which belong to the several elements. Therefore I would have to list any element seperately, or at least list any element type like MAC,

Re: SMP/E question

10:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question Yes, you're right, but if I only specify LIST FORFMID(...) only, I'll get only the name of the elements which belong to the specified FMID, but not the DDDEFs which belong to the several elements. Therefore I would have to list

Re: SMP/E question

-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Juergen Kehr Sent: Wednesday, July 22, 2015 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question Thanks for your reply, but LIST FORFMID(...) doesn't do the job

Re: SMP/E Question regarding automatically relinking a load module with maintenance

On Thu, 15 May 2014 14:40:11 -0500, Tom Marchant wrote: I have observed that merely deleting from the SMPPTS and re-RECEIVEing leaves tramp entries in the GLOBAL zone. I'm not surprised. Do it correctly. I wouldn't be surprised if Kurt Q. knows how to clean it up correctly without using

Re: SMP/E Question regarding automatically relinking a load module with maintenance

Of Paul Gilmartin Sent: Friday, May 16, 2014 8:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E Question regarding automatically relinking a load module with maintenance On Thu, 15 May 2014 14:40:11 -0500, Tom Marchant wrote: I have observed that merely deleting from the SMPPTS and re-RECEIVEing

SMP/E Question regarding automatically relinking a load module with maintenance

I have a vendor product that provides for a customization of the product via a load module. The load module is a table of exits that are called at certain points in the product to allow the user to make decision, perform additional functions, etc. At our site, this module had been set up to

  1   2   >