So what makes the AS/400 Operating System so special?
The AS400 Operating System is one of the most modern Operating Systems in wide spread use today. I was at an interesting talk given by Doctor Frank Soltis the chief designer for the IBM AS/400 and the IBM System 38 that came before it. He explained that Windows can trace it’s roots back via Windows NT to VAX VMS, Unix, Linux and OSX can trace their roots back into the late 60’s. In comparison OS/400 or CPF (Control Program Function) as it was known on the System/38 was designed the ground up in the 1980’s.
In current terms OS/400 has more in common with the Java Virtual Machine (JVM) than operating systems like Windows. OS/400 has a machine independent layer that sits between it and the underlying processors and hardware. Over the years the processors have changed many times, for example from CISC to RISC whilst marinating software compatibility. Software first compiled in the 1980’s on long forgotten hardware can still be run on the latest hardware today without being recompiled.
In addition to the Technology Independence Layer, OS/400 also features something called Single Level Storage. In computer software the most expensive operation is the Branch operation. This is where the processor switches from one task to another. OS/400 handles this by having a single continuous 128 bit address range. This covers all the physical memory and disk storage. The Operating System then uses heretical storage management to move the most frequently used content into the fastest memory in the Single Level Storage. These days this will range from slow mass storage drives, SANS, fast drives, SSD’s to RAM.
OS/400 is not a truly Object Orientated Operating System in the current sense (i.e. inheritance and polymorphism) but it is Object Based and very much embraces Encapsulation. Being Object Based literally everything on the system is an Object. Each object has a set of interfaces and can only be accessed through those interfaces. This has made the platform incredible secure as most of the memory overrun and buffer attacks that hackers exploit on other platforms are not possible.
The other interesting thing about OS/400 is that it has a built in database. These days it’s called DB/2 and shares much of the DB/2 technology from other platforms. OS/400 uses this built in database for many of it’s own storage requirements. DB/2 on iSeries leverages the Single Level storage to be highly reliable and low maintenance. Unlike on other platforms the AS/400 will run for years without any operator or DBA (Database Administrator) assistance. For example I’m aware of several companies in the UK where AS/400 applications run for years on end with little to no operations support. I’d contrast this with Microsoft SQL Server based applications where performance degrades if not given regular attention. IBM S/38 was the first commercial computer to implement a Relational Database using SQL. This took the conceptual work from Ted Codd at IBM and implemented it for real in the S/38. At the time the S/38 CPF Operating System was ahead of the processing power really available for this type of processing. It was slow but successfully proved the vision of a Relational Database based on SQL. IBM had invested everything in the development of the S/38 and continued this investment as they improved the processors, hardware and Operating System and relaunched it in the 1990’s as AS/400.
The AS/400 as a whole is often perceived to be out of date (by people who don’t know better) because it still runs many Green Screen or Character based applications on dumb terminals or terminal emulation. From a systems architecture perspective this is no more relevant than say the console interface on Mac OS (OSX) or the Terminal Interface on Windows. These days most modern applications are browser based and the users would never know that the backend is running on OS/400.
For anyone studying Systems Architecture or Computer Science OS/400 is something you really must study to get an alternative view of how well a fully integrated, single vendor system can work on an enterprise scale. Few doubt this today on the desktop or iPhone when they look at Apple products.
Using DB/2 for IBM i (aka IBM AS/400 or iSeries) I was trying to drop a stored procedure using the command
DROP PROCEDURE TEST/TEST_FTP;
But was getting a message
Message: [SQL0476] Routine TEST_FTP in TEST not unique. Cause . . . . . : Function or procedure TEST_FTP in TEST was specified, not by signature or specific name, and more than one specific instance of the routine was found. Or the procedure was used in a DESCRIBE PROCEDURE or ASSOCIATE LOCATOR statement without a schema name specified while connected to a remote system, and more than one procedure has been called with that name. Recovery . . . : Request the routine either by its specific name, or by its signature (function or procedure name with parameter types). If this is for a DESCRIBE PROCEDURE or ASSOCIATE LOCATOR statement, specify the schema name for the procedure. Try the request again.
Using Ops Navigator, to view the stored procedures I was getting an idex array error message, if I used query to query SYSRoutine in QSYS2, I could see 2 entries for this with slightly different settings in the SPECIFIC_NAME, but the ROUTINE_NAME was the same as TEST_FTP.
After some investigation I found that you could drop and specify the parameters, so I tried
DROP PROCEDURE TEST/TEST_FTP(CHAR(13));
Which successfully make the name unique and allow me to delete one, then managed to call
DROP PROCEDURE TEST/TEST_FTP;
Which then deleted the other one of the same name.
Basically in DB/2 on IBM i and I guess most other SQL databases stored procedures can have the same name as long as they have different parameters. This is essentially the same as method overloading in Java and some other languages where the method (sub routine) names signature is composed of the name part + the parameter list that is passed into it.
There may be more than one way of doing this but this is how I would do it….
From a command line type DSPJOB OUTPUT(*PRINT) and press ENTER. This will create a spool file containing information about your current interactive job. At the top of almost every AS/400 Operating System report like the one generated by the DSPJOB command you will find the Operating System Version. For example:
In the above example the second block of characters on the top line of the spool file is the version of OS/400 currently installed. In this case V5R4M0 which means Version 5 Release 4 Modification level 0 commonly known as OS/400 5.4.
Updated Feb 20th 2015:
Thanks to Jose for leaving a comment below pointing out that the DSPPTF (Display Program Temporary Fix) command is probably the best way to find the version of IBM i / AS400 operating system you have installed. The original method shown above will work with minimal access rights but if you have access to the DSPPTF command then best to use this instead. In the example shown below the machine is running OS/400 Version 7 Release 1 Modification Level 0.
How to find what Tech Refresh (TR) is installed?
It is worth noting that from OS/400 7.1 IBM decided to increase the frequency between actual OS point upgrades e.g. from 7.1 to 7.2 as these can be costly and disruptive to perform. At the same time IBM wanted to be able to accelerate the pace at which new features are added to OS/400. So from 7.1 IBM have now added the concept of “Tech Refreshes” (TR). In other words not all 7.1 and 7.2 systems are equal you now need to know the OS/400 version AND the TR level to know if a particular feature is available.
To do this you use the command DSPPTF 5770999 and then page through and look for the highest PTF starting MF99… For example:
This system has OS/400 7.1 Tech Refresh (TR) 9 installed, and you can see below it that TR8, 7, 6, 5, 4 etc were previously installed.
I thought I’d write this up as a quick post because this is one of those things I always forget how to do. I’m sure in earlier versions there used to be a menu or screen that showed the version number but when I needed to do this last week I couldn’t find any trace of it.
Anyway if you need to find the version and patch level of the version of JDE World is running all you need to do is navigate to a command line and then do a DSPDTAARA QJDF, you’ll then see data area displayed which shows the version and patch level. For example…
Data area . . . . . . . : QJDF Library . . . . . . . : JDFOBJ Type . . . . . . . . . : *CHAR Length . . . . . . . . : 2000 Text . . . . . . . . . : J.D Edwards & Co. Software Control Data Area Value Offset *...+....1....+....2....+....3....+....4....+....50 '50 'Software Source Library = JDFSRC '100 'Software Object Library = JDFOBJ V00MENU '150 'Software Data File Library = JDECOMSEC '200 'Program to Execute = '250 'System Identification/Name = '300 'Hidden Selections Menu Key = ZHIDDEN '350 'Software Version Id = A73PC00015 '400 'Library Editing Routine =
If you know a better way or an official way of doing this please drop me a net or leave a comment or drop us an e-mail, see the Contact Us section for details.
Update: February 3rd 2019 This article applies to JDE World ERP software which runs on the IBM i, if you want to learn more about J D Edwards (JDE) Enterprise One (E1), then I highly recommend the new LearnJDE.com website created by the JDE team at Oracle.
Why would a perfectly good SQL based application which has been running well for years suddenly start to run slowly?
It’s easy for us iSeries users to forget about database administration because the OS/400 or i5/OS does such a good job of managing this for us.
From time to time an AS/400 (for that is still what I like to call it) logical file (index) can become invalidated. This typically happens if a job is using it when the subsystem goes down for some reason.
Doing a little research what I’ve found is that if an RPG program with the table specified on an F Spec tries to opens a damaged logical it triggers the system to rebuild the logical during the file open. This isn’t the case when you run an SQL statement. The SQL processor only considers currently valid access paths when it builds its access plan, therefore skipping damaged logical (indexes).
In my case, this was causing the SQL processor to drop back to a full table scan rather than an indexed lookup. This changed the usual runtime of the SQL statement from less than a second to several minutes.
Using OpsNav and the Visual Explain tool you can view the SQL statement and see exactly what it’s doing but it may still not be obvious why it didn’t use the logical view that you know exists.
The tip is to have your System Operator run the EDTRBDAP (Edit Rebuild of Access Paths) command which will list any damaged access paths. The system gives you an estimated time for the fix which so far we’ve found to be quite accurate. It’s best probably to plan to fix the access path out of normal operational hours. This screen does get displayed during an attended IPL but most SysOps I’ve spoken to say they were taught to just press Enter – because the system will sort the problem out later – which is obviously no longer true if you’re using SQL.