Near as I can tell they're talking about IIS for.NET (Which isn't free, you need a Windows Sever license). Or on the Java side, Websphere, Weblogic, or the Oracle Application server.
Naturally, none of this company's clients would use cheaper, simpler solutions to their business application problems. Of course not.
This article looks like the result of a travesty generator.
"Companies sorting out their strategies around Web services and service-oriented architectures (SOAs) need to decide which development platform and tools they'll employ and how they'll extend services and composite applications to partners and customers."
"Security remains a barrier that must be hurdlee."
3270 Terminals don't have I/O ports for digital cameras.
You can't make a picture ID and keep a central record cost-effectively without digital cameras. Using Polariod film like we used to do costs at least twice as much as the fancy digital printers, and was easier to counterfeit.
So starting about ten, twelve years ago State Driver Licensing agencies started migrating to client server applications. These were built as wrappers around legacy mainframe database apps, adding Db2 or Oracle tables to store pictures.
Since web apps were unheard of at the time, they used thick PC clients to handle the pictures, wrapped around the legacy green screen application, with an added database feed for the photos. It'll take a couple of rounds of upgrades to completely re-architecture these DL applications.
I belive many states used OS/2 for Driver License systems until quite recently. I have personal knowledge my own agency (Tennessee Department of Safety) did. Polaroid's one of the leading vendors in ID cards, and their systems in the ninties were build around OS/2 and LU 6.2 over SDLC. Which made sense given legacy IBM mainframes and SDLC networks.
Oh, and they were also typically maxed out on interfaces, with cameras, SCSI-based ID printers, signature capture devices -- so much stuff and so many drivers loaded into memory that Windows 3.1 or Windows 95 would curl up and die.
These systems were typically planned to have a 5 year life cycle, and may have been streatched out further given the usual government procurement follies for their replacements.
Regarding OS400 on 32 bit architecures: I seem to recall reading the original Silverlake CICS architecture was 48 bits. But I believe the S/38 was 32 bits.
If my memory serves me correctly, one of the big advantages to going to 64 bits with the RISC boxes was increasing a certain pointer size (or some such data structure) that ID'd objects in memory. These IDs were never recycled except during a reboot, so increasing the size significantly increased uptime. (I've over simplified the explaination I read - and possibly mis-understood.) The OS was written for a fat wide processor with fast drive I/O and not really a lot of RAM by modern standards.
The JVM lives in the machine layer -- so conceptionally, for any application it might as well be native as RPG, Cobol, or even C Integrated Language Environment (ILE) compiler programs are no closer to the metal.
Of course this just brings up the question: Does the JVM run as fast & well as the ILE runtime? The only way to know is bench mark and compare comperable programs. I expect ILE programs require less RAM but ????
There was a rumor / new report the machine layer for the 400 had been ported to the '86 architecture - mostly as an exercise.
Anybody have any information on this? I can't imagine getting any kind of decent performance with this sort of thing. Maybe with the newer 64-bit processors, but it really sounds like a Stupid Computer Trick (TM) along the lines of porting the Java Virtual Machine to a Commadore 128 or Apple II.
(OS400 is divided into several horizontal layers. There's a sharp divide at one layer -- all the physical hardware implimentation details live below it, it's a virtual machine interface the higher level programs must go through. various other measures were built into the system so that higher level programs are highly portable across different AS400/iSeries hardware implimentaions.
For example, you can back up your applications and data from a ten year old CICS architecture AS400, restore to a brand new 825, and just go. The equivlant to a JIT compiler in the machine layer makes all the necessary adjustments and optimizations as it opens the restored objects. Very nifty.)
In my city, and I expect in others, the local two year community college teaches extension courses in what we used to call "Data Processing". Basic Tape Monkey and Console operator courses in mainframes and AS400s. JCL, CL, maybe a bit of Cobol, RPG, or some SQL queries. Nothing fancy, but the courses are hands on. These classes would not necessarily be for college credit - perhaps for adult education CEUs. Fees don't seem particularly expensive.
This is obviously dependent on your local CC's resources, interests, and local demand. But check it out.
Two or three years ago there was a consulting firm that rented time on their AS400 for not very much a month advertising on the AS400 newe group. Hop over to groups.yahoo.com or your favorite newsreader and do some looking there. Ask -- it's quite friendly as usenet goes.
IBM publishes all their reference manuals for both the iSeries and zSeries OSs on line for free access. Go to www.ibm.com and search around for eSeries, OS400, OS390 and Reference. Also search around for:Redbooks and Redpapers -- that's what they call techical whitepaper, and they're a good resource.
If you'd been paid that overtime, you'd have paid more income taxes, right?
Give the tax collection agencies a call. Most of them have a tips hotline.
Also call the national department of labor, and your state's department of labor.
I will note that based on stories related to me, this sort of fraud seems to be common in the Resterant industry. The stories I've heard were from a waiter who turend in each of his ex-employers to the state, and collected fat back wage checkes each time. Perhaps you should research this on a Waiter oriented web site.
"Btw, isn't the S/400 filesystem a DB/2 database ?"
Well, to oversimplify, yes. But only part of it.
AS400 / I-Series computers actually have multiple file systems, arranged heiraraclly under what they call an "Integrated File System". Some newer file systems will hold any old blob of data in a file, whereas the original file system is basically inherited from the old S38 library system.
Basically, under ROOT there's a branch that follows OS2 or NT file naming conventions, under QOPENSYS a branch that emulates Unix file naming system, etc. These have directories and files, as you'd expect in most OS filesystems. But the QSYS.LIB is special. It's a library, not a directory. On the AS400 libraries are quite a bit more structured. Among other things, a library can act as a database "collection".
Some objects in the libraries are DB2 tables, views, indexes, and transaction journals. Others are stored procedures, queries and application programs.
All other libraries live in QSYS.LIB, and no other library can contain another library.
Now, since the S38 predated the DB2 product, and for that matter SQL, there are many database tools on an AS400 that no other DB2 platform has. And these tools are useful. There used to be a couple of logical file tricks (indexed views) you can do with DDS that SQL didn't do for example. But most tools from the mainframe and unix version have been ported to the I Series.
Neat boxes, those AS400. Single source as all hell though.
Client Access is a bundle of software, some of which will be easy to replace, and some won't.
5250 terminal emulation tops the list, and is the easiest to work around. Over TCP/IP, it's just a TN5250 emulator. The latest versions include SSL. Mocha or a Linux specific TN5250 ought to work fine.
There's a data transfer function that I personally find useless, (FTP works better for me) but some folks might be use to or otherwise prefer. The CA data transfer does have the occasionaly useful feature of creating Excel files. FTP host commands on the AS400 are a bit different than on Unix, mostly due to the different file systems. These are well documented in the extensive on-line docs. FTP will automagically convert from Ascii / Ebcidic, unless you tell it not too. I believe you can customize the conversion too.
Client Access includes ODBC and OLE DB drivers. Losing these could hurt. Databases are what the AS400 is all about. There's an open source JDBC driver, and you could always install DB2 on Linux for interconnectivity. Costs money of course. If you're spending money, and your heart is set on ODBC on Linux, there are 3ed party vendors out there who might be able to help you.
Printing: Some versions of Client Access allow printing from the AS400 to a PC's printer. Workarounds for this would involve LDP, as other posters have mentioned.
Client Access includes remote execution functions as well. (As400 to client and Client to AS400). Useful for batch processing, but you may never miss this.
Client Access includes file sharing. In current OS/400 releases this is via SMB. NFS is also supported. Earlier versions used propritary protocols, which Linux likely could never use.
SMB and NFS should work from Linux.
The biggest loss from not having Client Access on the Linux is Operations Navigator. ON is an AS400 System Operator / System Administrator / System Programmer tool for controlling and monitoring the system. There are many functions that are easier or more powerful from ON than from the AS400 green screen command line. And many others that work as well if not better from the command line.
I rather like AS/400s. All qsh is there for is to compile java - any other sh functionality is just a freebie for unix fanatics. (As opposed to AS400 fanatics whom think qsh is evil for entirely different reasons.) Oh, it comes in handy for maintaining web pages too.
The PACE environment for V4R5 and later is said to be more powerful and useful than qsh. It's basically a RS6000 emulator. Has Vi and a (real) port of perl and the like. I've heard it has X client capabilities too, which might be a different angle for interfacing linux and the AS400.
That's what we asked when we went to 32 bits. The answer is, you can address more memory, and have more memory bandwidth. Note many grapics cards these days have 128 bit architectures.
Real world benifits? Depends on the Application and OS. Usually Databases and big imaging applications see benifits first. And remember, many machines have been 64 bits for years, Intel and Microsoft are late to this party.
I understand that when the AS400 (basically database machine) line went from 48 bit CISC to 64 bit RISC chips several years back there were significant benifits in uptime, of all things. Seems the AS400/iSeries Single Level Store memory & storage management scheme requres a unique id for each object in memory. Bigger CPU words meant more (2 to the 12th?) id numbers were available. So, reboots to reset the counter for temporary objects were now needed only (all other things equal which they weren't) 1/2^12 as often. That's a big benifit for big iron.
Sounds like you're advocating some XP practices. Which is no suprise since the eXtreme means just take sucessful practices, such as the ones you just listed, and crank 'em up to the max.
You disagree with XP on Planning and Prototyping, I believe. In the XP process, you'd plan to build several sucessively more complete versions of your software. Do high level planning up front, then more detailed planning for each cycle.
Military experience is seen as a sign the individual is mature and works well in a team environment. (Contrast with Fresh College graduate to taste.) Active involvement in the Reserves, ditto.
Disclaimers:
First: I am not and have not ever been in the Military Reserves - this observation is based on co-workers.
Second: I work in State government agency with a large percentage of employees Law Enforcement personnel. We've been seriously affected by reserve call-ups - many Police officers have reserve committments. This is a strong part of our specific organizational culture, and my observations may or may not be widely applicable.
Is IBM up to something? Probably just selling hardware that they don't have to cut some software vendor in on.
IBM has always been about pushing Big Iron. (For appropriate values of "Big".). Even if they make more money off Software and Services, the company culture seems to revolve around hardware sales. Or, perhaps more precisely "Integrated System Sales".
Linux is another sales point -- it runs on pretty much all their hardware now, and it gives them another way to relatively cheaply leverage the value of their hardware ERR "Integrated System Solutions" for their costomers.
Slashdot Mirror
Hear Hear! Writing Changed Everything. The Printing Press Changed Everything. The Telegraph Changed Everything. Radio Changed Everything.
Now It's the Inter-Web-Net-Tubes, changing everything.
I wonder what we'll think of next?
If you find that the federal government needs more power, amend the Constitution to grant those powers. Anything else violates the 10th Amendment.
They did amend the Constitution. It's the 14th Amendment.
Some folks don't like to read that far.
Near as I can tell they're talking about IIS for .NET (Which isn't free, you need a Windows Sever license). Or on the Java side, Websphere, Weblogic, or the Oracle Application server.
Naturally, none of this company's clients would use cheaper, simpler solutions to their business application problems. Of course not.
This article looks like the result of a travesty generator.
"Companies sorting out their strategies around Web services and service-oriented architectures (SOAs) need to decide which development platform and tools they'll employ and how they'll extend services and composite applications to partners and customers."
"Security remains a barrier that must be hurdlee."
Blah blah blah, yackity smackity. This is trite.
The mainframes are still there. BUT:
3270 Terminals don't have I/O ports for digital cameras.
You can't make a picture ID and keep a central record cost-effectively without digital cameras. Using Polariod film like we used to do costs at least twice as much as the fancy digital printers, and was easier to counterfeit.
So starting about ten, twelve years ago State Driver Licensing agencies started migrating to client server applications. These were built as wrappers around legacy mainframe database apps, adding Db2 or Oracle tables to store pictures.
Since web apps were unheard of at the time, they used
thick PC clients to handle the pictures, wrapped around the legacy green screen application, with an added database feed for the photos. It'll take a couple of rounds of upgrades to completely re-architecture these DL applications.
I belive many states used OS/2 for Driver License systems until quite recently. I have personal knowledge my own agency (Tennessee Department of Safety) did. Polaroid's one of the leading vendors in ID cards, and their systems in the ninties were build around OS/2 and LU 6.2 over SDLC. Which made sense given legacy IBM mainframes and SDLC networks.
Oh, and they were also typically maxed out on interfaces, with cameras, SCSI-based ID printers, signature capture devices -- so much stuff and so many drivers loaded into memory that Windows 3.1 or Windows 95 would curl up and die.
These systems were typically planned to have a 5 year life cycle, and may have been streatched out further given the usual government procurement follies for their replacements.
The deadlines for this project procurement are probably related to Federal grant funding cycles. The US Government fiscal year kicks over in October.
Regarding OS400 on 32 bit architecures: I seem to recall reading the original Silverlake CICS architecture was 48 bits. But I believe the S/38 was 32 bits.
If my memory serves me correctly, one of the big advantages to going to 64 bits with the RISC boxes was increasing a certain pointer size (or some such data structure) that ID'd objects in memory. These IDs were never recycled except during a reboot, so increasing the size significantly increased uptime. (I've over simplified the explaination I read - and possibly mis-understood.) The OS was written for a fat wide processor with fast drive I/O and not really a lot of RAM by modern standards.
The JVM lives in the machine layer -- so conceptionally, for any application it might as well be native as RPG, Cobol, or even C Integrated Language Environment (ILE) compiler programs are no closer to the metal.
Of course this just brings up the question: Does the JVM run as fast & well as the ILE runtime? The only way to know is bench mark and compare comperable programs. I expect ILE programs require less RAM but ????
What's IBM's telling us these days?
Or New York City.
Or even someplace as cosmoplitan as Nashville.
There was a rumor / new report the machine layer for the 400 had been ported to the '86 architecture - mostly as an exercise.
Anybody have any information on this? I can't imagine getting any kind of decent performance with this sort of thing. Maybe with the newer 64-bit processors, but it really sounds like a Stupid Computer Trick (TM) along the lines of porting the Java Virtual Machine to a Commadore 128 or Apple II.
(OS400 is divided into several horizontal layers. There's a sharp divide at one layer -- all the physical hardware implimentation details live below it, it's a virtual machine interface the higher level programs must go through. various other measures were built into the system so that higher level programs are highly portable across different AS400/iSeries hardware implimentaions.
For example, you can back up your applications and data from a ten year old CICS architecture AS400, restore to a brand new 825, and just go. The equivlant to a JIT compiler in the machine layer makes all the necessary adjustments and optimizations as it opens the restored objects. Very nifty.)
In my city, and I expect in others, the local two year community college teaches extension courses in what we used to call "Data Processing". Basic Tape Monkey and Console operator courses in mainframes and AS400s. JCL, CL, maybe a bit of Cobol, RPG, or some SQL queries. Nothing fancy, but the courses are hands on. These classes would not necessarily be for college credit - perhaps for adult education CEUs. Fees don't seem particularly expensive.
This is obviously dependent on your local CC's resources, interests, and local demand. But check it out.
Two or three years ago there was a consulting firm that rented time on their AS400 for not very much a month advertising on the AS400 newe group. Hop over to groups.yahoo.com or your favorite newsreader and do some looking there. Ask -- it's quite friendly as usenet goes.
:Redbooks and Redpapers -- that's what they call techical whitepaper, and they're a good resource.
IBM publishes all their reference manuals for both the iSeries and zSeries OSs on line for free access. Go to www.ibm.com and search around for eSeries, OS400, OS390 and Reference. Also search around for
"Is this the same author that I remember from the Pliocene novels (Non-Born King, Adversary, Golden Torc et al)?"
I believe so. She had a long career writing children's books and non-fiction before hitting it bit with SF & Fantasy.
If you'd been paid that overtime, you'd have paid more income taxes, right?
Give the tax collection agencies a call. Most of them have a tips hotline.
Also call the national department of labor, and your state's department of labor.
I will note that based on stories related to me, this sort of fraud seems to be common in the Resterant industry. The stories I've heard were from a waiter who turend in each of his ex-employers to the state, and collected fat back wage checkes each time. Perhaps you should research this on a Waiter oriented web site.
"Btw, isn't the S/400 filesystem a DB/2 database ?"
Well, to oversimplify, yes. But only part of it.
AS400 / I-Series computers actually have multiple file systems, arranged heiraraclly under what they call an "Integrated File System". Some newer file systems will hold any old blob of data in a file, whereas the original file system is basically inherited from the old S38 library system.
Basically, under ROOT there's a branch that follows OS2 or NT file naming conventions, under QOPENSYS a branch that emulates Unix file naming system, etc. These have directories and files, as you'd expect in most OS filesystems. But the QSYS.LIB is special. It's a library, not a directory. On the AS400 libraries are quite a bit more structured. Among other things, a library can act as a database "collection".
Some objects in the libraries are DB2 tables, views, indexes, and transaction journals. Others are stored procedures, queries and application programs.
All other libraries live in QSYS.LIB, and no other library can contain another library.
Now, since the S38 predated the DB2 product, and for that matter SQL, there are many database tools on an AS400 that no other DB2 platform has. And these tools are useful. There used to be a couple of logical file tricks (indexed views) you can do with DDS that SQL didn't do for example. But most tools from the mainframe and unix version have been ported to the I Series.
Neat boxes, those AS400. Single source as all hell though.
Now now, it all starts to make sense when you realize the Klingons on TV are from the Marketing and HR departments.
The sensible, hard working Klingons stay at home and happily pay taxes to ship those bozos off planet.
" 5000 Americans died."
n de x.html
Slight correction, Over 3000. Preliminary death estimates in New York City were wildly incorrect. Still a lot of dead people.
http://www.cnn.com/2002/US/01/03/rec.wtc.toll/i
I have seen reports civilian deaths in Afganistan are of about the same order of magnitude. Lots of bombs, lots of fighting.
Client Access is a bundle of software, some of which will be easy to replace, and some won't.
5250 terminal emulation tops the list, and is the easiest to work around. Over TCP/IP, it's just a TN5250 emulator. The latest versions include SSL. Mocha or a Linux specific TN5250 ought to work fine.
There's a data transfer function that I personally find useless, (FTP works better for me) but some folks might be use to or otherwise prefer. The CA data transfer does have the occasionaly useful feature of creating Excel files. FTP host commands on the AS400 are a bit different than on Unix, mostly due to the different file systems. These are well documented in the extensive on-line docs. FTP will automagically convert from Ascii / Ebcidic, unless you tell it not too. I believe you can customize the conversion too.
Client Access includes ODBC and OLE DB drivers. Losing these could hurt. Databases are what the AS400 is all about. There's an open source JDBC driver, and you could always install DB2 on Linux for interconnectivity. Costs money of course. If you're spending money, and your heart is set on ODBC on Linux, there are 3ed party vendors out there who might be able to help you.
Printing: Some versions of Client Access allow printing from the AS400 to a PC's printer. Workarounds for this would involve LDP, as other posters have mentioned.
Client Access includes remote execution functions as well. (As400 to client and Client to AS400). Useful for batch processing, but you may never miss this.
Client Access includes file sharing. In current OS/400 releases this is via SMB. NFS is also supported. Earlier versions used propritary protocols, which Linux likely could never use.
SMB and NFS should work from Linux.
The biggest loss from not having Client Access on the Linux is Operations Navigator. ON is an AS400 System Operator / System Administrator / System Programmer tool for controlling and monitoring the system. There are many functions that are easier or more powerful from ON than from the AS400 green screen command line. And many others that work as well if not better from the command line.
I rather like AS/400s. All qsh is there for is to compile java - any other sh functionality is just a freebie for unix fanatics. (As opposed to AS400 fanatics whom think qsh is evil for entirely different reasons.) Oh, it comes in handy for maintaining web pages too.
The PACE environment for V4R5 and later is said to be more powerful and useful than qsh. It's basically a RS6000 emulator. Has Vi and a (real) port of perl and the like. I've heard it has X client capabilities too, which might be a different angle for interfacing linux and the AS400.
That's what we asked when we went to 32 bits. The answer is, you can address more memory, and have more memory bandwidth. Note many grapics cards these days have 128 bit architectures.
Real world benifits? Depends on the Application and OS. Usually Databases and big imaging applications see benifits first. And remember, many machines have been 64 bits for years, Intel and Microsoft are late to this party.
I understand that when the AS400 (basically database machine) line went from 48 bit CISC to 64 bit RISC chips several years back there were significant benifits in uptime, of all things. Seems the AS400/iSeries Single Level Store memory & storage management scheme requres a unique id for each object in memory. Bigger CPU words meant more (2 to the 12th?) id numbers were available. So, reboots to reset the counter for temporary objects were now needed only (all other things equal which they weren't) 1/2^12 as often. That's a big benifit for big iron.
Nashville Airport Post office is open 24x7.
Nashville is not that large a city.
I imagine this is not unusual, and expect most larger cities have one office open late.
Sounds like you're advocating some XP practices. Which is no suprise since the eXtreme means just take sucessful practices, such as the ones you just listed, and crank 'em up to the max.
You disagree with XP on Planning and Prototyping, I believe. In the XP process, you'd plan to build several sucessively more complete versions of your software. Do high level planning up front, then more detailed planning for each cycle.
Communication, as you say, is the key.
Military experience is seen as a sign the individual is mature and works well in a team environment. (Contrast with Fresh College graduate to taste.) Active involvement in the Reserves, ditto.
Disclaimers:
First: I am not and have not ever been in the Military Reserves - this observation is based on co-workers.
Second: I work in State government agency with a large percentage of employees Law Enforcement personnel. We've been seriously affected by reserve call-ups - many Police officers have reserve committments. This is a strong part of our specific organizational culture, and my observations may or may not be widely applicable.
Is IBM up to something? Probably just selling hardware that they don't have to cut some software vendor in on.
IBM has always been about pushing Big Iron. (For appropriate values of "Big".). Even if they make more money off Software and Services, the company culture seems to revolve around hardware sales. Or, perhaps more precisely "Integrated System Sales".
Linux is another sales point -- it runs on pretty much all their hardware now, and it gives them another way to relatively cheaply leverage the value of their hardware ERR "Integrated System Solutions" for their costomers.
For what it's worth, I found another text on this subject while surfing around this topic:
DATA MODEL PATTERNS:Conventions of Thought
by DAVID C. HAY
ISBN: 0-932633-29-3
http://www.dorsethouse.com/books/dmp.html
Apparently it further develops the Barker / Oracle CASE methods. And is also not UML.