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





You're right, Alan,

LDA is initialised (cleared) on each sign-on,
but that absolutely wasn't the problem here:

I'll explain:
     During a session, pgm1 can be called again and again: (call PGM1, doing the
business , back to the menu, or sign off, ... whatever)

     Also, pgm2-3 toggle can be left (ctl back to pgm1) to define for instance
another order to process.

     Key problem was that in pgm1, after defining the order to be processed,
     the pgm was to (re)initiate the *LDA with the last entity value processed;
If nothing found yet, entity-value was to be set on '00000'

     Then, after selecting an orderline (pgm2), the orderline got processed
(pgm3):
     and in pgm 3 the *LDA was retrieved and incremented. After processing, pgm3
was ended (LR), ctl going back to pgm2.

     This (pgm3) worked
          (records processed here showed an incremented entity: 00001, 00002,
00003, ...)

     while the same type of coding in pgm1 didn't seem to work
     even though debugging showed me that the last/highest entity# was indeed
found.
          (next pgm1-call/ctl:  --> back to entity 00001 for the same order)

     *LDA was supposedly  ( and is ! ! ! ) perfect for the job, since this pgm
is run from only 1 wstn per order.

Now it works.
(Also, Scotts' mail on the subject was very enlightning; In reflection, the
solution I concocted earlier on is more or less the same)

Greetings, Michel

               ___________________________________________________




|--------+----------------------->
|        |          "alan shore" |
|        |          <SHOREA@dime.|
|        |          com>         |
|        |                       |
|        |          11/04/01     |
|        |          18:54        |
|        |          Please       |
|        |          respond to   |
|        |          RPG400-L     |
|        |                       |
|--------+----------------------->
  >----------------------------------------------------------------------------|
  |                                                                            |
  |       To:     RPG400-L@midrange.com                                        |
  |       cc:     (bcc: Michel Cuypers/New Wave Logistics Belgium)             |
  |       Subject:     Re: LDA-problem got solved                              |
  >----------------------------------------------------------------------------|




Sorry, I could'nt resist that prior reply. However, it seems that my previous
comment that a Local Data Area (Object Type *LDA) is initialised with each sign
on
and I quote
                          Data area (DTAARA) - Help


                outside the group.  The length of this character data

                area is 512 bytes.


           *LDA

                The local data area is displayed.  The local data area
                (*LDA) is a character data area 1024 bytes in length.
                It is automatically associated with your job and

                cannot be accessed from another job.


end-quote.

>>> <michel.cuypers@newwave.be> 04/11/01 12:17PM >>>


Hi, Y'All,

Problem is cracked 'n solved.

Thanks to Mike & Alan
     (Alan, also: sorry for being somewhat sarcastic, earlier-on)

Even though processing seemed to work in pgm3, and (+- identically coded) in
pgm1,
You guys got me thinking about the *LDA definition itself,
and I changed the LDA-coding as follows:

PGM1:
     D* LDA (LAST USED ENTITY NR)
     D                 DS
     D  $LDA                   1   1024
     D  ENTITY              1020   1024
     . . .
     C     *DTAARA       DEFINE    *LDA          $LDA

     . . .  Calculating $ENTY ...
     C* FILL IN LDA
     C                   IN        $LDA
     C                   MOVEL     $ENTY         ENTITY
     C                   OUT       $LDA
     C*

PGM2: No LDA-processing, whatsoever.

PGM3:
     D* LDA (LAST USED ENTITY NR)
     D                 DS
     D  $LDA                   1   1024
     D  ENTITY              1020   1024
     . . .
     C     *DTAARA       DEFINE    *LDA          $LDA

      C* NEW ENTITY
     C* KEEP IN LDA
     C                   Z-ADD     0             $ENTY             5 0
     C*
     C                   IN        $LDA
     C                   MOVEL     ENTITY        $ENTY
     C                   ADD       1             $ENTY
     C                   MOVEL     $ENTY         ENTITY
     C                   OUT       $LDA
********
Finally,it works...
     Even though I still don't get it why it did work in pgm3 and NOT in pgm1.
(Pgm3 was ended after each processing, as You recall ...)

Greetings, Michel



+---
| 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
+---

+---
| 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
+---




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