net.digest May 1998

Click here for RAC sponsor message

Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your production or development HP 3000s.

918 systems beat to different drummer

If you’ve ever wondered about how HP separates the bottom two rungs of its 9x8 line, a recent thread that hoped for more horsepower on the 918 actually uncovered less. At least less than a very similar configuration of 3000 hardware. Gary Biggs, whose research on the new 918DX pricing opened a few eyes at the recent IPROF conference when he showed how to delete support for products on that developer’s bundle, asked:

“We unpacked the new 918 box yesterday and installed 384 megs of extra memory. During our work I noticed the CPU information indicated that we had a 48MhZ processor, the same speed as the 928RX we purchased two years ago. Has HP started ‘overclocking’ 918s? This box seems every bit as fast as the older unit.”

The replies came in quickly to deliver not only reports of the 918’s speed, but the relationship with the 928 units as well. Stan Sieler noted that HP’s documentation rates the 918 as a slower system, but more detailed education came from Brent Flowers, who explained:

“The HP3000/900 Configuration Guide (February, 1998, page 1-2) notes: “The clock speeds of the 918LX/RX, 939KS/020, and 996/80 are effected with software.”

[Notes on CSY’s] Jazz say, “The MPE 918DX ... is a 918/LX with ... 64 MB memory “

“Does this mean software is being used to intentionally slow the clocks down? I find myself imagining a piece of code which kicks in every so often to count from 1 to 1000, wasting enough clock cycles to slow it from 48MHz to 34MHz.”

There’s been documentation from HP in the public domain about how the Series 918s get their horsepower set. Now the question becomes how long it might be before a faster developer’s bundle can be ready. After all, it appears there’s no hardware modifications that need to be made.

Extending the long arm of IMAGE

It only takes a question on the Internet to find how wide the variety of database tools is on the HP 3000. One reply showed answers existed in the operating system, from two widely-respected third party suppliers and the Interex Contributed Software library. Michael Anderson asked:

I looking for some advice, or to be pointed in the right direction, to solve a particular IMAGE DBOPEN/Security Issue. My task is to write a program that will run as MANAGER.SYS(PM MODE), and find all IMAGE Databases on the System, in every account. Then open each one, and using DBINFO, build a report of all Search Items, and all Sort Items, in every Database.

How am I going to open databases that exist in other accounts, with MPE Security in the way, and not knowing the IMAGE Password? My first thoughts were to use FLABELINFO to get the creator of the ROOT FILE, and then use an Architected Interface call to become that USER, then call DBOPEN using “;” as the password. Does anyone have any experiences with similar solutions, or know of any reason that this won’t work?”

Mike Hornsby, author of the TurboIMAGE handbook, weighed in with a complete list that concluded with a well-known tool:

“First, to find all of the IMAGE databases you need to perform some type of LISTF command. Since all IMAGE databases must have at least one dataset you can start with @.@.@01. But this method does have some problems: directory problems can abort a listf, and MANMAN among others has a curious naming convention, so it is very likely that you will come across datasets with repeating 0101s.

The second phase of actually getting the data has three options: One method is to use SM and PM to open the root file and parse out the set and item tables directly. This method is the most direct but be warned that you will come across various versions of IMAGE that have various table formats.

The second method is to use Query or your own program that calls DBINFO to extract the data. This method only works if you can logon as the creator for each database. On the old MPE V systems HP included a program called TMPCONVP.CONVALL.SYS that really was the XLOGON program. On MPE/iX systems VESOFT still offers this functionality. Are there any other versions of XLOGON?
Finally, and probably your best bet, is to build a driver script for Adager or some other IMAGE utility that will allow you to extract the data you want.”

Gilles Schipper noted that there’s a modern-day substitute for XLOGON:

“WLKABOUT can be found in the Interex Contributed Library. It’s not quite as good as XLOGON5 was, since it does not work quite as well in batch – where it’s often most useful.”

John Zoltak offered an update including a command from one of the latest versions of MPE/iX:
“As of MPE/iX 5.5 Express 3 you can do this:

LISTFILE @.@.@,6;SELEQ=[CODE=-400]

This will list the fully qualified TurboIMAGE rootfiles.”

And another reply explained MPEX’s magic:

“You can use MPEX from VESOFT to do something like :
repeat extract account and group from and creator from : !MPEXCURRENTFILE chlogn to account (one possible problem is that the creator does not exist as a valid user) run your_program.pub.sys forfiles @.@.@(intcode=-400)”
Java: not for breakfast anymore

Once we stirred up some interest about Java/iX with our front page story of our last issue, one Internet poster and NewsWire reader wanted some first-hand reports on what to do with the new tool. Where better to get it than the Internet? SIGJAVA co-chair Gavin Scott answered questions from John Zoltak.

John: I haven’t been inclined to download the goods from Jazz because I am not doing any web stuff from the HP 3000.

Gavin: Ah, but Java’s not just for breakfast anymore.

John: So I have to ask, what can Java/iX do for me.

Gavin: It’s a programming language. You write programs in it.

It has also got extensive libraries for things like networking etc., and Mike Yawn at HP has written a set of TurboIMAGE classes that let you access IMAGE databases.

There are lots of reasons why Java is a better way to do software development, and not all of them are the things that Sun touts. After two years of playing with it, I’m more convinced than ever that I’d want to write everything in Java if I could. Unfortunately we’re not yet to the point that you can just throw out all your COBOL and replace it with Java. Also don’t forget that learning to design and write Object Oriented systems is not a skill that’s trivial to acquire.

Here are some possible Java and 3000 scenarios:

1) Java applets in web pages served from the 3000: You can write Java programs using any Java development tool and load the code for these programs (applets) on the 3000 where a web server like Apache can serve them up as part of a web page. These applets could then talk to C programs or CGI/Perl programs back on the host. This does not require that you install Java/iX on the 3000 at all, since the Java code will be running on the PCs, not on the 3000.

2) A Java Client/Server environment: As in number 1, a Java user interface runs on client PCs. The client can either be downloaded from a web server, or it could be a standalone application installed on the PC. The client would communicate with a server on the 3000 that was also written in Java. This would require Java/iX on the 3000 in order to run the server. Because both the client and server are in Java, it makes the development easier, and you can take advantage of Java to Java communication facilities like the RMI Remote Objects system.

3) A standalone Java application on the 3000: No web, no GUI, no Client/Server, no TCP/IP. Just good old fashioned HP 3000 application programs that happen to be written in Java rather than COBOL, C, or whatever.

So far there have not been too many people actually doing this, though a lot of people are thinking about it. Currently most of the effort is going into developing things like numbers 1 and 2, since they involve the Web.

John: Okay, object orientation and reusability is good. But for many of my users sitting at their HP700/98 terminal, how would a Java/iX application look and work for them?

Gavin: You can write a Java program just like you write a COBOL/iX or a C/iX program today. Also just like C and COBOL, the Java language does not have a built-in mechanism for screen handling on a character mode terminal. You would have to either call VPlus from Java (which can be done, though I don’t know of anyone who has tried it yet since you would have to write some C language stubs to call VPlus from Java code), or write/acquire a screen handling package of some kind. This probably wouldn’t be that hard to write, but it’s not something that exists today as far as I know.

John: Does Java/iX compile to a Native Mode Program (NMPRG), or is this an interpreted program?

Gavin: The normally interpreted universal Java code is automagically translated into native PA-RISC (a’la NMPRG) at runtime, so it’s somewhere in between interpreted and NMPRG. In the future you should be able to produce NMPRGs.

There are still some performance and resource usage issues in the current version, but things have been improving steadily over time. HP is making large investments in Java on the HP-UX side of the company, and the 3000 is benefiting from this by leveraging and porting those efforts to MPE.

John: Also the way I remember it, Java was supposed to run in a “sandbox” so that it couldn’t interfere with the executing client. Does this still apply?

Gavin: That only applies to Java “applets” that run in a Web Browser. Java “Applications” (ordinary programs) have none of those restrictions.

Copyright 1998, The 3000 NewsWire. All rights reserved.




		Click here for RAC sponsor message
		Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your production or development HP 3000s. 918 systems beat to different drummer If you’ve ever wondered about how HP separates the bottom two rungs of its 9x8 line, a recent thread that hoped for more horsepower on the 918 actually uncovered less. At least less than a very similar configuration of 3000 hardware. Gary Biggs, whose research on the new 918DX pricing opened a few eyes at the recent IPROF conference when he showed how to delete support for products on that developer’s bundle, asked: “We unpacked the new 918 box yesterday and installed 384 megs of extra memory. During our work I noticed the CPU information indicated that we had a 48MhZ processor, the same speed as the 928RX we purchased two years ago. Has HP started ‘overclocking’ 918s? This box seems every bit as fast as the older unit.” The replies came in quickly to deliver not only reports of the 918’s speed, but the relationship with the 928 units as well. Stan Sieler noted that HP’s documentation rates the 918 as a slower system, but more detailed education came from Brent Flowers, who explained: “The HP3000/900 Configuration Guide (February, 1998, page 1-2) notes: “The clock speeds of the 918LX/RX, 939KS/020, and 996/80 are effected with software.” [Notes on CSY’s] Jazz say, “The MPE 918DX ... is a 918/LX with ... 64 MB memory “ “Does this mean software is being used to intentionally slow the clocks down? I find myself imagining a piece of code which kicks in every so often to count from 1 to 1000, wasting enough clock cycles to slow it from 48MHz to 34MHz.” There’s been documentation from HP in the public domain about how the Series 918s get their horsepower set. Now the question becomes how long it might be before a faster developer’s bundle can be ready. After all, it appears there’s no hardware modifications that need to be made. Extending the long arm of IMAGE It only takes a question on the Internet to find how wide the variety of database tools is on the HP 3000. One reply showed answers existed in the operating system, from two widely-respected third party suppliers and the Interex Contributed Software library. Michael Anderson asked: I looking for some advice, or to be pointed in the right direction, to solve a particular IMAGE DBOPEN/Security Issue. My task is to write a program that will run as MANAGER.SYS(PM MODE), and find all IMAGE Databases on the System, in every account. Then open each one, and using DBINFO, build a report of all Search Items, and all Sort Items, in every Database. How am I going to open databases that exist in other accounts, with MPE Security in the way, and not knowing the IMAGE Password? My first thoughts were to use FLABELINFO to get the creator of the ROOT FILE, and then use an Architected Interface call to become that USER, then call DBOPEN using “;” as the password. Does anyone have any experiences with similar solutions, or know of any reason that this won’t work?” Mike Hornsby, author of the TurboIMAGE handbook, weighed in with a complete list that concluded with a well-known tool: “First, to find all of the IMAGE databases you need to perform some type of LISTF command. Since all IMAGE databases must have at least one dataset you can start with @.@.@01. But this method does have some problems: directory problems can abort a listf, and MANMAN among others has a curious naming convention, so it is very likely that you will come across datasets with repeating 0101s. The second phase of actually getting the data has three options: One method is to use SM and PM to open the root file and parse out the set and item tables directly. This method is the most direct but be warned that you will come across various versions of IMAGE that have various table formats. The second method is to use Query or your own program that calls DBINFO to extract the data. This method only works if you can logon as the creator for each database. On the old MPE V systems HP included a program called TMPCONVP.CONVALL.SYS that really was the XLOGON program. On MPE/iX systems VESOFT still offers this functionality. Are there any other versions of XLOGON? Finally, and probably your best bet, is to build a driver script for Adager or some other IMAGE utility that will allow you to extract the data you want.” Gilles Schipper noted that there’s a modern-day substitute for XLOGON: “WLKABOUT can be found in the Interex Contributed Library. It’s not quite as good as XLOGON5 was, since it does not work quite as well in batch – where it’s often most useful.” John Zoltak offered an update including a command from one of the latest versions of MPE/iX: “As of MPE/iX 5.5 Express 3 you can do this: `LISTFILE @.@.@,6;SELEQ=[CODE=-400]` This will list the fully qualified TurboIMAGE rootfiles.” And another reply explained MPEX’s magic: “You can use MPEX from VESOFT to do something like : `repeat extract account and group from and creator from : !MPEXCURRENTFILE chlogn to account (one possible problem is that the creator does not exist as a valid user) run your_program.pub.sys forfiles @.@.@(intcode=-400)”` Java: not for breakfast anymore Once we stirred up some interest about Java/iX with our front page story of our last issue, one Internet poster and NewsWire reader wanted some first-hand reports on what to do with the new tool. Where better to get it than the Internet? SIGJAVA co-chair Gavin Scott answered questions from John Zoltak. John: I haven’t been inclined to download the goods from Jazz because I am not doing any web stuff from the HP 3000. Gavin: Ah, but Java’s not just for breakfast anymore. John: So I have to ask, what can Java/iX do for me. Gavin: It’s a programming language. You write programs in it. It has also got extensive libraries for things like networking etc., and Mike Yawn at HP has written a set of TurboIMAGE classes that let you access IMAGE databases. There are lots of reasons why Java is a better way to do software development, and not all of them are the things that Sun touts. After two years of playing with it, I’m more convinced than ever that I’d want to write everything in Java if I could. Unfortunately we’re not yet to the point that you can just throw out all your COBOL and replace it with Java. Also don’t forget that learning to design and write Object Oriented systems is not a skill that’s trivial to acquire. Here are some possible Java and 3000 scenarios: 1) Java applets in web pages served from the 3000: You can write Java programs using any Java development tool and load the code for these programs (applets) on the 3000 where a web server like Apache can serve them up as part of a web page. These applets could then talk to C programs or CGI/Perl programs back on the host. This does not require that you install Java/iX on the 3000 at all, since the Java code will be running on the PCs, not on the 3000. 2) A Java Client/Server environment: As in number 1, a Java user interface runs on client PCs. The client can either be downloaded from a web server, or it could be a standalone application installed on the PC. The client would communicate with a server on the 3000 that was also written in Java. This would require Java/iX on the 3000 in order to run the server. Because both the client and server are in Java, it makes the development easier, and you can take advantage of Java to Java communication facilities like the RMI Remote Objects system. 3) A standalone Java application on the 3000: No web, no GUI, no Client/Server, no TCP/IP. Just good old fashioned HP 3000 application programs that happen to be written in Java rather than COBOL, C, or whatever. So far there have not been too many people actually doing this, though a lot of people are thinking about it. Currently most of the effort is going into developing things like numbers 1 and 2, since they involve the Web. John: Okay, object orientation and reusability is good. But for many of my users sitting at their HP700/98 terminal, how would a Java/iX application look and work for them? Gavin: You can write a Java program just like you write a COBOL/iX or a C/iX program today. Also just like C and COBOL, the Java language does not have a built-in mechanism for screen handling on a character mode terminal. You would have to either call VPlus from Java (which can be done, though I don’t know of anyone who has tried it yet since you would have to write some C language stubs to call VPlus from Java code), or write/acquire a screen handling package of some kind. This probably wouldn’t be that hard to write, but it’s not something that exists today as far as I know. John: Does Java/iX compile to a Native Mode Program (NMPRG), or is this an interpreted program? Gavin: The normally interpreted universal Java code is automagically translated into native PA-RISC (a’la NMPRG) at runtime, so it’s somewhere in between interpreted and NMPRG. In the future you should be able to produce NMPRGs. There are still some performance and resource usage issues in the current version, but things have been improving steadily over time. HP is making large investments in Java on the HP-UX side of the company, and the 3000 is benefiting from this by leveraging and porting those efforts to MPE. John: Also the way I remember it, Java was supposed to run in a “sandbox” so that it couldn’t interfere with the executing client. Does this still apply? Gavin: That only applies to Java “applets” that run in a Web Browser. Java “Applications” (ordinary programs) have none of those restrictions.
		Copyright 1998, The 3000 NewsWire. All rights reserved.