Re: AI expert hot new position.

[Bill Johnson]

Some “geniuses” here, at least some self proclaimed ones, think knowing 
assembler makes them real Systems Programmers. Well, I’ve been getting paid 
like one for 2 decades. Anyone dumb enough to learn assembler in 2023, which is 
dying a slow tortuous death, deserves to be replaced by AI. (They will be) My 
best advice to anyone who is young enough to still be working in this 
profession 10 years from now, is learn AI & forget about assembler. You’ll be 
glad you did.


Sent from Yahoo Mail for iPhone


On Sunday, September 10, 2023, 4:37 PM, Bob T Roller 
<044ef325f6c3-dmarc-requ...@listserv.ua.edu> wrote:

Just go to the CNBC home page. It’s now the third story.

Sent from Proton Mail for iOS

On Sun, Sep 10, 2023 at 4:33 PM, Bob T Roller 
<[044ef325f6c3-dmarc-requ...@listserv.ua.edu](mailto:On Sun, Sep 10, 2023 
at 4:33 PM, Bob T Roller < wrote:

> It’s from CNBC. It’s the lead story. I also checked the link after I got the 
> email.
>
> Sent from Proton Mail for iOS
>
> On Sun, Sep 10, 2023 at 3:58 PM, Paul Gilmartin 
> <[042bfe9c879d-dmarc-requ...@listserv.ua.edu](mailto:On Sun, Sep 10, 2023 
> at 3:58 PM, Paul Gilmartin < wrote:
>
>> On Sun, 10 Sep 2023 17:23:10 +, Bob T Roller wrote:
>>
>>>AI will pay handsomely.
>>>
>>>AI expert is a hot new position in the freelance jobs market
>>>https://www.cnbc.com/2023/09/10/ai-expert-is-a-hot-new-position-in-the-freelance-jobs-market.html?__source=iosappshare%7Ccom.apple.UIKit.activity.CopyToPasteboard
>>>
>> That URL looked funny to me, so I asked on an Apple-centric forum and got:
>>
>>> The rest of the URL is critical. It means your copy/paste buffer is being 
>>> sent over the internet. It could be benign, like a text to voice app, a 
>>> grammar checker, a scanner program. Or, it could be what the last security 
>>> update was all about.
>>>
>>> You need to find out if the network location can be trusted, so look at the 
>>> first part of the URL.
>>
>>>Sent from Proton Mail for iOS
>>
>> --
>> 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

--
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: Mysterious S0C4 pic 10

[Seymour J Metz]

I generally look at the RB chain for the failing TCB. After that it's the usual 
suspects.


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Monday, September 11, 2023 3:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mysterious S0C4 pic 10

The SDWA has the PROGRAM not the RB

Which I kind of strange

Given the fact that none registers

Have any value from the program



On Mon, Sep 11, 2023 at 3:39 PM Bill Hitefield <
bill.hitefi...@dino-software.com> wrote:

> Does the R13 point to your RSA, or does it point to someone else's RSA. If
> it does, is yours in the save-area chain?
>
> And, in the dump (if there was one), does the S0C4 show up in an SVRB or a
> PRB?
>
> Bill Hitefield
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Joseph Reichman
> > Sent: Monday, September 11, 2023 3:33 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Mysterious S0C4 pic 10
> >
> > Totally different that my program not one is in the program storage
> >
> > > On Sep 11, 2023, at 3:08 PM, Seymour J Metz  wrote:
> > >
> > > What is supposed to be in the registers on entry? Have you verified
> that they
> > are set correctly? What are the registers at the PIC '10'X?
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> > > behalf of Joseph Reichman 
> > > Sent: Monday, September 11, 2023 9:32 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Mysterious S0C4 pic 10
> > >
> > > Hi
> > >
> > >
> > >
> > > I have the following lines of code which basically sets up the
> > > parameter list to an ESTAE and calls it
> > >
> > >
> > >
> > > Later on when I populate Parse Parameter list   and call IKJPARS I get
> a
> > > s0c4 pic 10 right after the BALR
> > >
> > > When  I comment out the code below (that sets up the ESTAE parameter
> > > list) everything with PARS works great
> > >
> > >
> > >
> > > I check and double checked there is no storage overlay, I am just
> > > looking for guidance how to debug this
> > >
> > >
> > >
> > >  Thank you
> > >
> > >
> > >
> > > XC ESTAED,ESTAED Clear ESTAE parameter list
> > >
> > > LA R5,ESTAED
> > >
> > > USING  RECVPARM,R5
> > >
> > > MVCRECMOD,=CL8'TESTAUTR'
> > >
> > > ST R3,RECENTRY
> > >
> > > LARL   R5,ENDMOD
> > >
> > > ST R5,RECEND
> > >
> > > *   ST R9,RECCTLMD
> > >
> > > MVCRECRTRY,=A(RETURN)
> > >
> > > LR R8,R0
> > >
> > > *   LR R8,R0
> > >
> > > ESTAE (R8),CT,PARAM=(R5),MF=(E,ESTAEL)
> > >
> > > *
> > >
> > >
> > >
> > >  Rest of my code
> > >
> > >
> > >
> > >
> > >
> > > *
> > >
> > > * check if the sub system is running
> > >
> > > *
> > >
> > > IEFSSI REQUEST=QUERY,
> > >
> > >   SUBNAME=TSTA,
> > >
> > >   WORKAREA=JSIPTR,
> > >
> > >   WORKASP=SP,
> > >
> > >   RETCODE=RETURN_CODE,
> > >
> > >   RSNCODE=RSNCODE,
> > >
> > >   MF=(E,IEFLST)
> > >
> > > *
> > >
> > > CLC   RETURN_CODE,=F'0'Q. IS TSTA SS THERE
> > >
> > > *BNE   RETURN
> > >
> > >
> > >
> > >
> > >
> > > *
> > >
> > >  USING CPPL,R10
> > >
> > >  TITLE ' PARSE CONTROL LIST '
> > >
> > >  LAR1,MYPPL
> > >
> > >  USING PPL,R1
> > >
> > >  L R5,=A(MODPCL)
> > >
> > >  STR5,PPLPCL
> > >
> > >  LAR5,MYANSADDR OF ANSWER PLACE
> > >
> > >  STR5,PPLANS
> > >
> > >  MVC   PPLCBUF(4),CPPLCBUF
> > >
> > >  MVC   PPLUPT,CPPLUPT
> > >
> > > *MVC   PPLUPT,TSTUPT
> > >
> > >  MVC   PPLECT,CPPLECT
> > >
> > > *MVC   PPLECT,TSTECT
> > >
> > >  LAR4,MYECBGET ADDR OF ECB
> > >
> > >  XCMYECB,MYECB
> > >
> > >  STR4,PPLECB
> > >
> > >  LAR15,SAVEEXIT
> > >
> > >  STR15,PPLUWA
> > >
> > >  L R15,CVTPTR(,0)  POINT TO THE CVT
> > >
> > >  L R15,CVTPARS-CVT(,R15)   GET IKJPARS EP
> > >
> > >  BASR  R14,R15 CALL IKJPARS
> > >
> > >  LTR   R15,R15 RC FROM PARS OK
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > WORKAREA DSECT
> > >
> > > DS18F
> > >
> > > SAVEEXIT DS18F
> > >
> > > ABENDM   DSCL45
> > >
> > > ESTAED   DSXL(RECVLEN) <--- storage are for ESTAE
> parameter list
> > >
> > >
> > > JSIPTR   DSA
> > >
> > > TCB$ DSF
> > >
> > > RB$  DSF
> > >
> > > SRBA DSCL80
> > >
> > > LTOKEN   DSCL8
> > >
> > > DBWRDDSD
> > >
> > > RETCODE  DSF
> > >
> > > ASCBADDR DSF
> > >
> > > SP   DSX
> > >
> > > RETURN_CODE DS F
> > >
> > > ALELST   ALESERV MF=L
> > >
> > > ALELEN   EQU   *-ALELST
> > >
> > >
> > >
> > > 

Re: Compile mod_wsgi Python Apache module

[Grant Taylor]

I've not seen any other replies to this thread, so I'll go ahead and 
send what I had drafted before waiting in the hopes that someone more 
knowledgeable than I would reply.  But, maybe my experience compiling 
things will get you on the proper path.


On 9/6/23 10:16 AM, Oscar wrote:

Hello,


Hi,

Everything is fine until we run make to compile the plugin. Tt fails 
because somehow a file is missing, but AFAIK the file is where is 
supposed to be.


Please elaborate on "what file" and "where (it) is supposed to be". What 
file name are you looking for and where are you looking.



Has anyone succeeded in compiling mod_wsgi on z/OS (we are at 2.4)?


I've never tried.


make output: https://pastebin.com/raw/AhW6UMSh


Having spent a lot of time looking at make output and compiling things 
in years past, my thoughts are below.


libtoolexe: cc -Wl,DLL -o src/server/mod_wsgi.so -Wc,-qcpluscmt 
-Wc,-qlanglvl=extc99 -Wc,XPLINK,lp64,dll,expo -Wl,XPLINK,lp64 -O3 
-U_NO_PROTO -DSIGPROCMASK_SETS_THREAD_MASK -DTCP_NODELAY=1 
-L/u/ames/fixpack/blddir/destdir/home/oscar/apache/lib 
-L/u/ames/fixpack/blddir/destdir/u/ames/fixpack/blddir/destdir/home/oscar/apache/lib 
src/server/wsgi_apache.o src/server/mod_wsgi.o 
-L/STAGIN/IBM/python39/usr/lpp/IBM/cyp/v3r9/pyz/lib 
-L/STAGIN/IBM/python39/usr/lpp/IBM/cyp/v3r9/pyz/lib/python3.9/config-3.9 
-lpython3.9 -ldl -lm 
/STAGIN/IBM/python39/usr/lpp/IBM/cyp/v3r9/pyz/lib/python3.9/config-3.9/libpython3.9.x 
/home/oscar/apache/lib/apachecore.x /home/oscar/apache/lib/apachecore.x 
/home/oscar/apache/lib/libapr-1.x /home/oscar/apache/lib/libaprutil-1.x 
/home/oscar/apache/lib/liblua.x

FSUM3067 The archive library python3.9 (libpython3.9.a) cannot be found.

libtoolexe / cc can't find a library that they are looking for.

I assume that they are looking for libpython3.9.a in a typical library 
location.


This may be that the library itself can't be found and / or the headers 
therefor can't be found.


If you recently added said library / headers, try runing ldconfig to 
update the dynamic linker's cache of what libraries are where.



make file: https://pastebin.com/raw/PJs2d5C7

Thanks in advance!




--
Grant. . . .
unix || die

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

Re: What became of "mutually exclusive"?

[Paul Gilmartin]

On Mon, 11 Sep 2023 16:32:33 -0400, David Spiegel wrote:
>Hi Gil,
>You said: "...I recall seeing in days of your ..." My? ... My what? {;}-> ?
>I think that you meant "yore" instead of "your", n'est-ce pas?
> 
The other, very similar, comment I received was off-list.  I regret that
I provided an enticement to drift.  I hope further replies will address
not my style, but my substance (which, admittedly, addr3essed the
style of IBM's documentation.)  I corrected the spelling in the quoted
text.

>On 2023-09-11 14:21, Paul Gilmartin wrote:
>> In the JCL Ref, I recall seeing in days of [yore] a matrix of mutually
>> exclusive parameters on the DD statement.  I no longer find it; instead
>> for various parameters see:
>>  Relationship to other parameters
>>  Do not code the following parameters with the ... parameter:
>>
>> Does this mean they're mutually exclusive?  Earlier, I see:
>> • If you add a parameter that is mutually exclusive with a parameter
>>on a procedure statement, the override operation automatically
>>nullifies the procedure parameter.
>>
>> Did the matrix just become too big to print?  Should there be a statement
>> somewhere that "Do not code the following parameters with" implies
>> "mutually exclusive", or is it sometimes merely advisory?

-- 
Happy New Year,
gil

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

Re: z/OSMF and the Old Timer

[Tom Longfellow]

Thanks Kurt.
It is comforting to know that I can still punch my way out of a paper bag.

I took the 'clear the catalog' approach for the Dlibs.It was not totally 
clear sailing.   Still haunted by data set decisions and location choices made 
(literally) decades ago.

I am now at the Post Deploy options to build and integrate my other products 
and local mods into an IPLable system.

Onwards and upwards.

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

Re: What became of "mutually exclusive"?

[David Spiegel]

Hi Gil,
You said: "...I recall seeing in days of your ..." My? ... My what? {;}-> ?
I think that you meant "yore" instead of "your", n'est-ce pas?

Regards,
David

On 2023-09-11 14:21, Paul Gilmartin wrote:

In the JCL Ref, I recall seeing in days of your a matrix of mutually
exclusive parameters on the DD statement.  I no longer find it; instead
for various parameters see:
 Relationship to other parameters
 Do not code the following parameters with the ... parameter:

Does this mean they're mutually exclusive?  Earlier, I see:
• If you add a parameter that is mutually exclusive with a parameter
   on a procedure statement, the override operation automatically
   nullifies the procedure parameter.

Did the matrix just become too big to print?  Should there be a statement
somewhere that "Do not code the following parameters with" implies
"mutually exclusive", or is it sometimes merely advisory?



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

Re: Mysterious S0C4 pic 10

[Joseph Reichman]

The SDWA has the PROGRAM not the RB

Which I kind of strange

Given the fact that none registers

Have any value from the program



On Mon, Sep 11, 2023 at 3:39 PM Bill Hitefield <
bill.hitefi...@dino-software.com> wrote:

> Does the R13 point to your RSA, or does it point to someone else's RSA. If
> it does, is yours in the save-area chain?
>
> And, in the dump (if there was one), does the S0C4 show up in an SVRB or a
> PRB?
>
> Bill Hitefield
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Joseph Reichman
> > Sent: Monday, September 11, 2023 3:33 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Mysterious S0C4 pic 10
> >
> > Totally different that my program not one is in the program storage
> >
> > > On Sep 11, 2023, at 3:08 PM, Seymour J Metz  wrote:
> > >
> > > What is supposed to be in the registers on entry? Have you verified
> that they
> > are set correctly? What are the registers at the PIC '10'X?
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> > > behalf of Joseph Reichman 
> > > Sent: Monday, September 11, 2023 9:32 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Mysterious S0C4 pic 10
> > >
> > > Hi
> > >
> > >
> > >
> > > I have the following lines of code which basically sets up the
> > > parameter list to an ESTAE and calls it
> > >
> > >
> > >
> > > Later on when I populate Parse Parameter list   and call IKJPARS I get
> a
> > > s0c4 pic 10 right after the BALR
> > >
> > > When  I comment out the code below (that sets up the ESTAE parameter
> > > list) everything with PARS works great
> > >
> > >
> > >
> > > I check and double checked there is no storage overlay, I am just
> > > looking for guidance how to debug this
> > >
> > >
> > >
> > >  Thank you
> > >
> > >
> > >
> > > XC ESTAED,ESTAED Clear ESTAE parameter list
> > >
> > > LA R5,ESTAED
> > >
> > > USING  RECVPARM,R5
> > >
> > > MVCRECMOD,=CL8'TESTAUTR'
> > >
> > > ST R3,RECENTRY
> > >
> > > LARL   R5,ENDMOD
> > >
> > > ST R5,RECEND
> > >
> > > *   ST R9,RECCTLMD
> > >
> > > MVCRECRTRY,=A(RETURN)
> > >
> > > LR R8,R0
> > >
> > > *   LR R8,R0
> > >
> > > ESTAE (R8),CT,PARAM=(R5),MF=(E,ESTAEL)
> > >
> > > *
> > >
> > >
> > >
> > >  Rest of my code
> > >
> > >
> > >
> > >
> > >
> > > *
> > >
> > > * check if the sub system is running
> > >
> > > *
> > >
> > > IEFSSI REQUEST=QUERY,
> > >
> > >   SUBNAME=TSTA,
> > >
> > >   WORKAREA=JSIPTR,
> > >
> > >   WORKASP=SP,
> > >
> > >   RETCODE=RETURN_CODE,
> > >
> > >   RSNCODE=RSNCODE,
> > >
> > >   MF=(E,IEFLST)
> > >
> > > *
> > >
> > > CLC   RETURN_CODE,=F'0'Q. IS TSTA SS THERE
> > >
> > > *BNE   RETURN
> > >
> > >
> > >
> > >
> > >
> > > *
> > >
> > >  USING CPPL,R10
> > >
> > >  TITLE ' PARSE CONTROL LIST '
> > >
> > >  LAR1,MYPPL
> > >
> > >  USING PPL,R1
> > >
> > >  L R5,=A(MODPCL)
> > >
> > >  STR5,PPLPCL
> > >
> > >  LAR5,MYANSADDR OF ANSWER PLACE
> > >
> > >  STR5,PPLANS
> > >
> > >  MVC   PPLCBUF(4),CPPLCBUF
> > >
> > >  MVC   PPLUPT,CPPLUPT
> > >
> > > *MVC   PPLUPT,TSTUPT
> > >
> > >  MVC   PPLECT,CPPLECT
> > >
> > > *MVC   PPLECT,TSTECT
> > >
> > >  LAR4,MYECBGET ADDR OF ECB
> > >
> > >  XCMYECB,MYECB
> > >
> > >  STR4,PPLECB
> > >
> > >  LAR15,SAVEEXIT
> > >
> > >  STR15,PPLUWA
> > >
> > >  L R15,CVTPTR(,0)  POINT TO THE CVT
> > >
> > >  L R15,CVTPARS-CVT(,R15)   GET IKJPARS EP
> > >
> > >  BASR  R14,R15 CALL IKJPARS
> > >
> > >  LTR   R15,R15 RC FROM PARS OK
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > WORKAREA DSECT
> > >
> > > DS18F
> > >
> > > SAVEEXIT DS18F
> > >
> > > ABENDM   DSCL45
> > >
> > > ESTAED   DSXL(RECVLEN) <--- storage are for ESTAE
> parameter list
> > >
> > >
> > > JSIPTR   DSA
> > >
> > > TCB$ DSF
> > >
> > > RB$  DSF
> > >
> > > SRBA DSCL80
> > >
> > > LTOKEN   DSCL8
> > >
> > > DBWRDDSD
> > >
> > > RETCODE  DSF
> > >
> > > ASCBADDR DSF
> > >
> > > SP   DSX
> > >
> > > RETURN_CODE DS F
> > >
> > > ALELST   ALESERV MF=L
> > >
> > > ALELEN   EQU   *-ALELST
> > >
> > >
> > >
> > > --
> > > 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 

Re: Mysterious S0C4 pic 10

[Bill Hitefield]

Does the R13 point to your RSA, or does it point to someone else's RSA. If it 
does, is yours in the save-area chain?

And, in the dump (if there was one), does the S0C4 show up in an SVRB or a PRB?

Bill Hitefield

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Joseph Reichman
> Sent: Monday, September 11, 2023 3:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Mysterious S0C4 pic 10
> 
> Totally different that my program not one is in the program storage
> 
> > On Sep 11, 2023, at 3:08 PM, Seymour J Metz  wrote:
> >
> > What is supposed to be in the registers on entry? Have you verified that 
> > they
> are set correctly? What are the registers at the PIC '10'X?
> >
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Joseph Reichman 
> > Sent: Monday, September 11, 2023 9:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Mysterious S0C4 pic 10
> >
> > Hi
> >
> >
> >
> > I have the following lines of code which basically sets up the
> > parameter list to an ESTAE and calls it
> >
> >
> >
> > Later on when I populate Parse Parameter list   and call IKJPARS I get a
> > s0c4 pic 10 right after the BALR
> >
> > When  I comment out the code below (that sets up the ESTAE parameter
> > list) everything with PARS works great
> >
> >
> >
> > I check and double checked there is no storage overlay, I am just
> > looking for guidance how to debug this
> >
> >
> >
> >  Thank you
> >
> >
> >
> > XC ESTAED,ESTAED Clear ESTAE parameter list
> >
> > LA R5,ESTAED
> >
> > USING  RECVPARM,R5
> >
> > MVCRECMOD,=CL8'TESTAUTR'
> >
> > ST R3,RECENTRY
> >
> > LARL   R5,ENDMOD
> >
> > ST R5,RECEND
> >
> > *   ST R9,RECCTLMD
> >
> > MVCRECRTRY,=A(RETURN)
> >
> > LR R8,R0
> >
> > *   LR R8,R0
> >
> > ESTAE (R8),CT,PARAM=(R5),MF=(E,ESTAEL)
> >
> > *
> >
> >
> >
> >  Rest of my code
> >
> >
> >
> >
> >
> > *
> >
> > * check if the sub system is running
> >
> > *
> >
> > IEFSSI REQUEST=QUERY,
> >
> >   SUBNAME=TSTA,
> >
> >   WORKAREA=JSIPTR,
> >
> >   WORKASP=SP,
> >
> >   RETCODE=RETURN_CODE,
> >
> >   RSNCODE=RSNCODE,
> >
> >   MF=(E,IEFLST)
> >
> > *
> >
> > CLC   RETURN_CODE,=F'0'Q. IS TSTA SS THERE
> >
> > *BNE   RETURN
> >
> >
> >
> >
> >
> > *
> >
> >  USING CPPL,R10
> >
> >  TITLE ' PARSE CONTROL LIST '
> >
> >  LAR1,MYPPL
> >
> >  USING PPL,R1
> >
> >  L R5,=A(MODPCL)
> >
> >  STR5,PPLPCL
> >
> >  LAR5,MYANSADDR OF ANSWER PLACE
> >
> >  STR5,PPLANS
> >
> >  MVC   PPLCBUF(4),CPPLCBUF
> >
> >  MVC   PPLUPT,CPPLUPT
> >
> > *MVC   PPLUPT,TSTUPT
> >
> >  MVC   PPLECT,CPPLECT
> >
> > *MVC   PPLECT,TSTECT
> >
> >  LAR4,MYECBGET ADDR OF ECB
> >
> >  XCMYECB,MYECB
> >
> >  STR4,PPLECB
> >
> >  LAR15,SAVEEXIT
> >
> >  STR15,PPLUWA
> >
> >  L R15,CVTPTR(,0)  POINT TO THE CVT
> >
> >  L R15,CVTPARS-CVT(,R15)   GET IKJPARS EP
> >
> >  BASR  R14,R15 CALL IKJPARS
> >
> >  LTR   R15,R15 RC FROM PARS OK
> >
> >
> >
> >
> >
> >
> >
> > WORKAREA DSECT
> >
> > DS18F
> >
> > SAVEEXIT DS18F
> >
> > ABENDM   DSCL45
> >
> > ESTAED   DSXL(RECVLEN) <--- storage are for ESTAE parameter list
> >
> >
> > JSIPTR   DSA
> >
> > TCB$ DSF
> >
> > RB$  DSF
> >
> > SRBA DSCL80
> >
> > LTOKEN   DSCL8
> >
> > DBWRDDSD
> >
> > RETCODE  DSF
> >
> > ASCBADDR DSF
> >
> > SP   DSX
> >
> > RETURN_CODE DS F
> >
> > ALELST   ALESERV MF=L
> >
> > ALELEN   EQU   *-ALELST
> >
> >
> >
> > --
> > 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
> 
> --
> 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: Mysterious S0C4 pic 10

[Joseph Reichman]

Totally different that my program not one is in the program storage 

> On Sep 11, 2023, at 3:08 PM, Seymour J Metz  wrote:
> 
> What is supposed to be in the registers on entry? Have you verified that 
> they are set correctly? What are the registers at the PIC '10'X?
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 
> Sent: Monday, September 11, 2023 9:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Mysterious S0C4 pic 10
> 
> Hi
> 
> 
> 
> I have the following lines of code which basically sets up the parameter
> list to an ESTAE and calls it
> 
> 
> 
> Later on when I populate Parse Parameter list   and call IKJPARS I get a
> s0c4 pic 10 right after the BALR
> 
> When  I comment out the code below (that sets up the ESTAE parameter list)
> everything with PARS works great
> 
> 
> 
> I check and double checked there is no storage overlay, I am just looking
> for guidance how to debug this
> 
> 
> 
>  Thank you
> 
> 
> 
> XC ESTAED,ESTAED Clear ESTAE parameter list
> 
> LA R5,ESTAED
> 
> USING  RECVPARM,R5
> 
> MVCRECMOD,=CL8'TESTAUTR'
> 
> ST R3,RECENTRY
> 
> LARL   R5,ENDMOD
> 
> ST R5,RECEND
> 
> *   ST R9,RECCTLMD
> 
> MVCRECRTRY,=A(RETURN)
> 
> LR R8,R0
> 
> *   LR R8,R0
> 
> ESTAE (R8),CT,PARAM=(R5),MF=(E,ESTAEL)
> 
> *
> 
> 
> 
>  Rest of my code
> 
> 
> 
> 
> 
> *
> 
> * check if the sub system is running
> 
> *
> 
> IEFSSI REQUEST=QUERY,
> 
>   SUBNAME=TSTA,
> 
>   WORKAREA=JSIPTR,
> 
>   WORKASP=SP,
> 
>   RETCODE=RETURN_CODE,
> 
>   RSNCODE=RSNCODE,
> 
>   MF=(E,IEFLST)
> 
> *
> 
> CLC   RETURN_CODE,=F'0'Q. IS TSTA SS THERE
> 
> *BNE   RETURN
> 
> 
> 
> 
> 
> *
> 
>  USING CPPL,R10
> 
>  TITLE ' PARSE CONTROL LIST '
> 
>  LAR1,MYPPL
> 
>  USING PPL,R1
> 
>  L R5,=A(MODPCL)
> 
>  STR5,PPLPCL
> 
>  LAR5,MYANSADDR OF ANSWER PLACE
> 
>  STR5,PPLANS
> 
>  MVC   PPLCBUF(4),CPPLCBUF
> 
>  MVC   PPLUPT,CPPLUPT
> 
> *MVC   PPLUPT,TSTUPT
> 
>  MVC   PPLECT,CPPLECT
> 
> *MVC   PPLECT,TSTECT
> 
>  LAR4,MYECBGET ADDR OF ECB
> 
>  XCMYECB,MYECB
> 
>  STR4,PPLECB
> 
>  LAR15,SAVEEXIT
> 
>  STR15,PPLUWA
> 
>  L R15,CVTPTR(,0)  POINT TO THE CVT
> 
>  L R15,CVTPARS-CVT(,R15)   GET IKJPARS EP
> 
>  BASR  R14,R15 CALL IKJPARS
> 
>  LTR   R15,R15 RC FROM PARS OK
> 
> 
> 
> 
> 
> 
> 
> WORKAREA DSECT
> 
> DS18F
> 
> SAVEEXIT DS18F
> 
> ABENDM   DSCL45
> 
> ESTAED   DSXL(RECVLEN) <--- storage are for ESTAE parameter list
> 
> 
> JSIPTR   DSA
> 
> TCB$ DSF
> 
> RB$  DSF
> 
> SRBA DSCL80
> 
> LTOKEN   DSCL8
> 
> DBWRDDSD
> 
> RETCODE  DSF
> 
> ASCBADDR DSF
> 
> SP   DSX
> 
> RETURN_CODE DS F
> 
> ALELST   ALESERV MF=L
> 
> ALELEN   EQU   *-ALELST
> 
> 
> 
> --
> 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

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

Re: Mysterious S0C4 pic 10

[Seymour J Metz]

What is supposed to be in the registers on entry? Have you verified that they 
are set correctly? What are the registers at the PIC '10'X?


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Monday, September 11, 2023 9:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Mysterious S0C4 pic 10

Hi



I have the following lines of code which basically sets up the parameter
list to an ESTAE and calls it



Later on when I populate Parse Parameter list   and call IKJPARS I get a
s0c4 pic 10 right after the BALR

When  I comment out the code below (that sets up the ESTAE parameter list)
everything with PARS works great



I check and double checked there is no storage overlay, I am just looking
for guidance how to debug this



  Thank you



 XC ESTAED,ESTAED Clear ESTAE parameter list

 LA R5,ESTAED

 USING  RECVPARM,R5

 MVCRECMOD,=CL8'TESTAUTR'

 ST R3,RECENTRY

 LARL   R5,ENDMOD

 ST R5,RECEND

 *   ST R9,RECCTLMD

 MVCRECRTRY,=A(RETURN)

 LR R8,R0

 *   LR R8,R0

 ESTAE (R8),CT,PARAM=(R5),MF=(E,ESTAEL)

 *



  Rest of my code





*

* check if the sub system is running

*

 IEFSSI REQUEST=QUERY,

   SUBNAME=TSTA,

   WORKAREA=JSIPTR,

   WORKASP=SP,

   RETCODE=RETURN_CODE,

   RSNCODE=RSNCODE,

   MF=(E,IEFLST)

*

 CLC   RETURN_CODE,=F'0'Q. IS TSTA SS THERE

*BNE   RETURN





*

  USING CPPL,R10

  TITLE ' PARSE CONTROL LIST '

  LAR1,MYPPL

  USING PPL,R1

  L R5,=A(MODPCL)

  STR5,PPLPCL

  LAR5,MYANSADDR OF ANSWER PLACE

  STR5,PPLANS

  MVC   PPLCBUF(4),CPPLCBUF

  MVC   PPLUPT,CPPLUPT

 *MVC   PPLUPT,TSTUPT

  MVC   PPLECT,CPPLECT

 *MVC   PPLECT,TSTECT

  LAR4,MYECBGET ADDR OF ECB

  XCMYECB,MYECB

  STR4,PPLECB

  LAR15,SAVEEXIT

  STR15,PPLUWA

  L R15,CVTPTR(,0)  POINT TO THE CVT

  L R15,CVTPARS-CVT(,R15)   GET IKJPARS EP

  BASR  R14,R15 CALL IKJPARS

  LTR   R15,R15 RC FROM PARS OK







WORKAREA DSECT

 DS18F

SAVEEXIT DS18F

ABENDM   DSCL45

ESTAED   DSXL(RECVLEN) <--- storage are for ESTAE parameter list


JSIPTR   DSA

TCB$ DSF

RB$  DSF

SRBA DSCL80

LTOKEN   DSCL8

DBWRDDSD

RETCODE  DSF

ASCBADDR DSF

SP   DSX

RETURN_CODE DS F

ALELST   ALESERV MF=L

ALELEN   EQU   *-ALELST



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

What became of "mutually exclusive"?

[Paul Gilmartin]

In the JCL Ref, I recall seeing in days of your a matrix of mutually
exclusive parameters on the DD statement.  I no longer find it; instead
for various parameters see: 
Relationship to other parameters
Do not code the following parameters with the ... parameter:

Does this mean they're mutually exclusive?  Earlier, I see:
• If you add a parameter that is mutually exclusive with a parameter
  on a procedure statement, the override operation automatically
  nullifies the procedure parameter.

Did the matrix just become too big to print?  Should there be a statement
somewhere that "Do not code the following parameters with" implies
"mutually exclusive", or is it sometimes merely advisory?

-- 
gil

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

Re: [EXTERNAL] Re: Storage questions - mod9, mod27, mod54

[Pommier, Rex]

Tony,

Thank you for setting me straight on the lack of requirement of all volumes in 
an LCU being the same size.  I'm pretty sure my business partner had told me 
that was a requirement.  It may have been a restriction from long ago.  Our 
first emulated device was a DS6800 that was replaced by a DSD8870 then to a 
DS8910F.  Is it possible that was a requirement in the early days of the DS6800 
level and we just kept the idea even though the requirement vanished?

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Thigpen
Sent: Monday, September 11, 2023 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Storage questions - mod9, mod27, mod54

Linda,

Really, you need to take those questions to your storage group. There are a lot 
of variables based on hardware and currently used storage in the DASD subsystem.

To fix one incorrect reply, at lease on IBM DS8000, all DASD on the same LCU 
(FKA 'string') does *not* have to be the same size. It makes it easier for the 
storage group to manage if they are all the same, but it's not required.

The DS8000 allocates storage in Mod-1 slices. You current addresses only have 
enough slices for their current size. Converting from one size to another 
requires deleting a volume and redefining it. The rest of the volumes don't 
have to be touched.

There is a limit on how many slices each DS8000 is licensed for. If there are 
free slices, then the storage group can define you some new volumes to which 
you will migrate your data to. Then, they can reclaim the original slices. 
(Note: This leaves 'holes' in the CUU address range and some people don't like 
that.)

Talk to your storage group. They will tell you if they can create new volumes 
then the data can be migrated. Or, they may require a full back-up and re-load 
if they don't have free slices in the DS8000.

Tony Thigpen

Linda Hagedorn wrote on 9/11/23 10:14 AM:
> Hi,
> 
> I hope you won't mind a storage question.
> 
> We're running zOS 2.4 and have a smattering of volume sizes - mod9, mod27, 
> mod54.
> 
> I'd like to have all mod54's for Db2 and be prepared before going to the 
> storage folks.
> 
> 1. Is storage virtual nowadays?
> 2. Can virtual mod9s and mod27s be reconfigured to mod54s?
> 3. Does the reconfiguration require an IPL?
> 4. Does the reconfiguration new addressing in IODF?
> 5. Is the storage vendor (IBM, EMC, etc.) relevant?  Does the hardware 
> determine or be a factor in merging the mod9s/mod27s, into mod54s?
> 6. Is it a given that the volumes must be cleared/emptied before the 
> reconfiguration happens?
> 7. How long does reconfiguration take?
> 
> Is there anything else I should consider before taking this request to the 
> storage group?
> 
> Any information or advice is appreciated.
> 
> Thank you.  Linda Hagedorn
> 
> --
> 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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: Storage questions - mod9, mod27, mod54

[Tony Thigpen]

Linda,

Really, you need to take those questions to your storage group. There 
are a lot of variables based on hardware and currently used storage in 
the DASD subsystem.


To fix one incorrect reply, at lease on IBM DS8000, all DASD on the same 
LCU (FKA 'string') does *not* have to be the same size. It makes it 
easier for the storage group to manage if they are all the same, but 
it's not required.


The DS8000 allocates storage in Mod-1 slices. You current addresses only 
have enough slices for their current size. Converting from one size to 
another requires deleting a volume and redefining it. The rest of the 
volumes don't have to be touched.


There is a limit on how many slices each DS8000 is licensed for. If 
there are free slices, then the storage group can define you some new 
volumes to which you will migrate your data to. Then, they can reclaim 
the original slices. (Note: This leaves 'holes' in the CUU address range 
and some people don't like that.)


Talk to your storage group. They will tell you if they can create new 
volumes then the data can be migrated. Or, they may require a full 
back-up and re-load if they don't have free slices in the DS8000.


Tony Thigpen

Linda Hagedorn wrote on 9/11/23 10:14 AM:

Hi,

I hope you won't mind a storage question.

We're running zOS 2.4 and have a smattering of volume sizes - mod9, mod27, 
mod54.

I'd like to have all mod54's for Db2 and be prepared before going to the 
storage folks.

1. Is storage virtual nowadays?
2. Can virtual mod9s and mod27s be reconfigured to mod54s?
3. Does the reconfiguration require an IPL?
4. Does the reconfiguration new addressing in IODF?
5. Is the storage vendor (IBM, EMC, etc.) relevant?  Does the hardware 
determine or be a factor in merging the mod9s/mod27s, into mod54s?
6. Is it a given that the volumes must be cleared/emptied before the 
reconfiguration happens?
7. How long does reconfiguration take?

Is there anything else I should consider before taking this request to the 
storage group?

Any information or advice is appreciated.

Thank you.  Linda Hagedorn

--
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: Mysterious S0C4 pic 10

[Mike Schwab]

SNAP macro?
https://www.ibm.com/docs/en/zos/2.3.0?topic=dump-obtaining-snap-dumps

On Mon, Sep 11, 2023 at 11:58 AM Rob Scott  wrote:
>
> Joe,
>
> I know that you are writing a lot of assembler code in your spare time 
> without access to debugging software like zXDC , so I would advise the 
> following as a good investment of your time as working out errors in code 
> just from dumps can be difficult:
>
> (O) write yourself an internal trace tool that can dump out regs and named 
> storage areas during runtime (maybe activated by special ddname or 
> parameter). Make this code generic so that you can use it in all your 
> projects.
>
> (O) insert trace points before and after major logic points and any internal 
> or external calls.
>
> (O) consider improving your naming standards so that reading the code is 
> easier and obvious typos appear more frequently. A good example is using 
> something like "struct_field_name" for fields inside your own struct
>
> (O) consider working storage as a struct and apply the same rules as above
>
> (O) have a naming standard for constants (and this includes model list forms 
> of macros that you prime parameter lists from)
>
> Hope this helps
>
> Rob Scott
> Rocket Software
>
> Sent from Outlook for Android
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 
> Sent: Monday, September 11, 2023 4:09:35 pm
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Mysterious S0C4 pic 10
>
> EXTERNAL EMAIL
>
>
>
>
>
> No it’s not the ESTAE but the code that populates the parameter list to it
>  it when I comment that out
>
> Later on the BASR to pars works
>
> Is there some thing like setting a slip trap that might help me
> Thanks
>
> Joe Reichman
>
>
> On Mon, Sep 11, 2023 at 11:05 AM Tony Harminc  wrote:
>
> > On Mon, 11 Sept 2023 at 09:33, Joseph Reichman 
> > wrote:
> >
> > > I have the following lines of code which basically sets up the parameter
> > > list to an ESTAE and calls it
> >
> > > Later on when I populate Parse Parameter list   and call IKJPARS I get a
> > > s0c4 pic 10 right after the BALR
> >
> > There's no BALR in the code snippets you've shown. I'll assume you mean
> > BASR.
> >
> > > When  I comment out the code below (that sets up the ESTAE parameter
> > list)
> > > everything with PARS works great
> > > I check and double checked there is no storage overlay, I am just looking
> > > for guidance how to debug this
> >
> > Two basic approaches: Top Down and Bottom Up. Start at the bottom -
> > what is the failing address causing your PIC 10? Does it look
> > plausible for the AMODE you're in at the time? Which instruction
> > actually failed? Is the failing address (or a near or left-truncated
> > version of it) in a register?
> >
> > Etc...
> >
> > If that hasn't made the problem obvious, then you may have collected
> > enough information to work from the top down. If it's true that the
> > ESTAE is provoking the failure, then what does it change, i.e. how
> > could anything it does affect the result of calling IKJPARS?
> >
> > Etc...
> >
> > Tony H.
> >
> > --
> > 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
>
>
>
> 
> Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
> Main Office Toll Free Number: +1 855.577.4323
> Contact Customer Support: 
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
> http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential information 
> of Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
> prohibited. If you are not the intended recipient, please notify Rocket 
> Software immediately and destroy all copies of this communication. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Mysterious S0C4 pic 10

[Rob Scott]

Joe,

I know that you are writing a lot of assembler code in your spare time without 
access to debugging software like zXDC , so I would advise the following as a 
good investment of your time as working out errors in code just from dumps can 
be difficult:

(O) write yourself an internal trace tool that can dump out regs and named 
storage areas during runtime (maybe activated by special ddname or parameter). 
Make this code generic so that you can use it in all your projects.

(O) insert trace points before and after major logic points and any internal or 
external calls.

(O) consider improving your naming standards so that reading the code is easier 
and obvious typos appear more frequently. A good example is using something 
like "struct_field_name" for fields inside your own struct

(O) consider working storage as a struct and apply the same rules as above

(O) have a naming standard for constants (and this includes model list forms of 
macros that you prime parameter lists from)

Hope this helps

Rob Scott
Rocket Software

Sent from Outlook for Android


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Monday, September 11, 2023 4:09:35 pm
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Mysterious S0C4 pic 10

EXTERNAL EMAIL





No it’s not the ESTAE but the code that populates the parameter list to it
 it when I comment that out

Later on the BASR to pars works

Is there some thing like setting a slip trap that might help me
Thanks

Joe Reichman


On Mon, Sep 11, 2023 at 11:05 AM Tony Harminc  wrote:

> On Mon, 11 Sept 2023 at 09:33, Joseph Reichman 
> wrote:
>
> > I have the following lines of code which basically sets up the parameter
> > list to an ESTAE and calls it
>
> > Later on when I populate Parse Parameter list   and call IKJPARS I get a
> > s0c4 pic 10 right after the BALR
>
> There's no BALR in the code snippets you've shown. I'll assume you mean
> BASR.
>
> > When  I comment out the code below (that sets up the ESTAE parameter
> list)
> > everything with PARS works great
> > I check and double checked there is no storage overlay, I am just looking
> > for guidance how to debug this
>
> Two basic approaches: Top Down and Bottom Up. Start at the bottom -
> what is the failing address causing your PIC 10? Does it look
> plausible for the AMODE you're in at the time? Which instruction
> actually failed? Is the failing address (or a near or left-truncated
> version of it) in a register?
>
> Etc...
>
> If that hasn't made the problem obvious, then you may have collected
> enough information to work from the top down. If it's true that the
> ESTAE is provoking the failure, then what does it change, i.e. how
> could anything it does affect the result of calling IKJPARS?
>
> Etc...
>
> Tony H.
>
> --
> 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




Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Mysterious S0C4 pic 10

[Joseph Reichman]

Thank you all :)

> On Sep 11, 2023, at 11:39 AM, Tom Marchant 
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> 
> SLIP trap will just give you another dump. You do have a dump DD statement, 
> don't you? 
> If you have a SYSMDUMP DD the resulting dump will be very similar to an SVC 
> dump.
> 
> --
> Tom Marchant
> 
>> On Mon, 11 Sep 2023 11:09:08 -0400, Joseph Reichman  
>> wrote:
>> 
>> Is there some thing like setting a slip trap that might help me
> 
> --
> 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: Storage questions - mod9, mod27, mod54

[Mike Schwab]

The absolutely easiest way is to use TDMF, FDRPAS, etc., to move your
existing volumes to the new larger volumes on the new storage unit.
You then run ICKDSF to pick up the new size.  If your VTOC size is
pretty small you may run out of VTOC entries if you have lots of small
datasets on the volume.

And if you have lots of free space on some volumes after the move, you
can disable new the volumes you want to return until they are empty.
TDMF did include software to replicate datasets to a different volume
then rename when it is closed.

You might consider doing a few EAV volumes for experimenting with then
using for your largest storage group.  Maybe MOD 108 (128K Cylinders).
(And if you do, the Hercules group would like to see backups of a few
VTOC records used by EAV high datasets.)

On Mon, Sep 11, 2023 at 9:14 AM Linda Hagedorn  wrote:
>
> Hi,
>
> I hope you won't mind a storage question.
>
> We're running zOS 2.4 and have a smattering of volume sizes - mod9, mod27, 
> mod54.
>
> I'd like to have all mod54's for Db2 and be prepared before going to the 
> storage folks.
>
> 1. Is storage virtual nowadays?
> 2. Can virtual mod9s and mod27s be reconfigured to mod54s?
> 3. Does the reconfiguration require an IPL?
> 4. Does the reconfiguration new addressing in IODF?
> 5. Is the storage vendor (IBM, EMC, etc.) relevant?  Does the hardware 
> determine or be a factor in merging the mod9s/mod27s, into mod54s?
> 6. Is it a given that the volumes must be cleared/emptied before the 
> reconfiguration happens?
> 7. How long does reconfiguration take?
>
> Is there anything else I should consider before taking this request to the 
> storage group?
>
> Any information or advice is appreciated.
>
> Thank you.  Linda Hagedorn
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

CH3s ESCON card

[Kevin Bowling]

Hi,

I am looking for a CH3s QH50, P/N 63F3825 for a 9221 ES/9000.

Regards,
Kevin

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

Re: Mysterious S0C4 pic 10

[Tom Marchant]

SLIP trap will just give you another dump. You do have a dump DD statement, 
don't you? 
If you have a SYSMDUMP DD the resulting dump will be very similar to an SVC 
dump.

--
Tom Marchant

On Mon, 11 Sep 2023 11:09:08 -0400, Joseph Reichman  
wrote:

>Is there some thing like setting a slip trap that might help me

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

Re: Mysterious S0C4 pic 10

[Tony Harminc]

On Mon, 11 Sept 2023 at 11:09, Joseph Reichman  wrote:
>
> No it’s not the ESTAE but the code that populates the parameter list to it
>  it when I comment that out
>
> Later on the BASR to pars works

(As an aside, it would be really great if you could avoid starting
every line with a capital letter, and end each sentence (but not every
line) with a period. Yeah, maybe a pain on your phone, but it's not
*that* hard, and it makes things much easier to follow.)

So the ESTAE works with no arguments...? I'm not sure what the
difference between the "commented out" code and the original is. If
you don't populate the parameter list, the ESTAE "works" and so does
everything else? In the snippet you have a commented
*   LR R8,R0
preceded by a not commented
LR R8,R0
so that's a comment, but not exactly commented out. So either you
didn't comment it out, or you didn't show the actual code.

> Is there some thing like setting a slip trap that might help me

You've already said that there is no storage overlay, so I'm not sure
what a SLIP trap would do for you. There is no SLIP that triggers on a
logic error. Why not follow up on the failing address and instruction
first?

Tony H.

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

Re: Storage questions - mod9, mod27, mod54

[Radoslaw Skorupka]

Answers below.

W dniu 11.09.2023 o 16:14, Linda Hagedorn pisze:

Hi,

I hope you won't mind a storage question.

We're running zOS 2.4 and have a smattering of volume sizes - mod9, mod27, 
mod54.

I'd like to have all mod54's for Db2 and be prepared before going to the 
storage folks.

1. Is storage virtual nowadays?

Of course, YES. It have been virtual for decades.



2. Can virtual mod9s and mod27s be reconfigured to mod54s?

Well, yes and no.
No - you cannot automagically say "englarge my volume", even if you are 
Harry Potter.
Yes - you can change your DASD array, i.e. destroy all the volumes on 
given RAID group and re-create another bunch o volumes, larger ones. 
Details depend on you disk vendor, your needs, capacity, etc.

(theoretically enlarge on the fly is also possible, but.. usually not)



3. Does the reconfiguration require an IPL?
No, but it requires at least offline to your volumes. Note, you can even 
buy new disk system and start using it without the IPL.



4. Does the reconfiguration new addressing in IODF?

Usually yes - you will have less bigger volumes.


5. Is the storage vendor (IBM, EMC, etc.) relevant?  Does the hardware 
determine or be a factor in merging the mod9s/mod27s, into mod54s?


Yes, every supplier has it's own way of disk system management. No, the 
factor is the same - you simply cut the space in GB.



6. Is it a given that the volumes must be cleared/emptied before the 
reconfiguration happens?

Yes, your disks will be destroyed. All of them? No.
  
7. How long does reconfiguration take?

Hours to months, depending on details.


Is there anything else I should consider before taking this request to the 
storage group?

You should start from that point. Just talk to them.




--
Radoslaw Skorupka
Lodz, Poland

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

Re: Mysterious S0C4 pic 10

[Joseph Reichman]

No it’s not the ESTAE but the code that populates the parameter list to it
 it when I comment that out

Later on the BASR to pars works

Is there some thing like setting a slip trap that might help me
Thanks

Joe Reichman


On Mon, Sep 11, 2023 at 11:05 AM Tony Harminc  wrote:

> On Mon, 11 Sept 2023 at 09:33, Joseph Reichman 
> wrote:
>
> > I have the following lines of code which basically sets up the parameter
> > list to an ESTAE and calls it
>
> > Later on when I populate Parse Parameter list   and call IKJPARS I get a
> > s0c4 pic 10 right after the BALR
>
> There's no BALR in the code snippets you've shown. I'll assume you mean
> BASR.
>
> > When  I comment out the code below (that sets up the ESTAE parameter
> list)
> > everything with PARS works great
> > I check and double checked there is no storage overlay, I am just looking
> > for guidance how to debug this
>
> Two basic approaches: Top Down and Bottom Up. Start at the bottom -
> what is the failing address causing your PIC 10? Does it look
> plausible for the AMODE you're in at the time? Which instruction
> actually failed? Is the failing address (or a near or left-truncated
> version of it) in a register?
>
> Etc...
>
> If that hasn't made the problem obvious, then you may have collected
> enough information to work from the top down. If it's true that the
> ESTAE is provoking the failure, then what does it change, i.e. how
> could anything it does affect the result of calling IKJPARS?
>
> Etc...
>
> Tony H.
>
> --
> 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: Mysterious S0C4 pic 10

[Tony Harminc]

On Mon, 11 Sept 2023 at 09:33, Joseph Reichman  wrote:

> I have the following lines of code which basically sets up the parameter
> list to an ESTAE and calls it

> Later on when I populate Parse Parameter list   and call IKJPARS I get a
> s0c4 pic 10 right after the BALR

There's no BALR in the code snippets you've shown. I'll assume you mean BASR.

> When  I comment out the code below (that sets up the ESTAE parameter list)
> everything with PARS works great
> I check and double checked there is no storage overlay, I am just looking
> for guidance how to debug this

Two basic approaches: Top Down and Bottom Up. Start at the bottom -
what is the failing address causing your PIC 10? Does it look
plausible for the AMODE you're in at the time? Which instruction
actually failed? Is the failing address (or a near or left-truncated
version of it) in a register?

Etc...

If that hasn't made the problem obvious, then you may have collected
enough information to work from the top down. If it's true that the
ESTAE is provoking the failure, then what does it change, i.e. how
could anything it does affect the result of calling IKJPARS?

Etc...

Tony H.

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

Re: z/OSMF and the Old Timer

[Kurt Quackenbush]

> I have several ideas that I have to consider.
> -- Changing the names of my dlibs to have unique names.  This should allow 
> co-existence in my current MCAT.  (Possibly just adding a HLQ like the old 
> ServerPac 
> days).  Downside is the eventual recataloging after z/OS V2R5 goes live.
> -- Fully implement indirect cataloging for the Dlib volumes.  (This could end 
> up causing system PARMLIB changes and IPLs just to get an install done)
> -- Uncataloging all of my current Dlibs from my production environment (The 
> guy doing a maintenance cycle now will not be happy)
>
> Any suggestions?

I can't think of anything else besides the options you mention.  Sorry.

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,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Storage questions - mod9, mod27, mod54

[Pommier, Rex]

Hi Linda,

"A question"???  I see 9 of them!  LOL

I intermixed my responses below.  I'm sure there are others out there who have 
more current info than I have but thought I'd get the conversation going.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Linda Hagedorn
Sent: Monday, September 11, 2023 9:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Storage questions - mod9, mod27, mod54

Hi, 

I hope you won't mind a storage question.  

We're running zOS 2.4 and have a smattering of volume sizes - mod9, mod27, 
mod54.  

I'd like to have all mod54's for Db2 and be prepared before going to the 
storage folks. 

1. Is storage virtual nowadays? Yes, it's probably been over 20 years since 
the last "real" 3390 was supported.
2. Can virtual mod9s and mod27s be reconfigured to mod54s?Yes
3. Does the reconfiguration require an IPL?   This is a better question for 
your hardware vendor but I would think not.
4. Does the reconfiguration new addressing in IODF?This is a better 
question for your hardware vendor but I would think not.  We were able to 
remove some addresses from disk ranges to convert to PAV volumes without having 
to relabel the remaining volumes so I would think resizing volumes would be 
similar.
5. Is the storage vendor (IBM, EMC, etc.) relevant?  Shouldn't.
5a.  Does the hardware determine or be a factor in merging the mod9s/mod27s, 
into mod54s?  No, I've played with EMC, Hitachi, IBMN storage over the years 
and all have the capability.
6. Is it a given that the volumes must be cleared/emptied before the 
reconfiguration happens?   Unless things have change that I'm not aware of, yes 
- see below.
7. How long does reconfiguration take?  This is a better question for your 
hardware vendor, but it is going to depend on how many volumes you're creating 
etc.

Is there anything else I should consider before taking this request to the 
storage group?   Again, unless things have changed, I believe the entire string 
of volumes needs to be the same size.  Every time we've wanted to resize a 
string of volumes we've had to deconfigure the old volumes in the array, 
sending the storage back to free space, then rebuild the new volumes from free 
space.  

Any information or advice is appreciated.  

Thank you.  Linda Hagedorn 

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: Mysterious S0C4 pic 10

[Gord Tomlin]

On 2023-09-11 09:32 AM, Joseph Reichman wrote

Later on when I populate Parse Parameter list   and call IKJPARS I get a
s0c4 pic 10 right after the BALR

Does the PSW point right after the BALR, or elsewhere?

  XC ESTAED,ESTAED Clear ESTAE parameter list

You cleared an area named ESTAED



  ESTAE (R8),CT,PARAM=(R5),MF=(E,ESTAEL)

but used an area named ESTAEL (not shown in your code)


WORKAREA DSECT

  DS18F

SAVEEXIT DS18F

ABENDM   DSCL45

ESTAED   DSXL(RECVLEN) <--- storage are for ESTAE parameter list
Why not use ESTAE MF=L? Note that ESTAED as you have defined it is not 
aligned.


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

Storage questions - mod9, mod27, mod54

[Linda Hagedorn]

Hi, 

I hope you won't mind a storage question.  

We're running zOS 2.4 and have a smattering of volume sizes - mod9, mod27, 
mod54.  

I'd like to have all mod54's for Db2 and be prepared before going to the 
storage folks. 

1. Is storage virtual nowadays? 
2. Can virtual mod9s and mod27s be reconfigured to mod54s? 
3. Does the reconfiguration require an IPL?  
4. Does the reconfiguration new addressing in IODF?  
5. Is the storage vendor (IBM, EMC, etc.) relevant?  Does the hardware 
determine or be a factor in merging the mod9s/mod27s, into mod54s?
6. Is it a given that the volumes must be cleared/emptied before the 
reconfiguration happens?   
7. How long does reconfiguration take?  

Is there anything else I should consider before taking this request to the 
storage group? 

Any information or advice is appreciated.  

Thank you.  Linda Hagedorn

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

Mysterious S0C4 pic 10

[Joseph Reichman]

Hi 

 

I have the following lines of code which basically sets up the parameter
list to an ESTAE and calls it 

 

Later on when I populate Parse Parameter list   and call IKJPARS I get a
s0c4 pic 10 right after the BALR

When  I comment out the code below (that sets up the ESTAE parameter list)
everything with PARS works great

 

I check and double checked there is no storage overlay, I am just looking
for guidance how to debug this 

 

  Thank you

 

 XC ESTAED,ESTAED Clear ESTAE parameter list  

 LA R5,ESTAED 

 USING  RECVPARM,R5   

 MVCRECMOD,=CL8'TESTAUTR' 

 ST R3,RECENTRY   

 LARL   R5,ENDMOD 

 ST R5,RECEND 

 *   ST R9,RECCTLMD   

 MVCRECRTRY,=A(RETURN)

 LR R8,R0 

 *   LR R8,R0 

 ESTAE (R8),CT,PARAM=(R5),MF=(E,ESTAEL)   

 *   

 

  Rest of my code 

 

 

*

* check if the sub system is running 

*

 IEFSSI REQUEST=QUERY,   

   SUBNAME=TSTA, 

   WORKAREA=JSIPTR,  

   WORKASP=SP,   

   RETCODE=RETURN_CODE,  

   RSNCODE=RSNCODE,  

   MF=(E,IEFLST) 

*

 CLC   RETURN_CODE,=F'0'Q. IS TSTA SS THERE  

*BNE   RETURN

 

 

*   

  USING CPPL,R10 

  TITLE ' PARSE CONTROL LIST '   

  LAR1,MYPPL 

  USING PPL,R1   

  L R5,=A(MODPCL)

  STR5,PPLPCL

  LAR5,MYANSADDR OF ANSWER PLACE 

  STR5,PPLANS

  MVC   PPLCBUF(4),CPPLCBUF  

  MVC   PPLUPT,CPPLUPT   

 *MVC   PPLUPT,TSTUPT

  MVC   PPLECT,CPPLECT   

 *MVC   PPLECT,TSTECT

  LAR4,MYECBGET ADDR OF ECB  

  XCMYECB,MYECB  

  STR4,PPLECB

  LAR15,SAVEEXIT 

  STR15,PPLUWA   

  L R15,CVTPTR(,0)  POINT TO THE CVT 

  L R15,CVTPARS-CVT(,R15)   GET IKJPARS EP   

  BASR  R14,R15 CALL IKJPARS 

  LTR   R15,R15 RC FROM PARS OK  

 

 

 

WORKAREA DSECT  

 DS18F  

SAVEEXIT DS18F  

ABENDM   DSCL45 

ESTAED   DSXL(RECVLEN) <--- storage are for ESTAE parameter list


JSIPTR   DSA

TCB$ DSF

RB$  DSF

SRBA DSCL80 

LTOKEN   DSCL8  

DBWRDDSD

RETCODE  DSF

ASCBADDR DSF

SP   DSX

RETURN_CODE DS F

ALELST   ALESERV MF=L   

ALELEN   EQU   *-ALELST



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to