Change opcodes to free format

[michal2442]

Hi, can you tell me how to rewrite this operations into free-format RPGLE ?

     c                   move      '1'               Zapis
     c                   movel     'SYSTEM'      User_
     c                   z-add     40                Operacja
     c                   move      PROTDT        ActionDta
     c                   out       ARA

     c                   movel(p)  SUBMIT        Command1        200
     c                   call      'QCMDEXC'
     c                   parm                    Command1
     c                   parm      200           cmdlen           15 5

[tomliotta]

Re: Change opcodes to free format

In order to be certain, we would need to see the variable definitions for everything. In order to know what MOVE or MOVEL will do, we need to know data types and sizes. (That's also true for CALL statements, but it's fairly clear in the existing code.)

[michal2442]

Re: Change opcodes to free format

ok, so all variables are in data area ARA.
Zapis is 1 char text.
User_ is 10 char text
Operacja is number 3 0
Protdt and ActionDta are number 7 0

SUBMIT is text of command which has to be executed.

[DAG0000]

Re: Change opcodes to free format

Most of this isn't very complicated:

D ExecCMD         PR                  ExtPgm('QCMDEXC')          
D  Command                   32702A   Const Options(*Varsize)    
D  Length                       15P 5 Const                      
                                                                 
  Zapis = '1';                                                   
  %SubST(User_:1:6) = 'SYSTEM';                                  
  Operacja = 40;                                                 
  ActionDta = PROTDT;                                            
  Out ARA;                                                       
                                                                 
  ExecCMD(Command1:%Len(Command1));

What you most likely want to watch out for was the MoveL you were doing with User_, because your only populating the first 6 bytse of User_ and the remaining 4 are not changed.
I don't even remember the last time I used the CallP op code.

[Rocky]

Re: Change opcodes to free format

Or one step further for full free format:

      // Prototype for 'QCMDEXC'
       DCL-PR Qcmdexc EXTPGM('QCMDEXC');
         Command_    Char(32702) Const Options(*Varsize);
         Length_     Packed(15:5) Const;
       END-PR Qcmdexc;

       //---------------------------------------------------------------------
       // Stand Alone Fields - TOP
       //---------------------------------------------------------------------
       DCL-S Command1 CHAR(200);

        //---------------------------------------------------------------------
        // Stand Alone Fields - BOTTOM
        //---------------------------------------------------------------------

       Zapis = '1';
       %Subst(User_:1:6) =  'SYSTEM';
       Operacja = 40;
       Actiondta = Protdt;
       Out Ara;
       Command1 = Submit;
       Qcmdexec(Command1 : %Len(Command1));

[DAG0000]

Re: Change opcodes to free format

Being able to write a write a Long field or Procedure names on one line is about the only benefit I am seeing from using DCL-XXX for fields and procedures.
Also I will never call this latest iteration of RPG "FULLY FREE" until IBM finally eliminates the 80 column limit.

[Rocky]

Re: Change opcodes to free format

Not having to be column dependent is what I like about it - though in the F & D specs not that big a deal - and the 80 column limit is, IMO, not a problem. If you have to scroll right or left to see the entire line it needs to be reformatted anyway if for no other reason than readability.

With the use of SQL and hence, the longer field names, the longer field names can be a big deal. Declaring variables VARCHAR or ZONED or PACKED to me is a lot clearer than the D specs - so in some ways the DCL statements clarify code.

The only thing I don't like is always having to have DCL-S for standalone variables - but I deal with that by just specifying DCL-DS STANDALONE and putting the standalone variables in that data structure...

The things I have always detested about RPG is the column dependency and numbered indicators - the last iteration of free form solved most though I still disliked the /end-free /free statements as they were, well, there's just no kind way to say it, STUPID and cluttered up the code needlessly - for every procedure having to specify /END-FREE and /FREE statements to allow for the P & D specs was just plain silly.

Now - if one likes the F & D specs... use them. If you like the DCL-## - use them. I'll never go back to P specs - much prefer the DCL-PROC/END-PROC.

[Brian Rusch]

Re: Change opcodes to free format

One nice benefit of the update to allow all free form code is eliminating the need to code /FREE and /END-FREE whether the program is all free or a mixture of free and fixed code.

[tomliotta]

Re: Change opcodes to free format

ok, so all variables are in data area ARA.
Zapis is 1 char text.
User_ is 10 char text
Operacja is number 3 0
Protdt and ActionDta are number 7 0

Okay, so the ARA data area holds a DS (data structure) consisting of the named fields. Are the fields in the order that you listed? For the fields that you say are "number", are they packed or zoned numbers?

How large is the ARA data area? Do the variables fill the entire data area? (If not, does the remaining part of the data area contain any data that needs to be kept?)

Other posts mention most parts of your question. The data area specs can be done a few variations. Here's one possible example:

     D ARA_DS         UDS           100    DTAARA( ARA )
     D  Zapis                         1
     D  User                         10
     D  Operacja                      3s 0
     D  Protdt                        7s 0
     D  ActionDta                     7s 0

      /free

        out ARA ;

      /end-free

In that example, the ARA data area is assumed to be 100 bytes long, and the fields don't fill the entire data area. (The "100" isn't needed if the fields cover the whole data area and might not be needed if you don't care about any extra bytes.)

The "number" fields are explicitly declared here as zoned (data type "S"). For zoned sub-fields of a data area data structure, you can specify a blank instead of "S". If those "number" sub-fields are packed, you must specify a data type of "P". It can be a good practice always to specify data types.

There are some other possible details such as how to specify locking and the data area name, but the Information Center already has all of the details.

[tomliotta]

Re: Change opcodes to free format

...- though in the F & D specs not that big a deal - and the 80 column limit is, IMO, not a problem.

I especially like not having to use ellipsis ("...") to continue a long name for LIKEDS(), etc. When searching source for all references to a data structure name, it can be tricky when only part of the name is on one source line and the other part is on the next line. Too many false positives in various cases.

... there's just no kind way to say it, STUPID and cluttered up the code needlessly - for every procedure having to specify /END-FREE and /FREE statements to allow for the P & D specs was just plain silly.

I partially disagree. It was a way to transition from old format to new. I suspect that it wouldn't have happened nearly as soon if the entire set of specs had to be done at the same time. It was an inconvenience to be sure. However, IMO, the advantages we gained were worth it even if we had to wait for it to be finished.

[Rocky]

Re: Change opcodes to free format

I partially disagree. It was a way to transition from old format to new. I suspect that it wouldn't have happened nearly as soon if the entire set of specs had to be done at the same time. It was an inconvenience to be sure. However, IMO, the advantages we gained were worth it even if we had to wait for it to be finished.

I wouldn't have an issue with the P specs if it wasn't for the silly /FREE, /END-FREE statements. It's not that hard - if there was something in column 6 it is a statement in fixed format - if not it would be free format.

[jtaylor___]

Re: Change opcodes to free format

IMO, the fuss over /FREE & /END-FREE was just silly, and the 80 column limit is a much greater hassle than fixed-format H, D & P specs ever were.

[Rocky]

Re: Change opcodes to free format

It's always a manner of perspective - the 80 column limit to me is silly as, IMO, lines that long should be formatted differently anyway for readability sake. The /FREE and /END-FREE is a nuisance problem technically except the compiler complained profusely if you happened to forget to put them in... it would be one thing if they had any value or added anything to the code - but all they did was tell the compiler what was already obvious by virtue of column 6 - it either has a blank (free format) or it isn't (fixed format). In short - they cluttered code for no purpose but the compiler complained if you didn't have them.

[Scott Klement]

Re: Change opcodes to free format

For the 80-column problem... why not file a requirement with COMMON and maybe you can get IBM to fix it?

For the /FREE and /END-FREE problem... I already filed a requirement with them in 2012, and this restriction has already been removed. Is there really more to say on this topic?

[Rocky]

Re: Change opcodes to free format

Come on Scott - the dead horse hasn't been beaten enough yet... there's still a carcass!