Re: SMP/E question of the day

[Jon Perryman]

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
>... The name can contain any alphanumeric characters and $, #, @, or hex 
> C0.
>
>Is that documenting limitations already described, introducing further 
>limitations,
>or fully describing the lexical syntax.  The reader should be told.

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 outside the context of 
SMP/e if it does not reference an SMP/e object.

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

Re: SMP/E question of the day

[Jon Perryman]

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 names allows one ++MOD to contain multiple CSECTs. 
I suspect that this is important for packaging LE programs.

>Fiendish case: a CSECT in one ++MOD is identical to the name of a different 
>++MOD.

Having the same CSECT name in different ++MODs is not a problem. A problem only 
occurs if both MODs are included into the same LMOD.

>Why are TALIAS and DALIAS mutually exclusive?

++MOD have a dist library DDN but do not have a target library DDN. DALIAS has 
an obvious implementation. TALIAS on the other hand is used for something that 
is not obvious because the MOD does not physically 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 standalone JCL SYSLIN "INCLUDE alias" worked.  Failed in SMP/E.
>Went to SR.  Got WAD.

An alias is not a SMP/e object so JCLiN cannot process an alias. All SMP/e 
objects are unique but the same alias can be used for many objects. SMP/e 
cannot identify the SMP/e object which affected.

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

Re: SMP/E question of the day

[Paul Gilmartin]

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: 


name
... The name can contain any alphanumeric characters and $, #, @, or hex C0.

Is that documenting limitations already described, introducing further 
limitations,
or fully describing the lexical syntax.  The reader should be told.

This is "The exception that implies the rule."  Explicitly mentioning only some
limitations leads the reader to conclude that there are no others.

-- 
gil

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

Re: SMP/E question of the day

[Seymour J Metz]

In SMP you can specify an alias of a distribution or target library member. 
That works as expected. What you can't do is specify an alias of a SMP element.

Yes, the element name and the member name are normally the same, but they exist 
in different name spaces.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion 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 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 but not all sounds like a service  nightmare.
>
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.

Fiendish case: a CSECT in one ++MOD is identical to the name of a different 
++MOD.

>Does the 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 SMP/E.
Went to SR.  Got WAD.

--
gil

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


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

Re: SMP/E question of the day

[Jon Perryman]

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 customer is experiencing. 
If the workaround is for a very specific situation, restricting the change to a 
specific LMOD may be necessary. 

>Does the 8 character limitation apply to alias names? PDSE limits main names 
>too 8.

I suspect that alias names are limited to 8 because IBM added SYMLINK for long 
name support needed by UNIX.

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

Re: SMP/E question of the day

[Jon Perryman]

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.  CSECT name ABCPROC#C is 9 
> characters.
>> 
>You're making that up.  The SMP/E Ref. for ++ZAP mentions no such maximum.

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.

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

Re: SMP/E question of the day

[Paul Gilmartin]

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 but not all sounds like a service  nightmare.
>
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.

Fiendish case: a CSECT in one ++MOD is identical to the name of a different 
++MOD.

>Does the 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 SMP/E.
Went to SR.  Got WAD.

-- 
gil

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

Re: CSVQUERY in ARR routine return code 8 didn't have PLISTVER=MAX On CSVQUERY

[Joseph Reichman]

Just let me point  out the SDWA didn’t have SDWAEPA or SDWANAME I was able to 
get that info from CSVQUERY using SDWANXT1 as the inaddr parm 
 Thanks 

> On Dec 17, 2023, at 11:50 AM, Ed Jaffe  wrote:
> 
> On 12/17/2023 4:59 AM, Peter Relson wrote:
>> I'd make it "almost always".
>> 
>> The case that comes up occasionally, and is a reason that the default is not 
>> PLISTVER=MAX, is when someone has embedded the list form in a structure (not 
>> at the end) so that if the size changed, fields beyond this structure would 
>> have changed offsets and if you didn't recompile everything appropriate 
>> things would break. That potential incompatibility drives the default. And, 
>> yes, the default has the downside that if your list form "gets it wrong", 
>> things don't work.
>> Compatibility wins in this case.
> 
> Good point, Peter.
> 
> I assume it goes without saying that if a DSECT is changed incompatibly -- 
> even when it occurs by "surprise" due to a change in an IBM macro -- all 
> parts using it must be recompiled...
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
> 
> 
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: CSVQUERY in ARR routine return code 8 didn't have PLISTVER=MAX On CSVQUERY

[Ed Jaffe]

On 12/17/2023 4:59 AM, Peter Relson wrote:

I'd make it "almost always".

The case that comes up occasionally, and is a reason that the default is not 
PLISTVER=MAX, is when someone has embedded the list form in a structure (not at the end) 
so that if the size changed, fields beyond this structure would have changed offsets and 
if you didn't recompile everything appropriate things would break. That potential 
incompatibility drives the default. And, yes, the default has the downside that if your 
list form "gets it wrong", things don't work.
Compatibility wins in this case.


Good point, Peter.

I assume it goes without saying that if a DSECT is changed incompatibly 
-- even when it occurs by "surprise" due to a change in an IBM macro -- 
all parts using it must be recompiled...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: CSVQUERY in ARR routine return code 8 didn't have PLISTVER=MAX On CSVQUERY

[Joseph Reichman]

Understood I look to do better 

Thanks 

> On Dec 17, 2023, at 7:59 AM, Peter Relson  wrote:
> 
> Ed J wrote
> 
> Always code PLISTVER=MAX on the list form but (based on recent
> experience) *never* code it on the execute form of a macro unless you
> want to risk things not working as expected on back-level systems.
> 
> 
> I'd make it "almost always".
> 
> The case that comes up occasionally, and is a reason that the default is not 
> PLISTVER=MAX, is when someone has embedded the list form in a structure (not 
> at the end) so that if the size changed, fields beyond this structure would 
> have changed offsets and if you didn't recompile everything appropriate 
> things would break. That potential incompatibility drives the default. And, 
> yes, the default has the downside that if your list form "gets it wrong", 
> things don't work.
> Compatibility wins in this case.
> 
> The documentation for PLISTVER (at least within the macro itself) includes:
> 
> If your program can
> tolerate this, IBM recommends that you always specify MAX
> when creating the list form parameter list as that will
> ensure that the list form parameter list is always long
> enough to hold whatever parameters might be specified on
> the execute form.
> 
> The part to be careful about is "If your program can tolerate this". Maybe 
> you have embedded within a structure; maybe your program has a highly limited 
> amount of dynamic storage available. Those could be cases where you cannot 
> "tolerate this".
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SMP/E question of the day

[Seymour J Metz]

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 
but not all sounds like a service  nightmare.

Does the 8 character limitation apply to alias names? PDSE limits main names 
too 8.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
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_CODE.
>GIM23101E ** THERE IS A SYNTAX ERROR IN A ZAP CONTROL STATEMENT FOR MODULE
> 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 certain features. You will need to 
determine how SMP/e handles the various NAME statement options.

Consider a simple ++ZAP where in superzap where you specify NAME MYLMOD 
MYCSECT. Your first problem is that you don't zap an SMP/e LMOD. Instead, you 
would ++ZAP (MYCSECT) and use NAME MYCSECT. I think you can specify the LMOD if 
you only want to affect a single load module instead of all load modules with 
that csect name.

Verify that ABCDITSK is an SMP/e LMOD. ABCPROC#C is too long for an SMP/e MOD 
name so I'm guessing that you omitted an optional superzap NAME that SMP/e is 
relying upon. Look at the superzap NAME statement.

LE programs complicate the situation a little. I've never packaged them so I 
can only suggest how I would approach this. I'm guessing that SMP/e either 
requires a superzap NAME option specifying module name or requires ABCPROC#C be 
renamed to a valid ++MOD name which can be specified in the ++ZAP name. I'm 
guessing by this time, superzap with PDS/e now supports "NAME load-module 
module csect".

Remember that SMP/e may not have implemented all of the superzap NAME options. 
I suspect the C_CODE option is supported but it's possible that it's 
automatically determined in SMP/e and should not be specified as a NAME option.



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


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

Re: SMP/E question of the day

[Paul Gilmartin]

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.  The SMP/E Ref. for ++ZAP mentions no such maximum.

But APAR, please, not RCF.

-- 
gil

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

Re: CSVQUERY in ARR routine return code 8 didn't have PLISTVER=MAX On CSVQUERY

[Peter Relson]

Ed J wrote

Always code PLISTVER=MAX on the list form but (based on recent
experience) *never* code it on the execute form of a macro unless you
want to risk things not working as expected on back-level systems.


I'd make it "almost always".

The case that comes up occasionally, and is a reason that the default is not 
PLISTVER=MAX, is when someone has embedded the list form in a structure (not at 
the end) so that if the size changed, fields beyond this structure would have 
changed offsets and if you didn't recompile everything appropriate things would 
break. That potential incompatibility drives the default. And, yes, the default 
has the downside that if your list form "gets it wrong", things don't work.
Compatibility wins in this case.

The documentation for PLISTVER (at least within the macro itself) includes:

If your program can
tolerate this, IBM recommends that you always specify MAX
when creating the list form parameter list as that will
ensure that the list form parameter list is always long
enough to hold whatever parameters might be specified on
the execute form.

The part to be careful about is "If your program can tolerate this". Maybe you 
have embedded within a structure; maybe your program has a highly limited 
amount of dynamic storage available. Those could be cases where you cannot 
"tolerate this".

Peter Relson
z/OS Core Technology Design


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