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 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 > > > > > -- > 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 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
