Re: SMP/E question of the day

[Jon Perryman]

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

Re: Looking for COBOL SYSADATA record layouts

[Matt Hogstrom]

Provides more detail on the link Kirk provided.

https://developer.ibm.com/tutorials/build-java-records-from-cobol-with-ibm-record-generator/

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Dec 16, 2023, at 12:28, Kirk Wolf  wrote:
> 
> Along with generating Java mapping classes, you can also spit out XML 
> descriptions.
> 
> I haven't looked at this in a long time and I'm not 100% sure that IBM 
> provided DSECTS, but I think that they did.  I looked and can't find them 
> either.  


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

Re: Looking for COBOL SYSADATA record layouts

[Ed Jaffe]

That's silly. Anyone can do that. You don't need a go-between. It's a 
DIY affair!


The "captain's" name is Tom Ross, works for IBM, hangs out on various 
email lists, comes to our PSI party at every SHARE, and his email 
address is tmr...@us.ibm.com...


On 12/16/2023 10:29 AM, Charles Mills wrote:

Sure. ¿Porque no? Thanks,

Charles

On Sat, 16 Dec 2023 17:54:36 +, M. Ray Mullins  
wrote:


Charles,

Would you like me to ping Captain COBOL?





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: Looking for COBOL SYSADATA record layouts

[Charles Mills]

Sure. ¿Porque no? Thanks,

Charles

On Sat, 16 Dec 2023 17:54:36 +, M. Ray Mullins  
wrote:

>Charles,
>
>Would you like me to ping Captain COBOL?

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

Re: Looking for COBOL SYSADATA record layouts

[Charles Mills]

You know what I am actually looking at doing? You may laugh but it has worked 
for me in the past. I am thinking of pulling the IBM HTML documentation into 
MS-Word and massaging it there into C declarations. I did this for a *LOT* of 
RACF record layouts for the CorreLog product, so I know whereof I speak. Why 
MS-Word?

- IBM's HTML tables map to MS-Word tables. You can then manipulate stuff by 
columns. For example, the doc's Foo CL8 wants to become char Foo[8]; So you 
duplicate the CL8 column and have CL8 Foo CL8. Then you change the first 
column's CL8 to char and the third column's CL8 to [8]; and you are most of the 
way there. Not sure if this description make sense, but it works, at least for 
me.
- Good visual text manipulation tools
- I have done it before and am familiar with it.

Charles

On Sat, 16 Dec 2023 12:12:01 -0600, Kirk Wolf  wrote:

>>
>> I am not much of a Java guy but IIRC it would be a fairly short editing leap 
>> from Java classes to C structs.
>
>Depends on what you mean by "fairly short" :-)
>
>It would be good if you could find the DSECTS for Cobol ADATA, but if you look 
>at the ADATA produced by Cobol, you'll likely find that you only need a couple 
>of record types.   You could just type these into structs in a few hours, and 
>it would  be easier than translating from Java code.   But mapping the ADATA 
>records is by far the easiest part :-)

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

Re: Looking for COBOL SYSADATA record layouts

[Kirk Wolf]

> 
> I am not much of a Java guy but IIRC it would be a fairly short editing leap 
> from Java classes to C structs.

Depends on what you mean by "fairly short" :-)

It would be good if you could find the DSECTS for Cobol ADATA, but if you look 
at the ADATA produced by Cobol, you'll likely find that you only need a couple 
of record types.   You could just type these into structs in a few hours, and 
it would  be easier than translating from Java code.   But mapping the ADATA 
records is by far the easiest part :-)

Kirk Wolf
Dovetailed Technologies
http:// coztoolkit.com

On Sat, Dec 16, 2023, at 11:47 AM, Charles Mills wrote:
> @Kirk, interesting. I was not aware of that tool. I have used the DSECT to C 
> header conversion tool that is part of the XLC product, but I was not aware 
> of this tool.
> 
> I am not much of a Java guy but IIRC it would be a fairly short editing leap 
> from Java classes to C structs.
> 
> Unfortunately, as you imply, it needs DSECT or COBOL layouts as input, and I 
> don't have that. What is needed is a tool that would take a PDF manual as 
> input! (Only half kidding. Could ChatGPT do that?)
> 
> I have the HLASM ADATA layouts in DSECT form, but most of the record types 
> are not alike beyond the name and the type code.
> 
> Charles
> 
> On Sat, 16 Dec 2023 11:28:22 -0600, Kirk Wolf  wrote:
> 
> >Hi Charles,
> >
> >This may not be what you are looking for, but as I recall it's pretty cool:
> >
> >https://www.ibm.com/docs/en/record-generator/3.0?topic=what-is-record-generator-java
> >
> >Along with generating Java mapping classes, you can also spit out XML 
> >descriptions.
> >
> >I haven't looked at this in a long time and I'm not 100% sure that IBM 
> >provided DSECTS, but I think that they did.  I looked and can't find them 
> >either.
> 
> --
> 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: Looking for COBOL SYSADATA record layouts

[M. Ray Mullins]

Charles,

Would you like me to ping Captain COBOL?

Cheers,
Ray

Sent from Outlook for iOS on my personal iPhone

From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Saturday, December 16, 2023 9:47:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Looking for COBOL SYSADATA record layouts

@Kirk, interesting. I was not aware of that tool. I have used the DSECT to C 
header conversion tool that is part of the XLC product, but I was not aware of 
this tool.

I am not much of a Java guy but IIRC it would be a fairly short editing leap 
from Java classes to C structs.

Unfortunately, as you imply, it needs DSECT or COBOL layouts as input, and I 
don't have that. What is needed is a tool that would take a PDF manual as 
input! (Only half kidding. Could ChatGPT do that?)

I have the HLASM ADATA layouts in DSECT form, but most of the record types are 
not alike beyond the name and the type code.

Charles

On Sat, 16 Dec 2023 11:28:22 -0600, Kirk Wolf  wrote:

>Hi Charles,
>
>This may not be what you are looking for, but as I recall it's pretty cool:
>
>https://www.ibm.com/docs/en/record-generator/3.0?topic=what-is-record-generator-java
>
>Along with generating Java mapping classes, you can also spit out XML 
>descriptions.
>
>I haven't looked at this in a long time and I'm not 100% sure that IBM 
>provided DSECTS, but I think that they did.  I looked and can't find them 
>either.

--
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: Looking for COBOL SYSADATA record layouts

[Charles Mills]

@Kirk, interesting. I was not aware of that tool. I have used the DSECT to C 
header conversion tool that is part of the XLC product, but I was not aware of 
this tool.

I am not much of a Java guy but IIRC it would be a fairly short editing leap 
from Java classes to C structs.

Unfortunately, as you imply, it needs DSECT or COBOL layouts as input, and I 
don't have that. What is needed is a tool that would take a PDF manual as 
input! (Only half kidding. Could ChatGPT do that?)

I have the HLASM ADATA layouts in DSECT form, but most of the record types are 
not alike beyond the name and the type code.

Charles

On Sat, 16 Dec 2023 11:28:22 -0600, Kirk Wolf  wrote:

>Hi Charles,
>
>This may not be what you are looking for, but as I recall it's pretty cool:
>
>https://www.ibm.com/docs/en/record-generator/3.0?topic=what-is-record-generator-java
>
>Along with generating Java mapping classes, you can also spit out XML 
>descriptions.
>
>I haven't looked at this in a long time and I'm not 100% sure that IBM 
>provided DSECTS, but I think that they did.  I looked and can't find them 
>either.

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

Re: Looking for COBOL SYSADATA record layouts

[Charles Mills]

ASM ≠ COBOL

The ADATA records for the two products have a lot in common but not as much as 
one might hope.

Charles

On Sat, 16 Dec 2023 08:03:46 -0600, Ralph Spadafora 
 wrote:

>HLA.SASMMAC1(ASMADATA)

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

Re: Looking for COBOL SYSADATA record layouts

[Kirk Wolf]

Hi Charles,

This may not be what you are looking for, but as I recall it's pretty cool:

https://www.ibm.com/docs/en/record-generator/3.0?topic=what-is-record-generator-java

Along with generating Java mapping classes, you can also spit out XML 
descriptions.

I haven't looked at this in a long time and I'm not 100% sure that IBM provided 
DSECTS, but I think that they did.  I looked and can't find them either.  

Kirk Wolf
Dovetailed Technologies
http:// coztoolkit.com

PS> When it comes to mapping Cobol records in C, you'll find that the basic 
stuff isn't hard, but the weird stuff is a nightmare.

On Fri, Dec 15, 2023, at 10:37 AM, Charles Mills wrote:
> I am looking for compiler-readable record layouts for Enterprise COBOL 
> SYSADATA. I see the human-oriented record descriptions in the Programming 
> Guide. I see the sample exit program in IGYxxx.SAMPLIB(ADEXIT), which 
> contains (very) partial record layouts. I have searched SYS1.SIEAHDR.H. I 
> have looked in IGYxxx.MACLIB and SYS1.MACLIB. I have asked the Goo Gal.
> 
> Source language, in order of descending preference, would be C header, 
> Assembler DSECT, or anything else.
> 
> Thanks!
> 
> Charles
> 
> --
> 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/16/2023 5:19 AM, Peter Relson wrote:

Lack of PLISTVER=MAX on the list form can result in the area for the parameter 
list being too small, with the result that the execute form expansion overlays 
something following it which perhaps something relies upon.


100 percent!

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.


--
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: Looking for COBOL SYSADATA record layouts

[Ralph Spadafora]

HLA.SASMMAC1(ASMADATA)

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

Once again, the lack of providing sufficient information about what was 
actually done has wasted the time of the good folks on this listserv.
I suppose it might be said that we enable this bad behavior by responding. I 
intend to stop responding for this sort of case from repeat "offenders".

"Sufficient information" may include the source but should include the data 
passed to the service (and in this case information from a dump showing the job 
pack queue CDE's). Of course before posting, you ought to look at that data and 
see that it matches your expectation.

I.e. do your due diligence and "prove it".

Lack of PLISTVER=MAX on the list form can result in the area for the parameter 
list being too small, with the result that the execute form expansion overlays 
something following it which perhaps something relies upon.

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