Author Topic: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5  (Read 3757 times)

tbe2856

  • Guest
Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
« on: June 15, 2016, 10:59:03 AM »
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                                               

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1209
    • View Profile
Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
« Reply #1 on: June 15, 2016, 02: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
#zOS #ODF

tbe2856

  • Guest
Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
« Reply #2 on: June 16, 2016, 11:20:29 AM »
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.

tbe2856

  • Guest
Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
« Reply #3 on: June 17, 2016, 09:01:14 AM »
 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.

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1209
    • View Profile
Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
« Reply #4 on: June 20, 2016, 08:29:03 AM »
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
#zOS #ODF

ewirtz

  • Guest
Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
« Reply #5 on: June 20, 2016, 10:33:55 PM »
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

tbe2856

  • Guest
Re: Upgrading from z/OS 1.13 to z/OS 2.2 with OnDemand 8.5
« Reply #6 on: June 27, 2016, 11:56:53 AM »
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.