Suppose you work with a network of several AS/400s located in different branches of your company. One day, you need to get a several hundred line source program to another machine. What do you do?
A. Fax the listing and rekey the source program.
B. Save the source code to tape and send it overnight express.
C. Try to configure SNADS so you can send the source member with the Send Network File (SNDNETF) command.
D. Try to find the documentation for the file transfer subroutine, QY2FTML, and write a short program.
E. Run one command to create a Distributed Data Management (DDM) file and use the Copy File (CPYF) command to transfer the source to the other machine.
The simplest technique is E: create the DDM file, then use CPYF. Since this is a source file with only a few hundred records, you can probably do it in five minutes. Any of the other techniques will take much longer and will involve either more research, programming, or manual steps.
Even so, you probably didn't think of using DDM; if you did, you may have dismissed it out of hand. After all, you've heard DDM is slow and it involves communications functions you'd rather avoid. As I've pointed out before, though, if you can start Display Station Pass-through (DSPT) to another system, you can use other communications functions, including DDM (see "Understanding Display Station Pass-through," MC, March 1995). If you are involved with programming and you work with several AS/400s, you owe it to yourself to become familiar with DDM. (By the way, the documentation for the QY2FTML program is in the ICF Programming manual.)
What Is DDM and What Does It Do?
DDM is a technology that originated back when the S/36 and S/38 were young. DDM is implemented as an APPC/APPN function and is available for mainframes and other IBM machines, including the AS/400, PC, S/36, and S/38.
Simply put, DDM lets a program on your source machine access a database file on another machine as if the remote file were local to your machine. That means your program does not have to be changed to access the file; DDM works in conjunction with the operating system to make the file appear local.
An example of where you might use DDM is an inventory application, where database files on remote machines have inventory data. You can create a function in your inventory inquiry program to display the data from the remote machines along with the data from your machine. In the future, DDM will be used less in application programs. The preferred approach will be Distributed Relational Database Architecture (DRDA).
You will probably use DDM more as a utility function, as in the example of copying source to another machine. For these purposes, DDM is the simplest technique.
In addition to providing access to remote files, DDM provides an extremely curious function, the Submit Remote Command (SBMRMTCMD) command, which lets you submit a command to another system. I'll cover this in more detail later.
DDM Terminology
Although you can use DDM as soon as you have an APPC/APPN connection to another system, there are some DDM specific constructs you should be familiar with. As with all communication functions, you are affecting two machines, so it helps to have terminology to describe the processes on both machines.
The source system is where the application program requesting access to a remote database file through DDM is run. The application program can be a program that you create (e.g., an RPG program) or it can be a CL command (e.g., CPYF). The remote database file is located on the target system.
The source and target systems are connected with APPC/APPN. In an APPN network of machines, the source and target systems can be connected through intermediate machines. The application program is not aware of the intermediate systems; it simply works with the source and target.
A DDM file is a file object located on the source system. DDM files are unusual in that they describe a database file but contain no data, members, or field definitions. Instead, a DDM file points to the actual database file on the target system.
When you run a program that uses a DDM file, a source DDM job is started on the source system. A corresponding target DDM job is started on the target system. You don't usually have to be concerned with the source or target DDM jobs, but you should be aware that DDM imposes more work on the two systems.
Defining a DDM File
The Create DDM File (CRTDDMF) command uses parameters that apply to both database file objects and to APPC communications. DDM files do not contain data; there are no DDS specs or record lengths associated with them. The DDM file name can be the same as the database file name on the remote system.
The four groups of parameters used on CRTDDMF are shown in 1. The only required parameters are FILE (the name of the DDM file on the source system), RMTFILE (the name of the database file and optionally the member on the remote system), and RMTLOCNAME (the name of the remote location where the database file is located).
The four groups of parameters used on CRTDDMF are shown in Figure 1. The only required parameters are FILE (the name of the DDM file on the source system), RMTFILE (the name of the database file and optionally the member on the remote system), and RMTLOCNAME (the name of the remote location where the database file is located).
The FILE parameter can be any name you want. It may make sense to use all 10 characters allowed in a file name-even if you will be using the DDM file with RPG programs-since you will probably be using an Override Database File (OVRDBF) command with the DDM file.
For RMTFILE, supply the qualified name of the file on the remote system. Note the format for specifying a member name, as shown in 1.
For RMTFILE, supply the qualified name of the file on the remote system. Note the format for specifying a member name, as shown in Figure 1.
The RMTLOCNAME is the name of the remote system. If you have established a DSPT session to the remote system, you can use the same remote location name for the DDM file that you use for the DSPT session. The remote location name is the default local location name of the remote system, which you can find by using the Display Network Attributes (DSPNETA) command on the remote system.
The CRTDDMF command runs very quickly, because there are no DDS statements to process. Also, the existence of the file on the remote system is not verified when you run CRTDDMF. You are not even required to have an active connection to the remote system when you run the command.
Using a DDM File
You will typically use a DDM file either with a high-level language (HLL) application program or a command that includes a file parameter. An example of using DDM files with an HLL program is an inquiry program in which you need to view data from files on other systems. An example of using a DDM file with a command is using the CPYF command to copy a member from one system to another.
When used with an HLL program that references the file as externally described, you'll need to use OVRDBF prior to starting the HLL program and, unless you have a similar externally described file on your system, prior to compiling a program that references a DDM file. On the OVRDBF command, specify the program file name in the FILE parameter and the name of the DDM file in the TOFILE parameter. When the program opens the file, it opens it on the remote system. You'll need to ensure that communication to the remote system is active before you open the DDM file in your program.
When used in a command like CPYF, you can usually just specify the name of the DDM file you want to copy to or from. For example, you can use a DDM file in the FROMFILE or TOFILE parameters, or both.
Many system-supplied create, change, and display commands include a SYSTEM parameter. The default value for the SYSTEM parameter is *LCL, meaning that the file is local to the system the command is run on. You can specify *RMT to indicate that the file is a DDM file, or *FILETYPE to indicate that the file may be either local or remote, depending on the definition of the file. If you do not specify a library qualifier for the file, the first occurrence of the file name in the library list is used, and the type of file is determined from that.
DDM Conversation Control
Because DDM files use communications, they have the potential to impact other communications work. Techniques are available to control that impact. When using DDM to another system, you are using one of the available sessions of a communications link. The number of sessions for a link and characteristics of those sessions are defined through a mode description object (*MODD), which the DDM file references. Other communications work (DSPT, SNADS, other DDM users) may be competing for the bandwidth available within the mode. The goal is to release the session as soon as possible.
You have two ways to control session usage. The first is with the DDMCNV job attribute. The default value for this parameter is *KEEP. The DDM conversation is kept active within the job, even if all DDM files used in the job have been closed. This might be advantageous in applications that require good response time and reservation of a session.
For example, an inquiry application may include several different programs that use DDM files on a menu. If it is likely that the user will access the programs throughout the day, it makes sense to keep the conversation active, even when the inquiry programs are not being used and the DDM files are closed. Keeping the conversation active helps avoid the overhead of establishing the session and, perhaps more importantly, reserves the session, so the chance of receiving a "Session Not Available" message is decreased when the user restarts a program.
The second technique uses either the *DROP value for the job's DDMCNV attribute or the Reclaim DDM Conversation (RCLDDMCNV) command. You can use the Change Job (CHGJOB) command with DDMCNV(*DROP). You would typically run either of those commands after the program that used the DDM files finished or closed the files. For example, a long-running batch program might use DDM files at a certain point, then no longer require them. To free the session, you could issue either command within the batch job stream.
The conversation is dropped only when there are no open DDM files. The CHGJOB technique sets a condition for the job in that the session is dropped as soon as the last DDM file is closed. RCLDDMCNV will drop the session only if all DDM files are closed when it is run; otherwise, it simply stops the target DDM jobs.
The Reclaim Resources (RCLRSC) command can also be used to reclaim a DDM conversation, but that command affects more than just DDM conversations.
DDM Access on the Remote System
There are other attributes of DDM to consider. For example, in addition to object authority to DDM files on the source system, the database files on the target system, and APPC device security, you can set the DDM Access (DDMACC) network attribute value on the target system. This attribute is used to indicate whether or not the target system will accept DDM requests.
You can view the current value of DDMACC with DSPNETA, and change the value with the Change Network Attributes (CHGNETA) command. The default value, *OBJAUT, means that object authority of the objects on the remote system is used to control access to the objects. A value of *REJECT means that no DDM requests are accepted by the target system. You can also specify an exit program, which you provide, that receives a parameter list indicating the user profile, type of request, and other information, and provides a return code, indicating your acceptance or rejection of the request. For example, you might want to limit DDM access to certain days and time periods; you can accomplish that with an exit program.
The DDMACC network attribute also controls old-style PC Support type 0 and type 1 shared folders and the use of the remote command function.
The Remote Command Function
Using what looks to be an afterthought, it is possible to submit a command to a remote system through a DDM file. This is accomplished with SBMRMTCMD. You can use this command to run a command on another system, without first having to establish a DSPT session to the system.
SBMRMTCMD uses a DDM file on your system simply as a pointer to the other system. The most relevant parameters from the DDM file are the remote location name and the mode name. The actual file name on the remote system, as specified in the DDM file on your system, is not used.
The CMD parameter of SBMRMTCMD is used to specify the CL command that you want to run on the remote system. The command must be allowed in both batch and interactive environments on the target system in order to be run with SBMRMTCMD. The command should make sense; for example, you cannot use SBMRMTCMD to run the Work System Status (WRKSYSSTS) command on the remote system and expect to see the display at your terminal.
"Submit" does not mean that the command is submitted to batch on your system. If you run SBMRMTCMD in your interactive job, you will tie up your job for as long as the command takes to run on the remote system. You can use SBMJOB on your system to run SBMRMTCMD on a target system.
I would be extremely reluctant to publicize the use of SBMRMTCMD to users. If you want to submit jobs to a remote system, you should investigate SNADS Submit Network Job (SBMNETJOB) command. With SNADS, you have better traceability of the job on both the source and target systems.
From There to Here
Is DDM on the way out? For most application program work, DDM is probably not the preferred technique when it comes to performance. With the improvements to the AS/400 database in V3R1, you should investigate using database facilities rather than the file-oriented DDM.
In some cases, though, DDM may be the simplest technique to access data on another machine. It's ideal for batch work, where response time is not an issue. DDM can be a lifesaver for programming work, where moving source code around quickly is required.
Craig Pelkie can be contacted through Midrange Computing.
References ICF Programming V3R1 (SC41-3442, CD-ROM QBKANU00). OS/400 Distributed Data Management V3R1 (SC41-3307, CD-ROM QBKALH00).
Distributed Data Management: From There to Here
Figure 1 CRTDDMF Command Parameter Grouping
File Related FILE-the name of the DDM file on the source system. This follows normal file naming, with the library/file name convention. LVLCHK-level checking in effect for the DDM file. AUT-authority used with the DDM file. REPLACE-replace existing DDM file. SHARE-share Open Data Path (ODP). TEXT-text description. Remote File ID RMTFILE-the name of the database file on the remote system. This can be specified in one of two ways: 1. No member required. RMTFILE(library/filename) 2. Member name required. RMTFILE(*NONSTD 'library/filename(member)') *NONSTD also allows naming conventions other than those used by the AS/400, S/38, and S/36. APPC/APPN RMTLOCNAME-the name of the remote location (target system) where the file specified in RMTFILE is located. DEV-the APPC communications device used to connect to the target system. LCLLOCNAME-name of the local location being used to con tact the remote location. MODE-name of the mode description used when the APPC session is established. RMTNETID-APPN network ID associated with the remote location. How Used ACCMTH-used when remote file is not on an AS/400 or S/38. Lets you request access by key, relative record number, or both. PTCCNV-protected conversation used if two-phase commitment control is used with this DDM file.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
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