HiddenValue details commands and programs in
MPE that can improve productivity on HP 3000 systems. Get a free NewsWire
"HP 3000 Always Online" denim and suede cap -- submit an MPE tip
to Hidden Value. E-mail your tips to rseybold@zilker.net, or fax them to
512-331-3807.
I need to add classes to a printer on my HP 3000. I keep getting a message that
the LDEV doesn't exist from SYSGEN's I/O section when I issue the ACLASS
command. I can see the device exists, so what's the problem?
Devices on your system that are configured through NMMGR must have
their classes changed through NMMGR, which is probably why you're getting the
error message. Run NMMGR and go to the PROFILE for the device. You should be
able to add classes to the device at that point. After making changes in NMMGR,
remember to VALIDATE these changes to NMCONFIG, and then cross-validate using
the RDCC command from SYSGEN's SYSFILE section. NMMGR changes take effect after
the system has been reSTARTed and the power has been cycled on the DTCs. You
should cut a System Load Tape (SLT) making these changes so you'll have them on
tape for your next UPDATE.
If your device was configured through SYSGEN, the device should have its
classes modified through SYSGEN. You're right, you do use the ACLASS command in
the IO section. Changes to the IO section require a START to make them take
effect.
Is there a way to use FTP to move an IMAGE database between two HP
3000s?
FTP by itself won't work, as it doesn't support user-labels, which are
included with the IMAGE root file. DSCOPY, while not being as trendy as FTP,
does know about user labels. Telamon has freeware LZW compressor programs which
know how to archive IMAGE datasets, so you can use FTP without having to change
the file codes to non-priv values beforehand. Just archive the sets into one
non-priv package, FTP it as a binary file, and then use LZW to re-expand the
data-sets back to their original form. Telemon's LZW programs are available on
the Internet at ftp://ftp.telamon.com/dist.
I've got out-of-date files on my system that haven't been accessed or modified
in months. How can I get rid of them without having to purge each file
individually?
The HP 3000's :STORE command lets you specify a fileset that will be stored
and then purged. To store and purge only those files that have not been accessed
on or since June 1, 1993, use these commands: :FILE T;DEV=TAPE :STORE
@.[group].[acct];*T;DATE<=06/01/93;PURGE Only those files that have not been
accessed on or since June 1, 1993, will be stored and purged. (Note the <=
symbol denoting "less than or equal to.") How can I get a segment
moved from a USL file into an XL file?
USLs contain only compatibility mode code, and XLs contain only native-mode
code. You'll need to do one of two things: rewrite the USL routine in a language
for which you have a Native Mode compiler, or write a switch stub, which is a
small piece of native mode code that can call the emulator and run compatibility
mode code. You'll also need to put the code that's in the USL into an SL using
SEGMENTER.
Switch stubs need to be written in Pascal or C, since those are the only
languages on the HP 3000 that support pointers. As long as you have a Pascal
compiler (or have access to one) and know the calling sequence of the routines
that you have in your USL, you can use SWAT -- HP's Switch Assist Tool -- to
write the code for you. SWAT is in PUB.SYS and is a simple VPlus application.
It's documented in the Switch Programming Manual.
If the routine that's in your USL is written in COBOL, it's probably
easiest just to compile the source with a Native Mode compiler. Switch stubs are
a bit harder to write for COBOL programs, and some COBOL subprograms can't be
accessed that way at all.
I'm trying to FTP a file from an IBM mainframe to the HP 3000. The FTP manual
says it automatically converts from EBCDIC to ASCII. But our program burps on
COMP-3 fields. How can we get our files moved?
Those COMP-3 fields are Packed Decimal fields. To convert the records from
EBCDIC to ASCII, you must first store the Packed Decimal fields to an internal
buffer, translate the records to ASCII, and then move the stored numbers back to
the records. The least painful way to do this is with a Transact/XL program
using the CTRANSLATE intrinsic. Of course, this means that the file must be
transferred to and stored on your 3000 in EBCDIC format.
The conversion probably was done, but the problem is that COMP-3 fields are
neither ASCII nor EBCDIC. They're binary fields that aren't supposed to be
translated at all. FTP has no way of knowing where your printable text stops and
the COMP-3 fields start. It converts all of the data, translating the COMP-3
into mush. You've got two choices, but both involve CTRANSLATE: Un-translate
(ASCII-to-EBCDIC) the COMP-3 fields, or FTP in BINARY and only translate
(EBCDIC-to-ASCII) the text fields.
We want to make use of user volume sets on our HP 3000. How do I go
about backing them up?
The best way to do this is to STORE off each volume set and its directory
separately with multiple STORE commands, using the format: :STORE
@.@.@;*T;DIRECTORY;ONVS=[userset]
This only STOREs the files and the directory associated with this volume
set. To backup the entire system at once, including all of the directories, you
need to issue: :STORE @.@.@;*T;DIRECTORY;
ONVS=MPEXL_SYSTEM_VOLUME_SET,[setname1,setname2,....] If you just want all of
your files and are not interested in any directories: STORE @.@.@;*T
The standard format for a full backup without user volume sets (STORE
@.@.@;*T;DIRECTORY) will STORE off all user files, but only the system volume
set's directory.
We have lots of boxes of narrow paper, but are about to run out of our wide
paper. We could use up the narrower paper if we could print condensed characters
on our HP 2562C printer. How can I get it to print condensed (17 pitch)
characters?
There may be a front-panel setting; press "select" and then
"view"
to get the printer to help you. Alternatively, you can define a terminal type
file from your HP 3000 that contains the escape sequence [esc]&k1S. This
sets compressed print. If you make that TT file the default, you can override it
as necessary by using ;ENV=[alternate TT file] on file equations for the
printer.
In the old Classic HP 3000 days, there were a few available utilities that
manipulated a bit or two in the depths of MPE/V in order to bypass tape label
processing. Is there anything to do this under MPE/iX?
A probable adequate workaround might be safer than globally disabling tape
label processing. Assuming you want to write an application that can take any
kind of tape, labelled or not, do this: FOPEN the tape with INOUT access. Mount
the tape in question (without a write ring, unless you plan to write to it), and
reply to the FOPEN request with the LDEV in question.
For labelled tapes, MPE says "Hmm, the tape is labelled, but the user
wants to write ... OK, I'll forget that it is labelled...OK, you got it."
This allows you to then treat the tape as unlabelled, which means that FREAD
will return all those BOT/EOT/HDR label records that are on the
tape.
Some releases of MPE might require an extra reply, confirming that you
don't mind writing over a non-expired labelled tape. That's OK, since (if you
don't have a write ring) you won't be writing to it anyway. For unlabelled
tapes, MPE says "OK, you got it."