Re: SMP/E download anomaly

ber and used FTPS. Kurt Quackenbush IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, s

Re: SMP/E download anomaly

Hello Kurt, All cases, the CLIENT DD referenced the same PDS member. Regards, Norbert -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kurt Quackenbush Sent: Friday, April 19, 2024 5:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: SMP/E download

Re: SMP/E download anomaly

ntry to point to a data set that contains the XML? Kurt Quackenbush IBM | z/OS SMP/E and z/OSMF Software Management | ku...@us.ibm.com Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archi

SMP/E download anomaly

Hello I have an interesting case what I cannot untangle. I was creating multiple ORDERSERVER using the same job where downloadmethod="https" is specified, only the SMPCSI changed. For products like zSecure, MFA, AO, Netview, etc, the job ran fine and downloaded relevant PTFs, however in case

Re: SMP/E

: SMP/E CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this person? Were you expecting this email? If not, report it using the Report Phishing Button! I'll ask if you did the UPGRADE in the same run as the RECEIVE process. The example from the z/OS SMP/E Commands manual shows

Re: SMP/E

**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* בתאריך שבת, 30 במרץ 2024 ב-1:00 מאת Steely.Mark : > I recently received this message: GIM58903W SMP/E COULD NOT PROCESS A > ++HOLD FIXCAT MCS BECAUSE IT WOUL

Re: SMP/E

I'll ask if you did the UPGRADE in the same run as the RECEIVE process. The example from the z/OS SMP/E Commands manual shows the UPGRADE command as part of the same run. The following is from the SMP/E command manual. SET BDY(ZOSTGT). UPGRADE. BYPASS(HOLDSYS) CHECK. In this example

Re: SMP/E

I did perform the upgrade command on the global and target zone and nothing happen. The SMP/e level stayed the same and the receive still failed with the same error. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, March 29, 2024 5:20

Re: SMP/E

Just issue the UPGRADE command. IIRC FIXCAT support was added to SMP/E around 2008. Your global zone must have been created with a release of SMP/E before that. -- Tom Marchant On Fri, 29 Mar 2024 21:59:49 +, Steely.Mark wrote: >I recently received this message: GIM58903W SMP/E CO

SMP/E

I recently received this message: GIM58903WSMP/E COULD NOT PROCESS A ++HOLD FIXCAT MCS BECAUSE IT WOULD HAVE MADE A CHANGE TO THE GLOBAL ZONE THAT CANNOT BE PROCESSED COMPLETELY BY PRIOR LEVELS OF SMP/E. USE

Re: [EXTERNAL] Re: SMP/E can't find APAR

installed. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ann Kelley Sent: Thursday, March 14, 2024 7:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: SMP/E can't find APAR I also searched, and found an item in a PSP bucket -- I've encountered

Re: SMP/E can't find APAR

. APPLY S(UI65815) BYPASS(HOLDSYSTEM) CHECK. SMP/E APAR IO27985 has been created to address this issue. Here's the link to the item I found: https://www.ibm.com/support/pages/upgrade-zosv2r4-subset-zoswlpem

Re: [EXTERNAL] Re: SMP/E can't find APAR

Thank you. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Wednesday, March 13, 2024 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: SMP/E can't find APAR I just looked on ServiceLink. It's an open APAR, with a current target date

Re: SMP/E can't find APAR

, Rex wrote: > Hello list, > > I'm apparently having a senior moment. I'm having trouble running an apply > check on my 2.4 system with a missing shell script that exists. In > researching it, I found a similar situation and as part of it I found this on > IBM's web sit

SMP/E can't find APAR

Hello list, I'm apparently having a senior moment. I'm having trouble running an apply check on my 2.4 system with a missing shell script that exists. In researching it, I found a similar situation and as part of it I found this on IBM's web site: SMP/E APAR IO27985 has been created

Re: SMP/E JCLIN processing for job updates

21, 2023 11:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E JCLIN processing for job updates Hi Dave, Thanks for the response. No I am not editing the target data directly. We are working out of a pds separate from SMPe libraries. The user mod looks like what I'm after. I will look

Re: SMP/E question of the day

On Mon, 18 Dec 2023 08:12:33 -0600, Paul Gilmartin wrote: >In <https://www.ibm.com/docs/en/zos/3.1.0?topic=statements-zap-mcs>, >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 programmin

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

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

Re: SMP/E question of the day

d. Clearly this sentence is not necessary and as you say somewhat confusing why it is mentioned. In fact, "name" documentation should be rewritten. NAME must specify a valid SMP/e MOD entry. To say module member is out

Re: SMP/E question of the day

hysically exist as a member in a target library. What and where are you going to attach an alias name. I suspect that TALIAS has a meaning in both target and dist that conflicts with DALIAS. >SMP/E doesn't understand its own alias names. Once, as an experiment I created >an alias. In

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: <https://www.ibm.com/docs/

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

Re: SMP/E question of the day

8 character limitation apply to alias names? PDSE limits main names >too 8. > Why are TALIAS and DALIAS mutually exclusive? SMP/E doesn't understand its own alias names. Once, as an experiment I created an alias. In standalone JCL SYSLIN "INCLUDE alias" worked. Failed in

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. >

Re: SMP/E question of the day

ABCDITSK IN SYSMOD ABC8401. Like ++JCLIN, ++ZAP contains pseudo statements instead of actual superzap statements. SMP/E processes these pseudo statements which are sometimes incompatible with the real functionality. This is an SMP/e error message (not superzap). SMP/e may or may not support cer

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 r

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

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

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

ect supplies sample jobs to do > exactly that. > > Kurt Quackenbush > IBM | z/OS SMP/E and z/OSMF Software Management | ku...@us.ibm.com > > Chuck Norris never uses CHECK when he applies PTFs. > > -- > F

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

reate new, which should be about the same amount of work as cloning, and the new product release I suspect supplies sample jobs to do exactly that. Kurt Quackenbush IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com Chuck Norris never uses CHECK when he app

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

I work with Ross and can explain what he is trying to accomplish. We have a Db2 v13 Global zone for Db2 along with its associated target and DLIB zones. We have several Db2 related products (Admin Tool, etc) installed into the Db2 global with their own target and dlib zones. He wants to

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. >

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.

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 - Pointing Existing TARG & DLIB Zones To New CSI's

This statement is very confusing to me?So for DB2V13 is installed in its own global zone, with target and dlib zones.It’s the next part of your statement “use my existing target and dlib zones and update ddefs…” that is confusing me. It sounds like you are trying to marry your V13

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

You might want to look at the sysres cloning example on my web site / CBT file 434 also as that clones the SMP/E ZONEs with it. I don't clone the DLIB volser(s) / zones these days (haven't in many years), but you can easily see how it is done. See URL below. Regards, Mark -- Mark Zelden

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

Thanks for the info Tom. I had planned to use the ZONEEDIT to update my DDDEFs as well, so thanks for that confirmation. Ross > On Dec 14, 2023, at 12:44 PM, Tom Marchant > <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > > I should have added that when I clone zones, I like to

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

I should have added that when I clone zones, I like to copy the SMPLOG as well, so that the full history is preserved. Don't forget to define the disposition for SMPLOG as MOD or the SMPLOG will be useless. -- Tom Marchant On Thu, 14 Dec 2023 12:31:15 -0600, Tom Marchant wrote: >Create a

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

Create a new ZONEINDEX in the Global zone for each new zone (target and DLIB), and relate them to each other. If each zone is in its own CSI you can copy with IDCAMS REPRO. Otherwise use ZONECOPY. You can use ZONEEDIT to change the DDDEFs in your new zone(s). Don't forget that the target zone

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 - Pointing Existing TARG & DLIB Zones To New CSI's

I’m upgrading a product in my DB2v13 global zone. I plan to use my existing target & DLIB zones and just update my DDDEFs to point to my new dataset names. My question is - if I want to create new CSI’s (copied from my existing CSIs) for the target & DLIB what’s the best way to point the

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: Extracting SMP/e details

Message- > From: IBM Mainframe Discussion List On Behalf > Of Lizette Koehler > Sent: Thursday, October 19, 2023 9:33 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Extracting SMP/e details > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don

Re: Extracting SMP/e details

, 2023 9:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Extracting SMP/e details [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] I need

Re: Extracting SMP/e details

> I need a simple process to get the following out of SMP/e > PTF. Fmid. Date received. Date applied If you want to query specific PTFs rather than all, and if your installed software is defined as a z/OSMF Software Instance, then you can use the z/OSMF Software Update Search REST API:

Re: Extracting SMP/e details

rely what others think you are.” - - - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: Thursday, October 19, 2023 9:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extracting SMP/e details The standard solution is gimapi. We

Re: Extracting SMP/e details

owing out of SMP/e > > PTF. Fmid. Date received. Date applied > > I am thinking of writing a Rexx or icetool to read a listing to produce > the one liners > > Just wanted to check here to see if there was a better way > > I have not found much on cbttape > > From t

Extracting SMP/e details

I need a simple process to get the following out of SMP/e PTF. Fmid. Date received. Date applied I am thinking of writing a Rexx or icetool to read a listing to produce the one liners Just wanted to check here to see if there was a better way I have not found much on cbttape >From t

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Peter Relson wrote: >I on the other hand do have sympathy. A highly significant reason that >z/OS still exists (and the same could have been said for its >predecessors OS/390 and MVS) is because of the enormous amount of time >and effort we have put into maintaining as much compatibility as we

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

That should just be made a syntax error. I have no sympathy for the "compatibility" argument. I on the other hand do have sympathy. A highly significant reason that z/OS still exists (and the same could have been said for its predecessors OS/390 and MVS) is because of the enormous amount of

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On Wed, 11 Oct 2023 15:44:39 +, Peter Relson wrote: > >As it happens, the offending sentence had already been removed from the 3.1 >book. Since the thread started before those books were generally available to >be looked at, it's not surprising that that was not realized. > I see that.

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Paul G wrote I fear "unpredictable" is too often the writers' excuse when they don't know the answer to a request for clarification and can't find out. I don't think you will find that that is true in z/OS books. Writers do not make up usage of that word. They are asked to do so because the

Re: SMP/E and PATH existence

On Behalf Of Jon Perryman Sent: Tuesday, October 10, 2023 5:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E and PATH existence EXTERNAL EMAIL On Fri, 6 Oct 2023 15:46:25 +, Rob Scott wrote: >This was precisely the reason for the original implementation of DDDEFCHK/PTH.

Re: SMP/E and PATH existence

Jon Perryman wrote: >Is APPLY CHECK no longer standard practice when installing a PTF or >product? Quackenbush says checking DDDEF's externally is unnecessary >and will only take take the time required for APPLY CHECK. You missed my point-APPLY CHECK happens after doing several steps already, and

Re: SMP/E and PATH existence

On Fri, 6 Oct 2023 15:46:25 +, Rob Scott wrote: >This was precisely the reason for the original implementation of DDDEFCHK/PTH. > >Being able to quickly sniff-test the DDDEFs (across multiple target/dlib >zones) before >an APPLY that might take many minutes was deemed useful (well .. at

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Processing date from control card input is endemic to the financial industry, not just banks. I believe it stems from the fact that "daily" processing occurs after midnight, Michael At 11:08 AM 10/8/2023, Paul Gilmartin wrote: On Sat, 7 Oct 2023 22:30:52 +0200, Radoslaw Skorupka wrote:

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On Sat, 7 Oct 2023 22:30:52 +0200, Radoslaw Skorupka wrote: >To be honest I consider date-related variables as pooor when >compared to batch scheduler features, especially ControlM (it is not >advertisement, just opinion). > You worked for a bank. I had a co-worker who had worked for a bank.

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On Sat, 7 Oct 2023 18:42:42 +, Farley, Peter wrote: >I’ll admit I have NOT used symbol substitution in the “name” part (left of the >“=”) at all, only on the right (value) side, so the true answer is “I don’t >know”. Never had a reason to use substitution in the “name” part. > However

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On Sat, 7 Oct 2023 13:10:36 -0500, Michael Oujesky wrote: >Dynamic symbols (date/time) can be evaluated at different points in >time during conversion, so if used multiple time in the JCL, they can >resolve to different values. My ROT was to never use a dynamic >symbol more that once in coding

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

ctober 7, 2023 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?] On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote: On 9/20/2023 8:23 AM, Farley, Peter wrote: ... JCL symbols as part of the definition of othe

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

that need. When I get a chance I will try the new feedback process. Peter From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Saturday, October 7, 2023 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Dynamic symbols (date/time) can be evaluated at different points in time during conversion, so if used multiple time in the JCL, they can resolve to different values. My ROT was to never use a dynamic symbol more that once in coding and where it was needed multiple time, set it to my own

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote: >On 9/20/2023 8:23 AM, Farley, Peter wrote: >> ... JCL symbols as part of the definition of other JCL symbols works >> flawlessly every time. > Is this true alike for substitution both in the name (left of the "=") and in the value (right of

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

On 9/20/2023 8:23 AM, Farley, Peter wrote: I believe that statement in the JCL Reference is in error and needs to be deleted or at the very least completely rewritten. My quite substantial experience using this technique over the last 10-15 years is that using JCL symbols as part of the

Re: SMP/E and PATH existence

, 2023 1:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E and PATH existence EXTERNAL EMAIL Jon Perryman wrote: >Kurt is saying that APPLY CHECK does exactly what you want. CHECK >verifies SMP/e has everything expected and will run 100% through. If 3 >DD / DDDEF's are missing,

Re: SMP/E and PATH existence

Jon Perryman wrote: >Kurt is saying that APPLY CHECK does exactly what you want. CHECK >verifies SMP/e has everything expected and will run 100% through. If 3 >DD / DDDEF's are missing, then you should see those 3 errors and any >other errors that SMP/e detects. APPLY CHECK only

Re: SMP/E and PATH existence

On Thu, 5 Oct 2023 19:09:45 -0400, Phil Smith III wrote: >Kurt Quackenbush wrote: >>SMP/E APPLY CHECK and similar commands verify existence of directories >Thanks. Since I really, really don't want them to get 3/4 of the way through > and then have to go hunt down someone with U

Re: SMP/E and PATH existence

Kurt Quackenbush wrote: >SMP/E APPLY CHECK and similar commands verify existence of directories >and data sets from DDDEF entries before they are used. There is no >independent SMP/E command or utility to perform this verification. >However, there is a capability in z/OSMF Softwar

Re: SMP/E and PATH existence

>>A long time ago, I wrote a program called DDDEFCHK that used the SMP/E >>API to check if normal DDDEF data sets exist - there is also a DDDEFPTH >>companion program to handle paths. > Ah, so that kinda confirms that SMP/E can't do it natively. I think > BPXBATCH

Re: SMP/E and PATH existence

Rob Scott wrote: >A long time ago, I wrote a program called DDDEFCHK that used the SMP/E >API to check if normal DDDEF data sets exist - there is also a >DDDEFPTH companion program to handle paths. Ah, so that kinda confirms that SMP/E can't do it natively. I think BPXBATCH/IDCAMS are

Re: SMP/E and PATH existence

Phil, A long time ago, I wrote a program called DDDEFCHK that used the SMP/E API to check if normal DDDEF data sets exist - there is also a DDDEFPTH companion program to handle paths. I believe these programs still exist in the public domain in the CBT tape site (www.cbttape.org) - see files

SMP/E and PATH existence

Is there a way to get SMP/E to validate the existence of a USS path on a DDEF? Thanks to y'all's help, I have externalized the USS path we use to a variable. However, if the directory doesn't exist, the user can get pretty far (to the RECEIVE step) before that's recognized. I've looked

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Farley, Peter wrote: >I believe that statement in the JCL Reference is in error and needs to >be deleted or at the very least completely rewritten. My quite >substantial experience using this technique over the last 10-15 years >is that using JCL symbols as part of the definition of other JCL

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

Thanks for changing the Subject: as the topic drifted. On Wed, 20 Sep 2023 15:23:31 +, Farley, Peter wrote: >I believe that statement in the JCL Reference is in error and needs to be >deleted or at the very least completely rewritten. My quite substantial >experience using this technique

JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

to be substituted. From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Wednesday, September 20, 2023 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is SMP/E needed for installs? On Wed, 20 Sep 2023 04:12:20 +, Peter Hannigan wrote: >... >// SET A=' ' >

Re: Is SMP/E needed for installs?

nobody is going to load our stuff to the "root" on a real system, and if they do, then they're going to be an SMP/E jock already. So while I love this suggestion and will look at other ways to use it, I think I'm just going to put a comment in the common member that does the SETs saying

Re: Is SMP/E needed for installs?

On Wed, 20 Sep 2023 04:12:20 +, Peter Hannigan wrote: >... >// SET A=' ' > - Do not specify JCL symbols within other JCL symbols. The results can be unpredictable, especially if the imbedded JCL symbol is

Re: Is SMP/E needed for installs?

> -Original Message- > > Date:Tue, 5 Sep 2023 17:34:17 -0400 > From:Phil Smith III > Subject: Re: Is SMP/E needed for installs? > . . > 2.On the SMP/E RECEIVE command, I believe that in 99.44% (or higher) > cases, an RPREFIX will be needed. And

Re: Next SMP/E question

sh IBM | z/OS SMP/E and z/OSMF Software Management | ku...@us.ibm.com Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.

Re: SMP/E and USS

3 3:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E and USS On Wed, 6 Sep 2023 19:27:36 +, Seymour J Metz wrote: >The SMP convention is that LINK is a hard link and SYMLINK is a soft link. > Long ago I was (disingenuously) dismayed to learn that in SMP/E Linkage Editor JCLIN: IN

Re: [EXTERNAL] Re: SMP/E and USS

file. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Wednesday, September 6, 2023 4:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: SMP/E and USS Rex wrote: > Ok, that is odd now. Ah hah: https://urldefense.com/v3/__https://www.ibm.co

Re: SMP/E and USS

Rex wrote: > Ok, that is odd now. Ah hah: https://www.ibm.com/docs/en/zos/2.5.0?topic=examples-example-3-packaging-sysmod-symbolic-link is an example showing: ++HFS(GSKAH010) and says When SMP/E installs file GSKAH010 into the directory specified on the given DDDEF entry, the LINK and SYML

Re: [EXTERNAL] Re: SMP/E and USS

Ok, that is odd now. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Wednesday, September 6, 2023 3:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: SMP/E and USS Thanks, Rex-they are not symlinks, I did check that (and should have

Re: SMP/E and USS

Thanks, Rex-they are not symlinks, I did check that (and should have said so!). They're all -rw-r--r-- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message:

Re: SMP/E and USS

On Wed, 6 Sep 2023 19:27:36 +, Seymour J Metz wrote: >The SMP convention is that LINK is a hard link and SYMLINK is a soft link. > Long ago I was (disingenuously) dismayed to learn that in SMP/E Linkage Editor JCLIN: INCLUDE SYSLIB(alias-name) ... failed even though alia

Re: SMP/E and USS

M-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E and USS On Wed, 6 Sep 2023 18:57:25 +, Seymour J Metz wrote: >LINK and SYMLINK are for alternate names. > Don't know SMP/E conventions. But in UNIX jargon a "link" is an ordinary directory entry identifying a file by its I-number. There may

Re: SMP/E and USS

On Wed, 6 Sep 2023 18:57:25 +, Seymour J Metz wrote: >LINK and SYMLINK are for alternate names. > Don't know SMP/E conventions. But in UNIX jargon a "link" is an ordinary directory entry identifying a file by its I-number. There may be multiple such links for a single fi

Re: SMP/E and USS

LINK and SYMLINK are for alternate names. From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Wednesday, September 6, 2023 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMP/E and USS Consider this from an SMPMCS: ++HFS(

Re: [EXTERNAL] SMP/E and USS

actually a link or a pointer to the other location. I wouldn't remove it. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Wednesday, September 6, 2023 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] SMP/E and USS Consider this from

SMP/E and USS

on the DDDEF for sss, file ; and in the lib\ directory under that, lib.a. These files are identical. I don't need the for linking etc.; do I need it for later service or something? If it's not required, why did SMP/E leave it there? Reading the doc found very

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

  1   2   3   4   5   6   7   8   9   10   >