Click here for RAC Sponsor Message

net.digest

Analysis by John Burke

Hello JetDirect EX. Please answer. Is anybody home?
With MPE/iX 5.5, we are now able to define and print to network connected printers through the NM spooler. The catch is you need an HP JetDirect internal card in the printer or an HP JetDirect external print server (or 100 percent compatible). Which means you will be in the position of the persons who posted the following composite questions:

"I just got my JetDirect equipment. I went to install it but found that there really aren't any directions on how to set the IP address. And I assume that without the IP address the MPE/iX 5.5 network printing will not work. The manual mentions being able to telnet into it to set the IP address using the default IP address. Does anyone know what that default IP address is? I don't want to mess around with BOOTP or other things that I have not used. Telnet I know."

"Since the JetDirect EX has three ports we need to also set the port number. I do not know if MPE/iX 5.5 gives you a facility to do this."

There followed quite a bit of advice, some of it contradictory. I am going to present most of it in the hope that one of the techniques will work for you.

"The JetDirect EX has its default IP address and subnet mask set to 0.0.0.0. You can't telnet to assign the IP address."

"I believe this is correct. The JetDirect interface (internal, EX, or EX Plus 3) receives its (one) IP address via a bootp query. So you cannot telnet to it until that IP address has been installed."

"As long as you are running MPE/iX 5.5 you can run a job which takes a bootp request from the JetDirect card. This is detailed in the manual 'Configuring and Managing MPE/iX Internet Services'. It requires that you have the JINETD job running, which listens for the bootp requests. There are a number of other files (SERVICES, PROTOCOL, INETDCNF, BOOTPTAB) that are required. If you have a Unixbox you can configure it to process bootp requests as well. If the JetDirect card can handle DHCP, you can use a DHCP server (such as NT) to reserve an IP address. You can also get firmware upgrades for some JetDirect cards off the HP home page which will allow the card to do DHCP requests."

"I believe the more recent versions of the JetAdmin software allow you to set the TCP/IP address directly. You can download the software from HP's FTP site, but it should also come with the JetDirect box. Off hand, I don't recall just how to navigate to the right spot to do it, and I do seem to recall that it wasn't obvious -- try searching in help if you can't find it. By the way, bootp is real easy, once you get used to it, although it is a typical 'yet-another-flag-file-Unix-type-thing'."

"Not all JetAdmin versions seem to support configuring the TCP/IP aspects of the JetDirect interfaces. If you don't have JetAdmin or it does not seem to want to help and you do not want to do bootp, try telneting to the ip address 192.0.0.192 as the factory default. You will have to change the IP address of your PC to something like 192.0.0.1 so that it will be able to access the 192.0.0.192 address."

"The network printing spooler allows you to set a TCP/IP port number for a specific printer connected to any of the JetDirect EX Plus 3 ports. The default port is 9100, for the single-port JetDirect interfaces. The EX Plus 3 box uses the three ports 9100, 9101, and 9102. To specify one of the latter two, use the tcp_port_number item in NPCONFIG, as in:

Imagine images and IMAGE

In an increasingly graphics conscious world, we are being called upon to store data that no longer conforms to the fixed field/record model. Consider the following question posed on HP 3000-L:

"Does anyone know if it is possible to store Allbase BLOB-type data in a TurboIMAGE database, and if so, what are the storage limits of a single BLOB? This concerns a new ID card system where we might have the option of storing the student's picture with the textual part of their ID card."

"The answer, at the moment, is no, it's not possible to store BLOBs in IMAGE, although BLOB manipulation has been slowly moving up on the SIGIMAGE improvement ballot over the past five years indicating increased recognition of the value of BLOBs among the voting members.

"However, something I feel quite strongly about is that BLOBs shouldn't be done in the same manner as they are done in ALLBASE (or almost all other RDBMSs). In ALLBASE, the BLOB is held in-line with the other fields -- and I believe that doing this will become more and more obviously considered to be a fundamental design mistake, simply because BLOB usage is likely to increase quite explosively once desktop presentation mechanisms become common.

"BLOBs grew out of a philosophical extension of variable character text in RDBMSs, where text fields are the most general form of data storage in computers. You can store either a variable amount of text in such a field (as was the original intention) -- or you can store a bit-mapped signature, a bit of Beethoven, or a full-length, high resolution, quadraphonic sound copy of Dr. Zhivago, the movie.

"And that's the essence of the problem: all of the BLOB material stored in this manner has to be backed up because it is an integral part of the database. But BLOBs will never be as dynamic a part of the information held in the database's fields as are the more normal fields (name, address, city,...).

"By far and away the best way to design BLOBs into IMAGE is to create a blob object manager and store the BLOBs orthogonally to the data. This is not as difficult as it might sound. In fact, almost any of us could do it in a weekend. Presume that your BLOB object manager/storage mechanism was nothing more than a studio-quality DVD disc with high-speed indexing. In order to modify IMAGE to make it BLOB-capable, all you would have to do in add two or three new data items to the record: start point, stop point, and some form of disc ID name and provide some mechanism to pass that information to the DVD player.

"If you then wished to see a particular sequence of Dr. Zhivago (or get a signature, or a scan of a check, or whatever), you would search the IMAGE database as you always have in the past. Once the appropriate record(s) were found, the information held in the start, stop and ID fields would then be retrieved, passed to the BLOB object manager (which could be as simple as a small file reader program, where the data is stored on your standard discs, or as complicated as an automated disc retrieval system), and have the resulting bit map stream passed back to your desktop device for presentation.

"The structure of IMAGE in this design would be more like the index that appears at the end of a textbook. The index is the IMAGE database. The pages of the book are orthogonal BLOBs. If you wished to read every page in the book that had something to do with subject X, you would search the index as you always had and then retrieve only those pages of interest.

"The advantages of this form of design is that IMAGE remains small and compact, thus easily backed up, and very fast in retrievals, while the nature of the BLOBs are free to evolve as necessary, almost without impact on the fundamental nature of IMAGE or the CPU that bears it."

"The client scans 10,000 to 16,000 200dpi .tiff files per day that are stored as simple files on an NT server (100Mhz Pentium HP Netserver) with 150Gb of RAID. Each file is given a serial number (name) and these are 'slashed' into a hierarchy of directories. The serial number is the only entry in the TurboIMAGE database. This makes it easy to "IMAGE enable" any existing or new application.

"We glue the structured data (from the HP 3000) and the BLOB from the NT server together on the PC Windows client using a Visual Basic DDE capable viewer, and Reflections via DDE commands echoed from the HP 3000."

Linking the HP 3000 to some external clock source

Michael Gueterman of Easy Does It Technologies explained this procedure:

"I sync the 3000 from one of my Windows NT machines which is sync'd to one of the official time sources over the internet. The reason I do it this way is that the software I use on the NT side is using the SNTP protocol which is a step up in accuracy from the TIME protocol I use from the 3000. Since I'm going over the Internet to get the time, latency can make a big difference in the adjusted time, so I want something a little better for my 'main source'. I'm not so worried about system or network loads affecting the time syncs on my internal LAN, so using the TIME protocol to set the 3000's clock isn't bad. Also, the best you can do on the 3000 side is 'to the second,' not below. Since I'm going to my NT system for the 3000, I also go to the same spot for my other systems as well.

"For the 3000 to make use of an external time server, you need something similar to the 'NETTIME' program available on the Interex CSL. It uses the TIME protocol via UDP datagrams to retrieve the time from some other system available to you over a LAN running a TIME server.

"If you want the 3000 to serve up the time using the TIME protocol, you can do that in a couple of ways depending upon your OS level. If you are on 5.5, HP has provided a time server running under INETD (see 'Configuring and Managing MPE/iX Internet Services' manual). If you are on 4.5 or 5.0, you can get a copy of my 'TIMESRV' program available at www.editcorp.com/editcorp/products/index.html

"I've also seen similar programs (both clients and servers) at several of the other HP 3000 sites that offer downloads. The only caveat I have on this is for those twice a year daylight savings time shifts. If you are adjusting your time via one of these clients on a frequent basis, make sure that at the appropriate time you adjust your time zone BEFORE you go off and set the new time. If you don't, the client will try and set the clock ahead/back the whole hour based on the now incorrect time zone. This will have the undesired effect of shifting what the system considers UTC off an hour!"

"Network-wise, there are three distinct sources of 'time' on the network you can sync with to varying degrees of accuracy. These are:

* DAYTIME - on port 13 udp/tcp returns an ASCII string of the date and time such as 'Sat Apr 12 12:28:29 1997'.

* TIME - on port 37 udp/tcp returns a 4-byte binary ctime()-like value corresponding to the GMT/UT clock.

* NTP - on port 123 udp/tcp, Network Time Protocol, returns a 'whole bunch of stuff' used to synchronize machines with considerable accuracy (milliseconds, if not better). Very important to Kerberos, DCE, and other time-relative certificate security systems.

"TARDIS and other programs for DOS/Win/NT set clocks based on TIME or NTP and a locally-defined time zone.

"There are various servers available for public access for time sync purposes such as tycho.usno.navy.mil, the US Naval Observatory, which is a stratum 2 ntp source ('stratum' is a degree of accuracy; stratum 1 servers have a built-in atomic clock, stratum 2 servers are set via ntp from a stratum 1, stratum 'n' servers are set via ntp from stratum 'n-1' servers, etc.)

"Of course, if you're a good network citizen, you only sync one or two sources to the external servers, and sync your remaining machines to the local sources."

"I actually have one of my NT systems setup using TARDIS as an 'NTP protocol client' to a publicly available server on the Internet, and as a 'TIME protocol server' to my 3000 and other PC's on my internal LAN. This keeps my systems in fairly close sync (1-3 seconds), and I'm being a good Netizen by having only one system sync itself with the outside world, thus reducing the load on the public time servers. Works pretty good for me!"

Copyright 1997, The 3000 NewsWire. All rights reserved.