|
Hello James, I've watched this silly debate in silence long enough. There are some serious errors and obvious lack of understanding in many of your comments. >Indeed, I believe that sometimes the OS/400 way of doing things is not >that great. This, I think, is the fundamental problem. You are overly enamoured of Unix and its various derivatives. That's what you learned, that's what you like, that's what you would rather use. All of which makes arguing with you a little pointless. Still, here I go, playing Don Quixote! >MONMSG doesn't need to even exist. In unix all programs return a value to >the shell after completion, even if they end abnormally. I've only seen >MONMSG used to check if some error occurred. In unix checking the exit >value of the command run will do the same. Presuming that the programmer actually checks the return code. The difference here is that return codes can be ignored simply by doing nothing. Exceptions cannot be implicitly ignored. The programmer must explicitly monitor for the exception and then choose to ignore it. It is common practice on Unix to not check the return code 'cause the programmer thinks "That'll never happen", 'cause Unix weenies generally find error handling clutters up the code, and 'cause Unix weenies think checking return codes causes performance problems. Indeed it was common for Unix I/O code to never check the failure of a write (for performance reasons) 'cause there would always be enough space to write new data! My data is obviously not as important to the OS programmers as it is to me. The S/38 and AS/400 are message based machines and use an exception model to inform callers of problems. That is much more advanced than the return code concept used by Unix and other systems. An advanced exception model means that the caller CANNOT simply ignore an exception. If they don't handle it the OS will by bringing it to the attention of the user. Of course stupid programmers can still code MONMSG CPF0000 and do nothing but that requires an explicit action on their part rather than an omission as in the case of return codes. Various HLLs impose their own handling on top of the exception model (RPG converts many exceptions into an indicator setting, C converts them into return codes, COBOL converts them into status flags, etc.) but even there exceptions that are unmonitored will be brought to the attention of a human. Unchecked return codes simply disappear into the ether -- I guess it doesn't really matter if the DB update worked or not! Advanced programming languages like Smalltalk and Java (and others) also use an exception model. The entire machine uses the exception model. SLIC sends MCH messages, OS/400 sends CPF messages, programs products have their own messages. They are all using the exception model. >Calling a program using the old OPM way is analogous to the system() >function in C on unix. Variables can be passed either with environment >variables (similar to the local data area) or with arguments. But this >isn't really a very good way to do things, either on unix or the iSeries. Not even close! system(), fork(), spawn(), and their variations allow parameters to be passed IN but there is no way to pass them OUT. They provide one way program-to-program communication. If the called program needs to give data back to the caller then it must use an external object (e.g., file) or some communications protocol (e.g., local sockets) Environment variables are a useful concept that I'm pleased to see implemented on the AS/400. >These days bound procedures are the way to go. Bound procedures are just >regular function calls in C and those have been around since the >beginning. I can think of one instance where I've used the OPM style call >in the last two years. I agree that bound calls for common functions are better than dynamic calls but you're not thinking large enough. Bound calls make no sense as the entry into an application. For example, an application menu displays a list of options. Each of those options will most likely be a dynamic program call because making it a bound call is simply unnecessary and there is no direct relationship between sale order entry and customer maintenance. Once an option has been invoked it makes sense to use bound calls for the real work within that compnent of the application. Dynamic program calls are very useful, and the ability to pass parameters bi-directionally between *PGM objects is useful and not to be ignored just because Unix doesn't support it. That strikes me as another example of a serious Unix failing being dressed up as an advantage. A bit like the Unix ability to delete a file while it is use with no effect on any processes using that file. The serious failing of an OS that allows open files to be deleted, and allows programs to read and write to that deleted file just because they have an open descriptor, and only really remove the file when all open descriptors are closed is simply STUPID and DANGEROUS, but it is dressed up as an advantage because I can create and open a temporary file, delete it, and continue to use it safe in the knowledge that if my program fails the temporary file will be cleaned up by the OS. The rationale is flawed, like so much of Unix, because my real, serious, business data is at risk just to allow some small benefit for temporary file use. You've only used dynamic calls in one instance in 2 years? Then you are working within very self-contained applications or your recall is slipping. >Message files are just database files. But I really don't use them much >so I better not say too much. I'm still smarting for getting single level >storage mixed up :) No they're not. They are index objects. They provide a very fexible and powerful method of externalising message text. They support substitution data. Unix has no equivalent -- print() and its variants don't cut it. However, that sort of thing seems alien to most Unix weenies judging by the amount of Unix code I've had to deal with that is full of: if ( !(fp = fopen( fn, "rb" ))) { printf("Error occured on file %s\n", fn); perror("fopen"); } or fprintf( stderr, "Bad things happened running program %s\n", p); This shit is impossible to make NLS aware because all the messages are imbedded in code. Of course, with some small amount of programming effort they could be externalised but Unix doesn't seem to have any standard way of externalising messages. Everybody has to do it themselves. Mind you the AS/400 programmers who imbed SNDPGMMSG MSGID(CPF9898) MSGDTA("Error occurred') or SNDPGMMSG MSG("Bad things happened") are equally guilty of being stupid and shortsighted. >Library lists are just a PATH. Nothing new or foreign here. In essence that's true. >All these things are really OS/400 specific stuff, not RPG. So not having >them on unix would block ports of OS/400 apps because they are used so >much. So I agree that it is best to run your OS/400 apps on an iSeries. >But none of these keep RPG from being a language on unix. An RPG >application could be written that used bash instead of CL. Coulda, woulda, shoulda. Without support for the OS/400 specific stuff there would be no point using RPG on Unix. Conversion of DDS to something Unix likes (e.g., curses, SQL DDL, etc) is not trivial. The simple cases of data entry screens would probably be easy enough, the dialectic differences in SQL can be handled easily, but I'd like to see you build subfile support into Unix such that it is transparent to the application. You would have to implement bi-directional parameter passing (because although you might not have used it in 2 years, most AS/400 sites use it constantly). You would have to implement an exception model to handle the expectations of the application. Any Unix RPG compiler will be basically a superset of RPG II. While you could build in support for RPG IV langauge constructs quite easily, providing all the other stuff an AS/400 application takes for granted is not trivial. Using a shell script to replace CL, using curses to replace display files, using SQL to replace native I/O means a port is impossible and a conversion is neccessary. In that case why bother with a Unix RPG compiler and simply convert the RPG code to C and create a native Unix application. >Just RPG without the rest of OS/400 would be very interesting and useful >to have on linux. Of course the hard part would be externally described >files. That and trying to get anyone to use it... It would be an interesting academic exercise to create an RPG compiler for Unix but I doubt its usefulness. No Unix programmer would bother to learn RPG when they already know C and half-a-dozen scripting languages -- especially when the RPG would not be as fully featured as AS/400 native version. Anyone who wants an understanding of what is seriously wrong with Unix should read The Unix-Haters Handbook (by Simson Garfinkel, Daniel Weise, and Steven Strassmann) -- especially t. Although I freely admit I am a CPF/XPF bigot, I do know the AS/400 is not perfect -- but it is a bloody sight closer than any of the competition! Regards, Simon Coulter. -------------------------------------------------------------------- FlyByNight Software AS/400 Technical Specialists http://www.flybynight.com.au/ Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\ Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au \ / X ASCII Ribbon campaign against HTML E-Mail / \ --------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.