Re: XYplorer - EBCDIC to ASCII translation - CP500 or something better

[Brian Westerman]

I use Directory Opus.  It has many more features than XYplorer, and a a bit 
more expensive, but it does everything (except Linux).  There are literally 
hundreds of plugins.

Brian

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

Re: XYplorer - EBCDIC to ASCII translation - CP500 or something better

[Farley, Peter x23353]

+1.  I agree that CP 1047 should be the default.

Also agree the developer should be persuaded to externalize the code page 
chosen, if at all possible.  EBCDIC users can and should be expected to know 
and understand the ramifications of the code page requested from the software.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Attila Fogarasi
Sent: Thursday, November 12, 2020 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XYplorer - EBCDIC to ASCII translation - CP500 or something better

Codepage 1047 is the IBM USS default codepage.  Since so much of z/OS now runs 
in USS it really is the standard.  There are 8 code poing differences between 
500 and 1047, including the crucial x'AD' and x'BD' :)

On Fri, Nov 13, 2020 at 6:50 AM Robert Prins 
wrote:

> For those who don't know, XYplorer 
>  NniQ8HSAI-g_K5b7VKg!ZSocfAeqHZxvsW9uB_853ntXFCn2TlFRV_4Mtyo5mQDhpSjGhI
> _ho7ITvVr0y-rXcxXhTA$ > is a replacement for Windows' Explorer, with 
> rather a lot more functionality, and that's a huge understatement. 
> Like Tom Brennan's Vista TN3270, you can try it free for
> 30
> days, the "Standard License Pro" costs USD 39.95, never expires, and 
> gives free upgrades (usually a few per week(!)) for a year, the 
> "Lifetime License Pro"
> costs USD 79.95, never expires, and gives free upgrades forever. Both 
> can be used on all of your computers.
>
> OK, advertising out of the way, Donald Lessau the developer has added 
> a tweak to
>   the "Mouse-Down Blow-Up" feature (click and hold on the icon of a 
> file, and you'll see its contents) to auto-convert EBCDIC files. I 
> asked for it (it's kind of useful to have a quick look at XMIT files 
> containing source, README, or "$INDEX" like members) and he has 
> hard-coded some defaults:
>
> The conversion is hard-coded to IBM EBCDIC International (codepage 500)
> and a record length of 80.
> Affects Text Preview, Hover Box, Mouse Down Blow Up, Quick File View,
> Floating Preview.
>
> I suggested the LRECL=80, he himself went for CP 500. I've already 
> suggested that he "externalizes" the CP, but if he doesn't, is there a 
> opinion on which code-page might be more useful for "Joe Average".
>
> For what it's worth, I suggested that the EBCDIC auto-detect is based 
> on long strings of the ASCII "@" character, the EBCDIC space.
>
> Robert
> --

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: XYplorer - EBCDIC to ASCII translation - CP500 or something better

[Seymour J Metz]

I'd be more interested if it ran on Linux and supported more code pages, both 
on the PC side and the z side.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [robert.ah.pr...@gmail.com]
Sent: Thursday, November 12, 2020 4:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: XYplorer - EBCDIC to ASCII translation - CP500 or something better

For those who don't know, XYplorer 

 is a replacement
for Windows' Explorer, with rather a lot more functionality, and that's a huge
understatement. Like Tom Brennan's Vista TN3270, you can try it free for 30
days, the "Standard License Pro" costs USD 39.95, never expires, and gives free
upgrades (usually a few per week(!)) for a year, the "Lifetime License Pro"
costs USD 79.95, never expires, and gives free upgrades forever. Both can be
used on all of your computers.

OK, advertising out of the way, Donald Lessau the developer has added a tweak to
  the "Mouse-Down Blow-Up" feature (click and hold on the icon of a file, and
you'll see its contents) to auto-convert EBCDIC files. I asked for it (it's kind
of useful to have a quick look at XMIT files containing source, README, or
"$INDEX" like members) and he has hard-coded some defaults:

The conversion is hard-coded to IBM EBCDIC International (codepage 500)
and a record length of 80.
Affects Text Preview, Hover Box, Mouse Down Blow Up, Quick File View,
Floating Preview.

I suggested the LRECL=80, he himself went for CP 500. I've already suggested
that he "externalizes" the CP, but if he doesn't, is there a opinion on which
code-page might be more useful for "Joe Average".

For what it's worth, I suggested that the EBCDIC auto-detect is based on long
strings of the ASCII "@" character, the EBCDIC space.

Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - 
https://secure-web.cisco.com/1za9WpfYYLbRTrQO4iF4IFKN3NWjlZtqqefmChD3PECaWBRWNuNjn2R5uMiKTU5_X3XzzeFMtNOuWmKehQjfXoKUrq6gvtLvUF5WAWaZFexCdGNCj-ZCpNrUroAi7dAnMiVZHxQu7fexGkvSkPdFwpr0pOkEOy1Z6nF4b5PBGMl19STKu9wWApYxM0vdhRM5ujeJLhBzpC6xwrh7laVaM--muaVYt352sLPudXKl-Kzcy2d2jurYs7s43cCAJ17HlCwganWg79DM9C1W67MKp1aKog_kIXivIhpF5J5cm3dZmacQbCFwQxwfGe6NIvocen5Bg8PG_Cd9Mrln4Ps3lxeZfMCWZn9615XMrzoq45ez8-k1O02nIU4HrvGOdx-KQAO5NedNTQoZuV7SLjQL2c5Ob57rV1kiv3dhbv9yC9yZvk-IoJAoh3_oc_-E4cRGh/https%3A%2F%2Fprino.neocities.org%2F
Some REXX code for use on z/OS - 
https://secure-web.cisco.com/1KldTsRMrrC8rMDgsL4poB_uPyMCVgGcle5qSJ7Y4Y9G0Fj92d19JHAtPV7SxNdaMFJMIYSNOJZsMm6eUOwethqwIIBhBMT6Y0FM8uoQ5Cp6fAYso55nHwGUFV2KZgy4792cvHN6-RZLn-0vaXog8fXzivUn5CmYoJ2fHOoYtH3DallD8PcwB10E_fJjR_uFu1ktCCcH2vJKOk7RcgKnKaTtweqo_yAyYVlPAl4FaWk4GIiUrwReXrotUznL8jz2gda5eZVdR8frp5VNCa1NNnUI2dFd-g-BCwrVuVqi82rKaty78nuJS-4Z9N6ryKO9TAPKoE7aUVlTr-Kt9goBRD4RxNMpK2vbLlv5Zj2kYkjeozTYK6iZ53sSieQft5CG34K5oxcBpjW-92lpBtRjLy4QecP1y_WzIKb9FSAbnbUEe2SIBtvYkcivdbmd43V8D/https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.html

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

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

Re: XYplorer - EBCDIC to ASCII translation - CP500 or something better

[Paul Gilmartin]

On Thu, 12 Nov 2020 23:27:19 +, Robert Prins wrote:
>>> ...
>>> Both can be used on all of your computers.
>>>
>> One of my computers is a Raspberry Pi.
>
>Almost all of your computers.
> 
Another is a MacBook Pro with a Linux guest (does virtual count?)

>>>...
>> RECFM=V files may lack such long strings of x'40'.  Would better be a 
>> preponderance
>> of octets above x'80'?  But there should be an option to override.
>
>If you go for over 0x80, you end up in UTF-8 territory, which is also 
>auto-detected.
>
It's extremely unlikely that an EBCDIC file be valid UTF-8.  More plausibly 
ISO8859-?
(Which might also be auto-detected.)

-- gil

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

Re: XYplorer - EBCDIC to ASCII translation - CP500 or something better

[Robert Prins]

On 2020-11-12 21:16, Paul Gilmartin wrote:

On Thu, 12 Nov 2020 21:48:06 +, Robert Prins wrote:


For those who don't know, XYplorer  is a replacement
...
Both can be used on all of your computers.


One of my computers is a Raspberry Pi.


Almost all of your computers.


... auto-convert EBCDIC files. I asked for it (it's kind
of useful to have a quick look at XMIT files containing source, README, or
"$INDEX" like members) and he has hard-coded some defaults:

The conversion is hard-coded to IBM EBCDIC International (codepage 500)
and a record length of 80.


XMIT files of RECVM=VB source contain control information sufficient to
reconstruct line boundaries.  Lacking that, it's not only a "quick look" but
also dirty.  A PDS member TRANSMITted without the SEQ option is worse:
it's an IEBCOPY PDSU inside a .XMIT envelope.


The option only shows the top of the file, it's never going to be anything line 
XMIT Manager or XmitApp.



I suggested the LRECL=80, he himself went for CP 500. I've already suggested
that he "externalizes" the CP, ...


It should be externalized.


We'll see what he decides


For what it's worth, I suggested that the EBCDIC auto-detect is based on long
strings of the ASCII "@" character, the EBCDIC space.


RECFM=V files may lack such long strings of x'40'.  Would better be a 
preponderance
of octets above x'80'?  But there should be an option to override.


If you go for over 0x80, you end up in UTF-8 territory, which is also 
auto-detected.

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: XYplorer - EBCDIC to ASCII translation - CP500 or something better

[Paul Gilmartin]

On Thu, 12 Nov 2020 21:48:06 +, Robert Prins wrote:

>For those who don't know, XYplorer  is a replacement
>...  
>Both can be used on all of your computers.
>
One of my computers is a Raspberry Pi.

>... auto-convert EBCDIC files. I asked for it (it's kind
>of useful to have a quick look at XMIT files containing source, README, or
>"$INDEX" like members) and he has hard-coded some defaults:
>
>The conversion is hard-coded to IBM EBCDIC International (codepage 500)
>and a record length of 80.
>
XMIT files of RECVM=VB source contain control information sufficient to
reconstruct line boundaries.  Lacking that, it's not only a "quick look" but
also dirty.  A PDS member TRANSMITted without the SEQ option is worse:
it's an IEBCOPY PDSU inside a .XMIT envelope.

>I suggested the LRECL=80, he himself went for CP 500. I've already suggested
>that he "externalizes" the CP, ...
> 
It should be externalized.

>For what it's worth, I suggested that the EBCDIC auto-detect is based on long
>strings of the ASCII "@" character, the EBCDIC space.
>
RECFM=V files may lack such long strings of x'40'.  Would better be a 
preponderance
of octets above x'80'?  But there should be an option to override.

-- gil

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

Re: XYplorer - EBCDIC to ASCII translation - CP500 or something better

[Attila Fogarasi]

Codepage 1047 is the IBM USS default codepage.  Since so much of z/OS now
runs in USS it really is the standard.  There are 8 code poing differences
between 500 and 1047, including the crucial x'AD' and x'BD' :)

On Fri, Nov 13, 2020 at 6:50 AM Robert Prins 
wrote:

> For those who don't know, XYplorer  is a
> replacement
> for Windows' Explorer, with rather a lot more functionality, and that's a
> huge
> understatement. Like Tom Brennan's Vista TN3270, you can try it free for
> 30
> days, the "Standard License Pro" costs USD 39.95, never expires, and gives
> free
> upgrades (usually a few per week(!)) for a year, the "Lifetime License
> Pro"
> costs USD 79.95, never expires, and gives free upgrades forever. Both can
> be
> used on all of your computers.
>
> OK, advertising out of the way, Donald Lessau the developer has added a
> tweak to
>   the "Mouse-Down Blow-Up" feature (click and hold on the icon of a file,
> and
> you'll see its contents) to auto-convert EBCDIC files. I asked for it
> (it's kind
> of useful to have a quick look at XMIT files containing source, README, or
> "$INDEX" like members) and he has hard-coded some defaults:
>
> The conversion is hard-coded to IBM EBCDIC International (codepage 500)
> and a record length of 80.
> Affects Text Preview, Hover Box, Mouse Down Blow Up, Quick File View,
> Floating Preview.
>
> I suggested the LRECL=80, he himself went for CP 500. I've already
> suggested
> that he "externalizes" the CP, but if he doesn't, is there a opinion on
> which
> code-page might be more useful for "Joe Average".
>
> For what it's worth, I suggested that the EBCDIC auto-detect is based on
> long
> strings of the ASCII "@" character, the EBCDIC space.
>
> Robert
> --
> Robert AH Prins
> robert.ah.prins(a)gmail.com
> The hitchhiking grandfather - https://prino.neocities.org/
> Some REXX code for use on z/OS -
> https://prino.neocities.org/zOS/zOS-Tools.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

XYplorer - EBCDIC to ASCII translation - CP500 or something better

[Robert Prins]

For those who don't know, XYplorer  is a replacement 
for Windows' Explorer, with rather a lot more functionality, and that's a huge 
understatement. Like Tom Brennan's Vista TN3270, you can try it free for 30 
days, the "Standard License Pro" costs USD 39.95, never expires, and gives free 
upgrades (usually a few per week(!)) for a year, the "Lifetime License Pro" 
costs USD 79.95, never expires, and gives free upgrades forever. Both can be 
used on all of your computers.


OK, advertising out of the way, Donald Lessau the developer has added a tweak to 
 the "Mouse-Down Blow-Up" feature (click and hold on the icon of a file, and 
you'll see its contents) to auto-convert EBCDIC files. I asked for it (it's kind 
of useful to have a quick look at XMIT files containing source, README, or 
"$INDEX" like members) and he has hard-coded some defaults:


   The conversion is hard-coded to IBM EBCDIC International (codepage 500)
   and a record length of 80.
   Affects Text Preview, Hover Box, Mouse Down Blow Up, Quick File View,
   Floating Preview.

I suggested the LRECL=80, he himself went for CP 500. I've already suggested 
that he "externalizes" the CP, but if he doesn't, is there a opinion on which 
code-page might be more useful for "Joe Average".


For what it's worth, I suggested that the EBCDIC auto-detect is based on long 
strings of the ASCII "@" character, the EBCDIC space.


Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: Have I misunderstood TOD clock & leap seconds?

[Seymour J Metz]

OS/VS2 is before sysplex, and doesn't have support for an ETR; the operator 
sets the TOD clock, and it increments without any steering. That remained true 
with MVS/SE, MVS/XA and every flavor of MVS/ESA before sysplex.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rupert Reynolds [rreyno...@cix.co.uk]
Sent: Thursday, November 12, 2020 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Have I misunderstood TOD clock & leap seconds?

Thanks Paul Gilmartin, you've reminded me to get GCC try on this museum
piece. And maybe PL/1, for old times :-)

And thanks to all for the advice.

If I read the replies right, z/OS does what I expected--keeps track of how
many leap seconds are included in the TOD clock, so that short intervals
measured across the leap second are right, but it can still be converted
into date&time by subtracting the extra seconds.

But MVS 3.8 (I checked SYS1.AMODGEN(CVT) ) doesn't have any reference to
leap seconds i can see. I suppose it was up to ops to adjust the time, and
TOD intervals would be out by a second across the leap second, but it makes
TOD time a bit easier to convert.

Hercules (as installed with defaults from TK4-) follows the Win64 host
clock trustingly. I IPL'd in 2019, saved my work, wound the clock forward
to the evening of Feb 28th 2020, and all the TSO sessions timed out in the
blink of an eye :-)

Interestingly perhaps, this version of MVS returns the century from TIME
DEC in x'0cyydddF', so I only have to add 1900 for . But there is no
STCKCONV, and the instruction set of a 3033 is a bit limiting :-)

Roops


On Thu., Nov. 12, 2020, 10:47 Paul Gilmartin, <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 12 Nov 2020 16:13:41 +1100, Attila Fogarasi  wrote:
>
> >Hercules emulates the TOD clock, so what you see is Hercules behaviour and
> >not the real hardware behaviour for any particular machine type.
> >
> Yes.  And I suspect H merely naively converts the Linux(?) system clock
> to TOD format (add 1970 years; etc.)
> >
> >On Thu, Nov 12, 2020 at 2:13 PM Rupert Reynolds  wrote:
> >
> >> I did look for IBM docs online, but I haven't found anything very
> helpful.
> >>
> You have probably read "TOD Programmable Register" in recent PoOp.
>
> >> I read of someone using STCK and converting (the hard way!) to display
> >> time, instead of using TIME DEC. So I tried it on my Hercules/MVS 3.8
> >> setup.
> >>
> Officially, z/OS keeps a leap second count in CVTLSO and *subtracts* that
> from TOD to get UTC and adds CVTLDTO to get local time.  What value
> do you see for CVTLSO/4096/100?  (Oops!  Does 3.8 have a CVTLSO?)
>
> At an ordinary leap second z/OS adds 1 second to CVTLSO (there has never
> been a negative leap second.)
> 
> https://secure-web.cisco.com/1jsiHGlspR01GS4FBOdZyArkCtmOQkgjhWblnd0CZSUbptOzlTijBnZXQaWfF2RRKnLKYSQdVJNpVCvnVKHA1cfFX4mVq2TEVBJhYTkcAD9HHxYXMTbD-3ZhnuE82dqy1DCcgFUy1qiwyHKQ4e7ZCvWFVvL-GgQNQWREupO9p0Epve9PhqqCkCqVSd-S6ryaBZhFAZiIVAfu-DVSRye3RdKnlShAhfB__zF0Oq2AAaFabo_y0qHv3EcIAr876bvZ36LyYz3GbFBkRrPDEMw7BdK_kmefTLOEeTYlhAES98gAkN3aNBQed9FKIJGHl59923KJhwCO3GAWCOoeUrThQx_x-zxXbEC1WXffsE7Y3ddbetYcXDSKH18SQA00FBkmsxOMfU0ew5krez1dAEDjf57ilUY-gfYoReDJ5qPEVxiUKqBPlQXl6Lbrne0D8sSDn/https%3A%2F%2Fhpiers.obspm.fr%2Fiers%2Fbul%2Fbulc%2Fbulletinc.dat
> 
> https://secure-web.cisco.com/1o7UnCDHKCzi4165kWWs5LAw990Ghbf7QUVqADjbz6iqdrv9K2oYqbKEeW9eY8ftthYd_4a-eOqu24IAkZP9mm9ZhKbfQu0n6Zxrzj4n0z8pTGIZf1L3tU-rD9j-FlBG7hb4FWIAKjjT8N_AK16KLCB__QKD2-reaX68TD2Mtg5vijZCeBdZY8qvspxune0ivNVoUA1QvWUgfWuxH4Vbtpbjwkkuxfn7YzFq_QMmd6mYjZyvumvh_6ca3uQPAUrfXn4RUS_iLUMG7J33S-RnPyn1CRWt7pD_UVCdjGr9urUMYl8rhUcaSmrcDK_OQ2KgmDUhMHFNb5RJYzIVxiwLWWzcfhJynLUCZre9nrjoqIraDMv3B-HIv4jGvLwMxD09zcwyMcknyPRWt0yz0X3QsrnoUXcj6n8W8bS2kt8HnK2QLuKGu4FnaqJL0p2HpMhvo/https%3A%2F%2Fwww.iana.org%2Ftime-zones
>
> During that leap second z/OS makes user processes nondispatchable so
> callers
> of TIME do not see anachronistic results.  No z/OS internals expert has
> ever
> come forth in this forum to explain how TIME accounts for the minuscule
> timing window that CVTLSO/CVTLDTO might be accessed and STCK performed
> on opposite sides of a leap second or DST boundary.
>
> Years ago, our site encountered two software products (both from IBM, IIRC)
> that had different notions of whether to apply CVTLSO, resulting in several
> seconds' inconsistency in SMF data.  We turned off leap seconds; set
> CVTLSO=0 and stayed that way ever after.
>
> I'll attempt to attach a C program that displays TAI rather than UTC.
>
> -- gil
> /* ** */
> /* Doc: Display TAI.
>BUGS: Requires /usr/share/zoneinfo/right.
>  Will never display 23:59:60.  */
>
> #include 
> #include 
> #include 
> #include 
> #include 
>
> int main( int argc, char **argv ) {
>
> char *format;
> time_t t;
> char str[ 99 ];
> s

Re: Have I misunderstood TOD clock & leap seconds?

[Paul Gilmartin]

On Thu, 12 Nov 2020 14:09:48 +, Rupert Reynolds wrote:
>
>But MVS 3.8 (I checked SYS1.AMODGEN(CVT) ) doesn't have any reference to
>leap seconds i can see. I suppose it was up to ops to adjust the time, and
>TOD intervals would be out by a second across the leap second, but it makes
>TOD time a bit easier to convert.
> 
Historian?  Bitsavers?  Nowadays the field is CVTLSO:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.iead100/iead100564.htm

In the earliest protocol, Sysplex Timer dialed NIST for UTC.
https://www.nist.gov/time-distribution/automated-computer-time-service-acts
I believe IBM charged dearly for a 1200 baud modem feature.

Target TOD to UTC and it struggled for several hours to fall in sync.
It's pointless to run 3.8 with a TOD setting (TAI-10 seconds) that
OS doesn't support.

-- gil

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

Re: Have I misunderstood TOD clock & leap seconds?

[Peter Relson]

>> Perhaps the TOD clock is slowed or stalled for leap seconds, to keep
>> TOD-derived date and time in synch with solar time?
>>
>Correct.

I'd have answered "Not correct".  When the leap second change is 
introduced, yes, this sort of thing might happen.
But only during that time. 

Does the OP know that their system has leap seconds in effect?
Does the operating system agree (what's the value in CVTLSO)?

Peter Relson
z/OS Core Technology Design


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

Re: Have I misunderstood TOD clock & leap seconds?

[Rupert Reynolds]

Thanks Paul Gilmartin, you've reminded me to get GCC try on this museum
piece. And maybe PL/1, for old times :-)

And thanks to all for the advice.

If I read the replies right, z/OS does what I expected--keeps track of how
many leap seconds are included in the TOD clock, so that short intervals
measured across the leap second are right, but it can still be converted
into date&time by subtracting the extra seconds.

But MVS 3.8 (I checked SYS1.AMODGEN(CVT) ) doesn't have any reference to
leap seconds i can see. I suppose it was up to ops to adjust the time, and
TOD intervals would be out by a second across the leap second, but it makes
TOD time a bit easier to convert.

Hercules (as installed with defaults from TK4-) follows the Win64 host
clock trustingly. I IPL'd in 2019, saved my work, wound the clock forward
to the evening of Feb 28th 2020, and all the TSO sessions timed out in the
blink of an eye :-)

Interestingly perhaps, this version of MVS returns the century from TIME
DEC in x'0cyydddF', so I only have to add 1900 for . But there is no
STCKCONV, and the instruction set of a 3033 is a bit limiting :-)

Roops


On Thu., Nov. 12, 2020, 10:47 Paul Gilmartin, <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 12 Nov 2020 16:13:41 +1100, Attila Fogarasi  wrote:
>
> >Hercules emulates the TOD clock, so what you see is Hercules behaviour and
> >not the real hardware behaviour for any particular machine type.
> >
> Yes.  And I suspect H merely naively converts the Linux(?) system clock
> to TOD format (add 1970 years; etc.)
> >
> >On Thu, Nov 12, 2020 at 2:13 PM Rupert Reynolds  wrote:
> >
> >> I did look for IBM docs online, but I haven't found anything very
> helpful.
> >>
> You have probably read "TOD Programmable Register" in recent PoOp.
>
> >> I read of someone using STCK and converting (the hard way!) to display
> >> time, instead of using TIME DEC. So I tried it on my Hercules/MVS 3.8
> >> setup.
> >>
> Officially, z/OS keeps a leap second count in CVTLSO and *subtracts* that
> from TOD to get UTC and adds CVTLDTO to get local time.  What value
> do you see for CVTLSO/4096/100?  (Oops!  Does 3.8 have a CVTLSO?)
>
> At an ordinary leap second z/OS adds 1 second to CVTLSO (there has never
> been a negative leap second.)
> https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
> https://www.iana.org/time-zones
>
> During that leap second z/OS makes user processes nondispatchable so
> callers
> of TIME do not see anachronistic results.  No z/OS internals expert has
> ever
> come forth in this forum to explain how TIME accounts for the minuscule
> timing window that CVTLSO/CVTLDTO might be accessed and STCK performed
> on opposite sides of a leap second or DST boundary.
>
> Years ago, our site encountered two software products (both from IBM, IIRC)
> that had different notions of whether to apply CVTLSO, resulting in several
> seconds' inconsistency in SMF data.  We turned off leap seconds; set
> CVTLSO=0 and stayed that way ever after.
>
> I'll attempt to attach a C program that displays TAI rather than UTC.
>
> -- gil
> /* ** */
> /* Doc: Display TAI.
>BUGS: Requires /usr/share/zoneinfo/right.
>  Will never display 23:59:60.  */
>
> #include 
> #include 
> #include 
> #include 
> #include 
>
> int main( int argc, char **argv ) {
>
> char *format;
> time_t t;
> char str[ 99 ];
> size_t len;
> struct tm timestruc;
>
> /* Use either argument as format or (volatile) environment string.
> */
> format = argv[ 1 ] ? argv[ 1 ]
>: nl_langinfo( D_T_FMT );
> /* get system time; convert to (UTC) struct tm.
> */
> t = time( &t );
> putenv( "TZ=Etc/Zulu");  /* Assume this indicates TAI vs. UTC.  */
> tzset();
> gmtime_r( &t, ×truc );
> len = strftime( str, sizeof( str ) -1, format, ×truc );
>
> /* Convert struct tm to atomic time.
> */
> putenv( "TZ=right/Etc/Zulu");
> tzset();
> t = mktime( ×truc );
> t = t + 10;  /* (10-second bias when UTC began in 1972.)  */
>
> /* Convert; format; and display.
> */
> putenv( "TZ=posix/Etc/Zulu");
> tzset();
> gmtime_r( &t, ×truc );
> len = strftime( str, sizeof( str ) -1, format, ×truc );
> printf( "%s\n", str );
>
> return( 0 ); }
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Can a non-admin restrict others from viewing one of their own MVS data sets?

[Seymour J Metz]

There's nothing special about TSO; HLQ=userid is handled the same way in batch, 
STC and TSO.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
R.S. [r.skoru...@bremultibank.com.pl]
Sent: Thursday, November 12, 2020 5:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can a non-admin restrict others from viewing one of their own MVS 
data sets?

W dniu 06.11.2020 o 22:43, Frank Swarbrick pisze:
> In the Unix world one can use chmod (change mode) on their own files to make 
> it so non-superusers cannot view a particular file.  Is there anything 
> similar for MVS data sets?

Few points:
1. In MVS world there is no concept of file ownership like in Unix.
2. For TSO users HLQ=userID is special case, but it is rather "ALTER by
default", which is hard to restrict and it has very little to do with
authorities management.
2.1 Such datasets are called "his own" despite there is no ownership
concept.
2.2 Note, special treatment is not for every RACF user, it is for TSO
users only. So, for example ftp and many other methods are excluded
(assuming the user has no TSO segment).
3. Every TSO user may or may NOT have rights to manage dataset
authorities, his own (HLQ=userid) OR OTHER DATASETS.
4. Details depend on your setup. Usually "his own" datasets are in scope
of the user (userid is the owner of userid.** profile) and that is
enough to manage access list and UACC.
5. However admin may restrict RACF commands like AD, ALDSD nad PE and
then user cannot use them to manage rights. There are other methods also.

HTH

--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1-0IRK32nm4q6txl1FSw7M3xM6GH7-EC9OQiAzAhOio3Yq5wCTu_S5ZGUBO6sdbacXaIKq8x45SOlPBJzlIv02jStB7o3aU0CJmDPSd6rjgBUTkhmphZ2_CodtoS_1xVRnWceMtrUQJ3fbuP9KDNhvEd6Q8HTNtpxC6xGei6HIKJ8kCevAjFGa_kZOefcFDsmvG6ChCk-vQnW2Qtd_pXovyokq6pfPnVQ6321NxsbFbVN3dCcnbHkSliZAUtlD2R9kQJRmV_ZedARpm8VxHlAyjMYlR7hMK-IF4YU8iKnsa7_XohSAbu1X9PY0920wELJZ_OtplOA4gsFiPzpBM09JfvdFl32TRMUt2SFtDeKIahadioCWt2ZSiSz6trEbmWLpiVswzafTiALk3iWvLU9OtWs2WkNG89A2OUFkkOGC5dcGix1ZX1c97ZN_M3h0iC3/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 
169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1-0IRK32nm4q6txl1FSw7M3xM6GH7-EC9OQiAzAhOio3Yq5wCTu_S5ZGUBO6sdbacXaIKq8x45SOlPBJzlIv02jStB7o3aU0CJmDPSd6rjgBUTkhmphZ2_CodtoS_1xVRnWceMtrUQJ3fbuP9KDNhvEd6Q8HTNtpxC6xGei6HIKJ8kCevAjFGa_kZOefcFDsmvG6ChCk-vQnW2Qtd_pXovyokq6pfPnVQ6321NxsbFbVN3dCcnbHkSliZAUtlD2R9kQJRmV_ZedARpm8VxHlAyjMYlR7hMK-IF4YU8iKnsa7_XohSAbu1X9PY0920wELJZ_OtplOA4gsFiPzpBM09JfvdFl32TRMUt2SFtDeKIahadioCWt2ZSiSz6trEbmWLpiVswzafTiALk3iWvLU9OtWs2WkNG89A2OUFkkOGC5dcGix1ZX1c97ZN_M3h0iC3/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th 
Commercial Division of the National Court Register, KRS 025237, NIP: 
526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 
January 2020.

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

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

Re: Have I misunderstood TOD clock & leap seconds?

[Paul Gilmartin]

On Thu, 12 Nov 2020 16:13:41 +1100, Attila Fogarasi  wrote:

>Hercules emulates the TOD clock, so what you see is Hercules behaviour and
>not the real hardware behaviour for any particular machine type.
> 
Yes.  And I suspect H merely naively converts the Linux(?) system clock
to TOD format (add 1970 years; etc.)
>
>On Thu, Nov 12, 2020 at 2:13 PM Rupert Reynolds  wrote:
>
>> I did look for IBM docs online, but I haven't found anything very helpful.
>>
You have probably read "TOD Programmable Register" in recent PoOp.

>> I read of someone using STCK and converting (the hard way!) to display
>> time, instead of using TIME DEC. So I tried it on my Hercules/MVS 3.8
>> setup.
>>
Officially, z/OS keeps a leap second count in CVTLSO and *subtracts* that
from TOD to get UTC and adds CVTLDTO to get local time.  What value
do you see for CVTLSO/4096/100?  (Oops!  Does 3.8 have a CVTLSO?)

At an ordinary leap second z/OS adds 1 second to CVTLSO (there has never
been a negative leap second.)
https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
https://www.iana.org/time-zones

During that leap second z/OS makes user processes nondispatchable so callers
of TIME do not see anachronistic results.  No z/OS internals expert has ever
come forth in this forum to explain how TIME accounts for the minuscule
timing window that CVTLSO/CVTLDTO might be accessed and STCK performed
on opposite sides of a leap second or DST boundary.

Years ago, our site encountered two software products (both from IBM, IIRC)
that had different notions of whether to apply CVTLSO, resulting in several
seconds' inconsistency in SMF data.  We turned off leap seconds; set
CVTLSO=0 and stayed that way ever after.

I'll attempt to attach a C program that displays TAI rather than UTC.

-- gil
/* ** */
/* Doc: Display TAI.
   BUGS: Requires /usr/share/zoneinfo/right.
 Will never display 23:59:60.  */

#include 
#include 
#include 
#include 
#include 

int main( int argc, char **argv ) {

char *format;
time_t t;
char str[ 99 ];
size_t len;
struct tm timestruc;

/* Use either argument as format or (volatile) environment string.
*/
format = argv[ 1 ] ? argv[ 1 ]
   : nl_langinfo( D_T_FMT );
/* get system time; convert to (UTC) struct tm.
*/
t = time( &t );
putenv( "TZ=Etc/Zulu");  /* Assume this indicates TAI vs. UTC.  */
tzset();
gmtime_r( &t, ×truc );
len = strftime( str, sizeof( str ) -1, format, ×truc );

/* Convert struct tm to atomic time.
*/
putenv( "TZ=right/Etc/Zulu");
tzset();
t = mktime( ×truc );
t = t + 10;  /* (10-second bias when UTC began in 1972.)  */

/* Convert; format; and display.
*/
putenv( "TZ=posix/Etc/Zulu");
tzset();
gmtime_r( &t, ×truc );
len = strftime( str, sizeof( str ) -1, format, ×truc );
printf( "%s\n", str );

return( 0 ); }

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

Re: Can a non-admin restrict others from viewing one of their own MVS data sets?

[R.S.]

W dniu 06.11.2020 o 22:43, Frank Swarbrick pisze:

In the Unix world one can use chmod (change mode) on their own files to make it 
so non-superusers cannot view a particular file.  Is there anything similar for 
MVS data sets?


Few points:
1. In MVS world there is no concept of file ownership like in Unix.
2. For TSO users HLQ=userID is special case, but it is rather "ALTER by 
default", which is hard to restrict and it has very little to do with 
authorities management.
2.1 Such datasets are called "his own" despite there is no ownership 
concept.
2.2 Note, special treatment is not for every RACF user, it is for TSO 
users only. So, for example ftp and many other methods are excluded 
(assuming the user has no TSO segment).
3. Every TSO user may or may NOT have rights to manage dataset 
authorities, his own (HLQ=userid) OR OTHER DATASETS.
4. Details depend on your setup. Usually "his own" datasets are in scope 
of the user (userid is the owner of userid.** profile) and that is 
enough to manage access list and UACC.
5. However admin may restrict RACF commands like AD, ALDSD nad PE and 
then user cannot use them to manage rights. There are other methods also.


HTH

--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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