RE: CPF5192 error message with RPG program. -- RPG400-L

Cheers,

DFTWRT(*NO) seems to do the trick. As another side note...I've had a
quick look at this and it would seem an alternative is to use the FRCDTA
keyword on the record formats in the Program1 Display file. This keyword
seems to overwrite the behaviour defined by DFTWRT during compile. The
only real advantage I can see though is that it means you don't need to
change the default compile option on DFTWRT...

As to format DUMMY requiring the OVERLAY keyword, it will never be
written to the screen so I guess it doesn't need it. This format is only
required when the Window being displayed is in a separate display file
and if pretty much just taken it straight from:

http://www.mcpressonline.com/programming/general/perfecting-dds-windows-
in-modular-programs.html

As for STRDBG...I can safely say I don't really care either!

Thanks everyone for their help:)

Steve

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Terrence Enger
Sent: Monday, 20 July 2009 9:14 PM
To: RPG programming on the IBM i / System i
Subject: RE: CPF5192 error message with RPG program.

Steve,

I think the problem comes from SrvPmg2D DDS saying DUMMY
... ASSUME while Program1D DDS is created (by default) with
DFRWRT(*YES), which renders the assumption invalid. Creating
Program1D with DFRWRT(*NO) seems to fix the error.

A couple notes on the side ...

(*) Even with DFRWRT(*YES), the program works if you call it from
a command line on a *DS4 panel, like F21 from an SEU display
with screen size = 1.

(*) I take ( InfoCenter > IBM i 6.1 Information Center >
Programming > DDS > DDS for display files > DDS keyword
entries for display files > ASSUME ) to mean that format
DUMMY should be defined with keyword OVERLAY, but in hacking
around I do not see that it makes a difference.

(*) I still have no idea what magic STRDBG does in or after
its (80 column) source display to avoid the CPF5192. Does
anybody care?

HTH,
Terry.

On Mon, 2009-07-20 at 12:03 +0800, Steven Harrison wrote:

Cheers Mark,

I have created a very basic little program and service program that
illustrate the problem. They can be found at:

http://code.midrange.com/af2d3f1902.html

Thanks,

Steve

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S. Waterbury
Sent: Monday, 20 July 2009 10:56 AM
To: RPG programming on the IBM i / System i
Subject: Re: CPF5192 error message with RPG program.

Hi, Steven:

Create a small, "cut-down" version of the display files and the RPG
program, that reproduces the problem, and then post the source code at

http://code.midrange.com -- and then post a reply to this list with a
link to the code you posted there.

That way, people on this list who want to help can look at the source
code and perhaps reproduce your problem, and perhaps then offer

various

solutions.

All the best,

Mark S. Waterbury

> Steven Harrison wrote:

Hi All,

I have been receiving the following error in the job log when my

program

runs:

Message ID . . . . . . : CPF5192 Severity . . . . . . . :

Message type . . . . . : Escape

Date sent . . . . . . : 17/07/09 Time sent . . . . . . :
10:50:57

Message . . . . : Data sent to device AFXIT02A not valid.

Negative

response

code is 10050112.

Cause . . . . . : The condition was caused by the program output

data

containing below hex 40 or too many input fields. More

information

on

the

negative response code can be found in either the IBM 5494 Remote
Control

Unit Functions Reference (under negative responses) or the SNA

Formats

Manual (under SENSE or LUSTAT codes). Invalid data (below hex 40)

may

have

occurred in one of the following ways:
etc etc...

followed by:

Message ID . . . . . . : RNX1251 Severity . . . . . . . :

Message type . . . . . : Escape

Date sent . . . . . . : 17/07/09 Time sent . . . . . . :
10:50:57

Message . . . . : Permanent I/O error occurred in file STATUSD.
Etc etc...

The following is happening:

Program 1 displays a subfile containing the discount rates for a

price

code. The DDS for this program contains the subfile.

Program 2 is a service program that is responsible for displaying a
window that reports any status events that might take place (ie.

Could

not find price code, discount rate invalid etc...). The DDS for the
window is in a separate display file. I have never had a problem

with

this program and it is used by a number of other programs to display
status events.

The error is occurring when Program 2 is called to display the

Window.

While trying to figure out what was causing the error I started
stripping out code bit by bit to identify where the problem was
occurring. I ended up removing the subfiles from Program 1's DDS
altogether and ended up with just a Header record displaying a

single

text field and a Footer record that contains indicators for the F12

and

F03 keys. It seems that the error is occurring when 'ExFmt' is

called

in

Program 2 before a read or ExFmt in Program 1.

So with the following code the error would occur:

Program 1:

Write Header;

DoesPriceCodeExist() <- Procedure to determine if the price code

exists.

If it doesn't it sets a status event that can be displayed by

Program

2.

Call Program 2 <- Calls ExFmt on the Window to display the status

event.

The program will fall over at this point.

ExFmt Footer;

But with the following code the error won't occur:

Write Header;

ExFmt Footer;

DoesPriceCodeExist()

Call Program 2 <- Display the window reporting that the Price Code
doesn't exist.

ExFmt Footer;

I'm wondering if anyone can shed some light on why this is

happening?

Why will the ExFmt on the Window cause the program to crash if the

DDS

it is overlaying has only had Writes to it but it will be fine if

the

there has been a previous Read/ExFmt.

Both DDS files are compiled with RSTDSP *YES. Also for some strange
reason the error will not occur if I'm running the program in the
Debugger?!?!? Which I find very strange.

Any help would be greatly appreciated.

Steve