Problem
When STOR targets a data set that does not exist, ftpd allocates it
(src/ftpd#mvs.c:1700-1746). RECFM/LRECL/BLKSIZE come from the configuration —
the space quantities do not:
src/ftpd#ses.c:52-54 sets primary = 10, secondary = 5,
spacetype = "TRK" on every session, hardcoded.src/ftpd#cfg.c:221-236 accepts DEFRECFM, DEFLRECL, DEFBLKSIZE,
DEFUNIT, DEFVOLUME from DD:FTPDPRM — there is no DEFPRIMARY,
DEFSECONDARY or space-unit key.src/ftpd#mvs.c:1710-1713 carries fallbacks
sess->alloc.primary > 0 ? … : 100 and sess->alloc.secondary > 0 ? … : 50
that are dead code: ftpd_session_new() always sets 10/5, so the : 100 and
: 50 arms can never be reached.
Two consequences:
- The upload ceiling is fixed at 85 tracks. 10 tracks primary plus 15
secondary extents of 5 tracks; at FB/80/3120 that is roughly 4 MB. A larger
STOR gets an x37 and there is no way to configure around it. The only
override is an interactive SITE PRIMARY= / SECONDARY= / TRACKS|CYLINDERS
(src/ftpd#sit.c:110-131), which scripted clients rarely send.
- The dead fallbacks advertise a configurability that does not exist, which
is misleading when reading the allocation path.
Suggested change
- Add
DEFPRIMARY, DEFSECONDARY and a space-unit key (TRK|CYL) to FTPDPRM
and copy them in ftpd_session_new() alongside the other defaults.
- Then either delete the dead
? : fallbacks in the STOR path or make them the
documented default of the new keys — but not both as they are now.
Note
Not a regression, and not fixable by measuring the transfer: FTP gives no size
at STOR time and ftpd implements no ALLO command, so the allocation cannot be
derived from the file. The ask is only to make the constants configurable.
Related: mvslovers/mvsmf#65 — the same auto-create was removed from mvsMF
because z/OSMF has a separate allocation request; the comment at
src/ftpd#mvs.c:1702 still points at that removed code
("the proven mvsMF DSAPI pattern (dsapi.c line 1794)") and should be corrected
while in the area.
Problem
When STOR targets a data set that does not exist, ftpd allocates it
(
src/ftpd#mvs.c:1700-1746). RECFM/LRECL/BLKSIZE come from the configuration —the space quantities do not:
src/ftpd#ses.c:52-54setsprimary = 10,secondary = 5,spacetype = "TRK"on every session, hardcoded.src/ftpd#cfg.c:221-236acceptsDEFRECFM,DEFLRECL,DEFBLKSIZE,DEFUNIT,DEFVOLUMEfromDD:FTPDPRM— there is noDEFPRIMARY,DEFSECONDARYor space-unit key.src/ftpd#mvs.c:1710-1713carries fallbackssess->alloc.primary > 0 ? … : 100andsess->alloc.secondary > 0 ? … : 50that are dead code:
ftpd_session_new()always sets 10/5, so the: 100and: 50arms can never be reached.Two consequences:
secondary extents of 5 tracks; at FB/80/3120 that is roughly 4 MB. A larger
STOR gets an x37 and there is no way to configure around it. The only
override is an interactive
SITE PRIMARY= / SECONDARY= / TRACKS|CYLINDERS(
src/ftpd#sit.c:110-131), which scripted clients rarely send.is misleading when reading the allocation path.
Suggested change
DEFPRIMARY,DEFSECONDARYand a space-unit key (TRK|CYL) toFTPDPRMand copy them in
ftpd_session_new()alongside the other defaults.? :fallbacks in the STOR path or make them thedocumented default of the new keys — but not both as they are now.
Note
Not a regression, and not fixable by measuring the transfer: FTP gives no size
at STOR time and ftpd implements no
ALLOcommand, so the allocation cannot bederived from the file. The ask is only to make the constants configurable.
Related: mvslovers/mvsmf#65 — the same auto-create was removed from mvsMF
because z/OSMF has a separate allocation request; the comment at
src/ftpd#mvs.c:1702still points at that removed code("the proven mvsMF DSAPI pattern (dsapi.c line 1794)") and should be corrected
while in the area.