RE: program crash

Thanks for the thoughts.

It's always a battle, isn't it - the tradeoffs of performance vs. other
factors? And I would never be one to say that there is only one
architecture that fits all situations.

We use a standard of including the full SDS in our programs. This allows
us to tie some of this data to common error handling and reporting
modules. By passing the address of the SDS to a module, all of that data
is available for reporting and error handling without needing to pass
lengthy parms. We find this a convenient way to report on program
problems.

The majority of such code is for user applications, where the frequency
of use is limited. Therefore, we don't feel there's any impact on
performance. 

For processor intensive batch programs  - especially ones were many
calls are made to sub-programs, we at times limit this approach. But
generally, we find the good outweighs the bad.

Thanks for the point. It should always be noted that a given solution
needs to be taken in context of the real-world need and usages, and that
nothing comes without a cost.

Best Wishes

Jim Wiant

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Larry Ducie
Sent: Wednesday, 9 November 2005 21:31
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: program crash


Hi Jim,
 
<snip>
By adding the Program SDS and file INFDS structures to the program,
you'll have a lot more information available in the dump - especially
file details from the INFDS including the last operation performed.
</snip>
 
There are two opposing factors you must consider when using an SDS:
 
1) PRO: Increased level of observability and control
 
According to IBM:
A program status data structure (PSDS) can be defined to make program
exception/error information available to an RPG IV program. The PSDS
must be
defined in the main source section; therefore, there is only one PSDS
per
module. 











A data structure is defined as a PSDS by an S in position 23 of the data
structure statement. A PSDS contains predefined subfields that provide
you
with information about the program exception/error that occurred. The
location of the subfields in the PSDS is defined by special keywords or
by
predefined From and To positions. In order to access the subfields, you
assign a name to each subfield. The keywords must be specified,
left-adjusted in positions 26 through 39. 


Information from the PSDS is also provided in a formatted dump. However,
a
formatted dump might not contain information for fields in the PSDS if
the
PSDS is not coded, or the length of the PSDS does not include those
fields.
For example, if the PSDS is only 275 bytes long, the time and date or
program running will appear as *N/A*. in the dump, since this
information
starts at byte 276.

 
2) CON: Reduced performance
 
Also according to IBM:
 
Call performance with LR on will be greatly improved by having no PSDS,
or a
PSDS no longer than 80 bytes, since some of the information to fill the
PSDS
after 80 bytes is costly to obtain.
 
 
So, it would appear to be a balancing act - increased level of
information
vs reduced program performance. In some circumstances it may be better
to
code a PSDS in a program which uses only the first 80 bytes, and include
subfields past byte 80 only if specifically required - such as the job
name
or user name. Of course, the performance hit is felt when the program is
initialised, so it is much less of an impact if the program is called
several times and returns with LR off, or if it is a long-running
program.
It's just a case of getting the right balance.
 
Cheers
 
Larry
 
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

######################################################################
This message was scanned for compliance with Foodstuffs email policies
######################################################################
This message has been sent from Foodstuffs (Auckland) Limited ("Foodstuffs").

The information contained in this message and or attachments 
is intended only for the person or entity to which it is 
addressed and may contain confidential and/or privileged 
material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon, this 
information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from any 
system and destroy any copies.

The views and opinions expressed in this message may be those
of the individual and not necessarily those of Foodstuffs, 
and are not given or endorsed by it.

Please note that this communication does not designate an 
information system for the purposes of the Electronic 
Transactions Act 2002.