|
scott, having never used threads,and who knows if i ever will, but, i just wanted to say that your example of the game really helped in understanding the purpose of threads. A nice example. Mike -----Original Message----- From: Scott Klement [mailto:klemscot@klements.com] Sent: Tuesday, July 17, 2001 12:29 PM To: RPG400-L@midrange.com Subject: Re: Activation Groups and Threadsafe On Mon, 16 Jul 2001 FKolmann@netscape.net wrote: > I checked the archives on Activation Groups and although some > things are explained I still don't understand. > I checked the archives on Threadsafe and some questions come > to mind. > Long, long, ago when I was but a boy I wrote a MRT program > on a S38. (MRT = multi requesting terminal). It worked fine > but it was a bit of a monster, keeping track of each users state > resetting variables etc, etc, etc. > I quickly came to a conclusion that SRT and the way the S38 > managed jobs was the greatest thing since sliced bread was > invented and was thankful that, MRTs I will never have to > endure again. > Then along came activation groups. What do MRT's have to do with activation groups? Do you understand the concept of a 'call stack'? Each time a program is called by another program, it creates a new stack level. Each time a program ends, it's taken off the end of the stack. So if a CL program called 'DSPINVCL' calls an RPG program called 'DSPINVR' and the RPG program DSPINVR calls another RPG program called 'DETAILSR' you might have a call stack that looks like this: 1 QCMD 2 LOGINCL 3 MENUPGM 4 DSPINVCL 5 DSPINVR 6 DETAILSR An activation group is a way of "grouping together" entries on the call stack. That's _ALL_ it is, very simple. 1 QCMD 2 LOGINCL 3 MENUPGM 4 DSPINVCL ----+ 5 DSPINVR + Activation group "DSPINV" 6 DETAILSR ----+ Now, you can scope overrides, ODP's and export variables to be shared between all of the programs in the "DSPINV" group. You can, furthermore, force the DSPINV group to end, which will unload all three programs in it from memory. That's all an activation group is. It has nothing whatsoever to do with threads or MRTs. (I hated MRTs too, by the way) > What exactly are AGs for. I know I can scope file overrides > within AGs, but to what end. A long time ago I wrote programs > that used 'shared file opens' to minimise ODPs and PAG sizes > and I had to be careful that my file cursor was explicitly positioned > for every IO (or sometimes very sneakily I used the position of > the cursor as input for the next program, confused the heck out > of the contractors) but I came to the conclusion that what I was doing > was complexity for my own egos sake and I could do the same job > using simple programs that opened ODPs as needed. OK so the > machine needed to do a bit more work, but no one noticed the difference > and the programs were much simpler. No argument there. The only nice thing about MRTs was the ability to share data across the different 'requestors' that were running the program... but, of course, there are other ways to do that today. > Am I now supposed to go back to the dark ages of the MRT. > Is that what activation groups are about. Do you seriously expect > me to break my job up into multiple sub-jobs (AGs), when I can > simply invoke another job. That's not what an activation group does. > Do AGs address the issue of having thousands upon thousands of jobs > all the same and then allow all these similar jobs to live within > only ONE job, that now has thousands upon thousands of AGs. > What sort of application needs such a thing. > Does anyone have examples where they use AGs in a production > environment where they could NOT have done the same job > using SRT type programs and the usual AS400 JOB setup. This is more along the lines of what 'threads' do, not what activation groups do. They allow you to have the computer switch between many concurrent tasks. > > What are threads, I assume it is like the MRT I wrote where I had > to keep each users data separate. I understand JAVA uses threads, > is that because JAVA does not use the AS400 job structure and > so has to reinvent the AS400 wheel. > (I am guessing, I am ignorant in JAVA) Actually, I'd venture to say that threads are the exact opposite of a MRT. With a MRT, you have one program that's handling multiple users. With threads you have multiple procedures (i.e. subprocedures or 'sub-programs') running at the same time, usually servicing only one user. This isn't useful for a traditional accounting, order entry, or inventory fulfillment package. If that's what you're writing, don't worry about threads. Don't use them. However, let's say you're writing a computer game. Moving around the screen are lots of little 'people'. Each person moves his legs when he walks, he makes decisions about which way he's going to go. Sometimes he stops and says 'hi' when he sees another person. In addition, there are monsters walking about the screen. They're looking for the the people. When they find people, they chase them, and eat them. They also animate. Their mouths move, their feet move, etc. How would you program this? Sure, you could do one action for one person, then do an action for the next person, then do an action for a monster, then do an action for another person, etc... but your code would be constantly switching between each of the 'tasks' that needs to be done, and that makes for hard-to-follow code. Wouldn't it be easier to write the code for each person that walks about the screen as a separate procedure, and have the system handle the switching between them? That's what threads do. Let's say you wanted to write a web server. You want to handle up to 200 people accessing this web server at the same time. Each web browser can be downloading up to 20 different objects (either html documents, or pictures, or running scripts) all at the same time. You could, as above, continually switch between every single user that is connected to you. Send 50 bytes to connection one, then send 50 bytes to connection 2, then read 50 bytes from connection 3, and so on for up to 4000 simultaneous connections. This is very complicated code. If something goes wrong during just ONE of these connections, causing the program to crash, all of the connections also crash. You could submit a new job for every connection. Granted, this would work -- but it would require a system capable of running 4000 simulatenous active jobs! and each time someone connected, they'd have to wait for a new job to be submitted and take control of the connection... while the job is being submitted, no other users could connect. This WOULD work, however... Threads are a lot more 'lightweight' than jobs. A new thread uses a lot less memory than a job, and requires a lot less time for the system to set up. Therefore, if the AS/400 only supported 'full jobs', it would not be able to compete with systems that support threads, for the purposes of a writing web server. > > Where is the simplicity of the AS400 going where I could > write a program and have as many users call it as they want and > the computer keeps everything in its place, now I am supposed > to be able to stick things within AGs (named or otherwise). Are you suggesting that IBM might be taking this ability away? I find that very hard to believe. > Now I have to consider whether a command is Threadsafe or > not. I notice that DSPFFD is not threadsafe. What does this mean, > am I now able to get a file description in one job then somehow > change the file (would you ever do this) on the fly and then use > DSPFFD in another job the gets back the old file layout. > How can a DSPFFD give back corrupt data threadsafe or not > if the file layout has not changed. Unless you're writing multi-threaded applications (which it doesn't sound like you ever will) you don't need to worry about whether a command is threadsafe... > Is ILE and AGs and Threads simply a way of redoing what the > AS400 has already done but in a fashion that is compatible with > the UNIX / C world. If so then I pray that I retire before all > this comes to pass. No other platform that I've ever worked on, (including Windows, and including UNIX) has anything quite like activation groups. I don't think IBM introduced them to 'be like Unix'. For certain types of programming (especially games and other animated things) threads make life a lot easier. If all you've ever written is simple accounting software, then the odds are pretty good that you'll never need to use threads. In that case, don't worry about them. But, PLEASE, don't petition IBM to cripple the AS/400 just because you're afraid of them. Some of us DO write different types of applications. +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.