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 htt

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 gue

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 makin

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 careful

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 name

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

o: 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 multiple program objects (is there a >generic term for LM & PO), I don't see whwre you would need an lmod parameter >on the

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 cust

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

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

man 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

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

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 ABC84

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 support

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 pre

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 ABCP

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 ge

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 Chuc

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

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 somewher

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 th

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 process