System iNetwork

How can it be that IBM i hardware is so cutting edge awesome but the OS, runtime and languages are 15 yrs behind the competition?

The spooled output feature of the system is very good. The output of a job is stored and located within the scope of the job. Currently the system limits job output to spooled files that are intended to be printed. I suggest an enhancement where job output can include pdf documents, spreadsheets, xml files, database tables ... anything that can be written to the IFS. Enable this directory structured output to be accessible as a mapped network drive from windows explorer.

Another suggestion to improve the OS is to expand the amount and type of information written to the joblog of a job. Depending on the logging level setting, log sql statements, program calls and procedure calls. Files opened and closed. IFS directory activity. Add attributes to a program object that specify that every time a statement in the program is executed or a variable accessed a record is written to the joblog. Change the joblog itself so that it is structured in a tree like way with job steps as high level nodes and program calls nested within those nodes. To look for information in the joblog you drill down within each execution step and sub step.

in i6.1


OVRPRTF FILE(print-file) DEVTYPE(*AFPDS) WSCST(*PDF) +

     TOSTMF('/usr/local/pdfs/my-pdf-file.pdf')

CALL PGM(MYRPGPGM)

DLTOVR FILE(print-file)

Speaking of joblogs, It would be nice if the joblog had a field for the subsystem that produced the message.

@Steve: We've been writing PDFs, spreadsheets, et al, to a shared directory for years. If you haven't, it's not because the facilities aren't there already.

Most of the info you're looking for in the job log suggestion is already available, although not in one place. Not sure why I'd want program trace data munged into a job log, although I can see some value in creating an option to merge object audit entries into a job log. Certainly nothing to prevent you from writing your own messages to the job log when needed.

As long OS400 doesn't get native graphical capabilities and the native language not OO, all the talk about improvments here and there is comparable to a drop in the ocean.

I love the idea of a tree-like joblog. That would make the joblog much more readable. I also love the idea of adding more information to the joblog. In today's world of calling service program procedures (... and more stuff that is not logged), this would really help in determining what is going on. Do not want all that extra information making your joblog huge and taking up your disk space? Change the message level logging to that level only when you want it. (The message level logging would obviously need to be enhanced.) But it can be there when you want it :)



I have a suggestion to enhance the directory tree joblog: Have an Operations Navigator version with the +/- button. This would be ideal. Succint high level level information that you could drill down on as needed/wanted.



I agree with the above post that we could write our own messages -- and that would work. We could even retrieve message log level, etc ... But to have more messages appear/not appear based on your message log level without needing to code it. mmmmmm. Delicious!

"...@Steve: We've been writing PDFs, spreadsheets, et al, to a shared directory for years. ..."

And you can email the output also. The problem with writing to the shared IFS is the problem of name clashes. Which can be circumvented by adding a date and time to the file name. But all of these solutions results in a collection of files which grows every day, cluttering up the shared folders and user's inbox.

Consider the many spooled files produced daily on a typical production IBM i system. It would be a lot harder to manage that output if there was no such thing as output queues and spooled files.

"... The problem with writing to the shared IFS is the problem of name clashes...But all of these solutions results in a collection of files which grows every day, cluttering up the shared folders and user's inbox."

Every key report we produce does exactly that- it gets converted from spool file to PDF, slotted into the appropriate IFS directory, and replicated to a Windows file server for redundancy- usually without being printed on paper first.

Name clashes? Use subdirectories to organize the data. Worried about getting locked into a directory structure? Build a searchable database with links to resolve to the proper document/spreadsheet/file. Too many reports? Do some analysis about what are key reports. Move what you can to an ad hoc reporting structure.

Codify your availability and retention policies to manage your output. As a starting point, use the IFS handling samples that Scott Klement has graciously made available (http://www.scottklement.com/presentations/#RPGIFS). Walk through directories and handle the files as necessary.

It's not rocket science.

I can understand the comment about the OS not having a graphical UI, but I don't see any problem with a language not being OO.

If the System i compiles and runs other languages that are OO (Java, C++), is there a business case for converting RPG to OO? (I assume the above comment refers to RPG when it mentions the "native language").

With ILE, the benefits of modularization and code reuse that many seek in OO languages can be implemented with RPG. Granted: with RPG I can't model things as objects, but do I really need to?

P.D.: All comments about RPG also apply to COBOL as well.

"I can understand the comment about the OS not having a graphical UI, but I don't see any problem with a language not being OO."

My comment mainly addresses the perception iseries has with the outsider public. The two general accepted standards to measure whether a platform is considered "legacy" or "modern" is the availability of a native GUI and the native development language (in this case RPG and COBOL) having OO capability. Most developers agree that if these capabilites are seen missing, the platform is considered by management and wouldbe IT decision makers as "legacy".

What would be the effect if IBM came up with a native GUI and OO solution today?

Probably little - it would all depend on how much ISV's would be tempted to restart developing for OS400 again.
Most other platforms (leaving mainframe out for a moment) made the transition to Graphic UI and OO more than 10 years ago. Unix and Linux systems provide graphic capabilities tru what they call Xserver. Oracle and SAP carry embedded java since 2000 and Microsoft has and abundance of OO languages in Visual Studio. Java has graphic functions tru their swing class, and we all know java is the basis on which the eclipse framework is build.
My conclusion and probably also Ibm's, is they've missed the train in this fundamental step in IT evolution, and that today it is TOO LATE to jump on the bandwagon. So we'll see in the next OS400 releases some nice goodies like PDF or Excel output, additional parameters in os400 commands, maybe some joblog improvements -see earlier posts- but nothing that will fundamently change the perception to the outside (buyer) public of os400 being hopelessly legacy.

Do we need native GUI and native OO capability on the iseries?

That is imho a 'chicken and egg' question. I would say, my goodness, we don't need that stuff at all!
The result: iseries workloads continue to gradually narrow down to classic procedural batch processing in traditional areas like accounting, manufacturing (in China?), sales etc. We can forget about our 5250 screen programs, these will die out or at best be converted to batch applets and integrated in a backoffice app. So given this view, the "no we don't need gui or oo at all" is like a self fulfilling prophecy.
We all know iseries can do much better, it can act like a webserver, run php, run java, but frankly, I've NEVER seen such a decision taken in favor of iseries. In 99% of cases i've witnessed, when IT management decides on a new modern application, the job is invariabely put in the hands of the Windows or Unix guy who in turn mostly buys of the shelf solutions, while the as400 quitely continues in its corner to compute debet and credit amounts and spit out 132 column reports or PDF's. The remaining 1% of cases are probably those shops where brave people like Scott Klement work.

Again, perception is key in the survival of this platform, and I have the impression Ibm finds themselves in a catch 22 deadlock situation.
I really don't see what they can do today to reverse the downward spiral this system is in for years now, but frankly, they all own it to themselves.

ugeerts

ugeerts post raises many important points that need addressed.

The two general accepted standards to measure whether a platform is considered "legacy" or "modern" is the availability of a native GUI and the native development language (in this case RPG and COBOL) having OO capability.

What is the native development language of Linux and Unix? To get around this legacy definition, the answer given would be C++, but Linux and most apps are written in C, just as procedural as RPG. And our PASE Unix subset of i5/OS ~ OS/400 is exactly that C Unix environment.

In addition C++, the OO language, is just as much an ILE language as RPG, COBOL, CL, and C. To call RPG native and C++ not native due to predominance of use of RPG is just to make the argument work. But it doesn't. It's wrong.

Java and PHP are also fully integrated, as is everthing on the iseries, in multiple directions. I can call Java class methods directly from RPG and I can call RPG directly from Java. I can call anything running in the Unix subset directly. And I can do it with the most advanced operating system in the world, the object based i5/OS.

Unix and Linux systems provide graphic capabilities thru what they call Xserver.

iseries has XWindows as well. Why don't we use it? Well we would if were using iseries as a workstation, but almost none us do. But to say Linux and Unix is GUI because they have XWindows and iseries doesn't is again wrong.

It is fitting to be wrong in attempting to differentiate Unix and the similar Linux from iseries because 1) Unix dates to 1970 when System/38 was a gleam in Dr. Soltis' eye, and 2) it's a subset of i5/OS.

What would be the effect if IBM came up with a native GUI and OO solution today?

They did, it's called HTTP Powered by Apache, Java, EGL, and Websphere. The effect is that the gamut of solutions is available to the iseries businesses, from enterprise Java to high speed RPG CGIDEV2 web serving to the highly efficient 5250 terminal interfaces.

We can forget about our 5250 screen programs.

Nothing beats them for getting real work done. They're still being pumped out by growing and thriving businesses who grew and thrived on iseries 5250 screens.

We all know iseries can do much better, it can act like a webserver, run php, run java, but frankly, I've NEVER seen such a decision taken in favor of iseries.

You don't get out much. It not only acts as a webserver, it is a webserver. Businesses are making and acting on those decisions you've never seen every day.

The architecture of the iseries and every server solution integrated as one into the operating system of the future provides a more robust, cost effective platform than competitors.

Businesses can make most anything work, but businesses running on the iseries do it much more cost effectively.

IBM clearly doesn't care what operating system you run on their POWER hardware. They're not going to sell the iseries. But they've stopped at nothing in making it the best technology platform for business, so there's nothing stopping anyone else from selling it.

rd