Re: FTP PUT RECFM=FBM files
Paul Gilmartin
>I don't consider this a bug at all... FTP's job is to transfer the file,
>warts and all.
>
Yup.
>I was just hoping that when IBM taught it to handle //DD: , they might have
>added an option to not transmit the CC character when the file is
>RECFM=..A|M
>
Actually, I have the opposite sentiment. If I give FTP a
//DD: when I have overridden the attributes in the allocation,
I'd expect FTP to do QSAM reads and transfer whatever results
from my overrides.
Rather, it seems to be a busybody and snoop at labels,
JFCBs, TIOTs, etc., and overrule my overrides. Ugh.
>It's not a HUGE deal for me, I was just hoping to writ ethe file once
>instead of having a secondary process on Linux ... Though I may do it on MVS
>before the send... IEBGENER FBM to FB... I *think* that will strip the CCs
>for me...
>
I doubt it. IEBGENER's job is to copy the file, warts and all.
But you might try the control capabilities of IEBGENER SYSIN
and see what that does.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Hunkeler Peter , KIUP 4
importance to programs preparing the data to be printed, i.e.
JES2/3 or PSF/Infoprint. JES2/3 needs this information to build
the channel programm to drive the printer. PSF/Infoprint needs
this information to format the data according to the page format.
Apart from these, most programs probably don't care whether the
dataset is FB, FBM or FBA and treat all of them as FB. Same applies
to VB, VBM and VBA.
For example, to cut off the first byte, you need to tell IEBGENER
you want it to do so. Assume input is FBM123 and output is FB122,
then use:
//SYSIN DD *
GENERATE MAXFLDS=1
RECORD FIELD=(122,2,,1)
/*
--
Peter Hunkeler
CREDIT SUISSE AG
Chris Mason
Very much due to John McKown, ways of dealing with the perceived problem
have been suggested.
Following up on the subsequent posts, although I am sure many contributors
and observers are aware of what the "M" - or "A" - in the RECFM parameter is
all about, I see that it has not been spelled out precisely in such a way that
any possible misunderstandings are dispelled. Peter Hunkeler came the closest
and also - perhaps as prompted by Paul Gilmartin - provided sample IEBGENER
control statements which make clear that, when using the IEBGENER utility,
merely having an input file with RECFM=FBM or RECFM=FBA - or any of the
other combinations ending in "M" or "A" - with an output file which does not
have the supposedly offending "M" or "A" present in the RECFM parameter will
*not* cause the character to be removed. It will, in fact, merely hide from
any person or programming, who/which might care to know, that there is a
carriage control character present - in the opinion of whoever or whatever
created the RECFM information. It is sufficient to note that it is necessary to
copy the record length unchanged from the input file to the output file.[1]
Going even a little bit further than Peter - the FTP ASATRANS option[2] apart -
I would say that the *only* significance of the "M" or the "A" at the end of
the RECFM parameter characters is for when the file is in the process of being
printed. The software responsible for the printing operation actually pays
attention to whether the first character represents a "machine" control
character, "M", or an "American Standards Association" (ASA) character, "A".
If it is "M", in the days when everybody used the IBM printers of the '60s
and '70s, the software did the software equivalent of a whoop and a holler
and simply placed the character at the beginning of the channel command
word (CCW) which passed the print line text - if any - to the printer. The M
character was grist to the 1403 N1's mill!
On the other hand, the software would become somewhat irritated by having
to deal with the ASA character since the "standard" operated in precise
opposition to the way those old IBM printers liked to operate - at least as
indicated by the CCW codes and, given the technology of the time recalling
that any machine with a model number starting with 14 dated from at the
latest the early '60s, almost certainly the printer logic itself. Thus the simplest
option for the software driving a printer under the instruction of the ASA
control code for carriage movement would set up two CCWs, one a translation
of the carriage movement and one to print the text line without carriage
movement - or vice versa, I forget now which way round it goes. Naturally
cleverer software would combine the print line from record N with the carriage
movement implied by record N+1 or N-1 whichever way round it is - with
special considerations for the first and last records as necessary.
Thus "A" used to be very fiddly compared with "M".
I promised to remove all possibilities for misunderstanding so let me make one
more point: the RECFM characters have quite different "weights". As we saw
the "M" and the "A" apply only when the file is to be printed. On the other
hand the "F" and the "V" - and the "U" - the former two with or without "B" are
of great significance for each time the file is read or written - with QSAM.
Chris Mason
[1] I guess the record length could be changed - I've never tried it -
knowingly! - but I expect that any truncation would happen at the *end* of
the record.
[2] Something about which I have learned in this thread - but I'm a bit puzzled
over what actually it might be doing.
On Mon, 23 Nov 2009 10:37:01 -0800, Donald Russell
<russe...@GMAIL.COM> wrote:
>A batch process creates a sequential dataset with RECFM=FBM.... I transfer
>that to a zLinux system using FTPS in ASCII mode
>
>Is there an FTP option to specify that says "don't send the carriage
>control" character?
>Either in the PARM= or through the SYSFTPD DD statement?
>
>I haven't seen such a thing mentioned in any of the manuals but thought I'd
>check here before deciding what my work-around solution will be. :-)
>
>Thanks for any suggestion, or confirming there is no such option.
>
>Cheers