Good point. I believe it will capture what is in the workstation buffer. Reason it is more useful than a screen shot is that control characters are not visible on the screen and so do not appear in a screen shot. This API gives you everything the is in the current workstation buffer - regardless of how it got there e.g. by writing a format which retains other existing formats on the screen. It is conceivable I suppose that your latest exfmt is causing an invalid buffer but I'm not sure - personally I build the standard PSSR routine described in the Redpiece into each program via /Copy that way I've always got the screen data in the event of an unhanded exception.

So - simple answer - it may or may not help in this case but is good practice anyway.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Feb 6, 2019, at 6:24 AM, Dan <dan27649@xxxxxxxxx> wrote:

Thank you, Jon. Apparently, I need to take another look at the Redbook and
Redpaper offerings; I was unaware of that redpaper!

I briefly reviewed the content, but it's after midnight, so my
comprehension isn't at top form now. You said "That will give you a
capture of what is _on_ the and screen". However, I am curious, does this
type of error allow that the data in the RPG output buffer even gets to the
screen such that it could be "read" by a DSM API?

- Dan

On Tue, Feb 5, 2019 at 4:05 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

My suggestion would be to use the DSM APIs to grab the screen content from
the terminal do it in the PSSR or directly when the error is detected.
That will give you a capture of what is _on_ the and screen will include
all of the stuff added by workstation data management. You may find that
the error is being caused by an indicator combo causing attribute
overwrites for example. It is usually that that causes this kind of
problem. You'll have to capture it from a live explosion though I suspect.

I believe there's a ready made example of this in the RPG error handling
redbook but I can't check right now.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Feb 5, 2019, at 7:06 PM, Dan <dan27649@xxxxxxxxx> wrote:

We have an application that rarely bombs with RNX1251 (major return code
80
and minor return code C0). ("rarely" = once per week with the program
being called hundreds of times daily.) Several of us have interrogated
the
dumps, and have never found any non-displayable characters (x'00' -
x'3F' &
x'FF'). Today, I went so far as to write an RPG program in which I
copied/pasted the hex representation (i.e., 'C4C8C5C8D9C5D9404040'X) of
all
of the screen's variables from the dump and used the CVTCH MI function to
convert them to character:

HexVal = 'C4C8C5C8D9C5D9404040';
FromHex( USERNAME : HexVal : %len( HexVal ));
(where FromHex is the prototype used to call CVTCH.)

After all of the screen variables are "filled", an EXFMT on the record
format is executed. When I call this test program, it displays the
record
format with no errors, with all the data as we expected it.

The display file has only one record format and specifies DSPSIZ(27 132
*DS4), just like all of our application display files. There is an
OVERLAY
keyword in the record format. Other than that, it's all run of the mill
stuff.

The description for RNX1251 says that "If the major return code is 80
then
a system or file error occurred and programmer action is required to fix
the problem." It gives no indication of what minor return code C0 means.

Is it possible that splitting the EXFMT into WRITE and READ operations
might help? (A question for Barbara?) If for no other reason, I'd
encase
each of them in a MONITOR block. Maybe retry 3 times to see if it
resolves
it?
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com


This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2019 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].