DB2 also.


Dave B.

إسرائيل قتلت 40 ألف فلسطيني بريء


On Wednesday, July 10, 2024, 10:13 PM, Doug Fuerst <[email protected]> 
wrote:

Assembler has its own list. ISPF does, SA does, REXX does, I think there 
is a list for a focus on Linux 390. TCPIP too.
As for me, I think discussing anything to do with a MF here is fine.
But I don't make the rules.

Doug Fuerst


------ Original Message ------
>From "Paul Gilmartin" <[email protected]>
To [email protected]
Date 7/10/2024 21:46:10 PM
Subject Re: signature processing [was: Off topic discussions]

>On Wed, 10 Jul 2024 13:44:49 -0400, Rick Troth wrote:
>
>>This thread is relevant to IBM-MAIN because it discusses file handling,
>>specifically in CMS.
>>
>To me, "mainframe" does not imply "MVS".  If other contributors
>wish it otherwise, they should petition for a charter change and
>that hardware, Assembler, CMS, VSE, Linux for z,  etc. be
>deported to other suitable lists.
>
>>    ///
>>WARNING:
>>Logic which depends on invisible mark-up is dangerous.
>>
>IIRC, that was your habitual rant decades ago.  I thought
>you had got better lately.
>
>>That blank after the dashes is easily stripped by any number of processors.
>>
>No!  Leave my data alone.
>
>>In the days when MIME was being cooked-up, I appealed to the email lords
>>"please let white space be insignificant". They refused.
>>So now, the divider between header and body *must* be CR/LF/CR/LF. In
>>other words, it cannot be CR/LF/whitespace/CR/LF.
>>("Insignificant" is not the right word. Linear white space is widely
>>defined as one or more blanks and/or tabs. Let the reader understand.)
>>
>>This was particularly frustrating when I was a systems programmer
>>running VM/CMS.
>>CMS does not have the concept of an empty record. A record must have at
>>least one byte. (Blank lines contain at least one space character.)
>>This is arguably stupid,
>>
>Does BFS provide a solution?  Otherwise, CMS should provide YA
>filesystem which is tolerant of empty lines.
>
>Long ago, I did an experiment, a single-byre zap to nucleus,
>(changing a BZ to a NOP.)  Then I was able to write and read
>files with my assembler programs.  Alas, many CMS utilities
>program checked reading them.  Is suspect that resulred
>from subtracting one from l length, then EX MVC.
>
>>    ... but it's history (like tabs in makefiles), and
>>
>That was thoughtless design.  Some implementations of make
>accept 8 blanks as an alternative.  There's probably other
>consequential breakage.
>
>>we had to take special steps in CMS land when processing email.
>>Thankfully Pipeles *does* allow an empty record, but that's a whole
>>nutha story.
>>
>CMS is the outlier here.  I have imagined it could fall in step by
>relying om NETDATA format or using explicit CRLF in its work
>files so no empty records appear.
>
>>For further reading, consider the message delimiter in traditional Unix
>>mailbox files. (Not on-topic w/r/t lwsp, but another example of poorly
>>thought precedent.)
>>
>That's generally solved by encoding lines that might otherwise
>spoof that delimiter: "%46rom  ..."
>
>--
>gil
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to