Variables not populated after SELECT SQL statement execution/SSMBEGIN not updating DESIRED_STATE
search cancel

Variables not populated after SELECT SQL statement execution/SSMBEGIN not updating DESIRED_STATE

book

Article ID: 192690

calendar_today

Updated On: 04-03-2025

Products

OPS/MVS Event Management & Automation

Issue/Introduction

When reading a table in a security rule with a SQL statement like below:

address sql                                               
"SELECT CURRENT_STATE from STCTBL WHERE NAME='STCA'"
say 'SQLCODE 'sqlcode                                     
say 'Current State of 'resource 'is 'CURRENT_STATE.1  

Even if the resource if found in the table the variable CURRENT_STATE.1 contains the variable name instead of the correct current state of the resource. 

Another symptom is that SSMBEGIN is not able to update the desired state of tasks as the SQL statement that reads the SSM_MANAGED_TABLES fails after the upgrade from a previous OPS/MVS release.

Tracing the SSMBEGIN rule shows that the variable ssmtbl.0 is not updated with the number of rows returned by a previous SQL command so it has the value of 0 as set in the subroutine STATBLST.

OPS0997T *-* 561:Do i=1 To ssmtbl.0        
OPS0997T >>>     I=1                  
OPS1000I REXX Warning: ruleset.SSMBEGIN -  RC=0, SQLCODE=0   
OPS0997T *-* 569:Drop name.          

 

Environment

OPS/MVS

Cause

Value of the STACKMAIN parameter too low.

Resolution

Increasing the value of this parameter and recycling OPSMAIN may solve this problem.

OPS/MVS 14.0 requires at least 512 KB for the STACKMAIN parameter.

 

Additional Information