Postel's Law has caused a lot of problems. I also have issues with Hanlon's Razor.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List on behalf of Rick Troth Sent: Friday, March 28, 2025 11:05 AM To: [email protected] Subject: Re: Expand DSN names (WAS : Java saved IBM Z?!) External Message: Use Caution EXCELLENT observation Postel's Law should be followed https://en.wikipedia.org/wiki/Robustness_principle Consumer systems REGULARLY have blanks in filenames, which makes scripted automation difficult. Other punctuation can also be troublesome. -- R; <>< On 3/27/25 10:52 PM, Joel Ewing wrote: > Saying that any 8-bit combination is "supported" in file names and > paths by Unix is misleading. It would be very bad form to use a > character code that is not associated with a standard displayable > glyph, even if the creation of such a file were allowed, because > reliably working with a file with "invisible" characters in the name > after creation would be impractical. Special characters like > single-quote, double-quote, asterisk, question-mark, etc. may be > allowed, but are inadvisable because of their special semantic > significance when referring to files in commands and standard > utilities causes problems, Any broadning of file name rules in z/OS > would most likely need restrictions based on usage context as well. > > What is allowed and sometimes useful in current versions of Linux and > Windows is almost any other arbitrary standard Unicode glyph in file > and path names, represented in UTF-8. I would assume that multi-byte > characters count as that many bytes against the 255-byte limit. You > can use characters in non-Latin alphabets and even use special > symbols, such as in the file path > *~/gov_SNAFU/👊🇺🇸🔥.txt , *provided all the utilities you plan to > use with the file support fonts that provide the appropriate glyphs > and the system allows you to represent Unicode characters -- in this > case u+270A (✊), u+1F1FA u+1F1F8 (🇺🇸), and u+1F525 (🔥) -- by some > means that isn't too tedious. Linux provides Unicode text entry > support globally at the Operating System level. Windows > unfortunately requires that support to be provided by individual > applications, and not all provide it. > > JC Ewing > > On 3/27/25 6:17 PM, Thomas Berg wrote: >> Googled to a wikipedia page: >> >> https://en.wikipedia.org/wiki/Filename >> >> Interesting, there seems to be a common (?) Unix standard of 255 for the >> file name. And any 8-bit combination except / and null. Very simple and >> straight forward. >> Other systems seems to like to complicate things. >> But no mention of path lengths. Implementation specific? >> >> Speculating: maybe in z/OS use 44 (?) chars for a "key" to the >> file/dataset >> in z/OS, that is any 8-bit (352-bit) combination, with e g using >> x'FF' in >> the first byte to differentiate from "normal" dataset names. And a >> separate "directory"/mechanism to translate from/to the key with the >> readable name used by the users. >> This way only storage space would limit the length of the names (in >> practice). >> E g text written here by me could be used as a file name/datasetname. >> (Not >> that you neccessarly would want to do that in normal applications.) >> >> In practice we would want to work with much more limited name lengths >> as it >> would be more managable by the brain, but I could se lenghts of >> around 130 >> to be useful sometimes (with modern screen space in 3270). >> >> >> Thomas Berg >> >> >> >> Mundus Vult Decipi >> >> Den tors 27 mars 2025 12:29Mike Schwab < >> [email protected]> skrev: >> >>> z/OS Unix System Services imposes a 1024 name length limit. A few >>> directories exceed this and is corrected by CD brfore re-extracting the >>> affected files. >>> >>> On Thu, Mar 27, 2025 at 6:20 AM Thomas Berg < >>> [email protected]> wrote: >>> >>>> How about UNIX/Linux name standard limits? What lengths are >>>> permitted? >>>> (And what hex code ranges etc?) >>>> >>>> Are there any consensus? >>>> >>>> >>>> Thomas Berg >>>> >>>> Mundus Vult Decipi >>>> >>>> Den tors 27 mars 2025 01:22Seymour J Metz<[email protected]> skrev: >>>> >>>>> Sigma? You don't have to go as far as SDS; IBM had that too, in TSS. >>>>> >>>>> -- >>>>> Shmuel (Seymour J.) Metz >>>>> http://mason.gmu.edu/~smetz3 >>>>> עַם יִשְׂרָאֵל חַי >>>>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: IBM Mainframe Discussion List on behalf of Paul Gilmartin >>>>> Sent: Wednesday, March 26, 2025 6:05 PM >>>>> To:[email protected] >>>>> Subject: Re: Expand DSN names (WAS : Java saved IBM Z?!) >>>>> >>>>> >>>>> External Message: Use Caution >>>>> >>>>> >>>>> On Wed, 26 Mar 2025 21:25:01 +0000, Pew, Curtis G wrote: >>>>>> ... >>>>>> Things that can already exploit zFS would have no trouble exploiting >>>>> this. Also, programs that use QSAM or BSAM can in many cases run just >>>> fine >>>>> using Unix files instead of MVS datasets. IBM should make that even >>>> easier, >>>>> and provide more ways for other things to exploit Unix directories >>>>> and >>>>> files, instead of depending on a 60 year old storage architecture >>>>> that >>>>> seems to clearly have been a mistake from the start. >>>>> Moving the search to the control unit was an idea clever for >>>>> its time but which gained little traction. >>>>> >>>>> A co-worker once told me of a Sigma system which kept sourde >>>>> files in a sort of KSDS, keyed by the statement number. Records >>>>> could be added, deleted, or edited without rewriting the entire >>>>> file. Another innovation dead end. >>>>> >>>>> A UNIX antiquarian told me that within his memory directory entries >>>>> were 16 bytes: 14 for the filename and 16 bits for the I-number. >>>>> Both have been outgrown, but with little pain because those >>>>> numbers were parameters in header files or wrapped in system >>>>> functions. >>>>> >>>>> I understand that a MACLIB member contains equates, 44 for DSN >>>>> length and 8 for member length. If developers had been faithful >>>>> to the paradigm, it would be possible to increase those numbers >>>>> and assemble an installable OS with larger limits. >>>>> >>>>> -- >>>>> gil >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email [email protected] with the message: INFO IBM-MAIN >>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email [email protected] with the message: INFO IBM-MAIN >>>>> >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email [email protected] with the message: INFO IBM-MAIN >>>> >>> >>> -- >>> Mike A Schwab, Springfield IL USA >>> Where do Forest Rangers go to get away from it all? >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email [email protected] with the message: INFO IBM-MAIN >>> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email [email protected] with the message: INFO IBM-MAIN > -- -- R; <>< ---------------------------------------------------------------------- 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
