Re: [EXT] Re: zOS 2.4 migration guide

[Brian Westerman]

There is an APAR that provides a new setting (KCINDEX=N) that you use (after 
the first time you start zosmf), that keeps the i/o's down to a much more 
reasonable level.  Our clients that have small single frame systems (z13s, 
z14-rz1), find that it cuts the startup time by almost 40%. 

The official IBM speak is:

"With APAR PH06678, a new option "KCINDEX" is provided in IZUSVR. If 
"KCINDEX=N" is provided when starting IZUSVR, the embedded knowledge center 
will not build its index. As index is not rebuilt, startup time has 12% 
improvement. CPU usage has 24% improvement. I/O has 16% improvement. "

Remember, the first time you start it though it's going to be slow because you 
can't use the KCINDEX=N until after that first time.

Brian

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

Re: RACROUTE REQUEST=STAT and ACF2

[Gord Tomlin]

On 2019-10-28 21:09, Rob Schramm wrote:

If you have an ACF2 system, you can turn on SAF tracing and have it
formatted by SAF macro.  Jobname/STC filtering available.  Caution should
be used when using the tracing.


Thanks Rob. I don't have an ACF2 system, but I might be able to get the 
customer to run the trace.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: RACROUTE REQUEST=STAT and ACF2

[Gord Tomlin]

On 2019-10-28 21:01, Jon Perryman wrote:

You can easily send a small assembler program that issues this racroute stat 
and issue WTO TEXT= to display the results. Don't bother converting hex to 
display format in the WTO. WTO doesn't care if you include hex data in the 
message text. Use SDSF SE (Select Edit) for the joblog and turn hex on to see 
the hex data.

I would also suggest testing for class "BADCLASS" because it's unlikely to be a 
valid class. Also verify if RACROUTE must run authorized.

If both have RC=0 and REASON=0, then report the problem to CA. If only BADCLASS 
fails, then have the customer list the active classes for ACF2. If both fail, 
then you have some other problem.


Thanks Jon, exactly what I was considering as my next step if I couldn't 
get an answer.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: DCOLLECT use of KB/MB

[Mike Schwab]

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idai200/dcxmp1.htm

http://publibz.boulder.ibm.com/epubs/pdf/dgt3i201.pdf

Appendix F DCollect output
Record Type V VOLUME Printed page 478+ PDF page 504+.

Offset 121 x'79' is x'80' when EAV and capacity is stated in MB, Is
x'00' when non-EAV and capacity is stated in KB.
Offset 36 (free), 40 (allocated), 44 (total) is 4 bytes binary
capacity.  Non-EAV about 56 (KB) is one track and it uses the exact
byte count from the capacity table then divides and will jump.  So
dividing by 56 will cause jumps and suggest adding 1 before dividing
for a report in number of tracks.

On Mon, Oct 28, 2019 at 8:32 PM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Mon, 28 Oct 2019 16:22:34 -0500, Mike Schwab wrote:
>
> >Power of 2.  Number of cylinders is another field.
> >
> Citation needed.
>
> >On Mon, Oct 28, 2019 at 4:12 PM Steve Smith wrote:
> >>
> >>  What does "kilobytes" and "megabytes" mean to DCOLLECT, specifically, type
> >> "V" (volume) records in the values it shows for volume capacity, and
> >> several related fields?  i.e. does KB=1000 or KB=1024?  After spending
> >> considerable time perusing the fine manual, I haven't seen a hint.
> >>
> >> btw, my attempt to search the list on https://listserv.ua.edu/cgi-bin/wa
> >> returned nothing for any term I tried (including 'MVS').
> >>
> That's 1,048,576 VSes.
>
> -- gil
>
> --
> 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: Return code X'20' 32 from CELQPIPI INIT_MAIN

[Joseph Reichman]

The listing has the SYSSTATE  set AMODE 64
The  LISTPSW  indicates botH the EA and BA BITS of the PSW as one indicating 
AMODE 64 at location F8 right before the call CELQPIPI


  CEEWQPIP: LOADing CELQPIPI 
CEEWQPIP: Doing CELQPIPI INIT_MAIN 
IKJ57024I AT +F6   
TEST   
istpsw 
IKJ57652I PSW LOCATED AT 8BA068
  XRXXXTIE   KEY  XMWP  AS CC  PROGMASK  EA BA  INSTR ADDR 
  01118   1101  00 00   1  1   1F7010F6 
 
TEST   
t +f8  
TEST   
o  
CEEWQLOD: Called to LOAD "TEST64A "
IKJ57024I AT +F8   
TEST   
   
The program is AMODE 64

 TEST64A0D30   0001D6   0064  ANY

This is a listing of the table
+CEEXPTBL DCCL8'CELQPTBL'Eyecatcher 
+ DCA(CELQPIT0058)   Number of e
+ DCF'16'Entry size 
+ DCF'100'   Version
ice routines

  Source Statement  HLASM R6
+ DCAL1(0)  
+ DC3X'00'  
   CELQPITY TEST64A,0 ically load CE
+ DCCL8'TEST64A' Name, set t
+ DCAD(0)Load dblwd 
   CELQPITS , End of CELQPIP
+CELQPIT0058 EQU 1   Number of e
 *  
Here is the listing of TEST64A

TEST64A  CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A  
 YREGS  
*LOAD  EP=CEETEST   
*LRR15,R0   
*BASR  R14,R15  
 CELQCALL opendata,(SYSADATA),WORKREG=10
 XR  R15,R15
 CELQEPLG   
SYSADATA DC CL8'SYSADATA'   
*CEEPDDA opendata,SCOPE=IMPORT  
PARM1DC A(COMMANDS) 
PARM2DC A(FEEDBACK) 

Here is the link 
For TEST64A

//*  
//* LINK EDIT THE PROGRAM *  
//*  
//STEP0200 EXEC PGM=IEWL,COND=(0,LT,STEP0100),   
// PARM='AMODE(64),LIST,MAP,XREF,CASE=MIXED,DYNAM=DLL'   
//SYSPRINT DD SYSOUT=*   
//SYSDEFSD DD SYSOUT=*   
//OBJ  DD DSN=&&HEXOBJ,DISP=(OLD,PASS)   
//SYSLIB   DD DISP=SHR,DSN=IBMUSER.DBGR.DLLLIB   
// DD DISP=SHR,DSN=CEE.SCEEBND2  
// DD DISP=SHR,DSN=CEE.SCEELKED  
//SYSLMOD  DD DISP=SHR,DSN=IBMUSER.DBGR.DLLLIB   
//SYSUT1   DD UNIT=SYSDA,SPACE=(CYL,(3,2)),DSN=&SYSUT1   
//SYSPRINT DD SYSOUT=*,DCB=(RECFM=FB,BLKSIZE=3509)   
//SYSLIN   DD *  
  IMPORT CODE64,'SYSADATA','opendata'
  INCLUDE OBJ(TEST64A)   
  ENTRY TEST64A  
  NAME TEST64A(R)
 




  84 *
  85 
**
  86 *
 07B0 87 CEEWQPIP CSECT,
  88 CEEWQPIP AMODE64
   

Re: DCOLLECT use of KB/MB

[Paul Gilmartin]

On Mon, 28 Oct 2019 16:22:34 -0500, Mike Schwab wrote:

>Power of 2.  Number of cylinders is another field.
> 
Citation needed.

>On Mon, Oct 28, 2019 at 4:12 PM Steve Smith wrote:
>>
>>  What does "kilobytes" and "megabytes" mean to DCOLLECT, specifically, type
>> "V" (volume) records in the values it shows for volume capacity, and
>> several related fields?  i.e. does KB=1000 or KB=1024?  After spending
>> considerable time perusing the fine manual, I haven't seen a hint.
>>
>> btw, my attempt to search the list on https://listserv.ua.edu/cgi-bin/wa
>> returned nothing for any term I tried (including 'MVS').
>> 
That's 1,048,576 VSes.

-- gil

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

Re: RACROUTE REQUEST=STAT and ACF2

[Rob Schramm]

If you have an ACF2 system, you can turn on SAF tracing and have it
formatted by SAF macro.  Jobname/STC filtering available.  Caution should
be used when using the tracing.

Rob Schramm

On Mon, Oct 28, 2019, 21:03 Jon Perryman  wrote:

>  You can easily send a small assembler program that issues this racroute
> stat and issue WTO TEXT= to display the results. Don't bother converting
> hex to display format in the WTO. WTO doesn't care if you include hex data
> in the message text. Use SDSF SE (Select Edit) for the joblog and turn hex
> on to see the hex data.
>
> I would also suggest testing for class "BADCLASS" because it's unlikely to
> be a valid class. Also verify if RACROUTE must run authorized.
>
> If both have RC=0 and REASON=0, then report the problem to CA. If only
> BADCLASS fails, then have the customer list the active classes for ACF2. If
> both fail, then you have some other problem.
>
> Jon.
>
> On Monday, October 28, 2019, 08:00:57 AM PDT, Gord Tomlin <
> gt.ibm.li...@actionsoftware.com> wrote:
>
>  We have recently had a problem reported to us by a customer who runs
> ACF2. In our products, we check for the presence of a resource class
> "$MZCA" using:
>
>   RACROUTE REQUEST=STAT,WORKA=RACFWA,RELEASE=1.9,CLASS=$MZCA,
> DECOUPL=YES,
> MF=(E,LSTAT)
>   .
>   .
>   .
> $MZCADCCL8'$MZCA'
>
> On this customer's system, RACROUTE REQUEST=STAT returns with SAF return
> code 0 ("RACROUTE REQUEST=STAT has completed successfully"), RACF return
> code 0 ("RACF is active and the class (specified in CLASS= or returned
> in NEXT=) is active"), and RACF reason code 0.
>
> However the customer says that, without doubt, the $MZCA class does not
> exist in the ACF2 CLASMAP for that system.
>
> I have not been able to locate/access any information on ACF2 return
> codes for RACROUTE REQUEST=STAT. Is there any condition where ACF2 would
> return an indication that a resource class is active when the resource
> class does not actually exist?
>
> Thanks!
>
> --
>
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
> Support: https://actionsoftware.com/support/
>
> --
> 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: RACROUTE REQUEST=STAT and ACF2

[Jon Perryman]

 You can easily send a small assembler program that issues this racroute stat 
and issue WTO TEXT= to display the results. Don't bother converting hex to 
display format in the WTO. WTO doesn't care if you include hex data in the 
message text. Use SDSF SE (Select Edit) for the joblog and turn hex on to see 
the hex data.

I would also suggest testing for class "BADCLASS" because it's unlikely to be a 
valid class. Also verify if RACROUTE must run authorized.

If both have RC=0 and REASON=0, then report the problem to CA. If only BADCLASS 
fails, then have the customer list the active classes for ACF2. If both fail, 
then you have some other problem.

Jon.

On Monday, October 28, 2019, 08:00:57 AM PDT, Gord Tomlin 
 wrote:  
 
 We have recently had a problem reported to us by a customer who runs 
ACF2. In our products, we check for the presence of a resource class 
"$MZCA" using:

          RACROUTE REQUEST=STAT,WORKA=RACFWA,RELEASE=1.9,CLASS=$MZCA,
                DECOUPL=YES,
                MF=(E,LSTAT)
          .
          .
          .
$MZCA    DC    CL8'$MZCA'

On this customer's system, RACROUTE REQUEST=STAT returns with SAF return 
code 0 ("RACROUTE REQUEST=STAT has completed successfully"), RACF return 
code 0 ("RACF is active and the class (specified in CLASS= or returned 
in NEXT=) is active"), and RACF reason code 0.

However the customer says that, without doubt, the $MZCA class does not 
exist in the ACF2 CLASMAP for that system.

I have not been able to locate/access any information on ACF2 return 
codes for RACROUTE REQUEST=STAT. Is there any condition where ACF2 would 
return an indication that a resource class is active when the resource 
class does not actually exist?

Thanks!

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

--
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: Return code X'20' 32 from CELQPIPI INIT_MAIN

[Jon Perryman]

 The CALL macro supports 32 and 64 bit parm addresses. I believe it defaults to 
32 bit and the SYSSTATE macro is used to change it. Does CELQPITY require 64 
bit parm list? If so, make sure you have SYSSTATE prior to the call. Also make 
sure SYSSTATE is before the CALL MF=L.

I've never used TEST so I'm not familiar with the specifics. Your listing below 
seems to show it running the program with AMODE=31 and the L commands only 
display fullwords. Did you switch to AMODE64 before calling CELQPITY? 


Jon.

On Monday, October 28, 2019, 05:08:58 PM PDT, Joseph Reichman 
 wrote:  
 
 Just tried it with the service_rtns parm exactly as it was in the sample with 
the exception 
That the CELQPITY points to my 64 bit assembler program TEST64A  program and do 
X'20' DECIMAL 32
                                                                        
      CALL  (15),                                                               
               X  
            (INIT_MAIN,              CELQPIPI INIT_MAIN request    X  
            CEEXPTBL_ADDR,          Address of CELQPIPI table      X  
            SERVICE_RTNS,            Address of service rtn vector    X  
            TOKEN),                  Token from INIT_MAIN                      
X  
            MF=(E,CALL_PL)                                              
                                                                        
I traced the CEEWQLOAD it loaded TEST64A which had bit 63 as a one
 After the load

  IKJ57382I ENTRY POINT AT 1F790140    AMODE=31  
 TEST                                            
L +F6                                            
      +F6  05EFB902                            
 TEST                                            
AT +F6                                          
 TEST                                            
AT +F8                                          
 TEST                                            
GO                                              
 CEEWQPIP: LOADing CELQPIPI                      
 CEEWQPIP: Doing CELQPIPI INIT_MAIN              
 IKJ57024I AT +F6                                
 TEST                                            
GO                                              
 CEEWQLOD: Called to LOAD "TEST64A "            
 IKJ57024I AT +F8                                
 TEST                                            
L 15R                                            
 15R  0020   

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

Re: DCOLLECT use of KB/MB

[Edward Finnell]

The listserv search has been dinged for a while. If you go in to the main page 
and get the list of archives by month then there's a search box on right with 
advanced options above it. Enter dcollect as string and since 1 jan 2015 get 88 
hits. Don't know who's minding the store...

In a message dated 10/28/2019 6:21:21 PM Central Standard Time, 
mike.a.sch...@gmail.com writes:
> btw, my attempt to search the list on https://listserv.ua.edu/cgi-bin/wa> 
> returned nothing for any term I tried (including 'MVS').>

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

Re: SVC dump data set layout

[Steve Horein]

Thank you all for the great suggestions -

> I'll check out IHAPRD (and others!) for sure, and discuss updating data
set naming conventions with the MVS guys.
As far as DISPLAY DUMP command, D D,E,DSN=ALL is executed in an effort to
get useful information if/when it's available. NetView PIPEs provide some
pretty useful parsing options, so matching data set names with related
information from the display isn't too difficult. It just seems that
sometimes data sets on disk get "orphaned" and don't have corresponding
information in the command output.

Thanks again!

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

Re: Return code X'20' 32 from CELQPIPI INIT_MAIN

[Joseph Reichman]

Just tried it with the service_rtns parm exactly as it was in the sample with 
the exception 
That the CELQPITY points to my 64 bit assembler program TEST64A  program and do 
X'20' DECIMAL 32
 
   CALL  (15),  
X   
 (INIT_MAIN,  CELQPIPI INIT_MAIN request X   
 CEEXPTBL_ADDR,   Address of CELQPIPI table  X   
 SERVICE_RTNS,Address of service rtn vectorX   
 TOKEN),  Token from INIT_MAIN  
 X   
 MF=(E,CALL_PL)  
 
I traced the CEEWQLOAD it loaded TEST64A which had bit 63 as a one
 After the load

  IKJ57382I ENTRY POINT AT 1F790140AMODE=31   
 TEST
L +F6
   +F6  05EFB902 
 TEST
AT +F6   
 TEST
AT +F8   
 TEST
GO   
 CEEWQPIP: LOADing CELQPIPI  
 CEEWQPIP: Doing CELQPIPI INIT_MAIN  
 IKJ57024I AT +F6
 TEST
GO   
 CEEWQLOD: Called to LOAD "TEST64A " 
 IKJ57024I AT +F8
 TEST
L 15R
 15R  0020   
 *** 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
scott Ford
Sent: Monday, October 28, 2019 8:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN

Joe R.,

Look for the example on Google for Share.org, called Trimodal Assembler..
It has a pretty good example of 31bit and 64bit Assembler calls.

Scott

On Mon, Oct 28, 2019 at 8:54 AM scott Ford  wrote:

> Joe R.
>
> You have to establish the Assembler environment is correct 64bit prior 
> to the LE calls.
>
> Scott
>
> On Sun, Oct 27, 2019 at 11:09 PM Joe Monk  wrote:
>
>> You have to do the setup the way it is in the example
>>
>> Joe
>>
>>
>> Joe
>>
>>
>> On Sun, Oct 27, 2019 at 9:27 PM Joseph Reichman 
>> 
>> wrote:
>>
>> > So you are saying using the service routines would make the 
>> > difference
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List  On
>> Behalf
>> > Of scott Ford
>> > Sent: Sunday, October 27, 2019 8:52 PM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
>> >
>> > Exactly,
>> >
>> > CSECT, SAM ..etc
>> >
>> > On Sun, Oct 27, 2019 at 8:37 PM Joe Monk  wrote:
>> >
>> > > You seem to be missing a bunch ...
>> > >
>> > > Look at this example:
>> > >
>> > >
>> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.z
>> o
>> > > s.v2r1.ceeam00/coreyex.htm
>> > >
>> > > Joe
>> > >
>> > > On Sun, Oct 27, 2019 at 7:03 PM Joseph Reichman 
>> > > 
>> > > wrote:
>> > >
>> > > > Here is all the relevant code besides the assemble and link but 
>> > > > its
>> > > AMOD64
>> > > > RMODE ANY
>> > > >
>> > > > Thanks
>> > > >
>> > > > *
>> > > >
>> > > >  LGR15,CELQPIPI_EP  Address of CELQPIPI E.P.
>> > > > *
>> > > >
>> > > >  CALL  (15),
>> >  X
>> > > >(INIT_SUB,   CELQPIPI INIT_MAIN request
>> >  X
>> > > >CEEXPTBL_ADDR,   Address of CELQPIPI table
>> > X
>> > > >0,   Address of service rtn
>> vector
>> > X
>> > > >TOKEN),  Token from INIT_MAIN
>> >  X
>> > > >MF=(E,CALL_PL)
>> > > > *
>> > > >
>> > > > INIT_MAIN DC   F'1'
>> > > > INIT_SUB  DC   F'3'
>> > > > CALL_MAIN DC   F'2'
>> > > > CALL_SUB  DC   F'4'
>> > > > TERM  DC   F'5'
>> > > >
>> > > > CEEXPTBL_ADDR DC   AD(CEEXPTBL)  Address of PIPI table
>> > > > CEEXPTL_INDEX DC   AD(0) 1st row of CEEXPTBL = 0
>> > > > *
>> > > > CEEXPTBL  CELQPIT  ,
>> > > >   CELQPITY TEST64A,0   am
>> > > >   CELQPITS ,
>> > > > *
>> > > > TEST64A  CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A
>> > > >   YREGS
>> > > >  *LOAD  EP=CEETEST
>> > > >  *LRR15,R0
>> > > >  *BASR  R14,R15
>> > > >   CELQCALL opendata,(SYSADATA),WORKREG=10
>> > > >   XR  R15,R15
>> > > >   CELQEPLG
>> > > > -Original Message-
>>

Re: DCOLLECT use of KB/MB

[Mike Schwab]

Power of 2.  Number of cylinders is another field.

On Mon, Oct 28, 2019 at 4:12 PM Steve Smith  wrote:
>
>  What does "kilobytes" and "megabytes" mean to DCOLLECT, specifically, type
> "V" (volume) records in the values it shows for volume capacity, and
> several related fields?  i.e. does KB=1000 or KB=1024?  After spending
> considerable time perusing the fine manual, I haven't seen a hint.
>
> btw, my attempt to search the list on https://listserv.ua.edu/cgi-bin/wa
> returned nothing for any term I tried (including 'MVS').
>
> --
> sas
>
> --
> 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

DCOLLECT use of KB/MB

[Steve Smith]

 What does "kilobytes" and "megabytes" mean to DCOLLECT, specifically, type
"V" (volume) records in the values it shows for volume capacity, and
several related fields?  i.e. does KB=1000 or KB=1024?  After spending
considerable time perusing the fine manual, I haven't seen a hint.

btw, my attempt to search the list on https://listserv.ua.edu/cgi-bin/wa
returned nothing for any term I tried (including 'MVS').

-- 
sas

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

RACROUTE REQUEST=STAT and ACF2

[Gord Tomlin]

We have recently had a problem reported to us by a customer who runs 
ACF2. In our products, we check for the presence of a resource class 
"$MZCA" using:


 RACROUTE REQUEST=STAT,WORKA=RACFWA,RELEASE=1.9,CLASS=$MZCA,
   DECOUPL=YES,
   MF=(E,LSTAT)
 .
 .
 .
$MZCADCCL8'$MZCA'

On this customer's system, RACROUTE REQUEST=STAT returns with SAF return 
code 0 ("RACROUTE REQUEST=STAT has completed successfully"), RACF return 
code 0 ("RACF is active and the class (specified in CLASS= or returned 
in NEXT=) is active"), and RACF reason code 0.


However the customer says that, without doubt, the $MZCA class does not 
exist in the ACF2 CLASMAP for that system.


I have not been able to locate/access any information on ACF2 return 
codes for RACROUTE REQUEST=STAT. Is there any condition where ACF2 would 
return an indication that a resource class is active when the resource 
class does not actually exist?


Thanks!

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: Sample SMF records

[Pierre Fichaud]

Gord,
I get the following when I click on z Technical Information:

 Information Central - IBM Z ISVs
Requested Information is Unavailable

I think I have to register with IBM.
I have sent an email to ztech.
Thanks, Pierre.

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

Re: Return code X'20' 32 from CELQPIPI INIT_MAIN

[Joseph Reichman]

The program the driver is entered in amode 64 the example does SAM64 but that 
is not necessary 

I look at it again thanks for help 



Joe Reichman
170-10 73 rd ave 
Fresh meadows NY 11366

> On Oct 28, 2019, at 9:09 AM, scott Ford  wrote:
> 
> The example you provided was not , you have to set the mode in Assembler.
> Maybe a look at POP will help. The transition between 31bit and 64bit
> Assembler calls is major.
> 
> Scott
> 
>> On Mon, Oct 28, 2019 at 9:01 AM Joseph Reichman 
>> wrote:
>> 
>> The driver program is already in AMODE 64
>> So is TEST64A all the programs are RMODE 31 AMODE 64
>> 
>> I’ll re-vist this again in the afternoon thanks
>> 
>> 
>> 
>> Joe Reichman
>> 170-10 73 rd ave
>> Fresh meadows NY 11366
>> 
 On Oct 28, 2019, at 8:56 AM, scott Ford  wrote:
>>> 
>>> Joe R.,
>>> 
>>> Look for the example on Google for Share.org, called Trimodal Assembler..
>>> It has a pretty good example of 31bit and 64bit Assembler calls.
>>> 
>>> Scott
>>> 
 On Mon, Oct 28, 2019 at 8:54 AM scott Ford  wrote:
 
 Joe R.
 
 You have to establish the Assembler environment is correct 64bit prior
>> to
 the LE calls.
 
 Scott
 
> On Sun, Oct 27, 2019 at 11:09 PM Joe Monk  wrote:
> 
> You have to do the setup the way it is in the example
> 
> Joe
> 
> 
> Joe
> 
> 
> On Sun, Oct 27, 2019 at 9:27 PM Joseph Reichman >> 
> wrote:
> 
>> So you are saying using the service routines would make the difference
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
> Behalf
>> Of scott Ford
>> Sent: Sunday, October 27, 2019 8:52 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
>> 
>> Exactly,
>> 
>> CSECT, SAM ..etc
>> 
>> On Sun, Oct 27, 2019 at 8:37 PM Joe Monk  wrote:
>> 
>>> You seem to be missing a bunch ...
>>> 
>>> Look at this example:
>>> 
>>> 
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo
>>> s.v2r1.ceeam00/coreyex.htm
>>> 
>>> Joe
>>> 
>>> On Sun, Oct 27, 2019 at 7:03 PM Joseph Reichman
>>> 
>>> wrote:
>>> 
 Here is all the relevant code besides the assemble and link but its
>>> AMOD64
 RMODE ANY
 
 Thanks
 
 *
 
LGR15,CELQPIPI_EP  Address of CELQPIPI E.P.
 *
 
CALL  (15),
>> X
  (INIT_SUB,   CELQPIPI INIT_MAIN request
>> X
  CEEXPTBL_ADDR,   Address of CELQPIPI table
>> X
  0,   Address of service rtn
> vector
>> X
  TOKEN),  Token from INIT_MAIN
>> X
  MF=(E,CALL_PL)
 *
 
 INIT_MAIN DC   F'1'
 INIT_SUB  DC   F'3'
 CALL_MAIN DC   F'2'
 CALL_SUB  DC   F'4'
 TERM  DC   F'5'
 
 CEEXPTBL_ADDR DC   AD(CEEXPTBL)  Address of PIPI table
 CEEXPTL_INDEX DC   AD(0) 1st row of CEEXPTBL = 0
 *
 CEEXPTBL  CELQPIT  ,
 CELQPITY TEST64A,0   am
 CELQPITS ,
 *
 TEST64A  CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A
 YREGS
 *LOAD  EP=CEETEST
 *LRR15,R0
 *BASR  R14,R15
 CELQCALL opendata,(SYSADATA),WORKREG=10
 XR  R15,R15
 CELQEPLG
 -Original Message-
 From: IBM Mainframe Discussion List  On
 Behalf Of Joe Monk
 Sent: Sunday, October 27, 2019 7:53 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
 
 Where are your calls to CELQPIPI?
 
 Joe
 
 On Sun, Oct 27, 2019 at 6:05 PM Joseph Reichman
 mailto:reichman...@gmail.com> >
 wrote:
 
> AMODE 64 rmode  any
> 
> BROWSEIBMUSER.DBGR.DLLLIB   Row
> 022
>>> of
> 022
> Command ===>
> Scroll
 ===>
> CSR
>   Name PromptAlias-of Size  TTR
> AC
>>> AM
> RM
> _ TEST64A0D30   0001BD
> 00
> 64  ANY
>  **End**
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List > >>> IBM-MAIN@LISTSERV.UA.EDU> > On
> Behalf Of scott Ford
> Sent: Sunday, October 27, 2019 7:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Return code X'20' 32 from CELQPIPI

Re: Return code X'20' 32 from CELQPIPI INIT_MAIN

[scott Ford]

The example you provided was not , you have to set the mode in Assembler.
Maybe a look at POP will help. The transition between 31bit and 64bit
Assembler calls is major.

Scott

On Mon, Oct 28, 2019 at 9:01 AM Joseph Reichman 
wrote:

> The driver program is already in AMODE 64
> So is TEST64A all the programs are RMODE 31 AMODE 64
>
> I’ll re-vist this again in the afternoon thanks
>
>
>
> Joe Reichman
> 170-10 73 rd ave
> Fresh meadows NY 11366
>
> > On Oct 28, 2019, at 8:56 AM, scott Ford  wrote:
> >
> > Joe R.,
> >
> > Look for the example on Google for Share.org, called Trimodal Assembler..
> > It has a pretty good example of 31bit and 64bit Assembler calls.
> >
> > Scott
> >
> >> On Mon, Oct 28, 2019 at 8:54 AM scott Ford  wrote:
> >>
> >> Joe R.
> >>
> >> You have to establish the Assembler environment is correct 64bit prior
> to
> >> the LE calls.
> >>
> >> Scott
> >>
> >>> On Sun, Oct 27, 2019 at 11:09 PM Joe Monk  wrote:
> >>>
> >>> You have to do the setup the way it is in the example
> >>>
> >>> Joe
> >>>
> >>>
> >>> Joe
> >>>
> >>>
> >>> On Sun, Oct 27, 2019 at 9:27 PM Joseph Reichman  >
> >>> wrote:
> >>>
>  So you are saying using the service routines would make the difference
> 
>  -Original Message-
>  From: IBM Mainframe Discussion List  On
> >>> Behalf
>  Of scott Ford
>  Sent: Sunday, October 27, 2019 8:52 PM
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
> 
>  Exactly,
> 
>  CSECT, SAM ..etc
> 
>  On Sun, Oct 27, 2019 at 8:37 PM Joe Monk  wrote:
> 
> > You seem to be missing a bunch ...
> >
> > Look at this example:
> >
> >
> >>> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo
> > s.v2r1.ceeam00/coreyex.htm
> >
> > Joe
> >
> > On Sun, Oct 27, 2019 at 7:03 PM Joseph Reichman
> > 
> > wrote:
> >
> >> Here is all the relevant code besides the assemble and link but its
> > AMOD64
> >> RMODE ANY
> >>
> >> Thanks
> >>
> >> *
> >>
> >> LGR15,CELQPIPI_EP  Address of CELQPIPI E.P.
> >> *
> >>
> >> CALL  (15),
>  X
> >>   (INIT_SUB,   CELQPIPI INIT_MAIN request
>  X
> >>   CEEXPTBL_ADDR,   Address of CELQPIPI table
>  X
> >>   0,   Address of service rtn
> >>> vector
>  X
> >>   TOKEN),  Token from INIT_MAIN
>  X
> >>   MF=(E,CALL_PL)
> >> *
> >>
> >> INIT_MAIN DC   F'1'
> >> INIT_SUB  DC   F'3'
> >> CALL_MAIN DC   F'2'
> >> CALL_SUB  DC   F'4'
> >> TERM  DC   F'5'
> >>
> >> CEEXPTBL_ADDR DC   AD(CEEXPTBL)  Address of PIPI table
> >> CEEXPTL_INDEX DC   AD(0) 1st row of CEEXPTBL = 0
> >> *
> >> CEEXPTBL  CELQPIT  ,
> >>  CELQPITY TEST64A,0   am
> >>  CELQPITS ,
> >> *
> >> TEST64A  CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A
> >>  YREGS
> >> *LOAD  EP=CEETEST
> >> *LRR15,R0
> >> *BASR  R14,R15
> >>  CELQCALL opendata,(SYSADATA),WORKREG=10
> >>  XR  R15,R15
> >>  CELQEPLG
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Joe Monk
> >> Sent: Sunday, October 27, 2019 7:53 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
> >>
> >> Where are your calls to CELQPIPI?
> >>
> >> Joe
> >>
> >> On Sun, Oct 27, 2019 at 6:05 PM Joseph Reichman
> >> mailto:reichman...@gmail.com> >
> >> wrote:
> >>
> >>> AMODE 64 rmode  any
> >>>
> >>>  BROWSEIBMUSER.DBGR.DLLLIB   Row
> >>> 022
> > of
> >>> 022
> >>> Command ===>
> >>> Scroll
> >> ===>
> >>> CSR
> >>>Name PromptAlias-of Size  TTR
> >>> AC
> > AM
> >>> RM
> >>> _ TEST64A0D30   0001BD
> >>> 00
> >>> 64  ANY
> >>>   **End**
> >>>
> >>>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List    >> IBM-MAIN@LISTSERV.UA.EDU> > On
> >>> Behalf Of scott Ford
> >>> Sent: Sunday, October 27, 2019 7:02 PM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU 
> >>> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
> >>>
> >>> And what AMODE and RMODE is the Assembler code ?
> >>>
> >>> On Sun, Oct 27, 2019 at 6:55 PM Joseph Reichman
> >>> mailto:reichman...@gmail.com> >
> >>> wrote:
> >>>
>  The doc says
> 
> 
>  • Application program support runni

Re: Return code X'20' 32 from CELQPIPI INIT_MAIN

[Joseph Reichman]

The driver program is already in AMODE 64 
So is TEST64A all the programs are RMODE 31 AMODE 64

I’ll re-vist this again in the afternoon thanks 



Joe Reichman
170-10 73 rd ave 
Fresh meadows NY 11366

> On Oct 28, 2019, at 8:56 AM, scott Ford  wrote:
> 
> Joe R.,
> 
> Look for the example on Google for Share.org, called Trimodal Assembler..
> It has a pretty good example of 31bit and 64bit Assembler calls.
> 
> Scott
> 
>> On Mon, Oct 28, 2019 at 8:54 AM scott Ford  wrote:
>> 
>> Joe R.
>> 
>> You have to establish the Assembler environment is correct 64bit prior to
>> the LE calls.
>> 
>> Scott
>> 
>>> On Sun, Oct 27, 2019 at 11:09 PM Joe Monk  wrote:
>>> 
>>> You have to do the setup the way it is in the example
>>> 
>>> Joe
>>> 
>>> 
>>> Joe
>>> 
>>> 
>>> On Sun, Oct 27, 2019 at 9:27 PM Joseph Reichman 
>>> wrote:
>>> 
 So you are saying using the service routines would make the difference
 
 -Original Message-
 From: IBM Mainframe Discussion List  On
>>> Behalf
 Of scott Ford
 Sent: Sunday, October 27, 2019 8:52 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
 
 Exactly,
 
 CSECT, SAM ..etc
 
 On Sun, Oct 27, 2019 at 8:37 PM Joe Monk  wrote:
 
> You seem to be missing a bunch ...
> 
> Look at this example:
> 
> 
>>> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo
> s.v2r1.ceeam00/coreyex.htm
> 
> Joe
> 
> On Sun, Oct 27, 2019 at 7:03 PM Joseph Reichman
> 
> wrote:
> 
>> Here is all the relevant code besides the assemble and link but its
> AMOD64
>> RMODE ANY
>> 
>> Thanks
>> 
>> *
>> 
>> LGR15,CELQPIPI_EP  Address of CELQPIPI E.P.
>> *
>> 
>> CALL  (15),
 X
>>   (INIT_SUB,   CELQPIPI INIT_MAIN request
 X
>>   CEEXPTBL_ADDR,   Address of CELQPIPI table
 X
>>   0,   Address of service rtn
>>> vector
 X
>>   TOKEN),  Token from INIT_MAIN
 X
>>   MF=(E,CALL_PL)
>> *
>> 
>> INIT_MAIN DC   F'1'
>> INIT_SUB  DC   F'3'
>> CALL_MAIN DC   F'2'
>> CALL_SUB  DC   F'4'
>> TERM  DC   F'5'
>> 
>> CEEXPTBL_ADDR DC   AD(CEEXPTBL)  Address of PIPI table
>> CEEXPTL_INDEX DC   AD(0) 1st row of CEEXPTBL = 0
>> *
>> CEEXPTBL  CELQPIT  ,
>>  CELQPITY TEST64A,0   am
>>  CELQPITS ,
>> *
>> TEST64A  CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A
>>  YREGS
>> *LOAD  EP=CEETEST
>> *LRR15,R0
>> *BASR  R14,R15
>>  CELQCALL opendata,(SYSADATA),WORKREG=10
>>  XR  R15,R15
>>  CELQEPLG
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
>> Behalf Of Joe Monk
>> Sent: Sunday, October 27, 2019 7:53 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
>> 
>> Where are your calls to CELQPIPI?
>> 
>> Joe
>> 
>> On Sun, Oct 27, 2019 at 6:05 PM Joseph Reichman
>> mailto:reichman...@gmail.com> >
>> wrote:
>> 
>>> AMODE 64 rmode  any
>>> 
>>>  BROWSEIBMUSER.DBGR.DLLLIB   Row
>>> 022
> of
>>> 022
>>> Command ===>
>>> Scroll
>> ===>
>>> CSR
>>>Name PromptAlias-of Size  TTR
>>> AC
> AM
>>> RM
>>> _ TEST64A0D30   0001BD
>>> 00
>>> 64  ANY
>>>   **End**
>>> 
>>> 
>>> -Original Message-
>>> From: IBM Mainframe Discussion List >>> > IBM-MAIN@LISTSERV.UA.EDU> > On
>>> Behalf Of scott Ford
>>> Sent: Sunday, October 27, 2019 7:02 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU 
>>> Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
>>> 
>>> And what AMODE and RMODE is the Assembler code ?
>>> 
>>> On Sun, Oct 27, 2019 at 6:55 PM Joseph Reichman
>>> mailto:reichman...@gmail.com> >
>>> wrote:
>>> 
 The doc says
 
 
 • Application program support running in the PreInit
>>> environment.
 The PreInit table contains the names and entry point addresses
 of each routine that can be executed within the PreInit
 environment.
 The applications defined in the PreInit table must be able to
 run as AMODE
 64 (with XPLINK implied).
 Languages Supported:
 – C
 – C++
 – Assembler (64-bit Language Environment-conforming assembler)
 
 So when I have entry in the following table (CEEXPTBL) where
>>>

Re: Return code X'20' 32 from CELQPIPI INIT_MAIN

[scott Ford]

Joe R.,

Look for the example on Google for Share.org, called Trimodal Assembler..
It has a pretty good example of 31bit and 64bit Assembler calls.

Scott

On Mon, Oct 28, 2019 at 8:54 AM scott Ford  wrote:

> Joe R.
>
> You have to establish the Assembler environment is correct 64bit prior to
> the LE calls.
>
> Scott
>
> On Sun, Oct 27, 2019 at 11:09 PM Joe Monk  wrote:
>
>> You have to do the setup the way it is in the example
>>
>> Joe
>>
>>
>> Joe
>>
>>
>> On Sun, Oct 27, 2019 at 9:27 PM Joseph Reichman 
>> wrote:
>>
>> > So you are saying using the service routines would make the difference
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List  On
>> Behalf
>> > Of scott Ford
>> > Sent: Sunday, October 27, 2019 8:52 PM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
>> >
>> > Exactly,
>> >
>> > CSECT, SAM ..etc
>> >
>> > On Sun, Oct 27, 2019 at 8:37 PM Joe Monk  wrote:
>> >
>> > > You seem to be missing a bunch ...
>> > >
>> > > Look at this example:
>> > >
>> > >
>> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo
>> > > s.v2r1.ceeam00/coreyex.htm
>> > >
>> > > Joe
>> > >
>> > > On Sun, Oct 27, 2019 at 7:03 PM Joseph Reichman
>> > > 
>> > > wrote:
>> > >
>> > > > Here is all the relevant code besides the assemble and link but its
>> > > AMOD64
>> > > > RMODE ANY
>> > > >
>> > > > Thanks
>> > > >
>> > > > *
>> > > >
>> > > >  LGR15,CELQPIPI_EP  Address of CELQPIPI E.P.
>> > > > *
>> > > >
>> > > >  CALL  (15),
>> >  X
>> > > >(INIT_SUB,   CELQPIPI INIT_MAIN request
>> >  X
>> > > >CEEXPTBL_ADDR,   Address of CELQPIPI table
>> > X
>> > > >0,   Address of service rtn
>> vector
>> > X
>> > > >TOKEN),  Token from INIT_MAIN
>> >  X
>> > > >MF=(E,CALL_PL)
>> > > > *
>> > > >
>> > > > INIT_MAIN DC   F'1'
>> > > > INIT_SUB  DC   F'3'
>> > > > CALL_MAIN DC   F'2'
>> > > > CALL_SUB  DC   F'4'
>> > > > TERM  DC   F'5'
>> > > >
>> > > > CEEXPTBL_ADDR DC   AD(CEEXPTBL)  Address of PIPI table
>> > > > CEEXPTL_INDEX DC   AD(0) 1st row of CEEXPTBL = 0
>> > > > *
>> > > > CEEXPTBL  CELQPIT  ,
>> > > >   CELQPITY TEST64A,0   am
>> > > >   CELQPITS ,
>> > > > *
>> > > > TEST64A  CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A
>> > > >   YREGS
>> > > >  *LOAD  EP=CEETEST
>> > > >  *LRR15,R0
>> > > >  *BASR  R14,R15
>> > > >   CELQCALL opendata,(SYSADATA),WORKREG=10
>> > > >   XR  R15,R15
>> > > >   CELQEPLG
>> > > > -Original Message-
>> > > > From: IBM Mainframe Discussion List  On
>> > > > Behalf Of Joe Monk
>> > > > Sent: Sunday, October 27, 2019 7:53 PM
>> > > > To: IBM-MAIN@LISTSERV.UA.EDU
>> > > > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
>> > > >
>> > > > Where are your calls to CELQPIPI?
>> > > >
>> > > > Joe
>> > > >
>> > > > On Sun, Oct 27, 2019 at 6:05 PM Joseph Reichman
>> > > > mailto:reichman...@gmail.com> >
>> > > > wrote:
>> > > >
>> > > > > AMODE 64 rmode  any
>> > > > >
>> > > > >   BROWSEIBMUSER.DBGR.DLLLIB   Row
>> 022
>> > > of
>> > > > > 022
>> > > > >  Command ===>
>> Scroll
>> > > > ===>
>> > > > > CSR
>> > > > > Name PromptAlias-of Size  TTR
>>  AC
>> > >  AM
>> > > > >  RM
>> > > > >  _ TEST64A0D30   0001BD
>>  00
>> > > > > 64  ANY
>> > > > >**End**
>> > > > >
>> > > > >
>> > > > > -Original Message-
>> > > > > From: IBM Mainframe Discussion List > > > > > > IBM-MAIN@LISTSERV.UA.EDU> > On
>> > > > > Behalf Of scott Ford
>> > > > > Sent: Sunday, October 27, 2019 7:02 PM
>> > > > > To: IBM-MAIN@LISTSERV.UA.EDU 
>> > > > > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
>> > > > >
>> > > > > And what AMODE and RMODE is the Assembler code ?
>> > > > >
>> > > > > On Sun, Oct 27, 2019 at 6:55 PM Joseph Reichman
>> > > > > mailto:reichman...@gmail.com> >
>> > > > > wrote:
>> > > > >
>> > > > > > The doc says
>> > > > > >
>> > > > > >
>> > > > > > • Application program support running in the PreInit
>> environment.
>> > > > > > The PreInit table contains the names and entry point addresses
>> > > > > > of each routine that can be executed within the PreInit
>> > environment.
>> > > > > > The applications defined in the PreInit table must be able to
>> > > > > > run as AMODE
>> > > > > > 64 (with XPLINK implied).
>> > > > > > Languages Supported:
>> > > > > > – C
>> > > > > > – C++
>> > > > > > – Assembler (64-bit Language Environment-conforming assembler)
>> > > > > >
>> > > > > > So when I have entry in the following table (CEEXPTBL) where
>> > > > > > TEST64A is that’s C ptogram and use either I

Re: Return code X'20' 32 from CELQPIPI INIT_MAIN

[scott Ford]

Joe R.

You have to establish the Assembler environment is correct 64bit prior to
the LE calls.

Scott

On Sun, Oct 27, 2019 at 11:09 PM Joe Monk  wrote:

> You have to do the setup the way it is in the example
>
> Joe
>
>
> Joe
>
>
> On Sun, Oct 27, 2019 at 9:27 PM Joseph Reichman 
> wrote:
>
> > So you are saying using the service routines would make the difference
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of scott Ford
> > Sent: Sunday, October 27, 2019 8:52 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
> >
> > Exactly,
> >
> > CSECT, SAM ..etc
> >
> > On Sun, Oct 27, 2019 at 8:37 PM Joe Monk  wrote:
> >
> > > You seem to be missing a bunch ...
> > >
> > > Look at this example:
> > >
> > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo
> > > s.v2r1.ceeam00/coreyex.htm
> > >
> > > Joe
> > >
> > > On Sun, Oct 27, 2019 at 7:03 PM Joseph Reichman
> > > 
> > > wrote:
> > >
> > > > Here is all the relevant code besides the assemble and link but its
> > > AMOD64
> > > > RMODE ANY
> > > >
> > > > Thanks
> > > >
> > > > *
> > > >
> > > >  LGR15,CELQPIPI_EP  Address of CELQPIPI E.P.
> > > > *
> > > >
> > > >  CALL  (15),
> >  X
> > > >(INIT_SUB,   CELQPIPI INIT_MAIN request
> >  X
> > > >CEEXPTBL_ADDR,   Address of CELQPIPI table
> > X
> > > >0,   Address of service rtn vector
> > X
> > > >TOKEN),  Token from INIT_MAIN
> >  X
> > > >MF=(E,CALL_PL)
> > > > *
> > > >
> > > > INIT_MAIN DC   F'1'
> > > > INIT_SUB  DC   F'3'
> > > > CALL_MAIN DC   F'2'
> > > > CALL_SUB  DC   F'4'
> > > > TERM  DC   F'5'
> > > >
> > > > CEEXPTBL_ADDR DC   AD(CEEXPTBL)  Address of PIPI table
> > > > CEEXPTL_INDEX DC   AD(0) 1st row of CEEXPTBL = 0
> > > > *
> > > > CEEXPTBL  CELQPIT  ,
> > > >   CELQPITY TEST64A,0   am
> > > >   CELQPITS ,
> > > > *
> > > > TEST64A  CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,ENTNAME=TEST64A
> > > >   YREGS
> > > >  *LOAD  EP=CEETEST
> > > >  *LRR15,R0
> > > >  *BASR  R14,R15
> > > >   CELQCALL opendata,(SYSADATA),WORKREG=10
> > > >   XR  R15,R15
> > > >   CELQEPLG
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List  On
> > > > Behalf Of Joe Monk
> > > > Sent: Sunday, October 27, 2019 7:53 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
> > > >
> > > > Where are your calls to CELQPIPI?
> > > >
> > > > Joe
> > > >
> > > > On Sun, Oct 27, 2019 at 6:05 PM Joseph Reichman
> > > > mailto:reichman...@gmail.com> >
> > > > wrote:
> > > >
> > > > > AMODE 64 rmode  any
> > > > >
> > > > >   BROWSEIBMUSER.DBGR.DLLLIB   Row
> 022
> > > of
> > > > > 022
> > > > >  Command ===>
> Scroll
> > > > ===>
> > > > > CSR
> > > > > Name PromptAlias-of Size  TTR
>  AC
> > >  AM
> > > > >  RM
> > > > >  _ TEST64A0D30   0001BD
>  00
> > > > > 64  ANY
> > > > >**End**
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: IBM Mainframe Discussion List  >  > > > IBM-MAIN@LISTSERV.UA.EDU> > On
> > > > > Behalf Of scott Ford
> > > > > Sent: Sunday, October 27, 2019 7:02 PM
> > > > > To: IBM-MAIN@LISTSERV.UA.EDU 
> > > > > Subject: Re: Return code X'20' 32 from CELQPIPI INIT_MAIN
> > > > >
> > > > > And what AMODE and RMODE is the Assembler code ?
> > > > >
> > > > > On Sun, Oct 27, 2019 at 6:55 PM Joseph Reichman
> > > > > mailto:reichman...@gmail.com> >
> > > > > wrote:
> > > > >
> > > > > > The doc says
> > > > > >
> > > > > >
> > > > > > • Application program support running in the PreInit environment.
> > > > > > The PreInit table contains the names and entry point addresses
> > > > > > of each routine that can be executed within the PreInit
> > environment.
> > > > > > The applications defined in the PreInit table must be able to
> > > > > > run as AMODE
> > > > > > 64 (with XPLINK implied).
> > > > > > Languages Supported:
> > > > > > – C
> > > > > > – C++
> > > > > > – Assembler (64-bit Language Environment-conforming assembler)
> > > > > >
> > > > > > So when I have entry in the following table (CEEXPTBL) where
> > > > > > TEST64A is that’s C ptogram and use either INIT_SUB or INIT_MAIL
> > > > > > is works But assembler fails
> > > > > >
> > > > > > The Assembler has the following CELQPRLG THE 64 BIT version has
> > > > > > no main option unlike the 31 bit version which has a main option
> > > > > > (CEEENTRY) But CELQPIPI is mean for 64 bit
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > TEST64A  CELQPRLG FETCHABLE=RENT,PSECT=MYPSECT,E

Re: SVC dump data set layout

[SUBSCRIBE IBM-MAIN Anonymous]

Actual address space dump has an eye-catcher "CV" at 5th position, and then the 
actual data starts at 65th position. Each such record has 4096 bytes of dump 
data starting from 65th position. 4 bytes from position 25 represents the 
starting address of the dump data, and you may have to sort the dump dataset 
something like (25,4,CH,A) since the dump data may not be in the proper 
ascending order of virtual addresses.

Also for example if the 1st record has dump data representing the starting 
address x'', and the next record has dump data representing address 
x'2000' then that means the dump data starting from address x'1000' has all 
zeros until x'2000', and hence not captured in the dump dataset. You may have 
to take care of this if you wish to do something programatically. The dump may 
also include "Dataspace" dump which is indicated by by an indicator "DS" at 
position 5. 

You may create a dataspace, and move the dump data to dataspace so that there 
is 1:1 mapping between dataspace addresses and virtual addresses (4 bytes from 
25th position) in the dump data. With this you could just point to the 
dataspace, after loading, and scan through all the control blocks that you 
would like to inspect.

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