04
Mon, Nov
1 New Articles

TechTalk: Avoiding the AS/400 S/36 Environment

General
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: