Re: Fields too large for a Subprocedure - CWX9001

[Charles Wilt <charles.wilt@xxxxxxxxx>]

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