HP3000-L is a truly unique experience. Recently I have had the opportunity (somewhat forced, but that is the long story we have all been living since November 14, 2001) to compare HP3000-L with MIDRANGE-L. MIDRANGE-L is the listserver where those interested in the technical aspects of the iSeries (AS400) hang out. It is very collegial, just like HP3000-L, and a lot of good advice is dispensed. For example, I was able to solve a problem I was having with an iSeries, a problem not documented on IBM’s public web sites, by searching the MIDRANGE-L archives. However, the denizens of MIDRANGE-L just do not seem to have quite the same passion, not only for their system of choice, but for life in general, as those of HP3000-L. Of course sometimes that passion for life can be a bit overwhelming as threads whose roots are either in politics or in religion occasionally hijack the list. A casual observer might think nothing of technical merit was discussed this month, but he would be wrong.
I always like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you think I’m full of it or goofed, or a horse's behind, let me know. If something from these columns helped you, let me know. If you’ve got an idea for something you think I missed, let me know. If you spot something on HP3000-L and would like someone to elaborate on what was discussed, let me know. Are you seeing a pattern here? You can reach me at john@burke-consulting.com.
The question was
"How long will HP support the A400?" The answer of course is December
31, 2006. One person suggested buying up multiples of all peripheral equipment
and putting them in storage to use as replacements as a way to be good until
2020. This allowed peripheral expert Denys Deauchemin to chime in with the
following. "For an A or N-class, the issue of peripheral hardware is
nowhere near as dire as for the NIO systems. The problem with 9x9, 99x and 9x8
systems has to do with HVD (high voltage differential or FWSCSI in MPE
parlance) SCSI devices such as disk drives and tape drives. There has not been
an HVD disk drive manufactured in a few years and they probably never will be
again. The LVD devices used in A and N systems are still being manufactured and
should be for a while longer. However, please understand this situation will
change in the future as cheap, fast and huge capacity serial ATA or SATA drives
take over the world and the PCI architecture evolves into the PCI-Express
architecture starting in 2004.
"The server
of 2006 will be vastly different than the server in 2003. If you have a PCI
system (A and N) there should be a good supply of newly or recently
manufactured LVD disk and tape drives for several years to come. I would say
however, that much beyond 2010 should be problematic, all things being equal.
If you have a pre-PCI system (9xx), you have a challenge and some alternatives.
Technology does exist to allow you to connect the latest fiber or LVD disk drive
or arrays to your FWSCSI connections. These solutions work and work very well
but HP does not support them. For your SE SCSI connections, Seagate is
producing new technology disk drives with an SE SCSI connection, especially
targeted at legacy systems."
Note that HP
engineers maintain that HP firmware (the stuff that makes off-the-shelf disk
drives “HP” drives) is important, especially in high-end systems with the newer
very fast drives, to avoid I/O problems. I’ve written about this several times
under the heading SCSI is SCSI.
Samba can often
play a key role in transition plans, so I thought the following question and
the answers provided by two MPE/iX experts deserved repeating. The question
was, "Is anyone aware of performance issues or security issues with Samba
on an HP3000? We currently have a N4000 that is behind a firewall. Our
application provider is telling us that we need SAMBA to serve up .jpg files,
but that it was ill advised as SAMBA causes performance issues on the HP3000
and that it has security issues. Any insight is appreciated."
Mark Bixby, who
ported Apache among other things, replied, "For best Samba performance you
want to run the JSMB job instead of running Samba under INETD. As a separate
job, you can run SMBD in whatever dispatching queue (CS, DS, ES, etc) is
appropriate for your machine. Make sure your Samba content is stored as MPE
bytestream files. You will pay a performance penalty if you are using MPE
record-oriented file types. Samba on MPE is no more or no less secure than
Samba on any other platform. Follow good Samba security practices by disabling
guest access (all versions of Samba on MPE) and enabling encrypted passwords
(Samba 2.2.8a on MPE). For more information about Samba 2.2.8a on MPE, please
see: http://jazz.external.hp.com/src/samba/"
Lars Appel, who
did the original Samba port, added, "Maybe the application provider could
provide some details to his advice. Maybe he is referring to the fact that
older Samba/iX versions do not handle the 'encrypt passwords' feature and rely
on plain text passwords, similar to what telnet, NS/VT, or ftp connections do.
Another issue, but not 3000 specific, is whether you configure shares that
allow guest access (no passwords) and are browseable (i.e. can be seen in
network neighborhood or with net view \\hostname) and allow write access, like
the [public] example in the sample smb.conf file. The ‘popular’ Windows based
worms can use such shares for their evil purpose of propagating themselves
throughout the network. Infected files on a 3000 share don't cause trouble for
the 3000 itself; they only are dangerous for innocent PC users double-clicking
them. So you'd want to avoid shares with 'guest ok', 'browseable' and 'write
ok'.”
I used Samba for
over three years in a production environment during a migration to move data
back and forth between MPE applications and SAP’s R/3 running on Windows. MPE
programs would extract data to bytestream files that were then read directly
off the HP 3000 by ABAP programs running under SAP. Other ABAP programs would
write directly to bytestream files on the HP 3000 that other MPE programs would
read and process. Worked so well, we sometimes forgot we were even doing it.
Many people have difficulty the first time the try to use Samba. It is one of those systems that are so loaded with options it can become very confusing. The question went like this, "I am having trouble with Samba (207). I have set up a share in smb.conf:
[prod]
comment = share for PROD
path = /PROD/PUB
username = mgr.prod
writeable = Yes
guest ok = Yes
"When I open up the directory I can see the file that is already in PUB.PROD, but when I try to drag a file there using Windows Explorer, I get the message (from Windows 2k):
Cannot copy VOLGMT64: Access is denied. The source file may be in use.
"I have the feeling that it is an erroneous message (the file isn't in use) and if I leave the path at /tmp, I can drop it just fine. The engineer at the Response Center thought that I may not be able to drop it into the MPE filespace and that it had to go into a posix directory. That seemed kind of strange to me. So, is there another setting I need to allow me to drop into PUB.PROD? By the way, I have SWAT running, which is much easier than editing smb.conf with vi."
John Clogg, who obviously has struggled with this himself, replied, I have been dealing with exactly the same thing. Since you have guest access enabled, I assume you are not entering the password for MGR.PROD to gain access to it. Therefore, the SMB process is acting as if you are the guest user (probably MGR.SAMBA). Since you can't build files across account boundaries (unless you have SM capability), it honors the MPE access restriction and won't let you build a file there. If you had an HFS directory in that account, you could do a chmod on the directory to allow update access to the directory, which would allow you to save file there. The possible solutions are (1) change the guest user in smb.conf to mgr.prod, (2) give mgr.samba SM capability (possible security issues there), (3) create an HFS directory to store the file in and allow write access to the directory, or (4) do not use guest access. If anyone knows another approach, I would love to hear it. This has caused me some major headaches!"
Lars Appel, who
did the original Samba port, gave a short tutorial that should be part of every
system manager's System Manual, "John Clogg already hit the nail on the
head with his reply. Your share is 'guest ok' and will thus use the 'guest
account' from the [global] section to access the files. The 'username' is
irrelevant here, it would be used to check the password against, if you had
'guest ok = no'. In that case I would also add 'only user = yes', because SMBD
would otherwise use several other attempts to guess the user (e.g. share name,
windows logon, netbios name of client, potentially mapped via user.map) to try
the password against. This can be confusing, thus I prefer to override with
'username=x.y' and 'only user = yes'.
"For file
access problems after successful 'map network drive', it is typically useful to
examine the output of smbstatus (the showjob of samba and check on which (MPE)
user's behalf the access to the files is performed for the share at hand. You
can then logon as that very user and try the same file access from CI or Shell
to get an idea why SMBD might fail to do what you want. The CI or Shell has
typically much better error messages (and means to examine the permissions)
then the Windows PC presents. Two share definition examples that I typically
use (besides [homes]):
[alpha]
comment = guest ok / public means: no password needed
path = /ACCOUNT/GROUP
guest ok = yes
write ok = no
;
guest account = user.account
;
browseable = no
[bravo]
comment = this share requires MPE password validation
path = /ACCOUNT/GROUP
guest ok = no
write ok = yes
user = user.account
only user = yes
"For [alpha] you typically don't want 'write ok' and 'browseable' at the same time, because popular worms can then find and use the shared directory to try replicating themselves. No harm for MPE, but for the potentially infected/corrupted files and other users visiting the same share. I believe, you can override 'guest account' at the share level; thus my commented line in the [alpha] example. Depending on the MPE file system level permissions in /ACCOUNT/GROUP, you might need this for successful file access/modification/creation from the client side."