Is the format of the archive used by vmarc documented anywhere?
I don't know. It probably is. I've never found any need to delve into
the format any more than knowing that it is in 80 column card image format
which can readily be sent through a punch / card reader combination or over
an NJE link and each file starts with a header like this (in EBCDIC):
:CFF FNAME FTYPE FM
and that VMARC doesn't mind if there is garbage in the archive file (such as
USERID or :READ for example) before the first valid file header. The actual
file contents could be compressed with LZW compression and I never found any
compelling reason to know how that works.
if one
were to use the pack function to put a number of CMS files into an archive
file and then transfer this to another system, for example by IND$FILE, are
there likely to be utilities to unpack the archive? Likewise can one pack
files into an archive on another system and unpack onto CMS with vmarc?
This is exactly what VMARC was designed for. VMARC is available as S/370
assembler source which can be built on anything from VM/370 CMS to z/VM CMS.
I've done a mod which enables a limited VMARC version to be built on MUSIC.
I wouldn't be surprised if someone else tweaked it to make it buildable on
MVS and other mainframe operating systems.
If you have a Sixpack system up and running, log in to some CMS userid and
type VMARC370 and you should get brief usage details.
VMA is available as C source which can be compiled on any reasonable system
with a functioning C compiler. I have compiled it on my OpenVMS system, I
think most others use it on Windows or Linux. The purpose of VMA is to
read write and list VMARC format archive files on systems other than VM/CMS.
The previous discussion may have been the one I started - I was able to get
IND$FILE working and also send files to the real punch but I think the
current question is more about being able to transfer a number of files at
a time,
I think VMARC is ideal for this purpose but we seem to keep heading off in
the direction of emulated tapes or newly invented archive formats both of
which I think are not so ideal.
Regards,
Peter Coghlan.
