OnDemand Users Group

Support Forums => CMOD for z/OS Server => Topic started by: tbe2856 on June 15, 2016, 05:59:03 PM

Title: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
Post by: tbe2856 on June 15, 2016, 05:59:03 PM
We are running OnDemand 8.5 and are upgrading from z/OS 1.13 to z/OS 2.2.  Were can I find the necessary
steps that need to be performed (re-binds, etc.).  I believe that the error we are getting is due to the fact that the
binds have not been re-done.

DSNT408I SQLCODE = -551, ERROR:  BPXROOT DOES NOT HAVE THE PRIVILEGE
TO PERFORM           OPERATION SELECT ON OBJECT ZMAINT.ARSAG       
                       DSNT418I SQLSTATE   = 42501 SQLSTATE RETURN 
CODE                                 DSNT415I SQLERRP    = DSNXOSC 
SQL PROCEDURE DETECTING ERROR                      DSNT416I SQLERRD
= -10  0  0  -1  0  0 SQL DIAGNOSTIC INFORMATION                   
DSNT416I SQLERRD    = X'FFFFFFF6'  X'00000000'  X'00000000'  X'     
FFFFFFFF'                  X'00000000'  X'00000000' SQL DIAGNOSTIC 
INFORMATION                      ERRLOC=1:13:2 -- SQLSTATE=42501,   
SQLCODE=-551, File=arsag.c, Line=3673                               
BPXP011I THREAD 1EB1580000000001, IN PROCESS 67109179, WAS  792     
TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.                     
IEF450I ARSSOCKC ARSSOCKC - ABEND=S000 U0333 REASON=00000000  793   
        TIME=09.59.40                                               
Title: Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
Post by: Ed_Arnold on June 15, 2016, 09:18:25 PM
First question:   Does that table exist?

I know it's misleading, but a -551 can also be caused by something being non-existent.

Ed
Title: Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
Post by: tbe2856 on June 16, 2016, 06:20:29 PM
Ed,

I am in the process of verifying that.  Our DBAs are at a DB2 user group meeting today.  I am assuming it should exist
as it was running under z/OS 1.13.
Title: Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
Post by: tbe2856 on June 17, 2016, 04:01:14 PM
 I am working with our DBA's today to verify that the table exists.  Are there any binds for OnDemand
that have to be done for z/OS 2.2?  We did the ones for OAM.   Also could it be related to the changes
introduced in z/OS 2.1 with regards to OMVS and the elimination of the default user.  I noticed the user
it shows is BPXROOT.
Title: Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
Post by: Ed_Arnold on June 20, 2016, 03:29:03 PM
a) We've been running 8.5 on 2.2 in test from before when 2.2 became externally available and have found no 2.2 issues.

b) Do you have a way of running a SELECT on that table from that user outside of CMOD?  That would nail down pretty quickly where the problem lies.

c) It sounds like the STC is running with UID=0, which can be problematic.  This is what I see at the top of my CMOD V9.5 started task log:

IEF695I START ARSSOC95 WITH JOBNAME ARSSOC95 IS ASSIGNED TO USER ARSSV950

If I do the following command on USER ARSSV950 I get the following:

TSO LU ARSSV950 NORACF OMVS

USER=ARSSV950   
                 
OMVS INFORMATION
---------------- 
UID= 0000000564   
HOME= /u/arssv950
PROGRAM= /bin/sh 
CPUTIMEMAX= NONE 
ASSIZEMAX= NONE   
FILEPROCMAX= NONE
PROCUSERMAX= NONE
THREADSMAX= NONE 
MMAPAREAMAX= NONE
***           
   

Is your 8.5 CMOD running UID=0?

Ed
Title: Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
Post by: ewirtz on June 21, 2016, 05:33:55 AM
Hi

DSNT408I SQLCODE = -551, ERROR:  BPXROOT DOES NOT HAVE THE PRIVILEGE
TO PERFORM           OPERATION SELECT ON OBJECT ZMAINT.ARSAG       

the access right is missing

regards

Egon
Title: Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
Post by: tbe2856 on June 27, 2016, 06:56:53 PM
Sorry for the delay in replying back.  We had a DR test last week.  We have resolved the issue.  We wound up granting
DB2 DBADMIN for the BPXROOT user.  I am wondering if anyone else has encountered this issue?  So I am thinking that
it is OMVS related and has to do with the changes introduced in z/OS 2.1.  I will also qualify this with the statement that
our OMVS environment and the related ACF2 environment could have added to the scenario.  In the z/OS 1.13 environment
we had a wildcard OMVS user defined with ********.  This made it difficult in working through the impact of the elimination
of the BPX.DEFAULT.USER.