Re:Re: Developer Question

Discussion created by ca.portal.admin on Jan 6, 2010
What this 256-byte ""warning"" is telling you is that you are susceptible
to a
0C4 abend if you use a sort-key variable that is less than 256 bytes
long nd is allocated less than 256 bytes from the end of a physical 4K
page oundary.
The reason for this potential S0C4 is that if your program does not
he next physical 4K page, when 256 bytes are moved the move would start
on page that you own, but the end of the move would be on a page that
you do ot own. Somewhere during the execution of the move you will cross
the hysical 4K page boundary of storage to a page you don't own and will
get he S0C4 abend when this occurs.
When coding an OBTAIN USING SORT-KEY, remember that you can only have a
ingle variable in the SORT-KEY clause. If your INDEX or SORTED set has a
ey built of multiple values, you must supply a GROUP level SORT-KEY
ariable and each element within the group must match the picture and
order f the individual sort keys. This is noted in the second NOTE
following the OTE already cited by Chris.

----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM] On
ehalf Of Trayler, Christopher
Sent: Wednesday, January 06, 2010 1:37 AM
Subject: FW: Developer Question
You have fallen over the 256 byte problem. It is documented in the DML
ference Guide for Obtain Using.
pecifies the sort control element to be used in searching the sorted et.
he symbolic name of a field defined in working storage that contains he
value of the sort control element.
ote: Due to the architecture of the client interface for Advantage
A-IDMS, 256 bytes will be moved regardless of the actual length of the
orking storage sort key. This additional storage should be accounted or
in order to avoid potential program exceptions that can occur. While
hese exceptions are rare, they are more probable if the sort-key is
efined in a FILE or LINKAGE SECTION definition. To avoid this problem, t
is recommended that the sort-key be defined in the program's WORKING
TORAGE SECTION, padded to a full 256 bytes; and moved in and out of the
Chris Trayler