When I test, I like to copy production data into the test environment. If possible, I'll take the whole file, but if it's too big, I'll subset it by selecting on various criteria. I also prefer to copy the data using CL commands, rather than writing a high-level language (HLL), because once I get my test data, I make a copy of it, out of the way, and keep refreshing my test file from that until I'm done. So, most of the time, I need to use the production files only once, when I start testing.
The Copy File (CPYF) command is the most obvious choice for pulling these records, especially if there are no complex selection criteria. However, as the selection criteria become more complex, it gets less and less useful.
I discovered that I could get everything done with two commands: Open Query File (OPNQRYF) and Copy From Query File (CPYFRMQRYF). You can do some pretty fancy stuff to set up your selection criteria using OPNQRYF. And then CPYFRMQRYF can turn the open data path created by OPNQRYF into an actual physical file with test data.
For example, I can create a control file containing the keys of specific records I want from production. If I join a specified production file to that file on those keys with the OPNQRYF, CPYFRMQRYF copies only those records defined in the control file. I can even join the production file I'm extracting to other production files if the criteria include information in other files. And these commands can be run interactively from the command line or in a simple "down and dirty" CL program-if you think you'll want to reuse the logic.
I am not spelling anything out in detail here, and there are some tricks to getting this to work, especially for the more complex selection scenarios, such as joining files. But, once I learned the tricks, I found this approach to be the very simplest and quickest.
One hint if you're doing this interactively: As soon as you're done, if you're not going to be signing right off, be sure to run the Close File (CLOF) command to close the access path that OPNQRYF leaves open.
- Rebecca Whittemore
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online