HDTenEightyP/NetNews huggingface dataset:
From: karin@zach.fit.edu (Karin Nicholson)
Newsgroups: comp.os.vms
Subject: Re: help needed with directory problem
Date: 27 Aug 92 14:31:42 GMT
Organization: Florida Institute of Technology, Melbourne USA

Errors

  DIRALLOC

    directory allocation failure

       Facility: SYSTEM, VMS System Services

       Explanation: The file system failed to allocate space to increase
       the size of a directory file. Because directory files must be
       contiguous, this error might be caused by the disk being full.
       More likely, there is not enough contiguous space on the disk for
       the directory, so the free disk space is being fragmented.

       User Action: Reorganize the free disk space by copying it with the
       Backup Utility, or restructure your application to use a larger
       number of smaller directories.


-- 

 .-.|     |    |     | |     /------------------\    Karin Nicholson
 |  |-..-.|/.-.|-..-.|*|/   < karin@zach.fit.edu >   Academic Computing Services
 `-'| |`-'|\`-'| |`-'|||\    \------------------/    Florida Tech
Newsgroups: comp.os.vms
From: winalski@adserv.enet.dec.com (Paul S. Winalski)
Subject: Re: Linking problem!!!!!!! HELP!!!!!!!!
Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
Organization: Digital Equipment Corporation, Nashua NH
Date: Thu, 27 Aug 1992 02:05:37 GMT


In article <1992Aug26.191820.23959@mahendo.jpl.nasa.gov>,
robert@triton.jpl.nasa.gov (Robert Angelino) describes a problem where
linking a C program compiled /G_FLOAT gets scads of Linker MULDEF errors
when bringing in VAXCRTLG.EXE.

The problem here is that you're also linking against the DECwindows shareable
images, and these images are linked against VAXCRTL.EXE (the D-float version
of the C RTL).  There is no way to use the G-float version of the C RTL and
DECwindows calls from the same program image.  This restriction will go away
in some future version of DECwindows and of VMS, when everybody is using the
DEC C RTL in place of VAXCRTL (the DEC C RTL doesn't have this G-float/D-float
RTL mixing problem).  Unfortunately, there aren't any real work-arounds for
this problem.  Right now, DECwindows and the G-float C RTL simply don't mix.

If you can, try compiling your code /D_FLOAT.  If that isn't an option, then
you can try packaging your application as two separate images, one of which
is an executable image and one of which is a shareable image.  The key thing
is that one image must contain all the DECwindows calls and be compiled
/D_FLOAT, and the other image must contain all the /G_FLOAT code.  Use
LIB$FIND_IMAGE_SYMBOL to bring the shareable image into your process.

Another alternative is to package things as two executable images, one of
which does G-float and the other of which does DECwindows, and run the
application in multiple processes (as I said, there aren't any good work-
arounds).

--PSW
Newsgroups: comp.os.vms
From: gurman@umbra.gsfc.nasa.gov (Joseph B. Gurman)
Subject: Re: BookReader
Organization: Goddard Space Flight Center
Date: Wed, 2 Sep 1992 22:40:51 GMT

gvrod@isuvax.iastate.edu (R Eldridge, VMS FOREVER) writes:

>In article <gurman.715448263@umbra.gsfc.nasa.gov>, gurman@umbra.gsfc.nasa.gov (Joseph B. Gurman) writes:
>>canellis@MOHAWK.BROOKS.AF.MIL ("Alan J. Canellis") writes:
>>
>>>	This maybe a FAQ, but here it goes.  How do I setup BookReader so I
>>>can read Documentation on non-licensed products?
>>
>>    As one who initially failed to RTFM myself, let me refer you to the
>>"VMS Online Documentation Library / Disc Users's Guide" (AA-ND24N-RE)
>>with the July '92 CD's, p. 9. All you have to do is
>>
>>$ @cd_device_name:[DECW$BOOK]BOOKBROWSER.COM
>>
>>and you should be able to read any docs on the CD's, since you will have
>>licensed BOOKBROWSER. (And who said LMF was hard?)
>>
>interesting; i've just check and my cd's (i.e. CDDOC06JUL21, CDDOC06JUL22,
>CDDOC06JUL23) do not have this procedure on them.

    Right! As Colorado Springs admitted to me, they FORGOT to put
BOOKBROWSER on the July CD's. It's on the May CD's, however. Thanks to
Dan Packman of NCAR for pointing this omission out, as well.
    Sorry if I wasted anybody else's time as well mounting all the July
CD's....
						Joe Gurman
--
J.B. Gurman / Solar Physics Branch / NASA Goddard Space Flight Center /
Greenbelt MD 20771 USA / gurman@umbra.gsfc.nasa.gov
| Federal employees are prohibited from holding opinions under the Hatch Act.|
| Therefore, any opinions expressed herein are somebody else's.              |
Newsgroups: comp.os.vms
From: rbn@ralph.rtpnc.epa.gov (Bob Boyd)
Subject: Re: Invalid Login Information questoin (SAK 92_13)
Organization: UNISYS/Environmental Protection Agency
Date: Fri, 4 Sep 1992 14:34:51 GMT

SK0001@ACAD.DRAKE.EDU writes:
> Hello All.
> 
>    1- MAIL from KIRK to SPOCK and SPOCK to KIRK no longer displays receipt 
>       notification at the terminal.
> 
I'm assuming that your cluster is configured with 1 common sysuaf for the
whole cluster.  If not, then this may not apply.

Check your logical MAIL$SYSTEM_FLAGS/EXEC in the SYSTEM logical name table
You will probably want it to have the value "7"
If it is not defined on any node or has a different value then 
$ DEFINE/SYSTEM/EXECUTIVE_MODE MAIL$SYSTEM_FLAGS 7

>    2- MAIL to SPOCK::USER from KIRK, or KIRK::USER from SPOCK no longer works.
>       It returns the errors:
>       "%MAIL-E-LOGLINK, error creating network link to node KIRK",
>       "-SYSTEM-F-INVLOGIN, login information invalid at remode node".
> 
 This is a sure sign that your logical name is not defined correctly if 
you have a UAF homogeneous cluster.  MAIL should not be using DECnet to
deliver mail to another node in the cluster.  When the MAIL$SYSTEM_FLAGS
logical is defined to indicate that the cluster is homogeneous then it
will use local delivery for any node that is currently in the cluster.

DO 

$ NCP SHOW OBJECT MAIL CHARACTERISTICS  and note what username is displayed.
Then use AUTHORIZE to display the status of that username.  Make sure all
3 nodes are using the same username.
>    3- PHONE from SPOCK to KIRK and KIRK to SPOCK no longer works. Phoning 
>       KIRK::USER from spock results in the "Establishing DECnet link..."  
>       Message, the PHONE utility returns the error "login information invalid 
>       at remode node"

Same suggestion as above -- check the OBJECT PHONE CHARACTERISTICS, and
look at the USERNAME and check in the UAF.  Make sure that it is there,
and is not disabled for network access, or expired or other useless state.
> 
>    4- The DCL command REPLY/USER does not ALWAYS display a message on the
>       user's terminal on KIRK on occasion. I was unable to detect a pattern of
>       success or failure for this oepration.
> 
>    5- SHOW PROCESS/CONTINUOUS and SHOW PROCESS/ACCOUNTING no longer work if the
>       requestor process is on a different CPU than the target process.

You said that all of these systems are clustered together.  Are you really 
sure?

Have you done a SHOW CLUSTER/CONTINUOUS and seen that they all show up
in the display?  It sounds like 1 or more of them are no longer booting 
into the cluster correctly.

--
Bob Boyd                 
rbn@ralph.rtpnc.epa.gov 
Unisys/EPA               

Newsgroups: comp.os.vms
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Subject: Re: ?Cause of error message under $SUBMIT
Reply-To: carl@SOL1.GPS.CALTECH.EDU
Organization: HST Wide Field/Planetary Camera
Date: Tue, 1 Sep 1992 14:39:31 GMT

In article <1992Sep1.102042.1@npe.isnet.inmos.co.uk>, isodonovan@npe.isnet.inmos.co.uk writes:
>Also (sorry if this is going on a bit!) if you submit a file, then change it,
>it will be the OLD version that executes not the new one.  Because the queue
>manager keeps a note of the file id, you cannot fool it into executing the new
>version - you'd have to delete the old job and resubmit, so again, you need to
>keep the old version aroud if you want it to run.

Nonsense.  You can EASILY fool trhe queue manager.  After creating the new
version of the file, COPY/OVERLAY it on top of the old version.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
Newsgroups: comp.os.vms,talk.bizare
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: DECW$LOGIN_BACKGROUND & XV
Followup-To: talk.bizare
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Wed, 26 Aug 1992 22:02:49 GMT

In article <1992Aug25.195432.25644@tin.monsanto.com>, lesnyd@monsanto.com (Larry
E. Snyder) writes:

|>> protecting its rights.  Did you know that the castle is copyrighted?
|>> 
|>How can the castle be copyrighted? It in itself is a copy of the 
|>Neuschwanstein castle in southern Germany. Can the owners of the REAL
|>castle (whoever that is, presumably the German government) sue Disney??
|>Or can Disney sue Germany for having a castle that looks like theirs?
|>How far can this go???

Too far, a Chezloslovakian brewery is currently banned from selling the beer it
has brewed and sold under the name of the town it is made in in many countries.
Some upstart US company called Anhauser-Bushe seems to think that copying the
name and being bigger gives it exlusive rights. The UK is the one place where
you can get both beers under the name Budweiser so you have to ensure that you
specify Budvar or else you will get a fizzy drink.

--

Phill Hallam-Baker
Newsgroups: comp.os.vms
From: gordon@edwin.enet.dec.com (InfoServer Software Engineering)
Subject: Re: READING ISO-9660 CD'S ON AN INFOSERVER
Reply-To: gordon@edwin.enet.dec.com (InfoServer Software Engineering)
Organization: Digital Equipment Corporation, InfoServer Engineering
Date: Tue, 25 Aug 92 17:28:04 GMT


In article <1992Aug18.165842.2840@abel.incstar.com>, lhotka@abel.incstar.com writes:
>
>I (with great excitement) put in the InfoServer 100 1.0 CD and checked, but
>found nothing like that.
>
>There is a [SYSD.SYSEXE] directory and the top level *.SYS files and
>that is all there is.
>
>Would F11CD be on some other CD somewhere?  Such as the CON_DIST?  Thanks!
>
> Rockford Lhotka                                INCSTAR Corp
> Systems Analyst                                1990 Industrial Blvd
> lhotka@incstar.com                             PO Box 285
> 612/779-1701                                   Stillwater, MN 55082
>           >>>Amiga - The computer for the creative mind<<<
>

	There have been three releases of the InfoServer kernel since V1.0
(V1.1, V2.0 and V2.1) and V2.2 is about to go into FT.  If you have software
maintenance for the InfoServer kernel, you should have received these.
(V2.2 FT sites have already been selected.  Please don't bombard me with
mail.)

	F11CD, packaged with the InfoServer kernel V2.1, is a product of the
VMS Engineering group and we were merely a convenient delivery mechanism. 
Its future appearance on CONDIST or not is up to VMS Engineering.

	The InfoServer kernel has been kept off of CONDIST due to licensing
issues involving the bundled client license in V2.0.  We are currently working
to change this, and you should expect to see InfoServer kernel software beginning with a release of CONDIST in the near future.


					--Doug


--
Doug Gordon                             gordon@edwin.enet.dec.com
InfoServer Software Engineering         Anything resembling an opinion
Digital Equipment Corporation              is mine and not DECs.
From: goathunter@wkuvx1.bitnet
Newsgroups: comp.os.vms
Subject: Matt Madison's utilities (was Re: Looking for Newsreader software)
Date: 30 Aug 92 11:44:06 CDT
Organization: Western Kentucky University, Bowling Green, KY

In article <1992Aug29.170329.29824@news.iastate.edu>, gvrod@isuvax.iastate.edu (R Eldridge, VMS FOREVER) writes:
> NEWSRDR		- Available for Anonymous FTP on
> 		vms.ecs.rpi.edu/vms2.ecs.rpi.edu in directory
> 		[ANONYMOUS.NEWSRDR].  It is also available through E-mail
> 		distribution from Fileserv@vms.ecs.rpi.edu (FILESERV@RPIECSVX
> 		for BITNET users) -- send a one-line E-mail message with the
> 		command HELP to that address for more information.  Current
> 		contact is Matt Madison (madison@mdmvs.ecs.rpi.edu).
> 
Actually, all of this has changed.  NEWSRDR is available via anonymous
ftp from ftp.spc.edu ([192.107.46.27]) in [.MADISON.NEWSRDR].  It's
available via e-mail by sending the following commands in the body
a of mail message to FILESERV@WKUVX1.BITNET:

SEND NEWSRDR
SEND FILESERV_TOOLS
SEND NEWSRDR_SRC			!To get the sources

Matt's address is now madison@TGV.COM.

All of Matt's programs are available from ftp.spc.edu in [.MADISON]
and via e-mail from FILESERV@WKUVX1.BITNET.  Send the command DIR ALL
in the body of a mail message to FILESERV@WKUVX1.BITNET for a brief
listing of all the packages available from here.

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET, 502-745-5251
From: flowers@memstvx1.memst.edu (Harry Flowers)
Newsgroups: comp.os.vms
Subject: Re: Memory listing
Date: 2 Sep 92 16:29:25 GMT
Organization: Memphis State University

In article <01GOA2PTRDHE0001BH@VAXF.COLORADO.EDU>, DWING@UH01.Colorado.EDU
 (Dan Wing) writes:
> Raj Jathar, rdj@bass.bu.edu, wrote:
> 
>>When I did a show memory this is the listing I obtained :-
>>
>>
>>              System Memory Resources on 28-AUG-1992 18:44:40.69
>>
>>Physical Memory Usage (pages):     Total        Free      In Use    Modified
>>  Main Memory (32.00Mb)            65536       36315       28616         605
>>
>>  Bad Pages                        Total     Dynamic  I/O Errors      Static
>>                                   16384           0        8192        8192
>    ^^^^^^^^^
> You should NEVER see this.  You have some bad memory.  Call your HW support,
> and don't use this system until the bad memory is replaced (that includes
> you performing system management).
> 
> [...]
> 
>>Paging File Usage (pages):                      Free  Reservable       Total
>>  DISK$VAXVMSRL054:[SYS0.SYSEXE]SWAPFILE.SYS
>>                                                6296        6296        6296
>>  DISK$VAXVMSRL054:[SYS0.SYSEXE]PAGEFILE.SYS
>>                                               17613      -12611       30000
>>
>>Of the physical pages in use, 4294964587 pages are permanently allocated to VMS.
>                                ^^^^^^^^^^
> this number can't be larger than your total memory!! (which is 65536 pages 
> according to the top of your SHOW MEMORY display).

This probably indicates that the bad memory was in the first bank.  Physical
page zero is used to store configuration information that SHOW MEMORY uses.

>>While most of the stuff is either self-explanatory or intuitively
>>clear, I'm not quite sure what to make of the negative value.  Is that
>>simply because of a subtracted offset, or is it the complement or a
>>simlarly trivial addressing question?
> 
> Each user is allowed to use up to PGFLQUOTA (a SYSUAF value) pages of the
> page file.  (Processes have a similar limit).  When a process is created,
> the system deducts the PGFLQUOTA value from the "reserved" value in the
> page file.  The "reserved" value isn't significant, and should be ignored --
> it just means "if all proceses used up ALL the virtual memory they are 
> allowed, your page file would be 12611 pages too small."

Actually, it's not PGFLQUOTA, but RSRVPAGCNT (a Special SYSGEN parameter)
that's subtracted.  As Dan says, ignore it.  It's main purpose is balancing
page file allocations between multiple page files.

> You should, instead, compare the "free" value, when the system is heavily
> loaded, with the "total" value.  You should have at least 50% of the page 
> file free.

True.  There are a few pathological cases where the page file may need to
be bigger because of fragmentation, but this works for 99.9% of the cases.
On swap files, you can use up to 75%.
--
Harry Flowers                           Internet: FLOWERS@MEMSTVX1.MEMST.EDU
Memphis State University                & Bitnet: FLOWERS@MEMSTVX1
Newsgroups: comp.os.vms
From: kish@iasdvc.honeywell.com ()
Subject: Re: PAKGEN software (Was: will lmf will alpha?)
Reply-To: kish@iasdvc.honeywell.com ()
Organization: HONEYWELL_IAC
Date: Wed, 26 Aug 1992 17:12:56 GMT


Our experience with LMF is similar to Ken's. Our best customer quote:    
   "You mean we have to license it for each computer?"
           From a large multinational company who had been copying
           our software without the formality of paying for it..:)


                          Karl Kish
                           Honeywell IAC
                               KISH@IASDV1.IASD.HONEYWELL.COM
From: fairfield@slacvx.slac.stanford.edu
Newsgroups: comp.os.vms
Subject: Re: Editing large files with TPU
Date: 27 Aug 92 18:49:12 GMT
Organization: Stanford Linear Accelerator Center

In article <1992Aug27.115111.23317@dcatlas.dot.gov>, sethg@dcatlas.dot.gov (Seth Grimes) writes:
> 
> Wasn't the record-length limitation to 960 characters lifted (for all
> practical purposes -- new limit is large) as of VMS version 5.5?

    I don't _think_ so...there was nothing in the V5.5, nor the V5.5-1,
release notes that refers to lifting this restriction...
-- 
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slacvx.Slac.Stanford.Edu
 SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
 ----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
Newsgroups: comp.os.vms
From: HEGE@finabo.abo.fi (Kaj H{ggman DC)
Subject: Exabyte/HSC problems
Organization: Abo Akademi University, Finland
Date: Fri, 4 Sep 1992 05:15:51 GMT
X-News-Reader: VMS NEWS 1.23

Hello!

Seems like our Exabyte 8500C-2 (from System Industries) connected to our HSC50
(V4.1) doesn't like to co-operate with VMS5.5-1, since the backups worked
OK under VMS5.5. At least this is the only thing that comes up to my mind.

This happens after just a short while (a few files are backed up):

%BACKUP-E-FATALERR, fatal error on $1$MUA3:.....
-SYSTEM-W-DATAOVERUN, data overrun
%BACKUP-I-OPERSPEC
%BACKUP-I-OPERASSIST, operator assistance has been requested
%BACKUP-I-OPREPLY, operator reply is "QUIT"
%BACKUP-F-ABORT, operator requested abort on fatal error

Has anyone else experienced this?
I'd apprecviate any ideas or comments.

Kaj Haggman             Internet: Hege@abo.fi       Bitnet: Hege@finabo
Abo Akademi University  (Hepnet/span) Decnet/funet: (21905::)abovax::hege 
Computing Center        X.400: s=hege o=abo prmd=inet admd=fumail c=fi  
SF-20500 Abo, FINLAND   Phone : +358-21-654467  Telefax : +358-21-654497
From: allebrandi@inland.com (Tom Allebrandi)
Newsgroups: comp.os.vms
Subject: Re: CDROM players for VMS _and_ DOS
Date: 3 Sep 92 13:02:55 CST
Organization: Inland Steel Company; East Chicago, IN

In article <1992Sep1.122608.714@ae.chalmers.se>, hogstedt@ae.chalmers.se (Per Hogstedt) writes:
> We would like to be able to read VAX/VMS CDs
> as well as CDs aimed at the PC market in the same unit.
> 
> Questions for you CD wizards:
> 
> - As far as I can understand we are dealing with (at least) two different
>   "standards" in terms of how the CD is read. Are they incompatible or can
>   I use the same reader for any standard as long as the physical format is OK?

DOS machines tend to use High Sierra format which I believe was the
predecessor of ISO 9660 format. VMS machines tend to use ODS-2, that
is, native VMS file format.

If you are running VMS 5.5 or later, there is supposed to be a package
from Digital that will let you read High Sierra and ISO 9660 CDROMs on
a VMS system. This package provides interim functionality until Digital
releases native support for all three formats, reportedly in VMS 6.0.

For those with InfoServers, the F11CD055 package on the InfoServer 2.1
software CDROM will let you read High Sierra and ISO 9660 format. I
don't know if that package requires the InfoServer client support, or,
if it is the same package that I mentioned in the previous paragraph.

If you are running prior to VMS 5.5, you may still be able to get VFS
from Digital. This only reads ISO 9660 CDROMs and will not work on 5.5
or later.


> - If I buy one or two RRD42, connect them to one of our VAXen
>   can I then mount a "DOS formatted" CD in this drive and connect to
>   it and use it as a file service from PathWorks?

As luck would have it, I did this just last night. I have an InfoServer
150 at software version 2.1, and have installed the InfoServer 2.1
client and F11CD055 packages on my VMS 5.5-1 system. (In other words, your
milage may vary :-) This is what I did:

[InfoServer] 
Placed a High Sierra format CDROM in the InfoServer in the drive whose
service name is REVMSCD. This happened to be the Microsoft Programmers
Library CDROM whose label is PROGLIB_1A

[VMS]
$mcr ess$ladcp bind revmscd/system
$cd_mount/media=cdrom dad$revmscd proglib_1a/system/undefined_fat=(stream_lf:0)

[DOS w/PathWorks]
use y: \\vax\dad$revmscd:[000000]%myname mypassword

I then told the Microsoft Librarian that its files were on Y:. It
worked just fine.

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | NFS grunt   - CMU/Tek-IP
East Chicago, IN           | Chairperson - VMSnet Working Group, DECUS VAX SIG
219 399 6306               | Internet:  allebrandi@inland.com
DECUServe: allebrandi      | UUCP:      ...!uunet!inland!allebrandi
Xref: sparky comp.os.vms:14262 comp.compression:3119
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: comp.os.vms,comp.compression
Subject: Re: Need Info and Advice re VMS DCX Routines
Date: 28 Aug 92 15:27:35 GMT
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH


In article <1992Aug26.132902.1@lib.haifa.ac.il>, jody@lib.haifa.ac.il 
(Yosef Branse) writes:
|>
|>While skimming the VMS System Routines manual for something else, I found
|>a chapter entitled "Data Compression/Expansion (DCX) Routines." The
|>introductory note states "There is no DCL-level interface to this facility nor
|>is there a DCX utility."
|>
|>With a good bit of time and effort, I suppose I could learn how to use these
|>routines to write my own compression/decompression programs. But since I have
|>no prior experience, I'd like to pose a few questions first:
|>
|>1) Is it correct to assume that since the DCX routines are part of VMS, they
|>will be "better" (however that may be defined - faster, more reliable, etc.)
|>than other available compression packages for processing files in our system (a
|>VAX 6320 running VMS 5.4-3, soon to upgrade to 5.5)?

No, I don't think you can assume that.  The DCX routines use a straightforward
version of Huffman encoding; there are more sophisticated implementations
available elsewhere.  However, the DCX facility is included with VMS so you
know it will be around on any VMS system.  The reason for its existence is
to reduce space on VMS media kits for large libraries such as STARLET.OLB
and the various help libraries.  (The command procedure SYS$UPDATE:LIBDECOMP.COM
is used to uncompress any or all of the compressed libraries.)

But the statement in the manual is incorrect, as there IS a DCL-level
interface.  It is LIBRARY/DATA=(REDUCE|EXPAND).  It is not difficult to use
text libraries for storing compressed files, and I have done this a number
of times.  If file attributes are important (you get variable-length
records when you extract), store an FDL file as another module and do
a CONVERT/FDL when you extract it.  See the Librarian manual for more details.

--

Steve Lionel                    lionel@quark.enet.dec.com
Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062