× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I tried before cutting them down to a reasonable 1600 but I got parameter mismatch errors.

I'll try the static

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Charles Wilt
Sent: Monday, August 17, 2020 3:55 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Fields too large for a Subprocedure - CWX9001

It's a system limit...

Add STATIC to the variable declarations inside the procedure and it will compile...

Note this is really a best practice anyway, for larger i/o "buffer" type fields, keeps the system from having to re-initalized them every time the procedure is called. Huge run-time hit when repeatedly called, and unnecessary if you're using such buffers correctly.

Also, do you really need them that big? Yes, that's the max size that Scott's routines will return, but if you know you won't get anything that big back, you can cut them down to a more reasonable size.

Charles


On Mon, Aug 17, 2020 at 12:29 PM Jack Prucha <Jack.Prucha@xxxxxxx> wrote:

I made some enhancements to a running but very new program. Changed a
subroutine into a subprocedure and reworked the SQL select.

Started getting all sorts of misleading error messages.

The subroutine was using Scott's HTTP subroutine to call a PUT to a URL.
There's a send string and a result string each varchar of 16000000. I put
the call and the fields used by the call inside the subprocedure. Started
getting this error:

Msg id Sv Message text
*CWX9001 40 An error occurred during translation.
Cause . . . . . : An irrecoverable error has occurred
during
translation. The reason code is 0001. See the previous
messages listed in the joblog.
Recovery . . . : This error indicates that an internal
compiler error has occurred. Contact your service
representative.

This just a little bit more helpful message was in the joblog:

Message ID . . . . . . : MCH4216 Severity . . . . . . . : 40
Message type . . . . . : Escape
Date sent . . . . . . : 08/17/20 Time sent . . . . . . :
13:21:30

Message . . . . : Automatic storage for procedure exceeds maximum.
Cause . . . . . : The object was not created because an internal system
limit was reached. Not enough automatic storage was available to
allocate a
data object within a procedure.
Recovery . . . : Reduce the number or size of automatic data objects
within
the procedure.
Technical description . . . . . . . . : The current offset in automatic
storage of the next available byte is 16051152 bytes and the maximum
offset
is 16776703 bytes. The number of bytes required to allocate the
data object
is 16000004. The dictionary index for the data object is 513, the
dictionary entry is
X'080400010000022A0000000000F4240400000024000000007000800080010000',
and the


After a lot of trial and error I moved the definition of these fields
back outside of the new subprocedure and made them global to the program.

Dcl-s HTTPResponse VarChar(16000000);
Dcl-s JSONResponse VarChar(16000000);

Now, that part of the program is happy (the SQL is still needing
attention).

Is this just a current size limit inside subprocedures or is there a
setting? I tried the *Terrabyte setting while trying to figure this
out and that caused many other errors.

It compiles fine now but putting fields outside of the subprocedure
seems counter-productive.

BTW - 7.3

TIA
Jack



[CFNC]

This email, including any documents, files, or previous email messages
attached to it, has been sent from an email account of College
Foundation Inc., (CFI) and may contain confidential, proprietary, or
legally privileged information belonging to CFI. If you are not the
intended recipient, any dissemination, distribution, or copying of
this email or its attachments is strictly prohibited. If you have
received this email in error, please immediately notify the sender by
email and destroy the original email and any attachments.
--
This is the RPG programming on IBM i (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@xxxxxxxxxxxxxxxxxxxx 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 IBM i (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@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.