If you have just installed an AS/400 and migrated all the S/36 programs, files and folders over to it, you may be agonizing over the prospect of converting all those S/36 jobs to native AS/400. You have probably heard all the arguments for conversion. They run faster; they take advantage of AS/400 features; files can be externally described, and on and on. That is mostly true, of course. If all your staff had to do was stop development on S/36 projects and turn to the conversion, it would be a marvelous idea. Your programmers would learn all about RPG/400, external file descriptions, CL programming, and DDS. They and you probably do not have that luxury. Even if they did, would there be that much advantage in the conversion?
It is generally thought that if you convert from a S/36 to an AS/400, and run it as a S/36, that all users should have SPCENV(*S36) in their profiles. This is not necessarily true. The biggest single overhead resulting from running in Environment is placing all users in the big E, not in running a S/36 type program. Users with SPCENV(*S36) spend all their time running through an overhead program which anticipates all S/36-type commands. It is there (in the overhead program) that the lost time occurs. If there are fifty users on the system, that counts as fifty extra slices of time. And that is considerable waste of AS/400 energy.
Another general misconception centers on the relative speed of a native versus a S/36-type RPG program. The simple fact is that both native and S/36 source RPG generate machine language instructions on the AS/400 and are probably indistinguishable from each other, assuming each reads the same file and performs the same step. Yes, there are some things that can be done only in RPG/400, but the generated machine code is pretty much the same overall. The processing time for each program would probably not vary by more than two percent one way or the other.
Another misconception is that only AS/400 files are in database format and can be externally defined. This is patently untrue, as well. Any file brought over from the S/36 to the AS/400 resides as a database file, and certainly can be externally described if DDS exists for that file. While it is true that no S/36 Environment program could take advantage of its external description, Query and DFU programs could. The fact that S/36 files are all in library QS36F has no bearing on the ability to externally describe them. In sum, there are no such things as "S/36 files" and "AS/400 files"; there are only database files on the AS/400.
The answer to the conversion dilemma is to divide your users into two different groups: (a) those who spend most of their time running S/36E tasks, and (b) those who rarely, if ever, execute S/36E tasks.
"Group a" users should have SPCENV (*S36) in their user profiles, and should also execute their tasks from S/36E menus - that is, those you create using SDA while in the S/36E.
"Group b" users, on the other hand, should indicate SPCENV (*NONE) in their profiles. These users should execute their tasks from native menus, and use the AS/400 command STRS36PRC to drive whatever S/36 jobs they need to run. None of this will require a great deal of programmer time, but the benefits will be a measurable increase in response time for the user. In addition, programmers will have their first real opportunity to attack the AS/400 and win a little victory.
First, a brief discussion about menus on the AS/400 is in order. For the purpose of this article there are basically two kinds of menus on the AS/400: native AS/400 menus and S/36-type menus. As you have now surmised, all source members in AS/400 are stored in source files, usually beginning with Q, such as QS36SRC, QDDSSRC, and so forth. These names are IBM defaults that are shipped with an AS/400, but the names of the files can be anything the user prefers. The source members are further classified by member type. The member type determines, among other things, whether the member is to be treated as a S/36 or an AS/400 member. This is unlike the S/36, where they simply resided in a library as a member type SOURCE. The source for S/36 menus are stored in a file called QS36SRC in whatever library they were migrated to on the AS/400. There are two source members in this file for each menu, both type MNU36. So for a menu name PAYMNU, there would be a member called PAYMNU and a member called PAYMNU##.
An AS/400 menu source is stored in file QMENUSRC in whatever user library you like. For each menu there are two source members, one bearing the name of the menu and the other the menu name plus QQ. So for a menu named EQUIP, there is a member called EQUIP, type MNUDDS, and a member called EQUIPQQ, type MNUCMD. The member type MNUDDS contains the DDS source specs for the screen format, while type MNUCMD contains the command source for the menu. This is actually very similar to the S/36, except that the screen format is in DDS instead of S & D specs. 3 shows a simple diagram that summarizes it.
An AS/400 menu source is stored in file QMENUSRC in whatever user library you like. For each menu there are two source members, one bearing the name of the menu and the other the menu name plus QQ. So for a menu named EQUIP, there is a member called EQUIP, type MNUDDS, and a member called EQUIPQQ, type MNUCMD. The member type MNUDDS contains the DDS source specs for the screen format, while type MNUCMD contains the command source for the menu. This is actually very similar to the S/36, except that the screen format is in DDS instead of S & D specs. Figure 3 shows a simple diagram that summarizes it.
There are differences between native AS/400 menus and S/36-type menus on the AS/400. First, AS/400 menus can be the subject of a GO command, while S/36-type menus cannot. A GO command is equivalent to the MENU command on the S/36 and calls up a named menu. Different objects are created when a S/36 menu is compiled as compared to a native menu. A compiled AS/400 menu produces an object type *MENU, while the S/36 does not. In most other ways, they are quite similar.
To create a native AS/400 menu, simply enter the command STRSDA and press Enter. Now take the number 2 option (design menus) and notice that the next prompt screen asks for the source file, the library name and the menu name. Enter QMENUSRC for the file, a library name, and a menu name to create, and press Enter. At this point, it becomes very similar to SDA on the S/36, in that the programmer creates the screen format as he wants it to appear, then presses F10 to advance to the command part of the menu creation. The built-in functions to move, shift, add, and delete fields are quite similar to S/36 SDA.
The trick to making this work is to use the STRS36PRC in the command portion of the menu. For each valid number on the menu, type in the command STRS36PRC corresponding to the number and press F4. Now fill in the S/36 procedure name and library required. Remember that your objective is to build a native menu - one which calls S/36 procedures to execute from the menu. You might also want to call another AS/400 menu from this menu by using the GO command. Having filled in all the STRS36PRC commands for all the valid numbers on the menu, end the session by pressing F3, and request a compile of the menu. The compiled menu is now a native AS/400 menu, and could be the sign-on menu for a user. When items from the menu are selected by a user, the system will place the task in S/36 Environment only long enough to complete it. The user remains out of the Environment otherwise. If he works in Office, for example, he does so in native mode.
The next task, which will complete the project, is to take "Group b" users out of S/36 Environment by changing their profiles using the CHGUSRPRF command. The parameter to change is SPCENV(*NONE). After these users are changed, there should be a noticeable improvement in response time. The system is no longer wasting strokes by running the overhead Environment program for all users.
Ted May Jefferson City, Missouri
TechTalk: Avoiding the AS/400 S/36 Environment
Figure 3 Components of menus in S/36E and Native
Figure 3: Components of Menus in S/36E and Native Source Mbr Mbr File Name Type Native menu QMENUSRC EQUIP MNUDDS EQUIP EQUIPQQ MNUCMD S/36 menu QS36SRC PAYMNU MNU36 PAYMNU PAYMNU## MNU36
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