IBM's standard practice is to write source members in different files, depending on the type of source you're writing. For a CL program, the source member should be in QCLSRC; if you're defining a logical file, the A-specs must be placed in QDDSSRC.
Even though this approach is well organized and may have its advantages, it does present a problem: you can inadvertently give the same name to two different members that will try to generate two objects of the same name. Since this is not permitted, the second object usually replaces the first -- and chances are you won't find out until something malfunctions.
To give you an example, suppose that the Shipping department has asked you to create a report for them, say, of return authorizations. Because you're a conscientious programmer, you begin by writing member LSTRTNAUT in QCMDSRC, for the command. Then you write member LSTRTNAUT in QCLSRC, which will be the command processing program. This CL program runs OPNQRYF to extract the information and subsequently has to call an RPG program to print the information it needs. So you write member LSTRTNAUT in QRPGSRC.
Now you compile LSTRTNAUT from QCMDSRC, LSTRTNAUT from QCLSRC, and LSTRTNAUT from QRPGSRC. This produces one command and one RPG program. The CL program was created too, but because you later created the RPG program (which has the same name), the CL program is replaced.
Good naming standards will prevent this from happening. In general, you don't want to give the same name to two source members, even if they're in different source physical files.
The problem is compounded if you have to support several libraries. You wouldn't want to end up having several objects (in different libraries) with the same name, since you would then be forced to qualify names with hard-coded library names. Using the library list is always desirable, but the library list support will stop searching at the first hit.
Enter LSTSRCMBR
Command List Source Members (LSTSRCMBR) can help you tremendously in eliminating duplicate member names. LSTSRCMBR will print a report listing all the members contained in up to 50 source files, ordered in member name sequence for your convenience.
1 shows what the report looks like. As 2a shows, the command definition is simple indeed: the single parameter SRCF accepts anywhere between 1 and 50 qualified source file names.
Figure 1 shows what the report looks like. As Figure 2a shows, the command definition is simple indeed: the single parameter SRCF accepts anywhere between 1 and 50 qualified source file names.
The command processing program (2b) is a CL program. All the program really does is to run DSPFD for each source file selected; the list of members is added to the same outfile each time. OPNQRYF sorts the outfile, and autoreport program SRC004RT (2c) prints the list.
The command processing program (Figure 2b) is a CL program. All the program really does is to run DSPFD for each source file selected; the list of members is added to the same outfile each time. OPNQRYF sorts the outfile, and autoreport program SRC004RT (Figure 2c) prints the list.
Know Your Source Members
Figure 1 Sample printed report (see issue)
Know Your Source Members
Figure 2A Command LSTSRCMBR
LSTSRCMBR: CMD PROMPT('List Source Members') PARM KWD(SRCF) TYPE(Q1) MIN(1) MAX(50) + PROMPT('Source file(s)') Q1: QUAL TYPE(*SNAME) LEN(10) MIN(1) QUAL TYPE(*SNAME) LEN(10) DFT(*LIBL) + SPCVAL((*LIBL)) PROMPT('Library')
Know Your Source Members
Figure 2B CL program SRC004CL
SRC004CL: + PGM PARM(&SRCFILES) DCL VAR(&COUNTER) TYPE(*DEC) LEN(5 0) DCL VAR(&LIB) TYPE(*CHAR) LEN(10) DCL VAR(&OFFSET) TYPE(*DEC) LEN(3 0) DCL VAR(&SRCF) TYPE(*CHAR) LEN(10) DCL VAR(&SRCFILES) TYPE(*CHAR) LEN(1002) DCL VAR(&TWO_BYTES) TYPE(*CHAR) LEN(2) CHGVAR VAR(&TWO_BYTES) VALUE(%SST(&SRCFILES 1 2)) CVTBINDEC FROMBIN(&TWO_BYTES) TODEC(&COUNTER) CHGVAR VAR(&OFFSET) VALUE(3) DLTF FILE(QTEMP/QAFDMBRL) MONMSG MSGID(CPF0000) LOOP: + CHGVAR VAR(&SRCF) VALUE(%SST(&SRCFILES &OFFSET 10)) CHGVAR VAR(&OFFSET) VALUE(&OFFSET + 10) CHGVAR VAR(&LIB) VALUE(%SST(&SRCFILES &OFFSET 10)) CHGVAR VAR(&OFFSET) VALUE(&OFFSET + 10) DSPFD FILE(&LIB/&SRCF) TYPE(*MBRLIST) OUTPUT(*OUTFILE) + OUTFILE(QTEMP/QAFDMBRL) OUTMBR(*FIRST *ADD) CHGVAR VAR(&COUNTER) VALUE(&COUNTER - 1) IF COND(&COUNTER *GT 0) THEN(GOTO CMDLBL(LOOP)) OVRDBF FILE(QAFDMBRL) TOFILE(QTEMP/QAFDMBRL) SHARE(*YES) OPNQRYF FILE((QTEMP/QAFDMBRL)) QRYSLT(*ALL) KEYFLD((MLNAME) + (MLLIB) (MLFILE)) CALL PGM(SRC004RT) CLOF OPNID(QAFDMBRL) DLTOVR FILE(*ALL) DLTF FILE(QTEMP/QAFDMBRL) ENDPGM
Know Your Source Members
Figure 2C RPG Auto Report program SRC004RT
FQAFDMBRLIP E K DISK FQSYSPRT O F 132 OA PRINTER * C MOVE MLNAME MBRNAM 10 C MOVE MLSEU2 SRCTYP 10 C MOVE *BLANK QSRCF 21 C MLLIB CAT '/':0 QSRCF C QSRCF CAT MLFILE:0 QSRCF C MOVE MLMTXT MBRTXT 50 C Z-ADDMLNRCD NBRRCD 60 C MOVE MLCDAT CRTDAT 6 C MOVE MLCHGD CHGDAT 6 * OQSYSPRT H 304 *AUTO O 'LIST SOURCE MEMBERS' OQSYSPRT D 1 *AUTO O MBRNAM 'Member Name' O SRCTYP 'Source Type' O QSRCF 'Source File' O MBRTXT 'Member Text' O NBRRCD1 'Nbr Records' O CRTDAT 'Created' O CHGDAT 'Changed'
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