SSM: System Variables in STCTBL

[stephen.jenkinson]

Currently you can use system variables in the SSM SCTBL_ACT table. This is an example from the action_text column in one of my tables:-

MVSCMD('START CASYVIEW,JOBNAME=&JOBNAME,TASK=&JOBNAME(7,2)')

It would be useful to be able to use system variables in the PREREQ column of the STCTBL table in a similar way. At our site sometimes an lpar name is included in the STC name, for example PAGENTPA,PAGENTPB etc etc. Being able to use a system variable would enable easier table management and reduce the risk of a typo in the prereq column in the STCTBL table.

Using the PAGENTPA,PAGENTPB example above I could code PAGENT&SYSCLONE in the prereq column which would make all STCTBL entries consistent across the sysplex.

[Carlos Filho]

Hello Stephen,

This functionality is not currently available. Please, create an idea at the ideation section of this community so that it will be considered for a possible enhancement: 

https://community.broadcom.com/ideation/allideas

Thank you,
Mario

------------------------------
Carlos Mario Silveira Filho
Principal Support Engineer
[e-mail]
Broadcom

------------------------------

[stephen.jenkinson]

Done. Thanks

 

Stephen Jenkinson | zSeries Automation Specialist | Core Solutions, Technology
Tel: [phone]
Email: [e-mail]
RBS Gogarburn, 2^nd Floor, House E, PO Box 1000, Edinburgh, EH12 1HQ

The information classification of this email is Confidential unless otherwise stated.

 

[Dave Gorisek]

Another option is to use a product general NAME such as PAGENT with JOBNAME=PAGENTx​x, then your PREREQ can be just PAGENT. Only issue you may run into and will have to make slight code change to, is if you utilize 'manual' commands (S jobname,P jobname, SSM SJ/PJ jobname,etc) AND the supporting code (SSMSTART,SSMCNTL,rulexyz,etc) does not include 'Where NAME = :jobname or JOBNAME = :jobname' for the SQL logic to UPDATE DS=UP/DOWN. Meaning, S PAGENTA may not work if supporting rule to fire on START to set DS=UP does not use JOBNAME as well as NAME column. Thus, you simply use PAGENT to manually control (S PAGENT,P PAGENT,SSM SJ PAGENT,etc). of course assuming associating SSM actions for PAGENT is using &JOBNAME (as it should) and not &NAME

[stephen.jenkinson]

Absolutely and that is exactly what I'd do if I was in control of the naming convention of the tasks at my site but unfortunately I'm not. I'm just hoping that if system variables can be used in one part of SSM it wouldn't take too much effort to make them available elsewhere.

[stephen.jenkinson]

Yes follow you and you are quite correct but that kind of breaks other internal standards we have for managing our SSM tables. The way some tasks have been names is actually against IBM standards <sigh> but what can you do? I have raised an ideation so lets see what happens.

Thanks Dave.

[Ralf Haefner]

Hello Carlos,
build a REXX which invokes MVS Command "D SYMBOLS", read the values and put them into same named OPS/MVS variables. Do this at OPS/MVS start. It will be nice. :-)

[Dave Gorisek]

Not sure what you are referring to here, Ralf.   The  initial issue/request is to have SSM internally process system symbolics within PREREQ checking without any user 'tweeking'....as for D SYMBOLS command, you would never have to issue and parse that command output in any rule/pgm...as you would just invoke the OPSYSYSM() builtin OPS/REXX function.....