ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Data area as variable

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Data area as variable

    I'm writing an RPG process that uses several data areas, one for each workstation.
    In the program, I retrieve the job name which is the data area name as well. How can I use the data area name with an IN or OUT opcode?
    Everyday's a school day, what grade are you in?

  • #2
    You could do a qcmdexec to overide the name before doing the In and out. Or instead of a qcmdexec to it in a CL program.. So call the CL program from inside the RPGLE program or wherever really..

    Comment


    • #3
      <Edited to reflect "JOb" not "terminal">

      My initial thought is "Why on earth do it that way". It creates a requirement to create a new data area for each job. Not to mention that they all need to be deleted at some point in the future.

      If you don't want to use a database, keyed on job, then use a User Space with all the jobs in one place and index into it. Or for that matter use a User Space for each job rather than a Data Area. They are always opened by name and are "just memory" so there is no requirement to use IN/OUT. Just change the variable. Of course things still need to be cleaned up.

      Since the data is all apparently job related is using QTEMP not a possibility? Then all the names can be the same.
      Last edited by JonBoy; August 13, 2018, 12:21 PM.

      Comment


      • #4
        I think this should work:
        Code:
        D psds           SDS                                  
        D  job                          10    overlay(psds:244)
        
        D dtaaraname      S                   dtaara(*var:job)
        
           IN  dtaaraname;

        Comment


        • #5
          You can have the data area name in a variable in your RPG code.
          • For fixed-form D specs, code the DTAARA keyword as DTAARA(*VAR : field_name).
          • For free-form D specs, the DTAARA keyword as code DTAARA(field_name).

          Code:
          [FONT=courier new]dcl-s myDtaara char(200) dtaara(dtaaraName);
          dcl-s dtaaraName char(21);
          
          dtaaraName = whatever ...
          in *lock myDtaara;
          out myDtaara;[/FONT]

          Comment


          • #6
            JonBoy,
            I'm doing it this way because I need to change a value based on the terminal name (we have terminals around the building which require certain scanning operations be performed at each) an then based on the terminal, update the data area for use by another program to yada, yada, yada.....

            Everyone else,
            Unfortunately, although I appreciate all the help, can your suggestions be done in RPG III - what's used in this shop. I tried it a few different ways but couldn't get it to work.
            Everyday's a school day, what grade are you in?

            Comment


            • #7
              Originally posted by redvan View Post
              JonBoy,
              Unfortunately, although I appreciate all the help, can your suggestions be done in RPG III - what's used in this shop. I tried it a few different ways but couldn't get it to work.
              <SOB> I think I'll just go and shoot myself. New code being written in a language that was made obsolete 22+ years ago ...

              There is NO possible excuse for that.

              User Spaces would work but since RPG III can't map them to memory directly would require the same kind of IN/OUT operations that Data Areas need - so no advantage.

              Seriously? RPG III - good grief. Do they still use punch cards?

              Comment


              • #8
                I have to know... why RPGIII? Is it simply an incredibly old box that can't be replaced/upgraded, that is so old it can't handle newer RPG?

                Another workaround - write a CL program to read/write the data area and call that, instead of using in/out. In a CL program you can use a variable for the name of the data area. I don't know for sure, but I assume that was true even in the RPGIII days.

                Comment


                • #9
                  If I was absolutely unable to use ILE RPG, well, I can't actually imagine that. But assuming a bit of time travel, so I'm back before ILE RPG existed, I would use CL programs to lock, retrieve, and update the required data area. But beware, the locking rules for ALCOBJ are different from RPG's locking rules. And it's tricky to make sure you DLCOBJ in all cases.

                  Even if you get it working with CL, you'll need a lot of testing to make sure your data area is unlocked correctly if your program crashes.

                  Since it will be a LOT of extra work to get this working correctly without using ILE RPG, maybe that will be enough reason to get permission to write this particular program in ILE RPG.

                  Comment


                  • #10
                    There's always QWCRDTAA to retrieve (and QCMDEXC with CHGDTAARA command to make changes). So all of this CAN be done from RPG III.

                    But.. why?

                    Comment

                    Working...
                    X