Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Screen Management (SMG$)

 
SOLVED
Go to solution
dschwarz
Frequent Advisor

Screen Management (SMG$)

I've been playing around with SMG$CREATE_MENU and SMG$SELECT_FROM_MENU on my old VAXstation running OpenVMS 7.3 with all patches installed.
Menu Items are 76 characters long (appr. one line on a VTxxx) and the number of possible choices is around 500. I used FORTRAN77 (V6.6-201) and it seemed to work perfectly at first sight.
During some testing I found that there were only 138 choices on the screen, no chance to get more.
This made me curious and I tried out a (slightly modified) sample program written in C (found it somewhere on the web).
On my VAXstation I can select from 5436 choices instead of 20000. No messages.
I tried the same code on an Alpha (OpenVMS 7.3) and it works!
I changed the number of choices from 20000 to 6000 and it worked on the VAX, too.

Any idea ?
11 REPLIES
Hein van den Heuvel
Honored Contributor
Solution

Re: Screen Management (SMG$)

How do you even test 5000+ choices?

How is this ever practical?

Is there an accelerator in SMG to go down to the end of list of choices?

I would guess that somewhere in SMG it is dealing with the choices as a simple blob, and became limited by a 16 bit length restriction. 65K/5436 = 11 which is close to, but not equeal to, the element size of 9 in the example.

When you double the test element size, does the max number of elements roughly half?

fwiw,
Hein.

dschwarz
Frequent Advisor

Re: Screen Management (SMG$)

Testing is rather simple: put a book on the 'cursor down' key and take a cup of coffee or two. No accelerator, no tricks.

I set the number of choices to 10000 and the number of displayed elements was 2717 and a half (!), because the last element was displayed as 27 instead of 2718 !

The results seem to be unpredictable.
Hein van den Heuvel
Honored Contributor

Re: Screen Management (SMG$)

>> Testing is rather simple: put a book on the 'cursor down' key and take a cup of coffee or two. No accelerator, no tricks.

I was afraid you would say that :-).

In that case, try again with a thinner book!

Or rather more precisely, try with the terminal (emulator) set to a slow (=long) repeat delay interval. Maybe create a keyboard macro to emit 10 - 20 down arrows and allow the system to catch up between each hit.

I suspect this is a dynamic problem, in the terminal driver / SMG not being able to keep up.

You can 'proof' this by altering the code to use a default-choice-number for smg$select_from_menu towards the end.
For example use:
def_number = num_options - 4;

You'll see all you choices.

Next step would be to interpret certain terminaotr (page up/down?) as accelerators.

hth,
Hein.







dschwarz
Frequent Advisor

Re: Screen Management (SMG$)

As originally posted, I had to deal with about 140 choices, I did it without any book. The result is reproducable even on another VAX (running V6.2).

>>For example use:
>>def_number = num_options - 4;

I tried
def_number = num_options - 3;

The program presented the first element of the choice list !!!?

Now I tried
num_options=10000;
def_options=2713;

I hit 'cursor down' five times and saw: 27
instead of 2718 at the end of list (should be 9999).

I tried it with a terminal connected to console port and with a terminal emulator via telnet. The result is reproducable.


dschwarz
Frequent Advisor

Re: Screen Management (SMG$)

Hein, you wrote:
>> SMG it is dealing with the choices as a
>> simple blob, and became limited by a 16 bit
>> length restriction.

So I played with the number of choices:

7281 * 9 = 65529 ==> is working
7282 * 9 = 65538 ==> is not working

That's it.

But there is no error message and none of the descriptor's relevant fields is of type short. I think this must be a bug.
Hoff
Honored Contributor

Re: Screen Management (SMG$)

Yeah, there's a bug here, but arguably the biggest bug here is upstream of the word-length field.

Sure, not having infinite capabilities is a problem, but, well, it's a VAX. It's a 30 year computer old design, and a 30 year old compiler design. It's a twenty-year old RTL. Ten year old hardware. Wonderful stuff, yes, but scaled for a different era, and a different design center.

A menu that's seven screens long? Really?

As for the bug here that can be addressed, I'd tend to be looking at a UI design with this menu set-up. Menus with five or eight screens, and 500 entries? Really? Has anyone looked at the human factors here? (I'd not expect to see a significant change to SMG scaling in VAX, but that's up to HP to decide.)

I've certainly seen, and have scaled applications and UIs past their design limits over the year (and regretted same) and have had to re-scaled application UI designs, and this case sure looks familiar.

As for approaches available here, look at CGI and such (this in addition to getting the VAX tossed out the airlock just as soon as you can close the hatch behind it), given that Fortran can generate HTML and such; Fortran can easily work in a CGI environment. And you can build a far better UI than is possible with SMG.

Hein van den Heuvel
Honored Contributor

Re: Screen Management (SMG$)

>> The result is reproducable even on another VAX (running V6.2).

Ah yes, you mentioned VAX, and you meant it huh?

I only tried on Alpha (7.2-1) it works there. Even more proof that there is a bug / restriction here.

You may also want to try on an Alpha (Deathrow, Eisner), even if the target is VAX, just to remove doubt about the program versus VMS+RTL's.

In all, like Hoff implies, treat it as a warning that you are going out of the design bounds and you may want to do yourself, and the target users, a favor by review the UI design, possibly nesting some menues.

Cheers,
Hein.

Paul Beaudoin
Regular Advisor

Re: Screen Management (SMG$)

Hi,

Just to add: I used the create/select menu calls quite extensively on vax via macro some years ago and never found a limitation I can't remember how far I pushed it but certainly well beyond 10000 items in a block menu (there was, suprisingly, a good reason for this!) Because the call is an array of fixed length items, as near as I could tell, the only limit was the amount of memory available. At a guess, this sounds more like the compiler than the underlying SMG services.
I can post a mocro coded call that demonstrates if anyone is interested.
Regards

Paul
dschwarz
Frequent Advisor

Re: Screen Management (SMG$)

Hi,

It's a VAX, it's old,....
You are right but we have to live with it at least now.
There are reasons to have data presented in that way and the SMG$*MENU* functions offer a quite simple way to do this job without writing some hundred lines of code.

>> A menu that's seven screens long? Really?

Imagine your text editor and a source file of some hundred lines of code in whatever language. What's the difference?

Paul,
I don't believe it to be a language problem, because I first observed it in a FORTRAN program. I then tried the C example just get a feeling of the descriptor that has to be passed to SMG$CREATE_MENU.


Thank you very much for your help.
dschwarz
Frequent Advisor

Re: Screen Management (SMG$)

There are some alternatives to using SMG$*MENU* and we will use one.
Paul Beaudoin
Regular Advisor

Re: Screen Management (SMG$)

Gents;

Far be it for me to argue with the depth of experince displayed here, but, what the hell :-) (watch the wrapping)

This is the 'standard' call I used to build the SMG CREATE MENU call:

; Menu
M_DCS: .WORD 14 ; size of element
.BYTE DSC$K_DTYPE_T
.BYTE DSC$K_CLASS_A
MADDR: .LONG 0 ; Pointer to item list
.WORD 0 ; DIGITS, SCALE
.BYTE DSC$K_DTYPE_T ; AFLAGS
.BYTE DSC$K_CLASS_S ; DIMCT
; .LONG ^X01E00000 ;DIMCT,AFLAGS,DIGITS,SCALE
DMSIZE: .LONG 0 ; Size of array
.LONG 20
.LONG 1 ;
.LONG 20
.LONG 1 ;

And here is a snippet calculating the values: (R11 is counting the items)
MULL #128,R11
MOVW #128,M_DCS ; Item size
MOVL MENADDR,MADDR
MOVL R11,DMSIZE

Translation: The total size of the menu choices is passed in DMSIZE, a .long and appears to be the architectural limit. The program this is chopped out of has a hardcoded value of 2000 (vax) pages allocated to this and filled before the call. It worked with (almost) 1M characters. This would have been in V6.2 days probably.

Not trying to be pedantic or even 'my call is bigger than yours' but if you are looking to solve the problem, it does not look like it is in SMG to me.
Happy to be educated though ....

Regards

Paul