Resolving Field Names at Runtime, Part 3

Hey, Ted:

Assuming the fields are contiguous within the file, here is another solution [see links to the other articles in this series below]:

D memcpy          PR               EXTPROC('memcpy')
D  p_memD                      *   VALUE
D  p_memS                      *   VALUE
D  nByteCount                10I 0 VALUE

 *   MY_FILE has a sequence of fields 
 *        mfJan, mfFeb, ... , mfDec 
 *   defined as (8,0)

D MY_FILE_DS    E DS               EXTNAME(MY_FILE)

D monthBuckets    S              8S 0 DIM(12)

 * copy mfJan ... mfDec (from MY_FILE) into monthBuckets
C      CALLP     
           memcpy(%ADDR(monthBuckets):%ADDR(mfJan):96)

To create the program requires two steps. The first step is to run the CRTRPGMOD command to create a module. The second step is to run CRTPGM, specifying binding directory QC2LE.

Java gets a lot of the press when ILE is mentioned, but the C function library should not be overlooked.  There are numerous C functions that can be of use to the RPG programmer. And, because the C language is not object-oriented, the learning curve for most any RPG programmer can be quick.

It works great; as a plus, the code is clean and simple.

--Sean

Thanks, Sean. I had not even though of using memcpy, but that works.

For the benefit of your fellow readers, let me point out that the memcpy function requires three parameters: the address of the destination, the address of the source, and the number of bytes to copy.

After seeing your solution to this challenge, it occurred to me that memcpy also might be used as a replacement for the Move Array (MOVEA), in free-format RPG calculations.

 * to compile:
 *
 *     CRTBNDRPG PGM(xxx/MEMCPY1)
 *        SRCFILE(xxx/SRC)
 *        SRCMBR(MEMCPY1)    

H option(*srcstmt: *nodebugio)                         
H dftactgrp(*no) actgrp(*new)                          
H bnddir('QC2LE')                                      
                                                       
D MemCpy          pr             extproc('memcpy')
D  pDestination              *   value   
D  pSource                   *   value      
D  nByteCount              10i 0 value   

D ArrFrom         s         5a   dim(4)
D ArrTo           s         2a   dim(10)
D Msg             s        20a   inz('Press Y to continue.')
D Length          s        10i 0        
                                                       
 /free                                                 

    Length = %size(ArrFrom:*all);                      

    ArrFrom (1) = 'AAAAA';                             
    ArrFrom (2) = 'BBBBB';                             
    ArrFrom (3) = 'CCCCC';                             
    ArrFrom (4) = 'DDDDD';                         

    MemCpy (%addr(ArrTo): %addr(ArrFrom): Length); 

    // ArrTo now has the following values:
    //   "AA", "AA", "AB", "BB", "BB",
    //   "CC", "CC", "CD", "DD", "DD"

    MemCpy (%addr(ArrTo): %addr(Msg): Length);

    // ArrTo now has the following values:
    // "Pr", "es", "s ", "Y ", "to", 
    //  " c", "on", "ti", "nu", "e."

    *inlr = *on;                                   
 /end-free                                         

This example contains two calls to memcpy. The first copies one array to another. The second copies a scalar variable to an array.

Thanks for bring the memcpy function to our attention, Sean. It looks like I'd better take another quick read through the C functions manual and see what other goodies I can put to use.

--Ted

Resolving Field Names at Runtime, Part 1

Resolving Field Names at Runtime, Part 2

Sponsored By KISCO INFORMATION SYSTEMS

Protect your iSeries or AS/400 from unwanted network intrustions The iSeries 400 (AS/400) has changed much over the last few years. In the process, it has changed its role in most organizations from a centralized processor to a decentralized server. In the old days, you could easily point to the wealth of data security features built into OS/400. This gave you a feeling of confidence in the integrity of your data. With the recent changes, your confidence may not be as high, and rightly so! Most iSeries installations support attached PCs in some form of Client/Server function. For some shops, this takes the form of PC's that are simply running terminal and printer emulation. Many more shops are running a variety of Client/Server functions on these PCs. Neither of these arrangements bodes well in the area of network security; read on. Did you know . . . Many Client/Server functions bypass traditional OS/400 security checking unless you have fully implemented object level security. Without this same full implementation of object level security, a PC-based Client database tool, such as Microsoft Access, can ACCESS any data file on your system. That same MS Access user can UPDATE any data file on your system. The same MS Access user can even DELETE records or files on your system. SafeNet/400, from Kisco Information Systems, protects your iSeries system from unwanted and unauthorized access via network connections, including the Internet. It lets authorized users do the work they need while keeping unauthorized users out. Modern network connections, like Client Access/400, FTP, ODBC and others, can leave the information on your AS/400 exposed. SafeNet/400 closes this exposure, and it does it without forcing you to change the way you already have your system set up. For more information, visit www.kisco.com/safenet. Go to www.kisco.com/tips for free helpful advice about configuring security on your system.