Discussion:
SMP/E ++HFS Attributes
Add Reply
Paul Gilmartin
2017-12-23 00:10:27 UTC
Reply
Permalink
Raw Message
I see that ++HFS MCS supports BINARY and TEXT. But in other manuals, I see
ST_FILEFMT
S_FFBINARY
S_FFCR
S_FFCRLF
S_FFCRNL
S_FFNA
S_FFNL
S_FFRECORD

And:
ST_CCSID

Is it possible to specify the rest of these for a ++HFS element? The most
straightforward way would be if GIMDTS propagated them from SYSUT1 to SYSUT2
and APPLY in turn propagated them to the target library member.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Kurt Quackenbush
2018-01-02 14:13:00 UTC
Reply
Permalink
Raw Message
Post by Paul Gilmartin
I see that ++HFS MCS supports BINARY and TEXT. But in other manuals, I see
ST_FILEFMT
S_FFBINARY
S_FFCR
S_FFCRLF
S_FFCRNL
S_FFNA
S_FFNL
S_FFRECORD
ST_CCSID
Is it possible to specify the rest of these for a ++HFS element?
Nope. If you want to set or preserve these file attributes using
SMP/E's existing capabilities I think you'd have to specify BINARY and
tell SMP/E to invoke a shell script that will set the appropriate file
attributes.

Is this purely an academic exercise, or would builtin SMP/E support for
these attributes be truly interesting?

Kurt Quackenbush -- IBM, SMP/E Development

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-01-02 19:31:05 UTC
Reply
Permalink
Raw Message
Post by Kurt Quackenbush
Post by Paul Gilmartin
ST_FILEFMT
ST_CCSID
Is it possible to specify the rest of these for a ++HFS element?
Nope. If you want to set or preserve these file attributes using
SMP/E's existing capabilities I think you'd have to specify BINARY and
tell SMP/E to invoke a shell script that will set the appropriate file
attributes.
There's some trepidation here about post-processing. It compromises
the SMP/E audit trail.
Post by Kurt Quackenbush
Is this purely an academic exercise, or would builtin SMP/E support for
these attributes be truly interesting?
Some of each. ISPF Edit/Browse now has support for multiple file and
terminal CCSIDs and formats. SMP/E lags. If I needed to support those,
I might find the easiest approach to package a tarball and unpack it in
post-processinng. Of course, that's the technique most familiar to
developers with a UNIX background.

There's a rift in this community. Some advocate fine-grained
issue-oriented service with greatest isolation from collateral damage
from repairs to defects not experienced. Others prefer level-set service
with greatest protection from generating a configuration the supplier has
never tested.

++PROGRAM is a de-facto level-set for the entire program object.
Unpacking a tarball is a level-set for an entire directory structure.

Some are dismayed that Java service level-set-like, too coarse-grained.
And I wonder why occasional updates to the Java timezone database
require unusual administrative action rather than appearing in the PTF
stream.

Of course, all this is controlled by the product developers, not SMP/E.

But SMP/E is weak in the variety of languages in which it supports delivey
as source.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-01-02 19:36:45 UTC
Reply
Permalink
Raw Message
The lack of support for source in all of the languages for which IBM provides compilers is a long standing irritant.

As to OMVS, it would seem simple to provide for SMP to do things like setting file attributes rather than relying on post processing.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Tuesday, January 2, 2018 2:32 PM
To: IBM-***@listserv.ua.edu
Subject: Re: SMP/E ++HFS Attributes
Post by Kurt Quackenbush
Post by Paul Gilmartin
ST_FILEFMT
ST_CCSID
Is it possible to specify the rest of these for a ++HFS element?
Nope. If you want to set or preserve these file attributes using
SMP/E's existing capabilities I think you'd have to specify BINARY and
tell SMP/E to invoke a shell script that will set the appropriate file
attributes.
There's some trepidation here about post-processing. It compromises
the SMP/E audit trail.
Post by Kurt Quackenbush
Is this purely an academic exercise, or would builtin SMP/E support for
these attributes be truly interesting?
Some of each. ISPF Edit/Browse now has support for multiple file and
terminal CCSIDs and formats. SMP/E lags. If I needed to support those,
I might find the easiest approach to package a tarball and unpack it in
post-processinng. Of course, that's the technique most familiar to
developers with a UNIX background.

There's a rift in this community. Some advocate fine-grained
issue-oriented service with greatest isolation from collateral damage
from repairs to defects not experienced. Others prefer level-set service
with greatest protection from generating a configuration the supplier has
never tested.

++PROGRAM is a de-facto level-set for the entire program object.
Unpacking a tarball is a level-set for an entire directory structure.

Some are dismayed that Java service level-set-like, too coarse-grained.
And I wonder why occasional updates to the Java timezone database
require unusual administrative action rather than appearing in the PTF
stream.

Of course, all this is controlled by the product developers, not SMP/E.

But SMP/E is weak in the variety of languages in which it supports delivey
as source.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...