If you use the Submit Job (SBMJOB) command in a CL program to submit to batch a CALL to another CL program, be aware that the SBMJOB command can corrupt the parameter data if:
the parameter data being passed is in a character variable,
the character variable is longer than 32 characters, and
the character variable ends in one or more blanks.
To try one case on for size, see Figures 1a and 1b, which list programs X and Y.
When you CALL program X from the keyboard, program Y runs in batch and sends three messages to QSYSOPR. The first one contains the letter A (plus 29 blanks), the second message contains the letter B (plus 29 blanks) but the third message contains the letter C plus a lot of garbage. The funny thing is that if you change program X so that it CALLs program Y (instead of submitting to batch), all three messages arrive clean and proper into QSYSOPR.
Editor's Note: We believe that operating systems should work in a sensible manner, without requiring the user (or programmer) to remember exceptions to the rules or strange behavior patterns that violate common sense. Therefore, we reported this as a bug to IBM Level 2 and were told, in a nutshell, that this is the way OS/400 works. They faxed us a printout of the closure of APAR SA05183, dated July 31, 1989 (someone else was bitten by the same bug, apparently). The document includes the following text:
When the CALL command is being used as the argument for the SBMJOB command, it operates as a noncompiled CALL command (interactive CALL). Therefore, the rules for passing parameters in the embedded CALL code are the same as if the CALL command is run from the Command Entry screen or the command line. These rules apply whether or not the SBMJOB command is being invoked inside the CL program, any other High Level Language program or from the command line.
The following rules apply to passing parameters if the CALL command is invoked via the SBMJOB command issued by a CL program:
Character string constants of 32 bytes or less are always passed with a length of 32 bytes (padded on the right with blanks).
Constants longer than 32 characters are not padded to the length expected by the receiving program. In this case the calling program passes the exact number of bytes.
Character strings, resulting from variables substitutions, of 32 bytes or less are passed with a length of 32 bytes (padded on the right with blanks).
If the resulting string is longer than 32 bytes, the exact number of bytes up to the last nonblank character is passed to the receiving program, not padded to the length expected by the receiving program.
Neither the variables length defined in the calling program nor the receiving program have any effect on how the parameters are passed.
Numeric variables (whether passed as constants or passed as variables declared as numerics in the calling program) are passed in packed form and with a length of (15 5). Thus, the receiving program must declare the decimal field with a length of (15 5).
These limitations are unreasonable and should be eliminated. The SBMJOB command is old and probably has undergone very little change since Release 1 of CPF, the System/38's operating system, circa 1980. We think it's time IBM made a complete overhaul of some of this ancient code.
In the meantime, we need to circumvent the problem. See Figures 2a and 2b. They implement a character string one byte longer than necessary, which we set to a nonblank character in order to force the parameter data to end in a nonblank character. Alas, there's no circumvention for numeric parameters other than passing them as character and converting them to decimal inside the submitted program. Didn't we say it stinks?
TechTalk: Nasty, Nasty, Nasty!
Figure 1A Program X
Figure 1a: Program X X: PGM DCL VAR(&STRING) TYPE(*CHAR) LEN(90) DCL VAR(&PART1) TYPE(*CHAR) LEN(30) DCL VAR(&PART2) TYPE(*CHAR) LEN(30) DCL VAR(&PART3) TYPE(*CHAR) LEN(30) CHGVAR VAR(&PART1) + VALUE('A ') CHGVAR VAR(&PART2) + VALUE('B ') CHGVAR VAR(&PART3) + VALUE('C ') CHGVAR VAR(&STRING) VALUE(&PART1 *CAT &PART2 *CAT + &PART3) SBMJOB CMD(CALL PGM(Y) PARM(&STRING)) ENDPGM
TechTalk: Nasty, Nasty, Nasty!
Figure 2A Program Y
Figure 2a: Program Y Y: PGM PARM(&STRING) DCL VAR(&STRING) TYPE(*CHAR) LEN(90) DCL VAR(&PART1) TYPE(*CHAR) LEN(30) DCL VAR(&PART2) TYPE(*CHAR) LEN(30) DCL VAR(&PART3) TYPE(*CHAR) LEN(30) CHGVAR VAR(&PART1) VALUE(%SST(&STRING 1 30)) CHGVAR VAR(&PART2) VALUE(%SST(&STRING 31 30)) CHGVAR VAR(&PART3) VALUE(%SST(&STRING 61 30)) SNDMSG MSG(&PART1) TOUSR(QSYSOPR) SNDMSG MSG(&PART2) TOUSR(QSYSOPR) SNDMSG MSG(&PART3) TOUSR(QSYSOPR) ENDPGM
TechTalk: Nasty, Nasty, Nasty!
Figure 2A Program X, revised
Figure 2a: Program X, Revised X: PGM DCL VAR(&STRING) TYPE(*CHAR) LEN(91) DCL VAR(&PART1) TYPE(*CHAR) LEN(30) DCL VAR(&PART2) TYPE(*CHAR) LEN(30) DCL VAR(&PART3) TYPE(*CHAR) LEN(30) CHGVAR VAR(&PART1) + VALUE('A ') CHGVAR VAR(&PART2) + VALUE('B ') CHGVAR VAR(&PART3) + VALUE('C ') CHGVAR VAR(&STRING) VALUE(&PART1 *CAT &PART2 *CAT + &PART3 *CAT '*') SBMJOB CMD(CALL PGM(Y) PARM(&STRING)) ENDPGM
TechTalk: Nasty, Nasty, Nasty!
Figure 2B Program Y, revised
Figure 2b: Program Y, Revised Y: PGM PARM(&STRING) DCL VAR(&STRING) TYPE(*CHAR) LEN(91) DCL VAR(&PART1) TYPE(*CHAR) LEN(30) DCL VAR(&PART2) TYPE(*CHAR) LEN(30) DCL VAR(&PART3) TYPE(*CHAR) LEN(30) CHGVAR VAR(&PART1) VALUE(%SST(&STRING 1 30)) CHGVAR VAR(&PART2) VALUE(%SST(&STRING 31 30)) CHGVAR VAR(&PART3) VALUE(%SST(&STRING 61 30)) SNDMSG MSG(&PART1) TOUSR(QSYSOPR) SNDMSG MSG(&PART2) TOUSR(QSYSOPR) SNDMSG MSG(&PART3) TOUSR(QSYSOPR) ENDPGM
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