date:20210112

On Tue, 12 Jan 2021 12:34:20 -0800, Charles Mills wrote:

>http://www.longpelaexpertise.com/toolsTOD.php sez 
>
>TOD: (STCK): x" D91B6D3E F6430440 "
>UTC Date and Time (Date + HH:MM:SS): 11-Jan-2021 21:25:22
>UNIX Date/Time: 1610400322
> 
Some consequence of this impelled me to look for CVTLSO:
PH03250: TIME64() FAILS TO RETURN A VALID VALUE WHEN CVTLSO IS NEGATIVE.

Over 11 days of negative leap seconds!?  And I thought I was the compulsive
tester of edge cases.

IBM fixed it

-- gil

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

Re: STCK and epoch time

On Tue, 12 Jan 2021 17:24:52 -0600, Mike Schwab wrote:

>Request for information.
>To convert from STCK format to Unix time, what constants would you
>subtract from the STCK value for the same origin, then divide by what
>constant for the same time unit?  Or divide / subtract if easier.
> 
An example in Regina, tested with Itschak's hex example, giving
the same result as http://www.longpelaexpertise.com/toolsTOD.php

1073 $ cattimeoff
trace R
signal on novalue
numeric digits 20

call putenv "TZ=Universal"

TodOff = date( 'T', '1900-01-01', 'I' )
TimeNow = x2d( 'D91B6D3EF6430440' )
TimeDiv = 409600

UnixTime = TimeNow % TimeDiv + TodOff
1074 $ 
1074 $ regina timeoff
 2 *-* signal on novalue
 3 *-* numeric digits 20
 5 *-* call putenv "TZ=Universal"
 7 *-* TodOff = date( 'T', '1900-01-01', 'I' )
   >=>   "-2208988800"
 8 *-* TimeNow = x2d( 'D91B6D3EF6430440' )
   >=>   "15644217847788536896"
 9 *-* TimeDiv = 409600
   >=>   "409600"
11 *-* UnixTime = TimeNow % TimeDiv + TodOff
   >V>   "15644217847788536896"
   >V>   "409600"
   >V>   "-2208988800"
   >=>   "1610400322"


>> >> -Original Message-
>> >> From: Itschak Mugzach
>> >> Sent: Tuesday, January 12, 2021 10:00 AM
>> >>
>> >> This is the STCK value: D91B6D3EF6430440 (I have it in hex in variable 
>> >> TOD)
>> >> Converted to decimal  : 15644217847788536896
>> >> Actual dat eof run is : Yesterday

-- gil

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

Re: STCK and epoch time

2021-01-12 Thread Mike Schwab

Request for information.
To convert from STCK format to Unix time, what constants would you
subtract from the STCK value for the same origin, then divide by what
constant for the same time unit?  Or divide / subtract if easier.

On Tue, Jan 12, 2021 at 5:09 PM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Tue, 12 Jan 2021 22:53:02 +0200, Itschak Mugzach wrote:.
> >
> >I tested that there already. My rexx returns a different time. I noticed
> >that they only use the first four bytes. The code snip I gave is from the
> >TOD IPCS rexx.
> >
> Regina gives me:
> 502 $ date
> Tue Jan 12 15:59:30 MST 2021
> 503 $  rxx "numeric digits 20; say d2x( (  time( 'T' ) - date( 'T', 
> '1900-01-01', 'I' ) ) %1.048576 )"
> D91C6646
>
> Pasting into  http://www.longpelaexpertise.com/toolsTOD.php sez
> TOD: (STCK): x" D91C6646  "
> UTC Date and Time (Date + HH:MM:SS): 12-Jan-2021 15:59:31
> UNIX Date/Time: 1610467171
>
> What was the output of your:
> >> Say 'STCK HEX VALUE ' c2x(tod)
> >> tod=C2D(tod)
> >> Say 'STCK DEC VALUE ' tod
> ???
>
> >> -Original Message-
> >> From: Itschak Mugzach
> >> Sent: Tuesday, January 12, 2021 10:00 AM
> >>
> >> This is the STCK value: D91B6D3EF6430440 (I have it in hex in variable TOD)
> >> Converted to decimal  : 15644217847788536896
> >> Actual dat eof run is : Yesterday
> >> the code:
> >> /* rexx */
> >> NUMERIC DIGITS 20
> >> RC = SYSCALLS('ON')
> >> ADDRESS SYSCALL  'TIME'
> >> Say 'Current date is' retval
> >>
> >> TOD = 'R _ 6   '
> >> Say 'STCK HEX VALUE ' c2x(tod)
> >> tod=C2D(tod)
> >> Say 'STCK DEC VALUE ' tod
> >> tod=Trunc(tod/4096)
> >> microsec=tod//100
> >> seconds=Trunc(tod/100)
> >> Say 'Seocnds =' Seconds
> >> xxx = 70 * 3600 * 24 * 365
> >> Say 'diff=' xxx
> >> Say Seconds - xxx
> >> SAY '2ND DIF = ' SECONDS - XXX - RETVAL
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: STCK and epoch time

2021-01-12 Thread George Kozakos

You can use IPCS LTOD stck-value to check that your calculation is correct


George Kozakos
z/OS Software Service, Level 2 Supervisor

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

Re: STCK and epoch time

On Tue, 12 Jan 2021 22:53:02 +0200, Itschak Mugzach wrote:.
>
>I tested that there already. My rexx returns a different time. I noticed
>that they only use the first four bytes. The code snip I gave is from the
>TOD IPCS rexx.
> 
Regina gives me:
502 $ date
Tue Jan 12 15:59:30 MST 2021
503 $  rxx "numeric digits 20; say d2x( (  time( 'T' ) - date( 'T', 
'1900-01-01', 'I' ) ) %1.048576 )"
D91C6646

Pasting into  http://www.longpelaexpertise.com/toolsTOD.php sez
TOD: (STCK): x" D91C6646  "
UTC Date and Time (Date + HH:MM:SS): 12-Jan-2021 15:59:31
UNIX Date/Time: 1610467171 

What was the output of your:
>> Say 'STCK HEX VALUE ' c2x(tod)
>> tod=C2D(tod)
>> Say 'STCK DEC VALUE ' tod
???

>> -Original Message-
>> From: Itschak Mugzach
>> Sent: Tuesday, January 12, 2021 10:00 AM
>>
>> This is the STCK value: D91B6D3EF6430440 (I have it in hex in variable TOD)
>> Converted to decimal  : 15644217847788536896
>> Actual dat eof run is : Yesterday
>> the code:
>> /* rexx */
>> NUMERIC DIGITS 20
>> RC = SYSCALLS('ON')
>> ADDRESS SYSCALL  'TIME'
>> Say 'Current date is' retval
>>
>> TOD = 'R _ 6   '
>> Say 'STCK HEX VALUE ' c2x(tod)
>> tod=C2D(tod)
>> Say 'STCK DEC VALUE ' tod
>> tod=Trunc(tod/4096)
>> microsec=tod//100
>> seconds=Trunc(tod/100)
>> Say 'Seocnds =' Seconds
>> xxx = 70 * 3600 * 24 * 365
>> Say 'diff=' xxx
>> Say Seconds - xxx
>> SAY '2ND DIF = ' SECONDS - XXX - RETVAL

-- gil

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

Re: STCK and epoch time

Tx Charles.

I tested that there already. My rexx returns a different time. I noticed
that they only use the first four bytes. The code snip I gave is from the
TOD IPCS rexx.

Anyway, it will be an assembler, but I still wonder why I get wrong
numbers.

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Tue, Jan 12, 2021 at 10:35 PM Charles Mills  wrote:

> http://www.longpelaexpertise.com/toolsTOD.php sez
>
> TOD: (STCK): x" D91B6D3E F6430440 "
> UTC Date and Time (Date + HH:MM:SS): 11-Jan-2021 21:25:22
> UNIX Date/Time: 1610400322
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Itschak Mugzach
> Sent: Tuesday, January 12, 2021 10:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: STCK and epoch time
>
> This is the STCK value: D91B6D3EF6430440 (I have it in hex in variable TOD)
> Converted to decimal  : 15644217847788536896
> Actual dat eof run is : Yesterday
> the code:
> /* rexx */
> NUMERIC DIGITS 20
> RC = SYSCALLS('ON')
> ADDRESS SYSCALL  'TIME'
> Say 'Current date is' retval
>
> TOD = 'R _ 6   '
> Say 'STCK HEX VALUE ' c2x(tod)
> tod=C2D(tod)
> Say 'STCK DEC VALUE ' tod
> tod=Trunc(tod/4096)
> microsec=tod//100
> seconds=Trunc(tod/100)
> Say 'Seocnds =' Seconds
> xxx = 70 * 3600 * 24 * 365
> Say 'diff=' xxx
> Say Seconds - xxx
> SAY '2ND DIF = ' SECONDS - XXX - RETVAL
>
>
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
> and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*
>
>
>
>
>
> On Tue, Jan 12, 2021 at 7:30 PM Seymour J Metz  wrote:
>
> > 409600 will give you units of 10 ms. Is that really what you want?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu]
> > Sent: Tuesday, January 12, 2021 12:19 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: STCK and epoch time
> >
> > Paul,
> >
> > So if I ignore leap seconds, Can I just divide the number by 409600 and
> > subtruct 1.1.1970-1.1.1900?
> >
> > *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> > Platform* *|* *Information Security Continuous Monitoring for Z/OS,
> zLinux
> > and IBM I **|  *
> >
> > *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404
> **|*
> > *Skype**: ItschakMugzach **|* *Web**:
> >
> http://secure-web.cisco.com/1L852dJoPXmqKt9ESjpybzsrC6kwCrmelHuY9TPZ6FI1UhWGxaTPRmDMPbv2-J-TuNYR19i6Etk0RoqzBfZLQdQtLviWwwBp8h9N4dDQB8A3EYjz9KKOqUnYbzA7gaNnoYO2QfsLXZEtnUlTJRXD0XDjWu63swogFiPD2kMAZ3JuBQaB5QMgq6ez7eOinZRRxlKKgcL_TnDcJbNi4LeM2hMtheU40OhWYMuPWP1WVeMCRcujHG9YP8bNig6miEen_MPWOkmLAWIUE_y1DiNulpfiKwSNgfGdpd4e1JXrM8nF-uSVh4vBU9A6-GSINEcDfR1D_BjfuPVtcl86DWYoDhc5NnvCbr2SlwtU_sZGrTobUpcBKotsb_8is79X7TY6ISxy2KRLlqDdGOkhH0qHDMlQjNd0ViYcltcvCTHTEJWaRSHpwx1hRx5cjiLjiqAHA/http%3A%2F%2Fwww.Securiteam.co.il
> > **|*
> >
> >
> >
> >
> >
> > On Tue, Jan 12, 2021 at 7:09 PM Paul Gilmartin <
> > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > On Tue, 12 Jan 2021 16:30:52 +, Seymour J Metz wrote:
> > >
> > > >The TOD clock is just a counter; what you get out of it depends on
> what
> > > you put into it. There is a convention in PoOps, but if you want the
> > > correct time and date it is much easier to use system services than to
> do
> > > the adjustments yourself.
> > > >
> > > >MVS does not use the same epoch as Eunix. Unix System Services will
> > > adjust the epoch properly.
> > > >
> > > UNIX counts seconds, excluding leap seconds, starting
> 1970-01-01t00:00:00
> > > MVS  counts microseconds/4096, including leap seconds, starting
> > > 1900-01-01t00:00:10.
> > >
> > > >
> > > >From: ITschak Mugzach
> > > >Sent: Tuesday, January 12, 2021 10:36 AM
> > > >
> > > >How exactly STCK (not STCKE) stores the time? I took the value (8
> bytes)
> > > >and converted it to decimal 10 characters. I expect it to be the same
> as
> > > >the EPOCH time returned by USS time call. However the returned value
> is
> > > July
> > > >29, 2019 (have a time from yesterday). I know there is a macro to do
> it,
> > > >but I want to keep the correct epoch time.
> > > >
> > > I'm mystified (unless it's a coding error) by the 6-month error.  Show
> > > your code.
> > >
> > > -- gil
> > >
> > >

Re: STCK and epoch time

2021-01-12 Thread Charles Mills

http://www.longpelaexpertise.com/toolsTOD.php sez 

TOD: (STCK): x" D91B6D3E F6430440 "
UTC Date and Time (Date + HH:MM:SS): 11-Jan-2021 21:25:22
UNIX Date/Time: 1610400322

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: Tuesday, January 12, 2021 10:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STCK and epoch time

This is the STCK value: D91B6D3EF6430440 (I have it in hex in variable TOD)
Converted to decimal  : 15644217847788536896
Actual dat eof run is : Yesterday
the code:
/* rexx */
NUMERIC DIGITS 20
RC = SYSCALLS('ON')
ADDRESS SYSCALL  'TIME'
Say 'Current date is' retval

TOD = 'R _ 6   '
Say 'STCK HEX VALUE ' c2x(tod)
tod=C2D(tod)
Say 'STCK DEC VALUE ' tod
tod=Trunc(tod/4096)
microsec=tod//100
seconds=Trunc(tod/100)
Say 'Seocnds =' Seconds
xxx = 70 * 3600 * 24 * 365
Say 'diff=' xxx
Say Seconds - xxx
SAY '2ND DIF = ' SECONDS - XXX - RETVAL



*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Tue, Jan 12, 2021 at 7:30 PM Seymour J Metz  wrote:

> 409600 will give you units of 10 ms. Is that really what you want?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu]
> Sent: Tuesday, January 12, 2021 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: STCK and epoch time
>
> Paul,
>
> So if I ignore leap seconds, Can I just divide the number by 409600 and
> subtruct 1.1.1970-1.1.1900?
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
> and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**:
> http://secure-web.cisco.com/1L852dJoPXmqKt9ESjpybzsrC6kwCrmelHuY9TPZ6FI1UhWGxaTPRmDMPbv2-J-TuNYR19i6Etk0RoqzBfZLQdQtLviWwwBp8h9N4dDQB8A3EYjz9KKOqUnYbzA7gaNnoYO2QfsLXZEtnUlTJRXD0XDjWu63swogFiPD2kMAZ3JuBQaB5QMgq6ez7eOinZRRxlKKgcL_TnDcJbNi4LeM2hMtheU40OhWYMuPWP1WVeMCRcujHG9YP8bNig6miEen_MPWOkmLAWIUE_y1DiNulpfiKwSNgfGdpd4e1JXrM8nF-uSVh4vBU9A6-GSINEcDfR1D_BjfuPVtcl86DWYoDhc5NnvCbr2SlwtU_sZGrTobUpcBKotsb_8is79X7TY6ISxy2KRLlqDdGOkhH0qHDMlQjNd0ViYcltcvCTHTEJWaRSHpwx1hRx5cjiLjiqAHA/http%3A%2F%2Fwww.Securiteam.co.il
> **|*
>
>
>
>
>
> On Tue, Jan 12, 2021 at 7:09 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Tue, 12 Jan 2021 16:30:52 +, Seymour J Metz wrote:
> >
> > >The TOD clock is just a counter; what you get out of it depends on what
> > you put into it. There is a convention in PoOps, but if you want the
> > correct time and date it is much easier to use system services than to do
> > the adjustments yourself.
> > >
> > >MVS does not use the same epoch as Eunix. Unix System Services will
> > adjust the epoch properly.
> > >
> > UNIX counts seconds, excluding leap seconds, starting 1970-01-01t00:00:00
> > MVS  counts microseconds/4096, including leap seconds, starting
> > 1900-01-01t00:00:10.
> >
> > >
> > >From: ITschak Mugzach
> > >Sent: Tuesday, January 12, 2021 10:36 AM
> > >
> > >How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
> > >and converted it to decimal 10 characters. I expect it to be the same as
> > >the EPOCH time returned by USS time call. However the returned value is
> > July
> > >29, 2019 (have a time from yesterday). I know there is a macro to do it,
> > >but I want to keep the correct epoch time.
> > >
> > I'm mystified (unless it's a coding error) by the 6-month error.  Show
> > your code.
> >
> > -- gil
> >
> > --
> > 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
>
> --
> 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: STCK and epoch time

Nit: the code would be more readable with s hexadecimal constant for TOD.

70 * 3600 * 24 * 365 doesn't account for leap years.




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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, January 12, 2021 1:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STCK and epoch time

This is the STCK value: D91B6D3EF6430440 (I have it in hex in variable TOD)
Converted to decimal  : 15644217847788536896
Actual dat eof run is : Yesterday
the code:
/* rexx */
NUMERIC DIGITS 20
RC = SYSCALLS('ON')
ADDRESS SYSCALL  'TIME'
Say 'Current date is' retval

TOD = 'R _ 6   '
Say 'STCK HEX VALUE ' c2x(tod)
tod=C2D(tod)
Say 'STCK DEC VALUE ' tod
tod=Trunc(tod/4096)
microsec=tod//100
seconds=Trunc(tod/100)
Say 'Seocnds =' Seconds
xxx = 70 * 3600 * 24 * 365
Say 'diff=' xxx
Say Seconds - xxx
SAY '2ND DIF = ' SECONDS - XXX - RETVAL



*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: 
http://secure-web.cisco.com/1ZnbiZNcLTWRGelbKd-Vmb2tmDrGsG6dZmkbDcfS4vllmm7mdtkgPkvyxkyUk_KEBvVwY3mkFdR7J7V52GZIcpGGoVUw2SP2PG_0G80wSwli94THWvq8n1F2vTzNvrbbUghDEkPwbD34bST_Rh0Uhrp3obW9kRDaUkTJS4x3qYVt9DhrFTA_E-v7yhxc_Ahp0Fnk2GgfOFTmjrPaN4dqu-UZQdMncGRqRp4fcHAaeH-9UbAUnjQdx0Lpo2frp1MqxLYs58Qj2KcpQIj7SBqC_wp6Ww-J-8SWEvWs56Hmh2VV0boArCa681GHzEyTtoZh0zM_O8BJIXzOumqIAzYbCW2nW-7uc8CjomZHeyRsiKZ8OR6wltyxtUiwnpDPUiNRt59m8SE4Qyvst9SHZfTIGcF1GFjL0ehOTdO_JiISK0VFa6jVUbMNRZlintxoAqiLt/http%3A%2F%2Fwww.Securiteam.co.il
  **|*





On Tue, Jan 12, 2021 at 7:30 PM Seymour J Metz  wrote:

> 409600 will give you units of 10 ms. Is that really what you want?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu]
> Sent: Tuesday, January 12, 2021 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: STCK and epoch time
>
> Paul,
>
> So if I ignore leap seconds, Can I just divide the number by 409600 and
> subtruct 1.1.1970-1.1.1900?
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
> and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**:
> http://secure-web.cisco.com/1L852dJoPXmqKt9ESjpybzsrC6kwCrmelHuY9TPZ6FI1UhWGxaTPRmDMPbv2-J-TuNYR19i6Etk0RoqzBfZLQdQtLviWwwBp8h9N4dDQB8A3EYjz9KKOqUnYbzA7gaNnoYO2QfsLXZEtnUlTJRXD0XDjWu63swogFiPD2kMAZ3JuBQaB5QMgq6ez7eOinZRRxlKKgcL_TnDcJbNi4LeM2hMtheU40OhWYMuPWP1WVeMCRcujHG9YP8bNig6miEen_MPWOkmLAWIUE_y1DiNulpfiKwSNgfGdpd4e1JXrM8nF-uSVh4vBU9A6-GSINEcDfR1D_BjfuPVtcl86DWYoDhc5NnvCbr2SlwtU_sZGrTobUpcBKotsb_8is79X7TY6ISxy2KRLlqDdGOkhH0qHDMlQjNd0ViYcltcvCTHTEJWaRSHpwx1hRx5cjiLjiqAHA/http%3A%2F%2Fwww.Securiteam.co.il
> **|*
>
>
>
>
>
> On Tue, Jan 12, 2021 at 7:09 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Tue, 12 Jan 2021 16:30:52 +, Seymour J Metz wrote:
> >
> > >The TOD clock is just a counter; what you get out of it depends on what
> > you put into it. There is a convention in PoOps, but if you want the
> > correct time and date it is much easier to use system services than to do
> > the adjustments yourself.
> > >
> > >MVS does not use the same epoch as Eunix. Unix System Services will
> > adjust the epoch properly.
> > >
> > UNIX counts seconds, excluding leap seconds, starting 1970-01-01t00:00:00
> > MVS  counts microseconds/4096, including leap seconds, starting
> > 1900-01-01t00:00:10.
> >
> > >
> > >From: ITschak Mugzach
> > >Sent: Tuesday, January 12, 2021 10:36 AM
> > >
> > >How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
> > >and converted it to decimal 10 characters. I expect it to be the same as
> > >the EPOCH time returned by USS time call. However the returned value is
> > July
> > >29, 2019 (have a time from yesterday). I know there is a macro to do it,
> > >but I want to keep the correct epoch time.
> > >
> > I'm mystified (unless it's a coding error) by the 6-month error.  Show
> > your code.
> >
> > -- gil
> >
> > --
> > 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

Re: STCK and epoch time

On Tue, 12 Jan 2021 19:19:01 +0200, Itschak Mugzach wrote:
>
>So if I ignore leap seconds, Can I just divide the number by 409600 and
>subtruct 1.1.1970-1.1.1900?
> 
Here's some code I wrote.  The input data are the list of leap seconds
in PoOp.

Restriction:  Presumes a system such as Linux providing the "right"
hierarchy in /usr/share/zoneinfo.

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
/*bin/true;exec rexx "$0" "$@";exit # REXX  Magic!
   Doc: Verify the leap second list in Principles of Operation.
*/

ABCD = ,
7D91 048B CA00  ,  /* Circa Jan 1970 -- Must be first!  */
,  /* From PrincOps:   */ 
8000    ,  /* May 1971 -- TOD Rollover.   */
8126 D60E 4600  ,  /* Dec 1971 -- UTC begins. */
820B A981 1E24  ,  /* Jun 1972 -- first leap second.  */
82F3 00AE E248  84BD E971 146C  8688 D233 4690  8853 BAF5 78B4  
8A1F E595 20D8  8BEA CE57 52FC  8DB5 B719 8520  8F80 9FDB B744  
9230 5C0F CD68  93FB 44D1 FF8C  95C6 2D94 31B0  995D 40F5 17D4  
9DDA 69A5 57F8  A171 7D06 3E1C  A33C 65C8 7040  ,
A5EC 21FC 8664  A7B7 0ABE B888  A981 F380 EAAC  AC34 336F ECD0  
AEE3 EFA4 02F4  B196 2F93 0518  BE25 1097 973C  C387 0CB9 BB60  
C9CC 9A70 4D84  CF2D 54B4 FBA8  ,
D1E0 D681 73CC , /* 2016-12-31 23:59:60  */
d7c7 8993 9481 99a3, /* EBCDIC "PGilmart"*/
D7D9 E4C9 E3C5 D940, /* EBCDIC "PRUITER" */
F7A3 048A D5DC   /* The End of Time! */

signal on novalue
numeric digits 25
say ABCD
say
parse value ABCD with A B C D .
call Adjust
TOD1970 =  TOD
say '/*' TOD TOD1970 '*/'
say d2x( ( x2d( '7FFF' ) + TOD1970 + 1 ) * 4096 * 100 )
say d2x( ( 1483228827+ TOD1970 ) * 4096 * 100 )
say

RC = W( '#include ', 1 )  /* Start at line 1  */
RC = W( '#include ' )
RC = W( '#include ' )
RC = W( 'static const time_t leaps[] = {' )

do Lctr = 0 while ABCD<>''
parse value ABCD with A B C D ABCD
call Adjust
RC = W( '/* TOD:' A B C D ,
'UNIX: */' right( TOD - TOD1970, 10 )copies( ',', ABCD>>'' ),
'/*' Frac '*/' );  end Lctr
RC = W( '};' )
RC = W( '' )

RC = W( 'int ShowIt( const time_t *pT ) {' )
RC = W( 'char s[100];' )
RC = W( '' )
RC = W( 'strftime( s, 99, "%c", localtime( pT ) );' )
RC = W( 'printf( "Time =%11ld  for: %s\n", (long)*pT, s );' )
RC = W( 'return 0; }' )

RC = W( '' )
RC = W( 'int main( void ) {' )
RC = W( 'const time_t *I;' )
RC = W( '  time_t TT;' )
RC = W( '' )

RC = W( 'system( "uname -a" );' )
RC = W( 'putenv( "TZ=right/Universal" );')
RC = W( 'putenv( "TZ=right/America/Denver" );')
RC = W( 'putenv( "TZ=right/America/Los_Angeles" );')
RC = W( 'printf( "For Timezone: %s\n", getenv( "TZ" ) );' )
RC = W( 'tzset(); for ( I = leaps; I

Re: STCK and epoch time

This is the STCK value: D91B6D3EF6430440 (I have it in hex in variable TOD)
Converted to decimal  : 15644217847788536896
Actual dat eof run is : Yesterday
the code:
/* rexx */
NUMERIC DIGITS 20
RC = SYSCALLS('ON')
ADDRESS SYSCALL  'TIME'
Say 'Current date is' retval

TOD = 'R _ 6   '
Say 'STCK HEX VALUE ' c2x(tod)
tod=C2D(tod)
Say 'STCK DEC VALUE ' tod
tod=Trunc(tod/4096)
microsec=tod//100
seconds=Trunc(tod/100)
Say 'Seocnds =' Seconds
xxx = 70 * 3600 * 24 * 365
Say 'diff=' xxx
Say Seconds - xxx
SAY '2ND DIF = ' SECONDS - XXX - RETVAL



*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Tue, Jan 12, 2021 at 7:30 PM Seymour J Metz  wrote:

> 409600 will give you units of 10 ms. Is that really what you want?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu]
> Sent: Tuesday, January 12, 2021 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: STCK and epoch time
>
> Paul,
>
> So if I ignore leap seconds, Can I just divide the number by 409600 and
> subtruct 1.1.1970-1.1.1900?
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
> and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**:
> http://secure-web.cisco.com/1L852dJoPXmqKt9ESjpybzsrC6kwCrmelHuY9TPZ6FI1UhWGxaTPRmDMPbv2-J-TuNYR19i6Etk0RoqzBfZLQdQtLviWwwBp8h9N4dDQB8A3EYjz9KKOqUnYbzA7gaNnoYO2QfsLXZEtnUlTJRXD0XDjWu63swogFiPD2kMAZ3JuBQaB5QMgq6ez7eOinZRRxlKKgcL_TnDcJbNi4LeM2hMtheU40OhWYMuPWP1WVeMCRcujHG9YP8bNig6miEen_MPWOkmLAWIUE_y1DiNulpfiKwSNgfGdpd4e1JXrM8nF-uSVh4vBU9A6-GSINEcDfR1D_BjfuPVtcl86DWYoDhc5NnvCbr2SlwtU_sZGrTobUpcBKotsb_8is79X7TY6ISxy2KRLlqDdGOkhH0qHDMlQjNd0ViYcltcvCTHTEJWaRSHpwx1hRx5cjiLjiqAHA/http%3A%2F%2Fwww.Securiteam.co.il
> **|*
>
>
>
>
>
> On Tue, Jan 12, 2021 at 7:09 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Tue, 12 Jan 2021 16:30:52 +, Seymour J Metz wrote:
> >
> > >The TOD clock is just a counter; what you get out of it depends on what
> > you put into it. There is a convention in PoOps, but if you want the
> > correct time and date it is much easier to use system services than to do
> > the adjustments yourself.
> > >
> > >MVS does not use the same epoch as Eunix. Unix System Services will
> > adjust the epoch properly.
> > >
> > UNIX counts seconds, excluding leap seconds, starting 1970-01-01t00:00:00
> > MVS  counts microseconds/4096, including leap seconds, starting
> > 1900-01-01t00:00:10.
> >
> > >
> > >From: ITschak Mugzach
> > >Sent: Tuesday, January 12, 2021 10:36 AM
> > >
> > >How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
> > >and converted it to decimal 10 characters. I expect it to be the same as
> > >the EPOCH time returned by USS time call. However the returned value is
> > July
> > >29, 2019 (have a time from yesterday). I know there is a macro to do it,
> > >but I want to keep the correct epoch time.
> > >
> > I'm mystified (unless it's a coding error) by the 6-month error.  Show
> > your code.
> >
> > -- gil
> >
> > --
> > 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
>
> --
> 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: Request for help with removing sequence numbers from PDS members

On Tue, 12 Jan 2021 13:46:07 -0400, Clark Morris wrote:
>>
>>And a general note: when using ISPF edit to remove sequence numbers from a 
>>(large) number of (large) members, you might need to cater for the fact that 
>>a 
>>PDS might need to be compressed at some stage in the middle of your 
>>processing!
>
>Use of update in place should work if all that is being done is
>sequence number stripping since the size of the member does not
>change.
> 
Does ISPF Edit update in place, even optionally?  I think PDS usually
creates a new member.

-- gil

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

Re: Request for help with removing sequence numbers from PDS members

2021-01-12 Thread Clark Morris

[Default] On 12 Jan 2021 08:42:24 -0800, in bit.listserv.ibm-main
robert.ah.pr...@gmail.com (Robert Prins) wrote:

>>snip
>
>And a general note: when using ISPF edit to remove sequence numbers from a 
>(large) number of (large) members, you might need to cater for the fact that a 
>PDS might need to be compressed at some stage in the middle of your processing!

Use of update in place should work if all that is being done is
sequence number stripping since the size of the member does not
change.

Clark Morris
>
>Robert
>
>PS: Please people, strip off all the unnecessary garbage from your replies...

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

Re: Code to verify LOGON password

2021-01-12 Thread R.S.


W dniu 12.01.2021 o 06:42, Timothy Sipples pisze:

Radoslaw Skorupka wrote:

That's what we call brute force attack.
There is no way to protect against it ...or maybe there are some
things to help.
1. Do not give your RACF db to hackers. Never.
2. Enforce periodic password change.
3. Use KDFAES.
4. Use passphrases.

Here are some more examples for your list:

5. Don't grant overly generous permissions. Revoke permissions faithfully
and promptly when required.

6. IBM Z Multi-Factor Authentication.

7. Use excellent data access management and Security Information and Event
Management (SIEM) solutions.

8. "Stay sharp." Invest in talented security professionals, including in
their ongoing skills development. Hire other talented security people to
conduct periodic audits.

9. Stay at least reasonably current with software releases, including z/OS
releases. Have and follow a reasonable preventive maintenance plan,
including for security and integrity updates.

10. Use strong, properly implemented network encryption so that
credentials aren't flying across any LAN or WAN in cleartext. z/OS
Encryption Readiness Technology (zERT), a standard feature included with
the base z/OS operating system starting with z/OS 2.3, can help identify
gaps.


Good points. IMHO the most important is 8. Of course it is not about 
RACF, it is about people. However no technology would help if the only 
effort was to buy it, but no necessaruly well implemented. Uneducated, 
lazy people, overloaded staff, lack of interest from management lead to 
mistakes, even serious neglects.


--
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. Prosta 18, 00-850 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.

Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z 
prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które 
wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną 
działalnością bankową.
Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w 
Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo


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. Prosta 18, 00-850 
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.

We are the controller of your personal data, which you provided in connection 
with correspondence with us. We process your data for purposes resulting from 
the subject of correspondence, including those related to the banking services.
More information on how we protect and process personal data can be found in 
the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo.

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

Re: Code to verify LOGON password

2021-01-12 Thread R.S.

W dniu 11.01.2021 o 17:44, Charles Mills pisze:

https://en.wikipedia.org/wiki/John_the_Ripper

There is a downloadable plugin for RACF -- old RACF hashing only, I *think*.

@R.S. writes

1. Do not give your RACF db to hackers. Never.

No one "gives" their RACF DB to anyone (I would hope). The problem -- and everyone
reading this who is not sure about their RACF DB should go check right now -- is UACC or USERID(*)
READ access to the RACF DB *or its backup*. If I can download your RACF DB and attack it
off-platform I can defeat any "revoke the userid after 'n' tries" that you have in place.

Charles,
You missed the fine print between the lines : IRONY ;-)

Of course matter of backup copies, user revoking, etc. was discussed ad
infinitum. Of course it is important, but a little bit not closely
related to discussed details in this thread.

Regarding the ripper - There is password cracker for z/OS. You need APF
update, dictionaries (or program generating passwords) and cpu cycles.

APF update? Same configuration mistake as READ for RACF db.

Despite of cracker implementation, KDFAES plus passphrases plus
(included in passphrases) rules for password complexity make cracking
much less efficient.

--
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. Prosta 18, 00-850 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.

Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z
prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które
wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną
działalnością bankową.
Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w
Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo

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. Prosta 18, 00-850
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.

We are the controller of your personal data, which you provided in connection
with correspondence with us. We process your data for purposes resulting from
the subject of correspondence, including those related to the banking services.
More information on how we protect and process personal data can be found in
the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo.

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

Re: STCK and epoch time

409600 will give you units of 10 ms. Is that really what you want?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, January 12, 2021 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STCK and epoch time

Paul,

So if I ignore leap seconds, Can I just divide the number by 409600 and
subtruct 1.1.1970-1.1.1900?

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: 
http://secure-web.cisco.com/1L852dJoPXmqKt9ESjpybzsrC6kwCrmelHuY9TPZ6FI1UhWGxaTPRmDMPbv2-J-TuNYR19i6Etk0RoqzBfZLQdQtLviWwwBp8h9N4dDQB8A3EYjz9KKOqUnYbzA7gaNnoYO2QfsLXZEtnUlTJRXD0XDjWu63swogFiPD2kMAZ3JuBQaB5QMgq6ez7eOinZRRxlKKgcL_TnDcJbNi4LeM2hMtheU40OhWYMuPWP1WVeMCRcujHG9YP8bNig6miEen_MPWOkmLAWIUE_y1DiNulpfiKwSNgfGdpd4e1JXrM8nF-uSVh4vBU9A6-GSINEcDfR1D_BjfuPVtcl86DWYoDhc5NnvCbr2SlwtU_sZGrTobUpcBKotsb_8is79X7TY6ISxy2KRLlqDdGOkhH0qHDMlQjNd0ViYcltcvCTHTEJWaRSHpwx1hRx5cjiLjiqAHA/http%3A%2F%2Fwww.Securiteam.co.il
  **|*





On Tue, Jan 12, 2021 at 7:09 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 12 Jan 2021 16:30:52 +, Seymour J Metz wrote:
>
> >The TOD clock is just a counter; what you get out of it depends on what
> you put into it. There is a convention in PoOps, but if you want the
> correct time and date it is much easier to use system services than to do
> the adjustments yourself.
> >
> >MVS does not use the same epoch as Eunix. Unix System Services will
> adjust the epoch properly.
> >
> UNIX counts seconds, excluding leap seconds, starting 1970-01-01t00:00:00
> MVS  counts microseconds/4096, including leap seconds, starting
> 1900-01-01t00:00:10.
>
> >
> >From: ITschak Mugzach
> >Sent: Tuesday, January 12, 2021 10:36 AM
> >
> >How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
> >and converted it to decimal 10 characters. I expect it to be the same as
> >the EPOCH time returned by USS time call. However the returned value is
> July
> >29, 2019 (have a time from yesterday). I know there is a macro to do it,
> >but I want to keep the correct epoch time.
> >
> I'm mystified (unless it's a coding error) by the 6-month error.  Show
> your code.
>
> -- gil
>
> --
> 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

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

Re: STCK and epoch time

On Tue, 12 Jan 2021 19:19:01 +0200, Itschak Mugzach wrote:
>
>So if I ignore leap seconds, Can I just divide the number by 409600 and
>
409600?

>subtruct 1.1.1970-1.1.1900?
>
Are you doing it the hard way?  Borrowing from seconds to minutes,
minutes to hours, hours to days, days to months (which aren't of
uniform lengths), months to years (which aren't of uniform lengths
in some calendars) ...?

Show sample data and your code.

-- gil

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

Re: STCK and epoch time

True, but the difference may be within 24 hours. I get 21 days late

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Tue, Jan 12, 2021 at 7:23 PM Charles Mills  wrote:

> As @Shmuel says, it depends on how the clock is set.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Itschak Mugzach
> Sent: Tuesday, January 12, 2021 9:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: STCK and epoch time
>
> Paul,
>
> So if I ignore leap seconds, Can I just divide the number by 409600 and
> subtruct 1.1.1970-1.1.1900?
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
> and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*
>
>
>
>
>
> On Tue, Jan 12, 2021 at 7:09 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Tue, 12 Jan 2021 16:30:52 +, Seymour J Metz wrote:
> >
> > >The TOD clock is just a counter; what you get out of it depends on what
> > you put into it. There is a convention in PoOps, but if you want the
> > correct time and date it is much easier to use system services than to do
> > the adjustments yourself.
> > >
> > >MVS does not use the same epoch as Eunix. Unix System Services will
> > adjust the epoch properly.
> > >
> > UNIX counts seconds, excluding leap seconds, starting 1970-01-01t00:00:00
> > MVS  counts microseconds/4096, including leap seconds, starting
> > 1900-01-01t00:00:10.
> >
> > >
> > >From: ITschak Mugzach
> > >Sent: Tuesday, January 12, 2021 10:36 AM
> > >
> > >How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
> > >and converted it to decimal 10 characters. I expect it to be the same as
> > >the EPOCH time returned by USS time call. However the returned value is
> > July
> > >29, 2019 (have a time from yesterday). I know there is a macro to do it,
> > >but I want to keep the correct epoch time.
> > >
> > I'm mystified (unless it's a coding error) by the 6-month error.  Show
> > your code.
> >
> > -- gil
> >
> > --
> > 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
>
> --
> 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: Request for help with removing sequence numbers from PDS members

In either case, address ISPEXEC at the beginning wouldn't hurt.

I noticed the missing macro after I posted it.

This is Q code for a single member; if I had to do it for production I'd make 
it more general.

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

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, January 12, 2021 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for help with removing sequence numbers from PDS members

On Tue, 12 Jan 2021 16:20:17 +, Seymour J Metz wrote:

>ISREDIT is only valid for an edit macro. You need on script to invoke EDIT and 
>a second script running as an IMACRO for the edit. If they are in SYSPROC then 
>you need to start the first comment with REXX.
>
Is the initial command environment ISPEXEC?  My experience has been it's TSO.

>   /* Outer script */
>  parse upper arg dataset
>  "CONTROL ERRORS RETURN"
>  'EDIT DATASET('dataset') MACRO(STRIPED')'
>  /* Tailor above to suit your needs */
>
>  /* Inner script */
>  'CONTROL ERRORS RETURN'
> ADDRESS ISREDIT
>  'UNNUMBER'
>
The first command must be MACRO.

>  'SAVE'
> 'END'

These might be combined in a single EXEC (untested):

   /* Rexx */
  address ISPEXEC  /* at least for documentation.  */
  "CONTROL ERRORS RETURN"
  call INITIAL
  parse upper arg dataset
  /* Logic to enumerate members?  */
  'EDIT DATASET('dataset') MACRO(STRIPED')'  /* Unbalanced "'"? )
  /* Tailor above to suit your needs */
  EXIT

  /* Initial Macro script */
INITIAL:
 ADDRESS ISREDIT
 'MACRO'
 IF RC<>0 RETURN
  /* Is NUMBER needed before UNNUMBER if not all members are numbered?  */
  'UNNUMBER'
  'SAVE'
 'END'
 EXIT

-- gil

--
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: STCK and epoch time

2021-01-12 Thread Charles Mills

As @Shmuel says, it depends on how the clock is set. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: Tuesday, January 12, 2021 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STCK and epoch time

Paul,

So if I ignore leap seconds, Can I just divide the number by 409600 and
subtruct 1.1.1970-1.1.1900?

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Tue, Jan 12, 2021 at 7:09 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 12 Jan 2021 16:30:52 +, Seymour J Metz wrote:
>
> >The TOD clock is just a counter; what you get out of it depends on what
> you put into it. There is a convention in PoOps, but if you want the
> correct time and date it is much easier to use system services than to do
> the adjustments yourself.
> >
> >MVS does not use the same epoch as Eunix. Unix System Services will
> adjust the epoch properly.
> >
> UNIX counts seconds, excluding leap seconds, starting 1970-01-01t00:00:00
> MVS  counts microseconds/4096, including leap seconds, starting
> 1900-01-01t00:00:10.
>
> >
> >From: ITschak Mugzach
> >Sent: Tuesday, January 12, 2021 10:36 AM
> >
> >How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
> >and converted it to decimal 10 characters. I expect it to be the same as
> >the EPOCH time returned by USS time call. However the returned value is
> July
> >29, 2019 (have a time from yesterday). I know there is a macro to do it,
> >but I want to keep the correct epoch time.
> >
> I'm mystified (unless it's a coding error) by the 6-month error.  Show
> your code.
>
> -- gil
>
> --
> 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

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

Re: STCK and epoch time

Paul,

So if I ignore leap seconds, Can I just divide the number by 409600 and
subtruct 1.1.1970-1.1.1900?

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Tue, Jan 12, 2021 at 7:09 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 12 Jan 2021 16:30:52 +, Seymour J Metz wrote:
>
> >The TOD clock is just a counter; what you get out of it depends on what
> you put into it. There is a convention in PoOps, but if you want the
> correct time and date it is much easier to use system services than to do
> the adjustments yourself.
> >
> >MVS does not use the same epoch as Eunix. Unix System Services will
> adjust the epoch properly.
> >
> UNIX counts seconds, excluding leap seconds, starting 1970-01-01t00:00:00
> MVS  counts microseconds/4096, including leap seconds, starting
> 1900-01-01t00:00:10.
>
> >
> >From: ITschak Mugzach
> >Sent: Tuesday, January 12, 2021 10:36 AM
> >
> >How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
> >and converted it to decimal 10 characters. I expect it to be the same as
> >the EPOCH time returned by USS time call. However the returned value is
> July
> >29, 2019 (have a time from yesterday). I know there is a macro to do it,
> >but I want to keep the correct epoch time.
> >
> I'm mystified (unless it's a coding error) by the 6-month error.  Show
> your code.
>
> -- gil
>
> --
> 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: Request for help with removing sequence numbers from PDS members

On Tue, 12 Jan 2021 18:41:54 +, Robert Prins wrote:
>
>...  the advantage of keeping things together, like the PL/I RFE I've
>very recently entered,
>.
>Feel free to vote for it, although I already expect it to be accepted.
> 
I don't speak PL/I, but wouldn't it be even better to declare an array of
structures, each having two fields, ISO and INFO.  Initialization could then
keep the initial values even closer together.

>And a general note: when using ISPF edit to remove sequence numbers from a
>(large) number of (large) members, you might need to cater for the fact that a
>PDS might need to be compressed at some stage in the middle of your processing!
>
Use PDSE.

>PS: Please people, strip off all the unnecessary garbage from your replies...
>
PS: Please, people, set your clock and timezone consistently: 
TZ=Europe/Vilnius, not GMT.

-- gil

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

Re: STCK and epoch time

On Tue, 12 Jan 2021 16:30:52 +, Seymour J Metz wrote:

>The TOD clock is just a counter; what you get out of it depends on what you 
>put into it. There is a convention in PoOps, but if you want the correct time 
>and date it is much easier to use system services than to do the adjustments 
>yourself.
>
>MVS does not use the same epoch as Eunix. Unix System Services will adjust the 
>epoch properly.
> 
UNIX counts seconds, excluding leap seconds, starting 1970-01-01t00:00:00
MVS  counts microseconds/4096, including leap seconds, starting 
1900-01-01t00:00:10.

>
>From: ITschak Mugzach
>Sent: Tuesday, January 12, 2021 10:36 AM
>
>How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
>and converted it to decimal 10 characters. I expect it to be the same as
>the EPOCH time returned by USS time call. However the returned value is July
>29, 2019 (have a time from yesterday). I know there is a macro to do it,
>but I want to keep the correct epoch time.
>
I'm mystified (unless it's a coding error) by the 6-month error.  Show your 
code.

-- gil

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

Re: Request for help with removing sequence numbers from PDS members

On Tue, 12 Jan 2021 16:20:17 +, Seymour J Metz wrote:

>ISREDIT is only valid for an edit macro. You need on script to invoke EDIT and 
>a second script running as an IMACRO for the edit. If they are in SYSPROC then 
>you need to start the first comment with REXX.
>
Is the initial command environment ISPEXEC?  My experience has been it's TSO.

>   /* Outer script */
>  parse upper arg dataset
>  "CONTROL ERRORS RETURN"
>  'EDIT DATASET('dataset') MACRO(STRIPED')'
>  /* Tailor above to suit your needs */
>
>  /* Inner script */
>  'CONTROL ERRORS RETURN'
> ADDRESS ISREDIT
>  'UNNUMBER'
>
The first command must be MACRO.

>  'SAVE'
> 'END'

These might be combined in a single EXEC (untested):

   /* Rexx */
  address ISPEXEC  /* at least for documentation.  */
  "CONTROL ERRORS RETURN"
  call INITIAL
  parse upper arg dataset
  /* Logic to enumerate members?  */
  'EDIT DATASET('dataset') MACRO(STRIPED')'  /* Unbalanced "'"? )
  /* Tailor above to suit your needs */
  EXIT

  /* Initial Macro script */
INITIAL:
 ADDRESS ISREDIT
 'MACRO'
 IF RC<>0 RETURN
  /* Is NUMBER needed before UNNUMBER if not all members are numbered?  */
  'UNNUMBER'
  'SAVE'
 'END'
 EXIT

-- gil

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

Re: Request for help with removing sequence numbers from PDS members

Whilst this basically true, you can have the same REXX invoked as a macro
using the technique I used.

Wrapping ISREDIT MACRO in CONTROL ERRORS allows you to get the RC20 if it's
not running under Edit (and obviously any other major reasons) , this
enabling you to determine which path through the program you need to take.

If you call other edit macros from within an edit macro when both have
ISREDIT MACRO coded, you also get the RC20. Again wrapping that in CONTROL
ERRORS allows you to use a macro as a user command as well as calling it
from other macros.

Andy

On Tue, 12 Jan 2021, 16:20 Seymour J Metz,  wrote:

> ISREDIT is only valid for an edit macro. You need on script to invoke EDIT
> and a second script running as an IMACRO for the edit. If they are in
> SYSPROC then you need to start the first comment with REXX.
>
>/* Outer script */
>   parse upper arg dataset
>   "CONTROL ERRORS RETURN"
>   'EDIT DATASET('dataset') MACRO(STRIPED')'
>   /* Tailor above to suit your needs */
>
>   /* Inner script */
>   'CONTROL ERRORS RETURN'
>  ADDRESS ISREDIT
>   'UNNUMBER'
>   'SAVE'
>  'END'
>
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Sean Gleann [sean.gle...@gmail.com]
> Sent: Tuesday, January 12, 2021 5:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with removing sequence numbers from PDS
> members
>
> I've been told by Powers That Be that this line of development is redundant
> & that a different solution has been independently developed elsewhere in
> the company. (*sigh* - 'twas ever thus)
> But I'm still interested in discovering what I'm doing wrong.
> To that end, here's the jobstream I'm using, in the hope that someone can
> pin-point the problem:
> (I do so hope that this comes through without being reformatted by various
> e-mail servers...)
>
> 
> //RUNREXX  EXEC PGM=IKJEFT01
> //SYSTSPRT DD   SYSOUT=*
> //ISPMLIB  DD   DSN=ISP.SISPMENU,DISP=SHR
> //ISPPLIB  DD   DSN=ISP.SISPPENU,DISP=SHR
> //ISPSLIB  DD   DSN=ISP.SISPSLIB,DISP=SHR
> //ISPTLIB  DD   DSN=ISP.SISPTENU,DISP=SHR
> //ISPPROF  DD   DISP=(NEW,PASS),SPACE=(TRK,(1,1,1)),
> //  DSORG=PO,RECFM=FB,BLKSIZE=27920,LRECL=80
> //SYSEXEC  DD   DSN=,DISP=SHR
> //SYSTSIN  DD   *
> ISPSTART CMD(STRIPNOS )
>
> and here is the first part of the STRIPNOS REXX program - such as it is
> right now:
>
> /* REXX to strip line numbers in place */
> /* trace i */
> parse source
> arg dataset
> say "PDS to be modified:" dataset
> "ISPEXEC CONTROL ERRORS RETURN"
> "ISREDIT MACRO"
> edMac = rc
> "ISPEXEC CONTROL ERRORS CANCEL"
>  (followed by the rest of Andy's solution, currently all commented out)
>
>
>  ** Mark well that phrase 'as it is right now'. As I've already detailed,
> I've tried many different variants of this code to try and get something
> working, with a notable lack of success
>
> Regards
> Sean
>
> On Mon, 11 Jan 2021 at 20:03, Lennie Dymoke-Bradshaw <
> 032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Apologies, you wanted to do a PDS member.
> >
> > //EDIT EXEC  PGM=IKJEFT01
> > //SYSTSPRT  DD   SYSOUT=*
> > //SYSTSIN   DD   *
> >EDIT 'LEN.X.TEST.NVSAM.PDS(#ASM)' DATA
> >LIST
> >UNNUM
> >LIST
> >END SAVE
> > /*
> > //
> >
> > Note the LIST commands are optional.
> > Lennie
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Lennie Dymoke-Bradshaw
> > Sent: 11 January 2021 19:48
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Request for help with removing sequence numbers from PDS
> > members
> >
> > Here's how to do it using TSO EDIT.
> >
> > //EDIT EXEC  PGM=IKJEFT01
> > //SYSTSPRT  DD   SYSOUT=*
> > //SYSTSIN   DD   *
> >EDIT 'LEN.X.TEST.NVSAM.FB80' DATA
> >LIST
> >UNNUM
> >LIST
> >END SAVE
> > /*
> > //
> >
> > Lennie
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Lennie Bradshaw
> > Sent: 11 January 2021 12:26
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Request for help with removing sequence numbers from PDS
> > members
> >
> > How about TSO EDIT (yes TSO, not ISPF) in batch.
> > Lennie
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of R.S.
> > Sent: 11 January 2021 10:21
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Request for help with removing sequence numbers from PDS
> > members
> >
> > W dniu 11.01.2021 o 10:05, Sean Gleann pisze:
> > > This has almost certainly cropped up before but try as I might, I
> > > can't spot anything obvious in the archives.
> > >
> > > I have a need to strip sequence numbers from members in a PDS or PDSE.
> > > The input PDS(E) has DCB characteristics of REFCM=FB,LRECL-80, and
> > > contains an unknown number of members. Of those members, some will
> > > have records with 'old data' in character positions 73-80 (that is -
>

Re: Request for help with removing sequence numbers from PDS members

2021-01-12 Thread Robert Prins


On 2021-01-12 16:20, Seymour J Metz wrote:

ISREDIT is only valid for an edit macro. You need on script to invoke EDIT
and a second script running as an IMACRO for the edit. If they are in SYSPROC 
then
you need to start the first comment with REXX.

/* Outer script */
   parse upper arg dataset
   "CONTROL ERRORS RETURN"
   'EDIT DATASET('dataset') MACRO(STRIPED')'
   /* Tailor above to suit your needs */

   /* Inner script */
   'CONTROL ERRORS RETURN'
  ADDRESS ISREDIT
   'UNNUMBER'
   'SAVE'
  'END'


You can actually use a single exec, use a "VGET" (with RC=0) when the macro is 
invoked by the same command that has done a "VPUT".


Doing so has the advantage of keeping things together, like the PL/I RFE I've 
very recently entered, 
. 
Feel free to vote for it, although I already expect it to be accepted.


And using the earlier in this thread mentioned "parse source" to get the name of 
the executing exec/macro, it will actually continue to work if it's renamed.


And a general note: when using ISPF edit to remove sequence numbers from a 
(large) number of (large) members, you might need to cater for the fact that a 
PDS might need to be compressed at some stage in the middle of your processing!


Robert

PS: Please people, strip off all the unnecessary garbage from your replies...
--
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: Request for help with removing sequence numbers from PDS members

Whoops! Insert 'MACRO' after address ISREDIT. Also, you might want code to loop 
over all members of a PDS.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Seymour J Metz [sme...@gmu.edu]
Sent: Tuesday, January 12, 2021 11:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for help with removing sequence numbers from PDS members

ISREDIT is only valid for an edit macro. You need on script to invoke EDIT and 
a second script running as an IMACRO for the edit. If they are in SYSPROC then 
you need to start the first comment with REXX.

   /* Outer script */
  parse upper arg dataset
  "CONTROL ERRORS RETURN"
  'EDIT DATASET('dataset') MACRO(STRIPED')'
  /* Tailor above to suit your needs */

  /* Inner script */
  'CONTROL ERRORS RETURN'
 ADDRESS ISREDIT
  'UNNUMBER'
  'SAVE'
 'END'




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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Sean Gleann [sean.gle...@gmail.com]
Sent: Tuesday, January 12, 2021 5:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for help with removing sequence numbers from PDS members

I've been told by Powers That Be that this line of development is redundant
& that a different solution has been independently developed elsewhere in
the company. (*sigh* - 'twas ever thus)
But I'm still interested in discovering what I'm doing wrong.
To that end, here's the jobstream I'm using, in the hope that someone can
pin-point the problem:
(I do so hope that this comes through without being reformatted by various
e-mail servers...)


//RUNREXX  EXEC PGM=IKJEFT01
//SYSTSPRT DD   SYSOUT=*
//ISPMLIB  DD   DSN=ISP.SISPMENU,DISP=SHR
//ISPPLIB  DD   DSN=ISP.SISPPENU,DISP=SHR
//ISPSLIB  DD   DSN=ISP.SISPSLIB,DISP=SHR
//ISPTLIB  DD   DSN=ISP.SISPTENU,DISP=SHR
//ISPPROF  DD   DISP=(NEW,PASS),SPACE=(TRK,(1,1,1)),
//  DSORG=PO,RECFM=FB,BLKSIZE=27920,LRECL=80
//SYSEXEC  DD   DSN=,DISP=SHR
//SYSTSIN  DD   *
ISPSTART CMD(STRIPNOS )

and here is the first part of the STRIPNOS REXX program - such as it is
right now:

/* REXX to strip line numbers in place */
/* trace i */
parse source
arg dataset
say "PDS to be modified:" dataset
"ISPEXEC CONTROL ERRORS RETURN"
"ISREDIT MACRO"
edMac = rc
"ISPEXEC CONTROL ERRORS CANCEL"
 (followed by the rest of Andy's solution, currently all commented out)


 ** Mark well that phrase 'as it is right now'. As I've already detailed,
I've tried many different variants of this code to try and get something
working, with a notable lack of success

Regards
Sean

On Mon, 11 Jan 2021 at 20:03, Lennie Dymoke-Bradshaw <
032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote:

> Apologies, you wanted to do a PDS member.
>
> //EDIT EXEC  PGM=IKJEFT01
> //SYSTSPRT  DD   SYSOUT=*
> //SYSTSIN   DD   *
>EDIT 'LEN.X.TEST.NVSAM.PDS(#ASM)' DATA
>LIST
>UNNUM
>LIST
>END SAVE
> /*
> //
>
> Note the LIST commands are optional.
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Lennie Dymoke-Bradshaw
> Sent: 11 January 2021 19:48
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with removing sequence numbers from PDS
> members
>
> Here's how to do it using TSO EDIT.
>
> //EDIT EXEC  PGM=IKJEFT01
> //SYSTSPRT  DD   SYSOUT=*
> //SYSTSIN   DD   *
>EDIT 'LEN.X.TEST.NVSAM.FB80' DATA
>LIST
>UNNUM
>LIST
>END SAVE
> /*
> //
>
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Lennie Bradshaw
> Sent: 11 January 2021 12:26
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with removing sequence numbers from PDS
> members
>
> How about TSO EDIT (yes TSO, not ISPF) in batch.
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of R.S.
> Sent: 11 January 2021 10:21
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with removing sequence numbers from PDS
> members
>
> W dniu 11.01.2021 o 10:05, Sean Gleann pisze:
> > This has almost certainly cropped up before but try as I might, I
> > can't spot anything obvious in the archives.
> >
> > I have a need to strip sequence numbers from members in a PDS or PDSE.
> > The input PDS(E) has DCB characteristics of REFCM=FB,LRECL-80, and
> > contains an unknown number of members. Of those members, some will
> > have records with 'old data' in character positions 73-80 (that is -
> > sequence numbers, or whatever remains of them).
> > I want to be able to copy this input PDS(E) to a new one with the same
> > DCB info, but all records in all members must have spaces in positions
> 73-80.
> >
> > I thought that ICETOOL might be able to do this but as far as I can
> > see, ICETOOL needs to be told which member names to process. That
> > information is readily available while developing and testing a
>

Re: STCK and epoch time

The TOD clock is just a counter; what you get out of it depends on what you put 
into it. There is a convention in PoOps, but if you want the correct time and 
date it is much easier to use system services than to do the adjustments 
yourself.

MVS does not use the same epoch as Eunix. Unix System Services will adjust the 
epoch properly.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
ITschak Mugzach [imugz...@gmail.com]
Sent: Tuesday, January 12, 2021 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: STCK and epoch time

How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
and converted it to decimal 10 characters. I expect it to be the same as
the EPOCH time returned by USS time call. However the returned value is July
29, 2019 (have a time from yesterday). I know there is a macro to do it,
but I want to keep the correct epoch time.

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *

--
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: Request for help with removing sequence numbers from PDS members

ISREDIT is only valid for an edit macro. You need on script to invoke EDIT and 
a second script running as an IMACRO for the edit. If they are in SYSPROC then 
you need to start the first comment with REXX.

   /* Outer script */
  parse upper arg dataset
  "CONTROL ERRORS RETURN"
  'EDIT DATASET('dataset') MACRO(STRIPED')'
  /* Tailor above to suit your needs */

  /* Inner script */
  'CONTROL ERRORS RETURN'
 ADDRESS ISREDIT
  'UNNUMBER'
  'SAVE'
 'END'
  



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Sean Gleann [sean.gle...@gmail.com]
Sent: Tuesday, January 12, 2021 5:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for help with removing sequence numbers from PDS members

I've been told by Powers That Be that this line of development is redundant
& that a different solution has been independently developed elsewhere in
the company. (*sigh* - 'twas ever thus)
But I'm still interested in discovering what I'm doing wrong.
To that end, here's the jobstream I'm using, in the hope that someone can
pin-point the problem:
(I do so hope that this comes through without being reformatted by various
e-mail servers...)


//RUNREXX  EXEC PGM=IKJEFT01
//SYSTSPRT DD   SYSOUT=*
//ISPMLIB  DD   DSN=ISP.SISPMENU,DISP=SHR
//ISPPLIB  DD   DSN=ISP.SISPPENU,DISP=SHR
//ISPSLIB  DD   DSN=ISP.SISPSLIB,DISP=SHR
//ISPTLIB  DD   DSN=ISP.SISPTENU,DISP=SHR
//ISPPROF  DD   DISP=(NEW,PASS),SPACE=(TRK,(1,1,1)),
//  DSORG=PO,RECFM=FB,BLKSIZE=27920,LRECL=80
//SYSEXEC  DD   DSN=,DISP=SHR
//SYSTSIN  DD   *
ISPSTART CMD(STRIPNOS )

and here is the first part of the STRIPNOS REXX program - such as it is
right now:

/* REXX to strip line numbers in place */
/* trace i */
parse source
arg dataset
say "PDS to be modified:" dataset
"ISPEXEC CONTROL ERRORS RETURN"
"ISREDIT MACRO"
edMac = rc
"ISPEXEC CONTROL ERRORS CANCEL"
 (followed by the rest of Andy's solution, currently all commented out)


 ** Mark well that phrase 'as it is right now'. As I've already detailed,
I've tried many different variants of this code to try and get something
working, with a notable lack of success

Regards
Sean

On Mon, 11 Jan 2021 at 20:03, Lennie Dymoke-Bradshaw <
032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote:

> Apologies, you wanted to do a PDS member.
>
> //EDIT EXEC  PGM=IKJEFT01
> //SYSTSPRT  DD   SYSOUT=*
> //SYSTSIN   DD   *
>EDIT 'LEN.X.TEST.NVSAM.PDS(#ASM)' DATA
>LIST
>UNNUM
>LIST
>END SAVE
> /*
> //
>
> Note the LIST commands are optional.
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Lennie Dymoke-Bradshaw
> Sent: 11 January 2021 19:48
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with removing sequence numbers from PDS
> members
>
> Here's how to do it using TSO EDIT.
>
> //EDIT EXEC  PGM=IKJEFT01
> //SYSTSPRT  DD   SYSOUT=*
> //SYSTSIN   DD   *
>EDIT 'LEN.X.TEST.NVSAM.FB80' DATA
>LIST
>UNNUM
>LIST
>END SAVE
> /*
> //
>
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Lennie Bradshaw
> Sent: 11 January 2021 12:26
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with removing sequence numbers from PDS
> members
>
> How about TSO EDIT (yes TSO, not ISPF) in batch.
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of R.S.
> Sent: 11 January 2021 10:21
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Request for help with removing sequence numbers from PDS
> members
>
> W dniu 11.01.2021 o 10:05, Sean Gleann pisze:
> > This has almost certainly cropped up before but try as I might, I
> > can't spot anything obvious in the archives.
> >
> > I have a need to strip sequence numbers from members in a PDS or PDSE.
> > The input PDS(E) has DCB characteristics of REFCM=FB,LRECL-80, and
> > contains an unknown number of members. Of those members, some will
> > have records with 'old data' in character positions 73-80 (that is -
> > sequence numbers, or whatever remains of them).
> > I want to be able to copy this input PDS(E) to a new one with the same
> > DCB info, but all records in all members must have spaces in positions
> 73-80.
> >
> > I thought that ICETOOL might be able to do this but as far as I can
> > see, ICETOOL needs to be told which member names to process. That
> > information is readily available while developing and testing a
> > solution, but not when the result is used in a more general scenario.
> >
> > Can anyone point me at some sort of solution that I might adapt, please?
> > Perhaps there is something on the CBT tape that might help...
>
> I don't know any tool, but I have some idea how to do it.
> Use REXX script.
> It's quite simple to get member list and do somethin in a loop until last
> member is processed.
> What to do?
> Again, I don't know any tool, however it could be

Re: Ibm macro instructions code clarification

2021-01-12 Thread Jake Anderson

Apologies for giving a minimal information

This is a SNA application where user use to connect Database and they
receive FDBK2 00

This is the only information I have from the log and I have raised a case
with Product support for further investigation and meanwhile just curious
about these codes



On Tue, 12 Jan, 2021, 7:18 pm Charles Mills,  wrote:

> I think that's the problem: he does not know. They run some program for
> which the source code is not readily available. It fails, with the message
> FDBWD : 00141300 FDBK2. He knows that is insufficient information but wants
> to know if anyone here recognizes it, goes "oh yeah, that would be a blah
> blah blah failure in X."
>
> Trying to help, some IBM products issue a "feedback two" or FDBK2 code:
> VTAM comes to mind. VTAM return code and feedback of 0014 13 would be CID
> not valid: The RPLARG field or the NIBCID field does not contain a valid
> CID, or a valid CID was issued with the wrong ACB, or INTRPRET is being
> used for a cross-domain LU.
>
> @Jake, what *might* the product be trying to do? Is it a
> telecommunications product? A database product ...
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Tuesday, January 12, 2021 3:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ibm macro instructions code clarification
>
> Really vague. What  function are you trying to do? I am used to those
> fields being VSAM, and they are documented in the DFSMS manuals. But were
> you doing an OPEN, or a GET, or a PUT, or a CLOSE, or something else? What
> is the Return Code (Register 15)? Are you using RLS or TVS? What version of
> z/OS?
>
> --
> 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

Merging multiple records using DFSORT

2021-01-12 Thread Robert Prins


I'm currently using this

* Merge the LW file
*
* These sort commands can handle both the old, it's left unchanged, as
* well as the new, records are merged, LW output file.
***
 OPTION COPY
 INREC  IFTHEN=(WHEN=(1,1,CH,EQ,C'1',OR, ASA
114,1,CH,EQ,C'+',OR, Old eol
114,1,CH,EQ,C'|'),   Old eol
   OVERLAY=(122:C' ')),
IFTHEN=(WHEN=NONE,
   OVERLAY=(122:SEQNUM,8,ZD,122:122,8,ZD,MOD,+2,M11,LENGTH=1))
*
 OUTREC IFTHEN=(WHEN=GROUP,BEGIN=(122,1,CH,EQ,C'1'),
  PUSH=(123:1,121))
*
 OUTFIL FTOV,VLTRIM=C' ',
  OMIT=(122,1,CH,EQ,C'1'),
IFTHEN=(WHEN=(122,1,CH,EQ,C'0'),BUILD=(123,121,1,121)),
IFTHEN=(WHEN=(122,1,CH,EQ,C' '),BUILD=(1,121))

which works like a charm.

However, the input file is about to change, and as we're still not willing to 
update the regression testing framework to cater for files other than FB(121), 
the above has to change for additional input records, which means another 
ifthen-when group. I guess it's not a problem to change the current overlay to a 
fixed '1' followed by the current seqnum logic (Correct me if I'm wrong!) and 
add another with a fixed '2' plus a mod +3 sequence number, the new records need 
to be assembled from three records. (Yes, sigh...)


However, can I use multiple "PUSH"es? The manual tells me

You can use the following in PUSH:
c: Specifies the output position (column) to be overlaid. If you do not
specify c: for the first item, it defaults to 1:. If you do not specify c:
for any other item, it starts after the previous item. You can specify
items in any order and overlap output columns. c can be 1 to
32752.
If you specify an item that extends the output record beyond the
end of the input record, the record length is automatically
increased to that length, and blanks are filled in on the left as
needed. For variable-length records, the RDW length is increased
to correspond to the larger record length after all of the items are
processed. Missing bytes in specified input fields are replaced with
blanks so the padded fields can be processed.
p,m
***Specifies a field in the ***first input record*** of each group to be
propagated to every record of the group.*** p specifies the starting
position of the field in the input record and m specifies its length.
A field must not extend beyond position 32752.
ID=n
Specifies a ZD identifier of length n is to be added to every record
of each group. The identifier starts at 1 for the first group and is
incremented by 1 for each subsequent group. n can be 1 to 15.
SEQ=n
Specifies a ZD sequence number of length n is to be added to
every record of each group. The sequence number starts at 1 for
the first record of each group and is incremented by 1 for each
subsequent record of the group. n can be 1 to 15.[/quote]

Emphasis (***) added, which seems that I can only merge data from the first 
record?

Or do I have to resort to something more exotic, like 
?


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: STCK and epoch time

2021-01-12 Thread Mike Schwab

https://www.mail-archive.com/search?l=ibm-main@listserv.ua.edu=subject:%22Re%5C%3A+Converting+STCK%5C%28tod%5C%29+to+readable+format%22=newest=1

On Tue, Jan 12, 2021 at 9:37 AM ITschak Mugzach  wrote:
>
> How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
> and converted it to decimal 10 characters. I expect it to be the same as
> the EPOCH time returned by USS time call. However the returned value is July
> 29, 2019 (have a time from yesterday). I know there is a macro to do it,
> but I want to keep the correct epoch time.
>
> ITschak Mugzach
> *|** IronSphere Platform* *|* *Information Security Continuous Monitoring
> for z/OS, x/Linux & IBM I **| z/VM coming soon  *
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

STCK and epoch time

2021-01-12 Thread ITschak Mugzach

How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
and converted it to decimal 10 characters. I expect it to be the same as
the EPOCH time returned by USS time call. However the returned value is July
29, 2019 (have a time from yesterday). I know there is a macro to do it,
but I want to keep the correct epoch time.

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *

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

Re: Interchip's RTD/DB2

2021-01-12 Thread Jerome Benting

It works really well when customised and set up properly for your environment. 
I would recommend it.

Interchip's support is excellent and they resolve any issues really quick.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, January 12, 2021 5:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Interchip's RTD/DB2

We didn't have that specific product, just their standard dataset RTD. It 
consumed lots of CPU cycles.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐

On Tuesday, January 12th, 2021 at 9:49 AM, Michael Babcock 
 wrote:

> Anyone use Interchip's Real Time Defrag for DB2?   Does it work well?
>
> Any gotchas?  Other comments?
>
> --
> 
>
> 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
Jerome Benting

JMR Software
Waterview Corner, 2 Ernest Oppenheimer Avenue, Johannesburg
2198, Gauteng, ZA
t: +27 (0)11 484 5070
m: +27 (0)73 195 6766
e: jer...@jmr.co.za
www.jmr.co.za [Facebook icon] 
  [LinkedIn icon] 
  [Twitter icon] 

[Banner] 
The content of this email is confidential and intended for the recipient 
specified in message only. It is strictly forbidden to share any part of this 
message with any third party, without a written consent of the sender. If you 
received this message by mistake, please reply to this message and follow with 
its deletion, so that we can ensure such a mistake does not occur in the future.

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

Re: Ibm macro instructions code clarification

2021-01-12 Thread Charles Mills

I think that's the problem: he does not know. They run some program for which 
the source code is not readily available. It fails, with the message FDBWD : 
00141300 FDBK2. He knows that is insufficient information but wants to know if 
anyone here recognizes it, goes "oh yeah, that would be a blah blah blah 
failure in X."

Trying to help, some IBM products issue a "feedback two" or FDBK2 code: VTAM 
comes to mind. VTAM return code and feedback of 0014 13 would be CID not valid: 
The RPLARG field or the NIBCID field does not contain a valid CID, or a valid 
CID was issued with the wrong ACB, or INTRPRET is being used for a cross-domain 
LU.

@Jake, what *might* the product be trying to do? Is it a telecommunications 
product? A database product ...

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, January 12, 2021 3:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ibm macro instructions code clarification

Really vague. What  function are you trying to do? I am used to those
fields being VSAM, and they are documented in the DFSMS manuals. But were
you doing an OPEN, or a GET, or a PUT, or a CLOSE, or something else? What
is the Return Code (Register 15)? Are you using RLS or TVS? What version of
z/OS?

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

Re: Interchip's RTD/DB2

2021-01-12 Thread Mark Jacobs

We didn't have that specific product, just their standard dataset RTD. It 
consumed lots of CPU cycles.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐

On Tuesday, January 12th, 2021 at 9:49 AM, Michael Babcock 
 wrote:

> Anyone use Interchip's Real Time Defrag for DB2?   Does it work well? 
>
> Any gotchas?  Other comments?
>
> --
>
> 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: Request for help with removing sequence numbers from PDS members

On Tue, 12 Jan 2021 11:26:32 +, Sean Gleann wrote:
>
> 7 *-* "ISREDIT MACRO"
>   >L>   "ISREDIT MACRO"
>   +++ RC(20) +++
> 
That belongs not here but in your initial macro.

>21 *-*   "ISPEXEC EDIT DATAID() MEMBER() MACRO()"
>   >L> "ISPEXEC EDIT DATAID() MEMBER() MACRO()"
> 
Does Edit evaluate the apparent symbol ""?  Where is it given a value?

Was that from the (lately deleted) PARSE SOURCE instruction?  Then:
 "ISPEXEC EDIT DATAID("DSN") MEMBER("MEMBER") MACRO("ME")"

If you're attempting to use your driving exec as your initial macro (I've
done that at times), you need dual-path logic to prevent loops.

>  ISPP330 BDISPMAX exceeded   -/-100 displays exceeded in batch mode on
>panel
>
What's causing Edit to attempt a display?

As alternatives to Edit I suggest either EXECIO DISKR - EXECIO DISKW
or LMGET -  LMPUT logic.

-- gil

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

Interchip's RTD/DB2

2021-01-12 Thread Michael Babcock

Anyone use Interchip's Real Time Defrag for DB2?   Does it work well?  
Any gotchas?  Other comments?


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

Re: Request for help with removing sequence numbers from PDS members

The 'parse source . . me .' modification cracked the problem, Andy - many
thanks!
I see now from my very earliest version of the REXX, I had missed out the
the space between the placeholders for the first two tokens
That led me into a can of worms that eventually resulted in me removing the
'. . me .' completely, leaving just 'parse source'.
Which in turn led to a different can of worms, and from there on it was
just downhill all the way.
As I said early on, it had to be one of those 'basic, simple' things...

Regards
Sean


On Tue, 12 Jan 2021 at 13:23, Andy Styles  wrote:

> Actually, I think it does.
>
> The MACRO parameter should have the name of the calling exec - the other
> parms have values as I would expect.
>
> Can you add a trace ir right at the top,  it should show what the parse
> source is returning; you might instead add a say me ..
>
> The parse line should say:
>
> parse source . . me .
>
> Andy
>
> On Tue, 12 Jan 2021, 13:16 Sean Gleann,  wrote:
>
> > Hi Andy
> >
> > The ISPLOG output doesn't give anything useful, unfortunately.
> >
> > Time*** ISPF transaction log ***
> >
> >
> > 07:08   Start of ISPF Log - - -  - Session # 1
> > 
> > 07:08  TSO - Command  -  - STRIPNOS 
> >
> > 07:08   * Dialog Error * - Application(ISP); Function Command
> > (STRIPNOS); Service(EDIT)
> > 07:08  Line from cmd:- EDIT DATAID(ISR1) MEMBER(TEST1)
> > MACRO()  <<'TEST1' is the name of the first
> > member in the incoming PDS, though.
> > 07:08  BDISPMAX exceeded - 100 displays exceeded in batch mode on
> > panel
> >
> > Regards
> > Sean
> >
> > On Tue, 12 Jan 2021 at 12:56, Sri h Kolusu  wrote:
> >
> > > Sean,
> > >
> > > If your shop has File-manager , the following JCL will give you the
> > desired
> > > results
> > >
> > > //STEP0100 EXEC PGM=FILEMGR
> > > //SYSPRINT DD SYSOUT=*
> > > //PDS  DD DISP=SHR,DSN=Your.PDS/PDSE.to.remove.seqnum
> > > //SYSINDD *
> > > $$FILEM FCH INPUT=PDS
> > > C  P'=' ' ' 73 80
> > > /*
> > >
> > >
> > > Thanks,
> > > Kolusu
> > >
> > > --
> > > 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
> >
>
> --
> 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: Request for help with removing sequence numbers from PDS members

Actually, I think it does.

The MACRO parameter should have the name of the calling exec - the other
parms have values as I would expect.

Can you add a trace ir right at the top,  it should show what the parse
source is returning; you might instead add a say me ..

The parse line should say:

parse source . . me .

Andy

On Tue, 12 Jan 2021, 13:16 Sean Gleann,  wrote:

> Hi Andy
>
> The ISPLOG output doesn't give anything useful, unfortunately.
>
> Time*** ISPF transaction log ***
>
>
> 07:08   Start of ISPF Log - - -  - Session # 1
> 
> 07:08  TSO - Command  -  - STRIPNOS 
>
> 07:08   * Dialog Error * - Application(ISP); Function Command
> (STRIPNOS); Service(EDIT)
> 07:08  Line from cmd:- EDIT DATAID(ISR1) MEMBER(TEST1)
> MACRO()  <<'TEST1' is the name of the first
> member in the incoming PDS, though.
> 07:08  BDISPMAX exceeded - 100 displays exceeded in batch mode on
> panel
>
> Regards
> Sean
>
> On Tue, 12 Jan 2021 at 12:56, Sri h Kolusu  wrote:
>
> > Sean,
> >
> > If your shop has File-manager , the following JCL will give you the
> desired
> > results
> >
> > //STEP0100 EXEC PGM=FILEMGR
> > //SYSPRINT DD SYSOUT=*
> > //PDS  DD DISP=SHR,DSN=Your.PDS/PDSE.to.remove.seqnum
> > //SYSINDD *
> > $$FILEM FCH INPUT=PDS
> > C  P'=' ' ' 73 80
> > /*
> >
> >
> > Thanks,
> > Kolusu
> >
> > --
> > 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
>

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

Re: Request for help with removing sequence numbers from PDS members

Hi Andy

The ISPLOG output doesn't give anything useful, unfortunately.

Time*** ISPF transaction log ***

07:08   Start of ISPF Log - - -  - Session # 1

07:08  TSO - Command  -  - STRIPNOS 

07:08   * Dialog Error * - Application(ISP); Function Command
(STRIPNOS); Service(EDIT)
07:08  Line from cmd:- EDIT DATAID(ISR1) MEMBER(TEST1)
MACRO()  <<'TEST1' is the name of the first
member in the incoming PDS, though.
07:08  BDISPMAX exceeded - 100 displays exceeded in batch mode on
panel

Regards
Sean

On Tue, 12 Jan 2021 at 12:56, Sri h Kolusu  wrote:

> Sean,
>
> If your shop has File-manager , the following JCL will give you the desired
> results
>
> //STEP0100 EXEC PGM=FILEMGR
> //SYSPRINT DD SYSOUT=*
> //PDS  DD DISP=SHR,DSN=Your.PDS/PDSE.to.remove.seqnum
> //SYSINDD *
> $$FILEM FCH INPUT=PDS
> C  P'=' ' ' 73 80
> /*
>
>
> Thanks,
> Kolusu
>
> --
> 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: Request for help with removing sequence numbers from PDS members

2021-01-12 Thread Sri h Kolusu

Sean,

If your shop has File-manager , the following JCL will give you the desired
results

//STEP0100 EXEC PGM=FILEMGR
//SYSPRINT DD SYSOUT=*
//PDS  DD DISP=SHR,DSN=Your.PDS/PDSE.to.remove.seqnum
//SYSINDD *
$$FILEM FCH INPUT=PDS
C  P'=' ' ' 73 80
/*


Thanks,
Kolusu

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

Re: Ibm macro instructions code clarification

2021-01-12 Thread Joe Monk

Without a little more info (i.e. what product) its kinda hard to help.

BUT, having said that,

FDBWD usually means FDB WORD

00141300 = the value of FDBWD

FDBK2 ... there should be some data here. FDBK2 is normally some type of
error code.

Joe


On Tue, Jan 12, 2021 at 12:55 AM Jake Anderson 
wrote:

> Hello
>
> Apologies for my ignorance. One of our product failed with FDBWD : 00141300
> FDBK2.
>
> I am not able to decode the meaning or explanation for FDBWD. Could someone
> please help to understand so that I can make sure I understand fully ?
>
> Jake
>
> --
> 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: Request for help with removing sequence numbers from PDS members

So, it's the invocation of EDIT that's causing the error.

If you add an ISPLOG DD (RECFM VBA, LRECL 125) do you get more info?

Otherwise we're into adding some say statements in to see what ,
 and  are set to, and wrapping the whole thing in CONTROL ERRORS
so we can see what we get back in ZERRLM after the failure.

I did say it did limited error handling 

Andy



On Tue, 12 Jan 2021, 11:27 Sean Gleann,  wrote:

> Hi Andy
>
> "is it just that you're seeing the RC20 from the ISREDIT" - in this
> particular version of the REXX it is, but as previously detailed I had
> problems with the syntax of the CONTROL ERRORS statement.
> "Does the REXX continue afterwards if you uncomment the code" - in a manner
> of speaking, yes. The whole job terminates with RC990.
> Here's the SYSTSPRT produced by running the uncommented REXX, with 'trace
> i' specified:
>
>  3 *-* parse source
>
>  4 *-* arg dataset
>
>>>>   "**"
>
>  5 *-* say "PDS to be modified:" dataset
>
>>L>   "PDS to be modified:"
>
>>V>   "**"
>
>>O>   "PDS to be modified: **"
>
> PDS to be modified: **
>
>  6 *-* "ISPEXEC CONTROL ERRORS RETURN"
>
>>L>   "ISPEXEC CONTROL ERRORS RETURN"
>
>  7 *-* "ISREDIT MACRO"
>
>>L>   "ISREDIT MACRO"
>
>+++ RC(20) +++
>
>  8 *-* edMac = rc
>
>>V>   "20"
>
>  9 *-* "ISPEXEC CONTROL ERRORS CANCEL"
>
>>L>   "ISPEXEC CONTROL ERRORS CANCEL"
>
> 10 *-* if edMac = 0
>
>>V>   "20"
>
>>L>   "0"
>
>>O>   "0"
>
> 14 *-* "ISPEXEC LMINIT DATAID(DSN) DATASET('"dataset"') ENQ(SHR)"
>
>>L>   "ISPEXEC LMINIT DATAID(DSN) DATASET('"
>
>>V>   "**"
>
>>O>   "ISPEXEC LMINIT DATAID(DSN) DATASET('**"
>
>>L>   "') ENQ(SHR)"
>
>>O>   "ISPEXEC LMINIT DATAID(DSN) DATASET('**')
> ENQ(SHR)"
> 15 *-* "ISPEXEC LMOPEN DATAID()"
>
>>L>   "ISPEXEC LMOPEN DATAID()"
>
> 16 *-* Do until RC > 0
>
> 17 *-*  "ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMBER)
> STATS(NO)"
>>L>"ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMBER)
> STATS(NO)"
> 18 *-*  If RC = 8
>
>>V>"0"
>
>>L>"8"
>
>>O>"0"
>
> 20 *-*  If RC = 0
>
>>V>"0"
>
>>L>"0"
>
>>O>"1"
>
>*-*   Then
>
> 21 *-*   "ISPEXEC EDIT DATAID() MEMBER() MACRO()"
>
>>L> "ISPEXEC EDIT DATAID() MEMBER() MACRO()"
>
>   ISPP330 BDISPMAX exceeded   -/-100 displays exceeded in batch mode on
> panel
>
> Regards
> Sean
>
> On Tue, 12 Jan 2021 at 11:06, Andy Styles  wrote:
>
> > Twice recently I've tried to paste an answer to a question involving some
> > REXX output and been caught by our DLP filters.
> >
> > Subscribing separately to avoid that!
> >
> > Anyway, is it just that you're seeing the RC20 from the ISREDIT?
> >
> > I would expect that on the first invocation, the CONTROL ERRORS  wrapper
> > is there to stop ISPF terminating the exec with a severe error.
> >
> > Does the REXX continue afterwards if you uncomment the code?
> >
> > Andy
> >
> > --
> > 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
>

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

Re: Request for help with removing sequence numbers from PDS members

Hi Andy

"is it just that you're seeing the RC20 from the ISREDIT" - in this
particular version of the REXX it is, but as previously detailed I had
problems with the syntax of the CONTROL ERRORS statement.
"Does the REXX continue afterwards if you uncomment the code" - in a manner
of speaking, yes. The whole job terminates with RC990.
Here's the SYSTSPRT produced by running the uncommented REXX, with 'trace
i' specified:

 3 *-* parse source

 4 *-* arg dataset

   >>>   "**"

 5 *-* say "PDS to be modified:" dataset

   >L>   "PDS to be modified:"

   >V>   "**"

   >O>   "PDS to be modified: **"

PDS to be modified: **

 6 *-* "ISPEXEC CONTROL ERRORS RETURN"

   >L>   "ISPEXEC CONTROL ERRORS RETURN"

 7 *-* "ISREDIT MACRO"

   >L>   "ISREDIT MACRO"

   +++ RC(20) +++

 8 *-* edMac = rc

   >V>   "20"

 9 *-* "ISPEXEC CONTROL ERRORS CANCEL"

   >L>   "ISPEXEC CONTROL ERRORS CANCEL"

10 *-* if edMac = 0

   >V>   "20"

   >L>   "0"

   >O>   "0"

14 *-* "ISPEXEC LMINIT DATAID(DSN) DATASET('"dataset"') ENQ(SHR)"

   >L>   "ISPEXEC LMINIT DATAID(DSN) DATASET('"

   >V>   "**"

   >O>   "ISPEXEC LMINIT DATAID(DSN) DATASET('**"

   >L>   "') ENQ(SHR)"

   >O>   "ISPEXEC LMINIT DATAID(DSN) DATASET('**')
ENQ(SHR)"
15 *-* "ISPEXEC LMOPEN DATAID()"

   >L>   "ISPEXEC LMOPEN DATAID()"

16 *-* Do until RC > 0

17 *-*  "ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMBER)
STATS(NO)"
   >L>"ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMBER)
STATS(NO)"
18 *-*  If RC = 8

   >V>"0"

   >L>"8"

   >O>"0"

20 *-*  If RC = 0

   >V>"0"

   >L>"0"

   >O>"1"

   *-*   Then

21 *-*   "ISPEXEC EDIT DATAID() MEMBER() MACRO()"

   >L> "ISPEXEC EDIT DATAID() MEMBER() MACRO()"

  ISPP330 BDISPMAX exceeded   -/-100 displays exceeded in batch mode on
panel

Regards
Sean

On Tue, 12 Jan 2021 at 11:06, Andy Styles  wrote:

> Twice recently I've tried to paste an answer to a question involving some
> REXX output and been caught by our DLP filters.
>
> Subscribing separately to avoid that!
>
> Anyway, is it just that you're seeing the RC20 from the ISREDIT?
>
> I would expect that on the first invocation, the CONTROL ERRORS  wrapper
> is there to stop ISPF terminating the exec with a severe error.
>
> Does the REXX continue afterwards if you uncomment the code?
>
> Andy
>
> --
> 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: Ibm macro instructions code clarification

2021-01-12 Thread John McKown

Really vague. What  function are you trying to do? I am used to those
fields being VSAM, and they are documented in the DFSMS manuals. But were
you doing an OPEN, or a GET, or a PUT, or a CLOSE, or something else? What
is the Return Code (Register 15)? Are you using RLS or TVS? What version of
z/OS?

A quick search on "00141300" did not get any hits.

On Tue, Jan 12, 2021 at 12:55 AM Jake Anderson 
wrote:

> Hello
>
> Apologies for my ignorance. One of our product failed with FDBWD : 00141300
> FDBK2.
>
> I am not able to decode the meaning or explanation for FDBWD. Could someone
> please help to understand so that I can make sure I understand fully ?
>
> Jake
>
> --
> 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: Request for help with removing sequence numbers from PDS members

Twice recently I've tried to paste an answer to a question involving some REXX 
output and been caught by our DLP filters.

Subscribing separately to avoid that!

Anyway, is it just that you're seeing the RC20 from the ISREDIT?

I would expect that on the first invocation, the CONTROL ERRORS  wrapper is 
there to stop ISPF terminating the exec with a severe error. 

Does the REXX continue afterwards if you uncomment the code?

Andy

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

Re: z/OS holddata per https?

2021-01-12 Thread R.S.

Other solution: just circumvent restrictions. Simply download HOLDDATA 
using private PC and then send it via email. Yes, it is a crime... but 
it works.
Of course it would require some effort to understand that it is possible 
to allow ftp to IBM site, especially limited to few persons which have 
interest to use it. Access to HOLDDATA is valid need and it should be 
processed with no obstacles.


--
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. Prosta 18, 00-850 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.

Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z 
prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które 
wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną 
działalnością bankową.
Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w 
Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo


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. Prosta 18, 00-850 
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.

We are the controller of your personal data, which you provided in connection 
with correspondence with us. We process your data for purposes resulting from 
the subject of correspondence, including those related to the banking services.
More information on how we protect and process personal data can be found in 
the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo.

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

Re: Request for help with removing sequence numbers from PDS members

2021-01-12 Thread Greg Price


On 2021-01-11 8:06 PM, Sean Gleann wrote:

Can anyone point me at some sort of solution that I might adapt, please?
Perhaps there is something on the CBT tape that might help...


I am sure the original problem has been resolved by now, but for 
completeness I will mention a couple of things which I did not see 
previously mentioned - apologies if they were.


If you want to use CBT tape utilities, I'd recommend OFFLOAD and 
PDSLOAD.  OFFLOAD the the PDS to a sequential data set and then:


Option 1: edit the sequential data set and in the edit session issue 
RENUM followed by UNNUM, and then reload the members using PDSLOAD.


Use TSO EDIT (work file) or REVIEW's Edit (data space) if the the data 
is too large for an ISPF Edit session.


Don't want to use Edit?

Option 2: After the initial OFFLOAD, use PDSLOAD (or even IEBUPDTE if 
you don't care about ISPF statistics) to reload the member to a PDS 
which has LRECL=72. Then OFFLOAD again to an LRECL=80 sequential data 
set and reload by PDSLOAD/IEBUPDTE to a PDS with LRECL=80.



BUT, I think the obvious solution is to
1. Create a new PDS with similar space but with LRECL=72.
2. Use ISPF option 3.3 to copy all of the members to the new PDS.
3. Prepare your permanent result LRECL=80 PDS (make a new one or empty 
and compress the old one).
4. Use ISPF option 3.3 to copy all of the members from the LRECL=72 PDS 
back to the LRECL=80 PDS.



Cheers,
Greg

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

Re: Request for help with removing sequence numbers from PDS members