[hercules-os380] LFN support on MVS

[[e-mail] [hercules-os380]]

I was wondering if it would be possible to
add LFN support to MVS the same way it
was done to MSDOS/Windows.

PDS entries could have some dummy
entries added that redefine the core
name. Directories and extension would
still be limited to 8 characters though.

So PDPCLIB.C(FRED~1) could have
"$Fredwas" and "$here" entries that
end up with a translation of:

/pdpclib/Fredwashere.c

Note that I'm not familiar with LFN myself,
it was Alica who wrote that code.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
PDS entries could have some dummy
entries added

Or however ISPF statistics and link-edit
data were added could be reused.

BFN. Paul.

[[e-mail] [hercules-os380]]

What are you talking about?



OS/360 right up to MVS and z/OS already supports long file names up to 44 characters for dataset name, and up to 54 characters for a PDS, with a fully qualified member name.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com [hercules-os380]
What are you talking about?
OS/360 right up to MVS and z/OS already
supports long file names up to 44 characters
for dataset name, and up to 54 characters for
a PDS, with a fully qualified member name.

That's not what I'm after. GCC has source
code with names like stor-layout.c. What I
would like to do is translate:

/gcc/stor-layout.c

into:

GCC.C(STOR-LAYOUT)

To me that is the logical mapping, and for
practical use, the only segment that needs
long names is the thing that goes into the
PDS member name. You can see that the
".c" extension of the filename maps to the
last bit of the PDS name, and so long as
people don't use more than 8 character
long extensions, there won't be a mapping
problem.

Directory names will also need to be
restricted to 8 characters to fit the mapping
scheme, but again, directory names are
not as important as the filename sans
extension.

BFN. Paul.

['Bill Turner, WB4ALM' [e-mail] [hercules-os380]]

If you want to see your whole world come tumbling down,
then screw around with the logic, dsects, and billions of
lines of existing code that deals with 8-byte long member names,
just to make them longer...

you might, however, be able to come up with some sort
of alias mechanism that would use a (max) 44-byte filename
to point to an 8-byte (max) pds member nmae.

How you would do this, and how you would differenciate
between a real file name and a fake (pointer) file name
is beyond my knowledge.

/s/ Bill Turner, wb4alm

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com [hercules-os380]
What are you talking about?
OS/360 right up to MVS and z/OS already
supports long file names up to 44 characters
for dataset name, and up to 54 characters for
a PDS, with a fully qualified member name.

That's not what I'm after. GCC has source
code with names like stor-layout.c. What I
/gcc/stor-layout.c
GCC.C(STOR-LAYOUT)
To me that is the logical mapping, and for
practical use, the only segment that needs
long names is the thing that goes into the
PDS member name. You can see that the
".c" extension of the filename maps to the
last bit of the PDS name, and so long as
people don't use more than 8 character
long extensions, there won't be a mapping
problem.
Directory names will also need to be
restricted to 8 characters to fit the mapping
scheme, but again, directory names are
not as important as the filename sans
extension.
BFN. Paul.
------------------------------------------------------------------------

[[e-mail] [hercules-os380]]

Post by 'Bill Turner, WB4ALM' ***@arrl.net [hercules-os380]
If you want to see your whole world come tumbling down,
then screw around with the logic, dsects, and billions of
lines of existing code that deals with 8-byte long member names,
just to make them longer...

MSDOS had the same "insurmountable" issue
with 8.3 filenames. It was overcome.

BFN. Paul.

[[e-mail] [hercules-os380]]

Just because MS-DOS did this extremely gross kludge, why would you want to try to emulate that?

['Hamilton, Robert' [e-mail] [hercules-os380]]

I have to say, that might be what YOU want to see in name mapping, but the next guy may want a slightly different name mapping.

Is it too much to add #ifdef to check a value that indicates the platform, and select a command format appropriately? Most of the code will be platform-agnostic, but this has always allowed for a small section of the code to be platform-specific without affecting the rest. I’m happy with that, actually.

R;

From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Tuesday, July 17, 2018 11:00 PM
To: hercules-***@yahoogroups.com
Subject: [hercules-os380] Re: LFN support on MVS

Post by ***@yahoo.com [hercules-os380]
What are you talking about?
OS/360 right up to MVS and z/OS already
supports long file names up to 44 characters
for dataset name, and up to 54 characters for
a PDS, with a fully qualified member name.

That's not what I'm after. GCC has source
code with names like stor-layout.c. What I
would like to do is translate:

/gcc/stor-layout.c

into:

GCC.C(STOR-LAYOUT)

To me that is the logical mapping, and for
practical use, the only segment that needs
long names is the thing that goes into the
PDS member name. You can see that the
".c" extension of the filename maps to the
last bit of the PDS name, and so long as
people don't use more than 8 character
long extensions, there won't be a mapping
problem.

Directory names will also need to be
restricted to 8 characters to fit the mapping
scheme, but again, directory names are
not as important as the filename sans
extension.

BFN. Paul.

Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from CAS, a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.

[[e-mail] [hercules-os380]]

I wish to implement a Unix-style file system
on top of MVS datasets so that Posix-compliant
programs can run (to some extent) on MVS 3.8j.
The C library would take care of this instead of
needing to update the OS. MVS dataset names
and DD names would still work too.

BFN. Paul.




---In hercules-***@yahoogroups.com, <***@cas.org> wrote :

I have to say, that might be what YOU want to see in name mapping, but the next guy may want a slightly different name mapping.

Is it too much to add #ifdef to check a value that indicates the platform, and select a command format appropriately? Most of the code will be platform-agnostic, but this has always allowed for a small section of the code to be platform-specific without affecting the rest. I’m happy with that, actually.

R;

From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Tuesday, July 17, 2018 11:00 PM
To: hercules-***@yahoogroups.com
Subject: [hercules-os380] Re: LFN support on MVS

Post by ***@yahoo.com [hercules-os380]
What are you talking about?
OS/360 right up to MVS and z/OS already
supports long file names up to 44 characters
for dataset name, and up to 54 characters for
a PDS, with a fully qualified member name.

That's not what I'm after. GCC has source
code with names like stor-layout.c. What I
would like to do is translate:

/gcc/stor-layout.c

into:

GCC.C(STOR-LAYOUT)

To me that is the logical mapping, and for
practical use, the only segment that needs
long names is the thing that goes into the
PDS member name. You can see that the
".c" extension of the filename maps to the
last bit of the PDS name, and so long as
people don't use more than 8 character
long extensions, there won't be a mapping
problem.

Directory names will also need to be
restricted to 8 characters to fit the mapping
scheme, but again, directory names are
not as important as the filename sans
extension.

BFN. Paul.





Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from CAS, a division of the American Chemical Society (“ACS”). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.

[Mike Schwab [e-mail] [hercules-os380]]

How about a VSAM KSDS? Key is the MVS file name. Remainder of the
record is Unix file name, any aliases, any other Unix info about the
file. Basically a UNIX catalog on top of the MVS catalogs.

Post by ***@yahoo.com.au [hercules-os380]
I wish to implement a Unix-style file system
on top of MVS datasets so that Posix-compliant
programs can run (to some extent) on MVS 3.8j.
The C library would take care of this instead of
needing to update the OS. MVS dataset names
and DD names would still work too.
BFN. Paul.
I have to say, that might be what YOU want to see in name mapping, but the next guy may want a slightly different name mapping.
Is it too much to add #ifdef to check a value that indicates the platform, and select a command format appropriately? Most of the code will be platform-agnostic, but this has always allowed for a small section of the code to be platform-specific without affecting the rest. I’m happy with that, actually.
R;
Sent: Tuesday, July 17, 2018 11:00 PM
Subject: [hercules-os380] Re: LFN support on MVS

Post by ***@yahoo.com [hercules-os380]
What are you talking about?
OS/360 right up to MVS and z/OS already
supports long file names up to 44 characters
for dataset name, and up to 54 characters for
a PDS, with a fully qualified member name.

That's not what I'm after. GCC has source
code with names like stor-layout.c. What I
/gcc/stor-layout.c
GCC.C(STOR-LAYOUT)
To me that is the logical mapping, and for
practical use, the only segment that needs
long names is the thing that goes into the
PDS member name. You can see that the
".c" extension of the filename maps to the
last bit of the PDS name, and so long as
people don't use more than 8 character
long extensions, there won't be a mapping
problem.
Directory names will also need to be
restricted to 8 characters to fit the mapping
scheme, but again, directory names are
not as important as the filename sans
extension.
BFN. Paul.
Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from CAS, a division of the American Chemical Society (“ACS”). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[[e-mail] [hercules-os380]]

How about a VSAM KSDS? Key is the MVS file name. Remainder of the
record is Unix file name, any aliases, any other Unix info about the
file. Basically a UNIX catalog on top of the MVS catalogs.

This would be a totally alien file system,
which I agree would work, and IBM
went the same way. But I would like to
graft the Unix filenames onto existing
F/V/U datasets, using the "." as
directory separators, and just having
the PDS member name have an
alternate name for LFN-aware software
(and still work for non-LFN-aware
software).

BFN. Paul.

['Hamilton, Robert' [e-mail] [hercules-os380]]

You could implement the PATH= option for data set allocation, either in DD statements or the ALLOC command.

Or maybe that’s what you’re trying to do.

The way PATH is implemented now in z/OS it doesn’t affect non-LFN software, and provides access to a BFS. PATHOPT is used to set things like file access permissions, IIRC. And then, you could make your BFS a VSAM LDS.

Probably not what you’re doing. Sounds like you want to make a new style of data set names and write something like a new Format 9 DSCB with the long name and such.

I honestly wouldn’t mess with F1/F3 DSCBs. PATH is the way to go. If you want, add something into data set allocation like a PATHMAP option, to allow you to specify on a data-set-by-data-set basis how to map a particular path or kind of path specification to a real data set name or data set and member. Now that I think about it, rarely do I specify a full path name on #include; the compilers I use either know to look in SYSLIB or have a way to specify the “include path” to be searched for something to be #included.


R;


From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Thursday, July 19, 2018 4:09 AM
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-os380] Re: LFN support on MVS

How about a VSAM KSDS? Key is the MVS file name. Remainder of the
record is Unix file name, any aliases, any other Unix info about the
file. Basically a UNIX catalog on top of the MVS catalogs.

This would be a totally alien file system,
which I agree would work, and IBM
went the same way. But I would like to
graft the Unix filenames onto existing
F/V/U datasets, using the "." as
directory separators, and just having
the PDS member name have an
alternate name for LFN-aware software
(and still work for non-LFN-aware
software).

BFN. Paul.


Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from CAS, a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

This post might be inappropriate. Click to display it.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
I was wondering if it would be possible to

add LFN support to MVS the same way it
was done to MSDOS/Windows.
PDS entries could have some dummy
entries added that redefine the core
name. Directories and extension would
still be limited to 8 characters though.
So PDPCLIB.C(FRED~1) could have
"$Fredwas" and "$here" entries that
/pdpclib/Fredwashere.c
Note that I'm not familiar with LFN myself,
it was Alica who wrote that code.
BFN. Paul.
---
Paul, I've implemented LFN for FAT32 in Java,
and in the line of principle, records marked
as "deleted" may probably be used to implement
such an "hack" into a standard MVS3.8j dataset.
Don't even think, once implemented and used,
to "compress" such a dataset ;-)
Peppe.

Ops. Of coruse read it as "into a standard MVS3.8j PDS dataset".

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Paul, I've implemented LFN for FAT32 in Java,
and in the line of principle, records marked
as "deleted" may probably be used to implement
such an "hack" into a standard MVS3.8j dataset.

I think it would be best to use the extra info
field if possible. According to this:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/pdsst9.htm

62 bytes of info can be stored, which is plenty
enough for a long filename. But I don't know
how it can be specified so that it is distinct
from both ISPF statistics and Linkage Editor
data.

Actually the ISPF stats are useful. I'm not
sure if they can be extended to include a
long filename, even if it's not a full 62 bytes.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
62 bytes of info can be stored,

And I have some code in trav.c like this:

memcpy(ttr,buf+x+8,3);
scnt = *(buf+x+11);
scnt = scnt & 0x1f;
x += 12 + scnt * 2;

So after the TTR there is a count (up to 31 = 0x1f)
of number of halfwords of information that follows.

But I have no idea how you're supposed to
distinguish between ISPF and Linkage Editor
information, or how a new set of data can be
added.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"But I have no idea how you're supposed to
distinguish between ISPF and Linkage Editor
information, or how a new set of data can be
added."

http://www.naspa.net/magazine/1991/t9109019.txt

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
62 bytes of info can be stored,

memcpy(ttr,buf+x+8,3);
scnt = *(buf+x+11);
scnt = scnt & 0x1f;
x += 12 + scnt * 2;
So after the TTR there is a count (up to 31 = 0x1f)
of number of halfwords of information that follows.
But I have no idea how you're supposed to
distinguish between ISPF and Linkage Editor
information, or how a new set of data can be
added.
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
But I have no idea how you're supposed to
distinguish between ISPF and Linkage Editor
information, or how a new set of data can be
added.

http://www.naspa.net/magazine/1991/t9109019.txt

Thanks. That sort of suggests that only IEWL
and ISPF are available.

But ISPF only takes up 28 bytes, so 62-28 = 34
could be used for a long name. Adequate I think.

BFN. Paul.

[Jeremy Nicoll [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
But ISPF only takes up 28 bytes, so 62-28 = 34
could be used for a long name. Adequate I think.

I wonder if you'll run into a problem with enqueues. I see (from Google) that the
rname value these days can by up to 255 or so bytes long... but was that true in
ancient versions of MVS?

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by Jeremy Nicoll ***@letterboxes.org [hercules-os380]
I wonder if you'll run into a problem with enqueues. I see (from Google) that the
rname value these days can by up to 255 or so bytes long... but was that true in
ancient versions of MVS?

AFAIK, the 255 limit has been there since day one.


Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
https://www.avg.com

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
But ISPF only takes up 28 bytes, so 62-28 = 34
could be used for a long name. Adequate I think.

ISPF length is x'0F' - 30 bytes. The current version expanded that by
two bytes.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
https://www.avg.com

['Hamilton, Robert' [e-mail] [hercules-os380]]

I used to be with a software company that used the space in a directory entry for product configuration data. If you’re still going with LFNs, make the facility configurable so someone isn’t required to have it.

R;





From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Tuesday, July 24, 2018 5:54 AM
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-os380] LFN support on MVS

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
But I have no idea how you're supposed to
distinguish between ISPF and Linkage Editor
information, or how a new set of data can be
added.

http://www.naspa.net/magazine/1991/t9109019.txt

Thanks. That sort of suggests that only IEWL
and ISPF are available.

But ISPF only takes up 28 bytes, so 62-28 = 34
could be used for a long name. Adequate I think.

BFN. Paul.


Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from CAS, a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
So after the TTR there is a count (up to 31 = 0x1f)
of number of halfwords of information that follows.
But I have no idea how you're supposed to
distinguish between ISPF and Linkage Editor
information, or how a new set of data can be
added.

The "count" fields also contains the alias indicator bit, and the number
of additional TTRs following the first one. All load-modules have at
least one extra TTR (location of first text block); while it is
conventional to use RECFM=U, this is not required by the loader.

ISPF has two lengths - traditional (0F) and newer (10?). I don't have
the newer one for testing (yet?).

Load-module entries come in various lengths, and deciphering them
requires testing the option bits and/or rounding up to an even displacement.

Directory entries are maintained by BPAM. You can POINT or FIND a
member, or use BLDL to get a directory entry. The STOW macro (add,
change, delete) is used to update or add a directory or a member or an
alias.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
https://www.avg.com