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
User name.

In a search for the docs, I stumbled upon a mention of the ":VAR NAME=ZMNULIB." here:

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 Panel Identifier.

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. For example:


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_
"APPENDIX1.1.81.3 Dialog Variables Defined by UIM" link to->

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.