From: Willie Moore To: All
I am starting to convert S/36E RPG/FMT programs to native. The S/36E procedures use a MSGF36 to display information to the user as shown in 2.
I am starting to convert S/36E RPG/FMT programs to native. The S/36E procedures use a MSGF36 to display information to the user as shown in Figure 2.
I know I have to create a message file, but am not sure how to get the program to use it. If anyone could give me any ideas on how to do this, it would be greatly appreciated.
From: Pete Hall To: Willie Moore
If you name your message file USR1 (or override to USR1), and if you prefix your S/36E message IDs with USR (1001 becomes USR1001), your S/36E message output will work without modification. There is a CRTS36-MSGF command, which will convert your S/36E message source to a native message file, and CRTS36- DSPF can convert your S and D specs to DDS, including the MICs. CRTS36-DSPF likes to put INVITEs in where they're not wanted, and usually seems to add (*PGM) after the PRINT keyword, which makes the print key dysfunctional; but other than that, I've not had any problems, and I have converted a bunch of display files that way.
From: Willie Moore To: Pete Hall
I got the display file converted. Now when I try to compile the RPG program I get the following message: QRG6044 (Externally described field name exceeds six characters). The fields are MIC0000001 and MBR-0000001. These fields are from the display program. I tried the KRENAME keyword but it did not work- said could not find format. Any ideas where to go from here?
From: Pete Hall To: Willie Moore
KRENAME is only used for record names. In order to rename a field, you need to enter an I-spec for the record, and then an I-spec for each field being renamed, with the external and RPG names. Since you're working with a display file though, it would probably make more sense to simply rename the fields in the display file. There is no particular significance to the names that CRT- S36DSPF generates. These fields are really intended to be used by program- described display files, which is what I (fool that I am) figured you were doing.
From: Willie Moore To: Pete Hall
Thanks for the information. This RPG/400 and DDS is new to me. Not like the old S/36. Two more questions and then I will leave you alone.
1. Can you give me an example of the rename for a display file field?
2. The RPG/400 Reference book says that the file name can only be one to eight characters. But we can build a file with up to 10 characters in its name. How can you read the 10-character name in the RPG program? Or do I just have to continue making the files with no more than eight-character names?
From: Pete Hall To: Willie Moore
OK, here goes.
The I-specs in 3 will cause field EXTFLDNAME to be known as RPGNAM in your program.
The I-specs in Figure 3 will cause field EXTFLDNAME to be known as RPGNAM in your program.
In order to use the external definition of a file when its name is longer than eight characters, you can simply give it an abbreviated name in your program, and then override your internal program name to the database file name when you run the RPG compiler. For instance, if you had a database file named INVNTRYMST, you could call it INVMST in the RPG program. Before compiling, you would run:
OVRDBF FILE(INVMST) + TOFILE(INVNTRYMST)
Obviously, you would either need to write a CL program to create the override and execute CRTRPGPGM, or you would need to compile interactively, for the override to be in effect. It's kind of a pain to keep track of special compile requirements six months down the road though.
From: Willie Moore To: Pete Hall
Pete, thanks again for this information. I think I will just keep the eight- character file names for normal RPG programs. We do query programs on our master files with different sequences. I will use the last two characters as QY to separate them from nonquery files. Query works great with the 10- character file name.
TechTalk: Message Files in S/36E
Figure 2 Using messages in S/36E
Figure 2: Using Messages in S/36E ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 Display file: D 7524 2Y 41 M RPG36 program: O 504 '0020U1' Procedure: // MEMBER USER1-CFWMSG1 Message file: 0020 CFW020-ORDER NOT FOUND
TechTalk: Message Files in S/36E
Figure 3 Renaming a field in RPG
Figure 3: Renaming a Field in RPG ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 IRECNAME I EXTFLDNAME RPGNAM
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