Bad Abbreviaitons - Forum Fail.....

A little funny post as it's Christmas.

There is a reason why cumulative is never abbreviated....

Thanks for reading.
Lee.

What is a reasonable time to resolve an issue?

Today, I experienced a bug whilst building a wide screen definition in 2E.  The build was okay but when I went to use it (in the 2E device design editor), I was getting some low-level errors.

Upon googling the error, I came across this ticket which gave a few workarounds, one of which I implemented.

The given workarounds were:-

1. Set the screen footer to 25 as per the screen print. 
   
2. Set the subfile page size for consuming functions explicitly.  I am assuming they mean…
   
3. Override the YSFLEND model value to *PLUS and not *TEXT or override it in the consuming function via F7=Function Options
   
   
   
   

All of these appear to be perfectly good reasons to postpone fixing this issue up within the product as I am guessing...

• many use the + for subfile,  
• many also forget to move the command line down to row 26 anyhow when creating and generating wide screens (they leave it at 23) and then wonder why they have a 3 row gap at the bottom of their screens 😊

Is it okay though, that 15 years after it was raised, it is still an issue…..?

Thanks for reading.
Lee.

Multi-Line Edit Oddities

Hiya,

Today I helped a colleague (a very talented one at that) with a small issue around a PMTRCD and usage of multi-line edit for oversized fields.  Something he hadn't seen before.

He was confused as to why his data entry field was showing on the device design and not showing when executed.

Figure 1 shows a mock up of his device design looking pretty standard.

Figure 2 shows the same screen at run-time.  Note the cursor has positioned to the field acting strangely but the underline is not showing.

If you want to recreate this issue I created a file as follows (See Figure 3 and 4) :-

 

Additionally, in the device design we set the long field to multi-line Y and set it to 4 rows and 50 wide.

To resolve the issue was a case of applying a (clearly little known) trick of moving the multi-line field over by one byte.  (Figure 5) 

 

This then allows the run-time screen to paint properly. (Figure 6)

My assumption is that the screen attributes are being corrupted by the multi-line although comparing the source for the DDS didn't highlight anything untoward so I am guessing it is a 5250 issue.  (I also recommend aligning the rest of the fields on the screen.)

Any takers on providing the technical explanation? as a compare source doens't seem to highlight a clear and present danger. (Figure 7)

I've always nudged these over by an extra byte for years and years but I guess some tips and tricks get lost.

Thanks for reading.
Lee.