JDB/400 Version 1.0P is Here!

[J.Pluta]

Announcing! JDB/400 public version 1.0P is up on the website, folks. In order to access a keyed file on your AS/400, you now need a total of ONE, count 'em, ONE class. The Jdb400KeyedFile class is created using good old AS/400 QSYS syntax ("MYLIB/MYFILE(MYMEMBER)" or ".MEMBER") and supports READ, READP, CHAIN, SETLL and READE processing. The Jdb400SequentialFile class has the same syntax and supports READ, READP and CHAIN. Both handle all the vagaries of connecting to the AS/400 automatically: the first time you create one of these objects, the package attempts to logon to the AS/400. Here's one of the example programs:

 import java.math.*; import com.pbd.jdb400.*; public class TotalOrder { public static void main(String argv) { Jdb400.setDefaultLibrary("JDB400"); String orderNumber = argv0; Jdb400KeyedFile ORDHDRL1 = new Jdb400KeyedFile("ORDHDRL1"); Jdb400KeyedFile ORDDTLL1 = new Jdb400KeyedFile("ORDDTLL1"); BigDecimal totalAmount = new BigDecimal(0.00); if (ORDHDRL1.CHAIN(orderNumber)) { totalAmount = (BigDecimal) ORDHDRL1.getField("OHSHIP"); ORDDTLL1.SETLL(orderNumber); while (ORDDTLL1.READE(orderNumber)) totalAmount = totalAmount.add((BigDecimal) ORDDTLL1.getField("ODXAMT")); } System.out.println("Total for order " + orderNumber + " is " + totalAmount.toString()); System.exit(0); } } 

That program takes an order number from the command line, chains to the ORDHDRL1 file to get the shipment amount (OHSHIP) and then spins through the ORDDTLL1 file adding in the extended amount (ODXAMT), then prints the total. The zip file has two example programs, full source and full javadoc, and it's open-source, meaning you are free to copy it, modify it, use it, even sell it to your heart's content. Click href="http://www.zappie.net/Java/Techniques/JDB400/com_pbd.htm">here to find out more. (Um... there IS a professional version, of course... but we won't advertise that here grin) href="//www.zappie.net/java"> src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Zappie's Java Home" align="middle">

[Guest.Visitor]

The Java language's use of packages is extremely powerful. Yes, they are a pain when you first start to use them but they are very important to organizing your applications. What packages really are is for defining what is often called "name spaces" The names of packages a used to uniquely qualify a class. When you "import" a package eg: import java.awt.*; you don't have to qualify a class like: java.awt.Button pressMeHere = new java.awt.Button("Press me"); That much you probably already know, that is using Java's standard packages. But packages become real powerful for your own applications. AS/400 libraries can't be nested, packages can. When you have a package statement at the top of your source of: package net.zappie.access.JDB400; and you compile it, the .class byte code automatically gets placed in a directory of net/zappie/access/JDB400. When you test, the JVM will look for the class from the current directory but with the net/zappie/access/JDB400 qualification. If you are not in the directory that contains the directory net then the JVM won't find the class. Now, jar files makes everything real cool because when you use the jar.exe tool it places all your class files in one jar file. When your classpath contains that jar like: set classpath=C:javaAS400jt400.jar;c:java3rdPartyjdb40 0.jar; The JVM will be able to find the class that is in the JDB400.jar file. So, in summary:The javac compile stuffs the class in a directory qualified by the dot separated package name. The java JVM looks for any .class byte code files first in the jar files of the class path and then in the directory qualified by the dot separated package name. By using packages you are sure that if you call a class (like JDB400) it will not clash with some other fellow's class of the same name because you places a package statement at the top of your source qualifying it. That qualification, by the way, should start with the name of your company's domain. For Joe it's net.zappie for my stuff it's com.midrangecomputing. What I do then after com.midrangecomputing is I organized my classes according to technology like com.midrangecomputing.as400.access. For most companies you would organize it by application like com.lightBulbsRUs.inventory but you also might have utility areas. Pretty powerful stuff. Perhaps I ought to spend more than 10 minutes on this and publish an article at www.midrangecomputing/anje Web site on this.

[J.Pluta]

On Sunday, March 21, 1999, 07:28 PM, Don Denoncourt wrote: By using packages you are sure that if you call a class (like JDB400) it will not clash with some other fellow's class of the same name because you places a package statement at the top of your source qualifying it. That qualification, by the way, should start with the name of your company's domain. For Joe it's net.zappie for my stuff it's com.midrangecomputing.

---

Don is absolutely correct, but for a number of reasons I have chosen NOT to use color=blue>net.zappie as my name domain. This may change, but for now I use com.pbd for my packages (well, package singular... href="http://www.zappie.net/Java/Techniques/JDB400/com_pbd.htm">com.pbd.jdb400 is my first package). I co-opted it from a nice little company that does storage and distribution of documents (and, as an interesting little twist, they use an AS/400 to do their work). I don't expect them to be releasing any Java packages anytime soon. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Zappie's Java Home" align="middle">

[Guest.Visitor]

On Friday, March 19, 1999, 04:56 PM, Mario Martinez wrote: On Friday, March 19, 1999, 10:52 AM, Tom Conover wrote: .... With your background, they've already insulted you 3 times with those previous offers. Imagine what they'll do to you after your hired.

---

Tom, Over here in Phoenix, AZ a decent rate for a Senior Programmer/Analyst is $60,000 to $65,000 per year. What are the rates over in the LA area? (I think that's where you are from) I was thinking about going over to the LA area, but housing is much more expensive there. I still might go over there. I'd have to sell my house here, but that's not a problem. Thanks for your response. Here in southern MN (not the twin cities) the range is $35-$40 for entry level. Senior might get $55 or $60. In the twin cities you could expect at least 55k to start. Then again, you couldn't pay me enough to live in a metropolis area like Minneapolis, Chicaco, NY, LA, etc. Not my style... HREF="http://prairie.lakes.com/~bvstone/"> SRC="http://prairie.lakes.com/~bvstone/images/sig.gif">

[Guest.Visitor]

OK, I think I've got the idea of this package statement now, but I have a couple of problems. Let's say my Java program is called foo.java and I have a package statement at the top of it that goes like this: package MyPackage; If I compile foo.java I get a class called foo.class, and if I want to run it, I have to be in the directory immediately above the MyPackage directory, and I call it like this: java MyPackage.foo Problem 1 is how can I run this class if I'm not in the directory immediately above MyPackage? Problem 2 is a bit of a diversion, but how can I run a java class by clicking on a Windows icon? Any and all suggestions appreciated.

[J.Pluta]

On Monday, March 22, 1999, 11:43 PM, J V Thompson wrote: OK, I think I've got the idea of this package statement now, but I have a couple of problems. Let's say my Java program is called foo.java and I have a package statement at the top of it that goes like this: package MyPackage; If I compile foo.java I get a class called foo.class, and if I want to run it, I have to be in the directory immediately above the MyPackage directory, and I call it like this: java MyPackage.foo Problem 1 is how can I run this class if I'm not in the directory immediately above MyPackage? Problem 2 is a bit of a diversion, but how can I run a java class by clicking on a Windows icon?

---

1. I don't think you can, John. Now, I may be all wet here, but as far as I can tell, you normally only include in a package those classes that you are going to import. Your actual command line applications are not in a package. For me, I have my package com.pbd.jdb400. I include the statement "package com.pbd.jdb400;" at the front of every class in the package (but none of these classes are command-line classes!). Let's say my main source directory is: C:javaMySourcejdb400 All the source files are there in jdb400. THEN, I go to compile them, and because of the package statement, the classes all end up in: C:javaMySourcejdb400compbdjdb400 Way down in that directory is where my classes get created. So let's say one class is Jdb400KeyedFile. The class is: C:javaMySourcejdb400compbdjdb400Jdb400KeyedFile.cl ass All the other class files are down there, too. Now I create a test program that USES those files by specifying "import com.jdb.jdb400.*;". This first checks to see if compbdjdb400 exists in any of the jar files on my CLASSPATH. If it doesn't find them, it then looks for a subdirectory C:javaMySourcejdb400compbdjdb400 and brings all those classes into my program. I compile the program and the class is created in the C:javaMySourcejdb400 directory (because it does NOT have package statement), and I can run it from there. Hope this helps a little, John.
2. The easiest way I've found (and this applies to any DOS command line) is to put the command in a .bat file, and then create a shortcut to the .bat file (remember to set your working directory to the directory where the .bat file is). Works every time.

Joe src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Zappie's Java Home" align="middle">

[Guest.Visitor]

Regarding problem #1:Just set your classpath to point to the directory immediately prior to MyPackage. Then you can run it with java MyPackage.foo. This way you can have your entire application in a package. Regarding problem #2:Yep, use a .bat file and create a shortcut to the bat file on your desktop (or wherever). The bat file can also modify your classpath and path statements as needed. On Tuesday, March 23, 1999, 06:27 AM, Joe Pluta wrote: On Monday, March 22, 1999, 11:43 PM, J V Thompson wrote: OK, I think I've got the idea of this package statement now, but I have a couple of problems. Let's say my Java program is called foo.java and I have a package statement at the top of it that goes like this: package MyPackage; If I compile foo.java I get a class called foo.class, and if I want to run it, I have to be in the directory immediately above the MyPackage directory, and I call it like this: java MyPackage.foo Problem 1 is how can I run this class if I'm not in the directory immediately above MyPackage? Problem 2 is a bit of a diversion, but how can I run a java class by clicking on a Windows icon?

---

1. I don't think you can, John. Now, I may be all wet here, but as far as I can tell, you normally only include in a package those classes that you are going to import. Your actual command line applications are not in a package. For me, I have my package com.pbd.jdb400. I include the statement "package com.pbd.jdb400;" at the front of every class in the package (but none of these classes are command-line classes!). Let's say my main source directory is: C:javaMySourcejdb400 All the source files are there in jdb400. THEN, I go to compile them, and because of the package statement, the classes all end up in: C:javaMySourcejdb400compbdjdb400 Way down in that directory is where my classes get created. So let's say one class is Jdb400KeyedFile. The class is: C:javaMySourcejdb400compbdjdb400Jdb400KeyedFile.cl ass All the other class files are down there, too. Now I create a test program that USES those files by specifying "import com.jdb.jdb400.*;". This first checks to see if compbdjdb400 exists in any of the jar files on my CLASSPATH. If it doesn't find them, it then looks for a subdirectory C:javaMySourcejdb400compbdjdb400 and brings all those classes into my program. I compile the program and the class is created in the C:javaMySourcejdb400 directory (because it does NOT have package statement), and I can run it from there. Hope this helps a little, John.
2. The easiest way I've found (and this applies to any DOS command line) is to put the command in a .bat file, and then create a shortcut to the .bat file (remember to set your working directory to the directory where the .bat file is). Works every time.

Joe src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Zappie's Java Home" align="middle">

[J.Pluta]

On Tuesday, March 23, 1999, 06:56 AM, Alex Garrison wrote: Regarding problem #1: Just set your classpath to point to the directory immediately prior to MyPackage. Then you can run it with java MyPackage.foo. This way you can have your entire application in a package.

---

I have a problem with this. You ever have a situation where you find out you CAN do something, but something nags at you and you don't feel like you SHOULD do it? Kinda like sneaking a cupcake from the church bake sale tray... The following are my OPINIONS, and I'd love some feedback.

1. I get the same "this ain't right" feeling with "packaging" an application. Packaging is meant for APIs, obviously, used with the import statement. If a class is not intended to be instantiated by another class (that is, it's an application or applet), it should not be in a package (?).
2. I don't like accessing something in a jar from the command line. This is even more obviously a personal quirk, but it seems important to me for some reason. Maybe it's because I want the jar files to be as small as possible, and applications can just be classes in the directory. I equate jars to DLLs and application classes to .EXE files. Am I weird, or what?
3. I'd like to move towards a very simple classpath. Ultimately, I'd like to have a directory calls c:java3rdpartyjars, and point my classpath to it by adding "c:java3rdpartyjars*.jar;" to my CLASSPATH variable. If performance became an issue, I'd like an object that represented a set of jars that could be attached to a java class. It seems to me that the idea of WORA can be easily canceled out by a complex CLASSPATH. As soon as two java-based products require conflicting CLASSPATHs, we're going to have problems. On the other hand, I guess that temporary classpaths are okay; whenever you start a java-based product, it has its own CLASSPATH. My only issue there is that I'd worry about bridging between two applications. Dragging and dropping would seem to be okay, but directly initiating another application might be tricky, and invoking one another's objects could be downright problematic.

Again, these are opinions and need lots of input. Feel free to agree, argue, throw vegetables (I'm particularly fond of broccoli, BTW). src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Zappie's Java Home" align="middle">

[Guest.Visitor]

On Monday, March 22, 1999, 11:20 AM, Bradley V. Stone wrote: Here in southern MN (not the twin cities) the range is $35-$40 for entry level. Senior might get $55 or $60. In the twin cities you could expect at least 55k to start. Then again, you couldn't pay me enough to live in a metropolis area like Minneapolis, Chicaco, NY, LA, etc. Not my style... Bradley, I'm glad that you are happy about where you live and work. I wish that I could say the same. AS/400 wages definitely differ from region to region. As for me, I'm trying to get closer to my rural roots. I intend to do something about that, but I'm not quite sure what. In the meantime, I work in the city and head for the countryside on the weekends. Thanks for your input.

[Guest.Visitor]

Mario, That Phoenix rate seems about average for L.A. Probably the difference shows up with high demand skills such as JD Edwards, where you can get 75 - 90 K, plus you have more places to choose from. I had an apartment in Scottsdale (92nd and Shea) for about six months (still worked in L.A.) and I couldn't believe the price of housing compared to L.A. Unless you can swing a much better deal in L.A., you might as well stay where you are. Housing here is ridiculous.

---

On Friday, March 19, 1999, 04:56 PM, Mario Martinez wrote: Tom, Over here in Phoenix, AZ a decent rate for a Senior Programmer/Analyst is $60,000 to $65,000 per year. What are the rates over in the LA area? (I think that's where you are from) I was thinking about going over to the LA area, but housing is much more expensive there. I still might go over there. I'd have to sell my house here, but that's not a problem.