× 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.


  • Subject: Re: using a defined constant to dimension an array
  • From: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
  • Date: Wed, 04 Jul 01 16:18:19 +1000
  • Importance: Normal


Barbara wrote:
>By the way, INZ(*SYS) (but not INZ(*JOB)) is allowed in subprocedures
>starting in V4R4.

Yeah, but it's broke!  (Well certainly for TIME and TIMESTAMP and I assume 
DATE too).  I raised APAR SA92403 for this problem.  The issue is that a 
TIME or TIMESTAMP (and probably DATE) data structure subfield initialised 
to *SYS defined in a subprocedure is not reinitialised on subsequent calls 
to the procedure.  (Since INZ(*SYS) and INZ(*JOB) arrived in VRM370, not 
supporting them in procedures until VRM440 seems a silly oversight.  And 
why can't I use INZ(*JOB) in a procedure?)

>Simon, it's not that it parses the subprocedures before the global
>definitions, but rather that it can't consider any global definitions 
>until it has finished parsing the subprocedure, in case there is a later 
>definition within the subprocedure.  We _could_ have "fixed" the DIM 
>problem earlier by making a rule that DIM did an immediate global lookup, 
>but that would have forever precluded the possibility of 
>forward-referencing for DIM that was added in V5R1.

Hans wrote:
>No, the problem is that within a procedure names are assumed
>local until the end of the procedure is reached.  Then, if
>there are any names undefined, they are searched for in the
>global scope.  Since the parameter of DIM must (prior to V5R1)
>be previously defined, coding a global constant name for DIM
>will always result in an error since the name is not considered
>defined within the procedure until the end of the procedure is
>processed.

I simply repeated what I was told by IBM support.  It is quite likely that 
it lost something in the translation.  However, I don't understand why the 
parsing process can't scan the current procedure for the constant and if 
not found then check the global D-specs.  It doesn't seem too difficult.  
The restriction that DIM parameters be defined before use seems excessive 
-- one might say dim but that pun is just too obvious.

Regards,
Simon Coulter.


 FlyByNight Software         AS/400 Technical Specialists       
 Eclipse the competition - run your business on an IBM AS/400.  
                                                                
 Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\   
 Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /   
                                                           X    
               ASCII Ribbon campaign against HTML E-Mail  / \   

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.