On 27 Apr 2012 08:56, CRPence wrote:
On 26 Apr 2012 10:00, Jerry C. Adams wrote:
I deal with a lot of old S/36 style menus and use UIM for new,
native menus. I was wondering if there was any way to display the
name of the library, in which the menu resides, on the menu? The
reason I ask is because I create test libraries every night from
production. I have separate profiles for production and test.
Sometimes I forget which environment I'm in! Of course, I can
DSPLIBL or WRKUSRJOB. Thought there might be an easier way, like a
parameter on the menus that I missed or forgot about.
Look up "Dialog Variables" for the "User interface manager (UIM)"; in
the "Application Display Programming" manual IIRC. I believe there is a
variable for the menu name, and probably library, and I know for sure a
In a search for the docs, I stumbled upon a mention of the ":VAR
Seeing that message, I then recalled, what I had intended to describe
in my prior message were actually /special/ "Dialog Variables", called
Z-variables. Too long since I did any UIM, and I am sure that all I
would ever have used was the ZMENU [in a UIM Menu], and only for the
While I realize the use of &msg(msgid,msgf,lib) in some text area
[most likely the TITLE] might suffice as a static substitute, the dialog
variables from the UIM application variable pool are dynamic. Using the
message identifier might also be preferable if only because the
information can be placed easily as the menu TITLE, whereas the
capability for the use of dialog variables seems fairly limited in the
*MENU object UIM source.
However FWiW, following the "Figure 102. An Example Menu" available
in the docs noted at the bottom of my reply, I was able to include the
name of the *MENU as the Panel Identifier with the ZMENU variable on the
PANEL tag. Or use ZMENU as the menu TITLE and then change the PANELID
to present the ZMNULIB value; in presentation, that seems a bit more
logical, to have the menu name replace the title that would be lost.
:PANEL ... TITLE=ZMNULIB PANELID=ZMENU ...
:PANEL ... TITLE=ZMENU PANELID=ZMNULIB ...
If all of the menus being used have room, then the Menu Library [and
menu name] might be easily placed as Bottom Instruction(s) with the
BOTINST tag, placed before the EMENU tag. Or as Top Instruction(s),
perhaps before an existing typical "Select one of the following:", with
the TOPINST tag, placed after the MENU tag. For example:
Select from following options:
I expect that the COND tag could be used to define some logic to
exclude something from the menu when in test versus production. However
as a literal comparison to ZUSER or ZMNULIB however, given the
implication that there are multiple libraries and presumably users,
those might not be so nice to condition anything in the menu area. More
likely acceptable would be the use of a CHKOBJ built into the
Condition-definition to test for authority to or existence of an object
that always would be available or unavailable according to which of
those two environments. That could be useful. Both the Menu Group
MENUGRP tag and Menu Item MENUI tag enable the COND=condition-name to
suppress their appearance. Perhaps a menu item [e.g. item-0] could be
added conditionally to show its text as "This is a TEST environment";
for example establishing an existence test for *LIBL/TESTING *DTAARA as
a condition to establish that the job is for TEST versus PRODuction:
This is a TEST environment
FWiW, though not a good choice anyhow as alluded above, my attempts
to reference ZMNULIB in a comparison against a literal resulted in
msgMCH3601 t/QUIICHK X/0F9B in v5r3; so probably similar in v5r1, making
that an even less likely worthwhile choice. Identical tests using ZUSER
or for example EXPR='ZLMTCPB="*NO" *AND ...' did not exhibit that error.
Also it seems that the Z36ENV variable is completely unavailable in
the UIM *MENU. That variable can not even be declared per CPD5A6A
"CLASS attribute not found for Z36ENV variable VAR tag" and the CLASS
tag is not even allowed in UIM Menu source either, so there is no
apparent capability to use that information. These of course seem to be
obvious defects, but they may be corrected [though I am very doubtful]
in later releases; i.e. they had gone that long without any corrections,
likely they are still dysfunctional.
Chapter 17. Details of Using User Interface Manager
_Defining Dialog Variables_
"... For more information on Z-variables, see “Dialog Variables
Defined by UIM” on page 635.
The link Rory gave was to the v4r1 BookMgr version if you prefer to
avoid a large PDF [download]:
_i Application Display Programming V4R1 i_
"APPENDIX18.104.22.168 Dialog Variables Defined by UIM" link to->
As an Amazon Associate we earn from qualifying purchases.