FTP -- VM, MVS, VMS Questions
John C. Frickson
are a couple of points I need clarified.
For VM, a typical directory line looks like this:
APPCDEMO ASSEMBLE F 80 1320 26 4/17/92 19:25:07 -
1) I know that 80 is the logical record length. I think the 1320 is the
number of records and the 26 is the number of tracks. Is that correct?
2) Is there any way to calculate the filesize from this information? When
I download this file (IMAGE transfer) it ends up being 64,880 bytes.
MVS directory lines look like this:
Volume Unit Referred Ext Used Recfm Lrecl BlkSz Dsorg Dsname
OVH025 3380 12/29/95 1 60 FB 80 23200 PO MICSFILE.CLIST
USS018 3380 12/18/95 1 15 VB 259 8000 PS NFS.DOC
Migrated OAQPS.INTERIM.CNTYIM.V1.DATA.D052093
AIR030 3380 12/13/95 1 18 FB 80 3600 PS OAQPS.INTERIM.PLNTNAME.DATA
1) Ext is number of extents?
2) Used is number of tracks?
3) Is the volume name important or can I ignore it?
4) Is there any way to calculate filesizes? I think I would have to know
the capacity of the device (i.e. BlkSz * Blks/Trk * Trks)
5) Dsorg -- PO seems to equate to partioned data set. Is that always true?
Are any values other than PO and PS possible?
6) What is "Migrated"? Moved to tape? Is the file still available for
download, or should I simply ignore these lines?
7) After loggin in, the server reports the current directory as "PA2",
but in response to a "PWD" command, it says "PUBLIC.". ???
8) Is the "CD" command useful for anything other than getting into
partitioned data sets?
9) After CD'ing into a PDS, a directory looks like this:
Name VV.MM Created Changed Size Init Mod Id
$README 01.10 89/04/19 94/12/15 18:55 90 1 0 EWZ
What are the Size, Init, Mod and ID fields?
Is VV.MM version information?
VMS directories look like this:
NWLINK.386;1 66 7-AUG-1995 14:32 [ANONYMOUS] (RWED,RWED,,RE)
I have VMS stuff working pretty well, but I do have two questions.
1) What is the ";1" after the filename, and is it important?
2) The filesize (66 in this case) seems to be the number of 512-byte
blocks. Is this always true?
If anyone can answer these questions, I would *really* appreciate it.
I'm working long hours on this, so email would be best, though I will
try to remember to check the newsgroup, too ;-)
If you'ld like to know a little more about my program, you can read
a (not very polished) description at http://www.gibbon.com/projects.shtml
and see screen shots at http://www.gibbon.com/prodpics/
Thanks.
--
John C. Frickson | http://www.gibbon.com/ | * OS/2 * Linux *
Gibbon Computer Products | ftp://ftp.gibbon.com | PGP Fingerprint:
9864 Palm St. NW | Phone: +1 612 754 6557 | FD743D4E209DFC26
Coon Rapids, MN 55433 | VISA/MasterCard/AmEx | 371905C7B52B36E9
a...@epsilon.com
let's just say my mis-spent youth involved LOTS of IBM's.
In <4e7k0p$t...@blackice.winternet.com>, fric...@gibbon.com (John C. Frickson) writes:
>For VM, a typical directory line looks like this:
>
>APPCDEMO ASSEMBLE F 80 1320 26 4/17/92 19:25:07 -
>
>1) I know that 80 is the logical record length3914833920. I think the
1320 is the
> number of records and the 26 is the number of tracks. Is that correct?
No, 26 is the number of blocks. Block sizes can be 800, 512, 1024,
2048, or 4096, per the whim of the user. IBM loves 4096, but it wastes
space (just like on FAT partitions on DOS.)
>2) Is there any way to calculate the filesize from this information? When
> I download this file (IMAGE transfer) it ends up being 64,880 bytes.
For F files (any type which begins with F), record count times logical
record length.
For V files, you need to read the file for an exact count, or the block
size (times block count) for a good guess. In other words, you're up
the creek because you don't KNOW the block size. Use record size times
record length for a _maximum_ file size.
>MVS directory lines look like this:
>
>Volume Unit Referred Ext Used Recfm Lrecl BlkSz Dsorg Dsname
>OVH025 3380 12/29/95 1 60 FB 80 23200 PO MICSFILE.CLIST
>USS018 3380 12/18/95 1 15 VB 259 8000 PS NFS.DOC
>Migrated OAQPS.INTERIM.CNTYIM.V1.DATA.D052093
>AIR030 3380 12/13/95 1 18 FB 80 3600 PS OAQPS.INTERIM.PLNTNAME.DATA
>
>1) Ext is number of extents?
Yes.
>2) Used is number of tracks?
Yes.
>3) Is the volume name important or can I ignore it?
No more important than on a PC.
>4) Is there any way to calculate filesizes? I think I would have to know
> the capacity of the device (i.e. BlkSz * Blks/Trk * Trks)
Correct. You REALLY want the MVS DEVINFO macro, which looks at the
device on the fly. But FTP servers don't do it for you.
Let me clue you in ... they pay me lots around here to transfer MVS
files, and even with access to MVS (I use a custom server), I don't try
to determine the file size up front.
>5) Dsorg -- PO seems to equate to partioned data set. Is that always true?
> Are any values other than PO and PS possible?
Yup. VSAM, BDAM, ISAM, undefined ...you can also read the spool (line
printer queue!) with the proper magic. See "IBM TCP/IP for MVS User's
Guide Version 3, Release 1", SC31-7136 for details on latter. You can'd
process much but PO/PS or the printer queue, so don't sweat it.
>6) What is "Migrated"? Moved to tape? Is the file still available for
> download, or should I simply ignore these lines?
Migrated is moved to disk or tape archive, yes. No don't ignore them,
while the data is not immediately accessible, automatic recall of the
data is possible depending on the configuration.
>7) After loggin in, the server reports the current directory as "PA2",
> but in response to a "PWD" command, it says "PUBLIC.". ???
Curious. To do a absolute CD, use single quotes (') around the name.
>8) Is the "CD" command useful for anything other than getting into
> partitioned data sets?
Yes, any dataset level can be moved down into, much like directories.
>9) After CD'ing into a PDS, a directory looks like this:
> Name VV.MM Created Changed Size Init Mod Id
> $README 01.10 89/04/19 94/12/15 18:55 90 1 0 EWZ
> What are the Size, Init, Mod and ID fields?
Current record count, initial record count, and modified lines. (Latter
I am unsure of).
> Is VV.MM version information?
Yes. MM auto-updates from PDF editor, VV must be updated by hand.
>VMS directories look like this:
>
>NWLINK.386;1 66 7-AUG-1995 14:32 [ANONYMOUS] (RWED,RWED,,RE)
>
>I have VMS stuff working pretty well, but I do have two questions.
>1) What is the ";1" after the filename, and is it important?
Jeez, someone who uses VMS less than I do, but here goes ...
Version number. Yes, because, you can multiple versions in the
directory at the same time.
>2) The filesize (66 in this case) seems to be the number of 512-byte
> blocks. Is this always true?
Beats the hell of me, my last VMS account died in 1992; it was a mercy
killing.
>If anyone can answer these questions, I would *really* appreciate it.
>I'm working long hours on this, so email would be best, though I will
>try to remember to check the newsgroup, too ;-)
>
>If you'ld like to know a little more about my program, you can read
>a (not very polished) description at http://www.gibbon.com/projects.shtml
>and see screen shots at http://www.gibbon.com/prodpics/
>
>Thanks.
>
>--
> John C. Frickson | http://www.gibbon.com/ | * OS/2 * Linux *
>Gibbon Computer Products | ftp://ftp.gibbon.com | PGP Fingerprint:
> 9864 Palm St. NW | Phone: +1 612 754 6557 | FD743D4E209DFC26
> Coon Rapids, MN 55433 | VISA/MasterCard/AmEx | 371905C7B52B36E9
If you're gonna ask for email, put the address in your .sig file.
Gary Hughes
>VMS directories look like this:
>
>NWLINK.386;1 66 7-AUG-1995 14:32 [ANONYMOUS] (RWED,RWED,,RE)
>
>I have VMS stuff working pretty well, but I do have two questions.
>1) What is the ";1" after the filename, and is it important?
as a new file with the version number bumped. No version number (or version
number of zero) gets the highest existing version. Retaining the version
numbers is not critical, but will be appreciated by VMS folks.
>2) The filesize (66 in this case) seems to be the number of 512-byte
> blocks. Is this always true?
>
Yes. You can also ask the file system for the number of 512 blocks actually
allocated, e.g. 66/68 is the cluster size is 4 blocks.
gary (ex VMS developer)
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Gary Hughes ghu...@tardis.com
Stargate Video Systems Multimedia and Network Consulting
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/