date:20210111

On Mon, 11 Jan 2021 22:07:04 +, Jesse 1 Robinson  
wrote:

>I can confirm that HTTPS replaces FTP for downloads very nicely. Our use of 
>FTP depends on a gizmo (Bluecoat) that cannot understand FTPS. We made the 
>switch to HTTPS some time ago. 
>
How?  It doesn't seem to be as simple as changing the scheme in
ftp://public.dhe.ibm.com/s390/holddata/full.txt
to:
https://public.dhe.ibm.com/s390/holddata/full.txt
... that gives 404.  "Bluecoat" seems to be a Symantec subsidiary.
Is it also some sort of proxy?

-- gil

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

Re: Compile error and also possible library bug with Metal/C metal.h

2021-01-11 Thread Joe Monk

"I'd be perfectly happy for someone to tell me I missed some obvious
compiler option or did something else really stupid."

Found this on another website ...

The issue was with the search order. Although I did
search(/usr/metal/include) from with in my JCL I didn't proceed it with a
nosearch option, so string.h was getting picked up from the standard system
libraries instead of the version included with Metal C. I've pasted my
optfile dataset I passed to the CPARM below for reference.

//OPTIONS DD *
 SO
 LIST
 LONG
 NOXREF
 CSECT
 METAL
 LP64
 NOSEARCH
 search(/usr/include/metal/)

Joe

On Mon, Jan 11, 2021 at 12:39 PM Dennis Fitzpatrick 
wrote:

> I'm a developer working with a client to develop Metal C functions for
> their products. Up until recently I've defined __METAL_STATIC and linked
> with SCCR3BND. I decided recently to play with the dynamic library in
> LPALIB so I removed that #define. What I'm getting is compile errors on the
> substitution macros from metal.h. That is the first problem. I decided to
> try and circumvent the compile errors and I think I found a bug in the
> memcmp library function. That is the second problem. I'm really hoping
> someone will tell me I missed something really obvious or missed some
> maintenance.
>
> I created a trivial sample program to demonstrate:
>
> /*
>   Sample for Metal C
> */
>
> #include 
> #include 
>
> int main(int argc, char** argv)
> {
>   char* xarg = "abcd";
>   void *mem = malloc(64);
>   memset(mem, 0x0f, 64);
>   memcpy(mem, xarg, sizeof(xarg));
>   int mcmp = memcmp(mem, xarg, sizeof(xarg));
>   free(mem);
> }
> Of course, this compiles and runs just fine on Visual Studio where I do my
> initial development. On z/OS XLC though I get errors like the following:
>
> 12   |  memset(mem, 0x0f, 64);
>   | 12
> 12   +  ((___MEMSET * ) ( (*(struct __cvt_s * __ptr32 *
> __ptr32)16) -> __cvtecvt -> __ecvtsdc -> __sdca\+ 12
> ===>
> b...a.
> *=ERROR===> a - CCN3275 Unexpected text ')' encountered.
> *=ERROR===> b - CCN3045 Undeclared identifier ___MEMSET.
> 12   +libv31 -> __libfunc[33] ))(mem, 0x0f, 64);
>   + 12
> ===>
> .c
> *=ERROR===> c - CCN3277 Syntax error: possible missing ')' or ','?
>
> The header file include list is exactly what I expect:
>
> 1   /usr/include/metal/stdio.h
> 2   /usr/include/metal/metal.h
> 3   /usr/include/metal/stddef.h
> 4   /usr/include/metal/stdlib.h
> 5   /usr/include/metal/builtins.h
>
> Looking through all of the layers in the metal.h header started me looking
> for aspirin. I decided to push forward as an exercise by defining my own
> structures to use the Metal C function vector. I already had many of the
> standard z/OS structures mapped and added my own mapping of sys_libv31_s
> with real function prototypes:
>
> struct sys_libv31_s
> {
>   void (*_em_0)();
>   int (*_em_abs)(int,int); // 1
>   int (*_em_atoi)(char*); // 2
>   long (*_em_atol)(char*); // 3
>   long long (*_em_atoll)(char*); // 4
>   void* (*_em_calloc)(size_t); // 5
>
> And my own substitution macros to remove the metal.h definition and put in
> my own EMCALL reference:
>
> #define EMCALL(_t, _n)
> (##_t)(*(CVTPTR->CVTECVT->ECVTSDC->sdcalibv31->_em_##_n))
> #define em_0  EMCALL(void, em_0)
> #undef abs // 1
> #define abs EMCALL(int, abs)
> #undef atoi // 2
> #define atoi EMCALL(int atoi)
> #undef atol // 3
> #define atol EMCALL(long, atol)
> #undef atoll // 4
> #define atoll EMCALL(long long, atoll)
> #undef calloc // 5
> #define calloc EMCALL(void *, calloc)
>
> I can't give you the whole thing as it is too much to extract from client
> proprietary material. Hopefully, this is enough to get the gist.
>
> Now this is where I believe I found a bug in the memcmp function returning
> an invalid result and also a potential S0C4. With getting all of my code to
> compile I found things taking some weird code paths. I tracked it down to a
> memcmp and setup the code in the sample above to test it. I found the
> memcmp above returns an invalid result, 0x0f, even though the memory is
> equal. I went into TEST and disassembled the code and got this:
>
>
> 1F24CD78.STM R14,R3,12(R13)
>
> 1F24CD7C.LR  R15,R13
>
> 1F24CD7E.L   R13,8(,R13)
>
> 1F24CD82.ST  R15,4(,R13)
>
> 1F24CD86.STMHR14,R3,80(R13)
>
> 1F24CD8C.L   R14,0(,R1)
>
> 1F24CD90.L   R2,4(,R1)
>
> 1F24CD94.ICM R0,15,8(R1)
>
> 1F24CD98.BRC 8,*+52
>
> 1F24CD9C.LR  R1,R0
>
> 1F24CD9E.LLGCR15,0(,R14)
>
> 1F24CDA4.LLGCR3,0(,R2)
>
> 1F24CDAA.LA

Re: Compile error and also possible library bug with Metal/C metal.h

2021-01-11 Thread Charles Mills

The sizeof() a char* in any C implementation is the size of an address (4,
8, or formerly 2 bytes). A char* IS an address, of course.

sizeof() is resolved at compile time. If you think about it, there is no way
the compiler could know how long a string a char* is going to be pointing
to. That's why you need strlen(), which is a run time function.

If you look in the compiler library doc it should for memcpy() tell you the
required header and any required macro switches. For the "regular" C that is
#include .

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Don Poitras
Sent: Monday, January 11, 2021 3:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compile error and also possible library bug with Metal/C
metal.h

I've never used Metal C, but for the first problem (undeclared __MEMSET), I
would look to see if there's a string.h that can be used. That's normally
where memcmp is defined.

As for the runtime problem, I'd guess it had something to do with using 
'sizeof' incorrectly. It looks as if you are compiling 64-bit which would
mean that 'sizeof(xarg)' is going to be 8. If you replace all the sizeofs
with strlens, I think you'd see it work.

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

Re: Compile error and also possible library bug with Metal/C metal.h

2021-01-11 Thread Don Poitras

I've never used Metal C, but for the first problem (undeclared __MEMSET), I
would look to see if there's a string.h that can be used. That's normally
where memcmp is defined.

As for the runtime problem, I'd guess it had something to do with using 
'sizeof' incorrectly. It looks as if you are compiling 64-bit which would
mean that 'sizeof(xarg)' is going to be 8. If you replace all the sizeofs
with strlens, I think you'd see it work.


In article 

 you wrote:
> I'm a developer working with a client to develop Metal C functions for their 
> products. Up until recently I've defined __METAL_STATIC and linked with 
> SCCR3BND. I decided recently to play with the dynamic library in LPALIB so I 
> removed that #define. What I'm getting is compile errors on the substitution 
> macros from metal.h. That is the first problem. I decided to try and 
> circumvent the compile errors and I think I found a bug in the memcmp library 
> function. That is the second problem. I'm really hoping someone will tell me 
> I missed something really obvious or missed some maintenance.

> I created a trivial sample program to demonstrate:

> /*
>   Sample for Metal C
> */

> #include 
> #include 

> int main(int argc, char** argv)
> {
>   char* xarg = "abcd";
>   void *mem = malloc(64);
>   memset(mem, 0x0f, 64);
>   memcpy(mem, xarg, sizeof(xarg));
>   int mcmp = memcmp(mem, xarg, sizeof(xarg));
>   free(mem);
> }


-- 
Don Poitras

--
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-11 Thread Jesse 1 Robinson

I can confirm that HTTPS replaces FTP for downloads very nicely. Our use of FTP 
depends on a gizmo (Bluecoat) that cannot understand FTPS. We made the switch 
to HTTPS some time ago. 

Uploading doc (dumps, etc) is also problematic, but IBM has not pulled the plug 
yet on FTP. Nonetheless we also found a way to upload doc via PDUU using HTTPS 
without disturbing the gizmo. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kurt Quackenbush
Sent: Monday, January 11, 2021 5:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: z/OS holddata per https?

*** EXTERNAL EMAIL - Use caution when opening links or attachments ***

> Does anybody a link where these holddata are downloadable via http/s?
Not exactly what you asked for, but you can order and download the HOLDDATA, 
all with HTTPS, using SMP/E RECEIVE ORDER.  Read about it here (watch the wrap:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.gim3000/dsetup.htm

Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when 
he applies PTFs.


--
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-11 Thread Lennie Dymoke-Bradshaw

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 feasible to use IEBGENER with 
non-empty SYSIN, ICEMAN, or TSO EDIT, or ISPF EDIT, or something else.
Caution: things are simple when you just want to replace position 73-80 despite 
of its actual content, that means without checking it.

HTH

--
Radoslaw Skorupka
Lodz, Poland





==

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

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

mBank S.A. z siedzibą w Warszawie, ul. 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)

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

2021-01-11 Thread Lennie Dymoke-Bradshaw

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 feasible to use IEBGENER with 
non-empty SYSIN, ICEMAN, or TSO EDIT, or ISPF EDIT, or something else.
Caution: things are simple when you just want to replace position 73-80 despite 
of its actual content, that means without checking it.

HTH

-- 
Radoslaw Skorupka
Lodz, Poland





==

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

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

mBank S.A. z siedzibą w Warszawie, ul. 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

Compile error and also possible library bug with Metal/C metal.h

2021-01-11 Thread Dennis Fitzpatrick

I'm a developer working with a client to develop Metal C functions for their 
products. Up until recently I've defined __METAL_STATIC and linked with 
SCCR3BND. I decided recently to play with the dynamic library in LPALIB so I 
removed that #define. What I'm getting is compile errors on the substitution 
macros from metal.h. That is the first problem. I decided to try and circumvent 
the compile errors and I think I found a bug in the memcmp library function. 
That is the second problem. I'm really hoping someone will tell me I missed 
something really obvious or missed some maintenance.

I created a trivial sample program to demonstrate:

/*
  Sample for Metal C
*/

#include 
#include 

int main(int argc, char** argv)
{
  char* xarg = "abcd";
  void *mem = malloc(64);
  memset(mem, 0x0f, 64);
  memcpy(mem, xarg, sizeof(xarg));
  int mcmp = memcmp(mem, xarg, sizeof(xarg));
  free(mem);
}
Of course, this compiles and runs just fine on Visual Studio where I do my 
initial development. On z/OS XLC though I get errors like the following:

12   |  memset(mem, 0x0f, 64);  
| 12
12   +  ((___MEMSET * ) ( (*(struct __cvt_s * __ptr32 * __ptr32)16) -> 
__cvtecvt -> __ecvtsdc -> __sdca\+ 12
===> 
b...a.
*=ERROR===> a - CCN3275 Unexpected text ')' encountered.
*=ERROR===> b - CCN3045 Undeclared identifier ___MEMSET.
12   +libv31 -> __libfunc[33] ))(mem, 0x0f, 64);
+ 12
===> 
.c
*=ERROR===> c - CCN3277 Syntax error: possible missing ')' or ','?

The header file include list is exactly what I expect:

1   /usr/include/metal/stdio.h
2   /usr/include/metal/metal.h
3   /usr/include/metal/stddef.h
4   /usr/include/metal/stdlib.h
5   /usr/include/metal/builtins.h

Looking through all of the layers in the metal.h header started me looking for 
aspirin. I decided to push forward as an exercise by defining my own structures 
to use the Metal C function vector. I already had many of the standard z/OS 
structures mapped and added my own mapping of sys_libv31_s with real function 
prototypes:

struct sys_libv31_s
{
  void (*_em_0)();
  int (*_em_abs)(int,int); // 1
  int (*_em_atoi)(char*); // 2
  long (*_em_atol)(char*); // 3
  long long (*_em_atoll)(char*); // 4
  void* (*_em_calloc)(size_t); // 5

And my own substitution macros to remove the metal.h definition and put in my 
own EMCALL reference:

#define EMCALL(_t, _n) (##_t)(*(CVTPTR->CVTECVT->ECVTSDC->sdcalibv31->_em_##_n))
#define em_0  EMCALL(void, em_0)
#undef abs // 1
#define abs EMCALL(int, abs)
#undef atoi // 2
#define atoi EMCALL(int atoi)
#undef atol // 3
#define atol EMCALL(long, atol)
#undef atoll // 4
#define atoll EMCALL(long long, atoll)
#undef calloc // 5
#define calloc EMCALL(void *, calloc)

I can't give you the whole thing as it is too much to extract from client 
proprietary material. Hopefully, this is enough to get the gist.

Now this is where I believe I found a bug in the memcmp function returning an 
invalid result and also a potential S0C4. With getting all of my code to 
compile I found things taking some weird code paths. I tracked it down to a 
memcmp and setup the code in the sample above to test it. I found the memcmp 
above returns an invalid result, 0x0f, even though the memory is equal. I went 
into TEST and disassembled the code and got this:


1F24CD78.STM R14,R3,12(R13)

1F24CD7C.LR  R15,R13

1F24CD7E.L   R13,8(,R13)

1F24CD82.ST  R15,4(,R13)

1F24CD86.STMHR14,R3,80(R13)

1F24CD8C.L   R14,0(,R1)

1F24CD90.L   R2,4(,R1)

1F24CD94.ICM R0,15,8(R1)

1F24CD98.BRC 8,*+52

1F24CD9C.LR  R1,R0

1F24CD9E.LLGCR15,0(,R14)

1F24CDA4.LLGCR3,0(,R2)

1F24CDAA.LA  R14,1(,R14)

1F24CDAE.LA  R2,1(,R2)

1F24CDB2.CR  R15,R3

1F24CDB4.BRC 7,*+36

1F24CDB8.LLGCR15,0(,R14)

1F24CDBE.LLGCR3,0(,R2)

1F24CDC4.BRCTR1,*-26

1F24CDC8.BRC 15,*+16

1F24CDCC.LLGCR15,0(,R14)

1F24CDD2.LLGCR3,0(,R2)

1F24CDD8.SLR R15,R3

1F24CDDA.LMH R14,R3,80(R13)

1F24CDE0.L   R13,4(,R13)

1F24CDE4.L   R14,12(,R13)

1F24CDE8.LM  R1,R3,24(R13)

1F24CDEC.BCR 15,R14

The important thing is that the loop uses R14 & R2 as the character pointers 
and R1 as the count. The loop at D9E loads the first bytes of each memory area. 
Then it increments the pointers, does the compare, and if NE branches to *+36 
(DCC). It then reloads R15 & R3 but the pointers have already been

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

On Mon, 11 Jan 2021 17:58:07 +, Lars Höglund wrote:
>
>You can use SETMSG even in batch that's why ISPMLIB
> 
What is its effect?

>-Ursprungligt meddelande-
>Fr�n:  Seymour J Metz
>Skickat: den 11 januari 2021 18:39
>
>Why a separate allocation step?
>
>Why 3120 for ISPPROF?
> 
BLKSIZE(0)?

How old is that code?  What portable UNIT esoteric is advised for a temp DSN?

--
On Mon, 11 Jan 2021 17:43:09 +, Seymour J Metz wrote:

>ISPF has an ISPEXEC command in support of clists; '"ISPEXEC CONTROL ERRORS 
>RETURN"' is equivalent to 'ADDRESS ISPEXEC "CONTROL ERRORS RETURN"' with more 
>overhead. That rc 20 means that it is not running under ISPF. Under ISPF, the 
>initial environment is ISPEXEC.
>
I thought, TSO.  Silly design.

A mischievous developer might create a command environment named
ADDRESS with an ADDRESS command so:
address ADDRESS 'ADDRESS'
... would work without error.

Contrariwise, when I used CMS/370 ISPF many decades ago, ADDRESS ISREDIT
was mis-implemented.  Something like:
address ISREDIT 'MACRO'
"RC(-3)"
... but:
address ISREDIT 'ISREDIT MACRO'
... succeeded.

-- gil

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

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

2021-01-11 Thread Lars Höglund

This is a sample, do as You please.
This is the way I do it.

Don't use a proc
Use INCLUDE
Or
Don't use INCLUDE.

You can use SETMSG even in batch that's why ISPMLIB

//Lasse

-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List  För Seymour J 
Metz
Skickat: den 11 januari 2021 18:39
Till: IBM-MAIN@LISTSERV.UA.EDU
Ämne: Re: Request for help with removing sequence numbers from PDS members

Why a separate allocation step?

Why 3120 for ISPPROF?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Lars Höglund [lars.hogl...@alecta.se]
Sent: Monday, January 11, 2021 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SV: Request for help with removing sequence numbers from PDS members

Example of ISPF-proc

//*  PROC ISPFBAT
//ISPFBAT  PROC
//*
//*--
//* STEPNAME: CREPROF
//* STEPINFO: CREATE ISPPROF
//*--
//CREPROF  EXEC PGM=IEFBR14
//ISPTLIB  DD DISP=(NEW,PASS),
//SPACE=(TRK,(15,15,5)),
//LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
//DSN=&
//ISPTABL  DD DISP=(NEW,PASS),
//SPACE=(TRK,(15,15,5)),
//LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
//DSN=&
//*
//*--
//* STEPNAME: BATCHPDF
//* STEPINFO: EXECUTE ISPF IN BATCH
//*--
//BATCHPDF EXEC PGM=IKJEFT01,DYNAMNBR=128,
// PARM='ISPSTART CMD( )'
//SYSEXEC  DD  DISP=SHR,DSN=YOUR.ISPEXEC<---
// DD  DISP=SHR,DSN=ISP.SISPEXEC
//SYSPROC  DD  DISP=SHR,DSN=ISP.SISPCLIB //ISPPLIB  DD  
DISP=SHR,DSN=ISP.SISPPENU
//ISPSLIB  DD  DISP=SHR,DSN=YUOR.ISPSLIB<---
// DD  DISP=SHR,DSN=ISP.SISPSLIB
// DD  DISP=SHR,DSN=ISP.SISPSENU
//ISPMLIB  DD  DISP=SHR,DSN=YOUR.ISPMLIB<---
// DD  DISP=SHR,DSN=ISP.SISPMENU
// DD  DISP=SHR,DSN=ISF.SISFMLIB
// DD  DISP=SHR,DSN=SYSU.XMITIP.MSGS
//ISPLLIB  DD  DUMMY
//ISPPROF  DD  UNIT=WORK,SPACE=(TRK,(9,1,4)),
// LRECL=80,BLKSIZE=3120,RECFM=FB,DSORG=PO
//ISPTABL  DD  DISP=(OLD,DELETE),DSN=&

Use of proc

//S010 EXEC ISPFBAT,
// ISPFREX=ACCTCHGN,
// ISPFPRM=''
//BATCHPDF.SYSTSIN  DD  DUMMY


-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List  För Paul 
Gilmartin
Skickat: den 11 januari 2021 17:07
Till: IBM-MAIN@LISTSERV.UA.EDU
Ämne: Re: Request for help with removing sequence numbers from PDS members

On Mon, 11 Jan 2021 15:37:55 +, Sean Gleann wrote:

>Many thanks to all who responded.
>I opted to adapt and (try to) use the REXX that Andy Styles gave, but 
>I'm tripping up over something that has to be one of those 'simple, basic'
>things.
>The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
>I think I've got to use an 'ADDRESS ISPEXEC' command or something like 
>that at the start of the REXX, but attempts at variants of this give 
>the same result.
>
You need to run your Rexx under ISPF, which implies you need to run under TSO.
This can all be done in batch, with suitably complex DD statements.

Otherwise, RC(20)

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

2021-01-11 Thread Seymour J Metz

ISPF has an ISPEXEC command in support of clists; '"ISPEXEC CONTROL ERRORS 
RETURN"' is equivalent to 'ADDRESS ISPEXEC "CONTROL ERRORS RETURN"' with more 
overhead. That rc 20 means that it is not running under ISPF. Under ISPF, the 
initial environment is ISPEXEC.

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

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jeremy Nicoll [jn.ls.mfrm...@letterboxes.org]
Sent: Monday, January 11, 2021 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for help with removing sequence numbers from PDS members

On Mon, 11 Jan 2021, at 15:37, Sean Gleann wrote:
> Many thanks to all who responded.
> I opted to adapt and (try to) use the REXX that Andy Styles gave, but I'm
> tripping up over something that has to be one of those 'simple, basic'
> things.

> The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
> I think I've got to use an 'ADDRESS ISPEXEC' command or something like that
> at the start of the REXX, but attempts at variants of this give the same
> result.

The code should either have

  "address ispexec control errors return"
  "address ispexec whatever ispf command is next"

etc (where every ispf command is prefaced by 'address ispexec'), or

  "address ispexec"
  "control errors return"
  "whatever ispf command is next"

etc, where one sets the addressing environment to ispexec before issuing
a series of commands all intended to be executed under the ispexec
environment.  If you also have non-ispf commands following that you will
need to set their environments appropriately.

And of course it needs run in an ispf environment, so either foreground
ispf or (if in bactch) with all the appropriate batch ispf datasets allocated.

--
Jeremy Nicoll - my opinions are my own.

--
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-11 Thread Seymour J Metz

Why a separate allocation step?

Why 3120 for ISPPROF?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Lars Höglund [lars.hogl...@alecta.se]
Sent: Monday, January 11, 2021 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SV: Request for help with removing sequence numbers from PDS members

Example of ISPF-proc

//*  PROC ISPFBAT
//ISPFBAT  PROC
//*
//*--
//* STEPNAME: CREPROF
//* STEPINFO: CREATE ISPPROF
//*--
//CREPROF  EXEC PGM=IEFBR14
//ISPTLIB  DD DISP=(NEW,PASS),
//SPACE=(TRK,(15,15,5)),
//LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
//DSN=&
//ISPTABL  DD DISP=(NEW,PASS),
//SPACE=(TRK,(15,15,5)),
//LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
//DSN=&
//*
//*--
//* STEPNAME: BATCHPDF
//* STEPINFO: EXECUTE ISPF IN BATCH
//*--
//BATCHPDF EXEC PGM=IKJEFT01,DYNAMNBR=128,
// PARM='ISPSTART CMD( )'
//SYSEXEC  DD  DISP=SHR,DSN=YOUR.ISPEXEC<---
// DD  DISP=SHR,DSN=ISP.SISPEXEC
//SYSPROC  DD  DISP=SHR,DSN=ISP.SISPCLIB
//ISPPLIB  DD  DISP=SHR,DSN=ISP.SISPPENU
//ISPSLIB  DD  DISP=SHR,DSN=YUOR.ISPSLIB<---
// DD  DISP=SHR,DSN=ISP.SISPSLIB
// DD  DISP=SHR,DSN=ISP.SISPSENU
//ISPMLIB  DD  DISP=SHR,DSN=YOUR.ISPMLIB<---
// DD  DISP=SHR,DSN=ISP.SISPMENU
// DD  DISP=SHR,DSN=ISF.SISFMLIB
// DD  DISP=SHR,DSN=SYSU.XMITIP.MSGS
//ISPLLIB  DD  DUMMY
//ISPPROF  DD  UNIT=WORK,SPACE=(TRK,(9,1,4)),
// LRECL=80,BLKSIZE=3120,RECFM=FB,DSORG=PO
//ISPTABL  DD  DISP=(OLD,DELETE),DSN=&

Use of proc

//S010 EXEC ISPFBAT,
// ISPFREX=ACCTCHGN,
// ISPFPRM=''
//BATCHPDF.SYSTSIN  DD  DUMMY


-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List  För Paul 
Gilmartin
Skickat: den 11 januari 2021 17:07
Till: IBM-MAIN@LISTSERV.UA.EDU
Ämne: Re: Request for help with removing sequence numbers from PDS members

On Mon, 11 Jan 2021 15:37:55 +, Sean Gleann wrote:

>Many thanks to all who responded.
>I opted to adapt and (try to) use the REXX that Andy Styles gave, but
>I'm tripping up over something that has to be one of those 'simple, basic'
>things.
>The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
>I think I've got to use an 'ADDRESS ISPEXEC' command or something like
>that at the start of the REXX, but attempts at variants of this give
>the same result.
>
You need to run your Rexx under ISPF, which implies you need to run under TSO.
This can all be done in batch, with suitably complex DD statements.

Otherwise, RC(20)

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

2021-01-11 Thread Seymour J Metz

'"ISPEXEC CONTROL ERRORS RETURN"' is just 'address ISPEXEC "CONTROL ERRORS 
RETURN"' with more overhead.

'"ADDRESS ISPEXEC CONTROL ERRORS RETURN"" is wrong because there is no ADDRESS 
command.

'"CONTROL ERRORS RETURN"' is only valid in the ISPEXEC environment, which 
requires that you be running under ISPF.

For debugging, display the environment.

Any further analysis would require seeing your JCL and code.


--
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: Monday, January 11, 2021 11:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for help with removing sequence numbers from PDS members

Jeremy - I tried variants of what you suggest, but all to no avail.

"ISPEXEC CONTROL ERRORS RETURN" appears to be OK - at least, there's no
error message.

"ADDRESS ISPEXEC CONTROL ERRORS RETURN" results in
IKJ56500I COMMAND ADDRESS NOT FOUND
   +++ RC(-3) +++

Splitting the command into two gives
"ADDRESS ISPEXEC"
IKJ56500I COMMAND ADDRESS NOT FOUND
   +++ RC(-3) +++
"CONTROL ERRORS RETURN"
IKJ56500I COMMAND CONTROL NOT FOUND
   +++ RC(-3) +++

So I'm at a bit of a loss, really.
RC(-3) is an environment problem, no?

I'm trying to run the REXX in in a batch job with IKJEFT01.
I've got DD statements for ISP[M,P,S,T,]LIB pointing at relevant datasets
and a (now corrected) DD for ISPPROF, referring to a temporary file.
A SYSEXEC DD points to the PDS containing my REXX program.
For the SYSTSIN, I've got ISPSTART CMD()

The next command in the REXX is "ISREDIT MACRO", but that leads back to the
RC(20) situation
"ISPEXEC CONTROL ERRORS RETURN"
"ISREDIT MACRO"
  +++ RC(20) +++

Regards
Sean

On Mon, 11 Jan 2021 at 16:18, Lars Höglund  wrote:

> Example of ISPF-proc
>
> //*  PROC ISPFBAT
> //ISPFBAT  PROC
> //*
> //*--
> //* STEPNAME: CREPROF
> //* STEPINFO: CREATE ISPPROF
> //*--
> //CREPROF  EXEC PGM=IEFBR14
> //ISPTLIB  DD DISP=(NEW,PASS),
> //SPACE=(TRK,(15,15,5)),
> //LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
> //DSN=&
> //ISPTABL  DD DISP=(NEW,PASS),
> //SPACE=(TRK,(15,15,5)),
> //LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
> //DSN=&
> //*
> //*--
> //* STEPNAME: BATCHPDF
> //* STEPINFO: EXECUTE ISPF IN BATCH
> //*--
> //BATCHPDF EXEC PGM=IKJEFT01,DYNAMNBR=128,
> // PARM='ISPSTART CMD( )'
> //SYSEXEC  DD  DISP=SHR,DSN=YOUR.ISPEXEC<---
> // DD  DISP=SHR,DSN=ISP.SISPEXEC
> //SYSPROC  DD  DISP=SHR,DSN=ISP.SISPCLIB
> //ISPPLIB  DD  DISP=SHR,DSN=ISP.SISPPENU
> //ISPSLIB  DD  DISP=SHR,DSN=YUOR.ISPSLIB<---
> // DD  DISP=SHR,DSN=ISP.SISPSLIB
> // DD  DISP=SHR,DSN=ISP.SISPSENU
> //ISPMLIB  DD  DISP=SHR,DSN=YOUR.ISPMLIB<---
> // DD  DISP=SHR,DSN=ISP.SISPMENU
> // DD  DISP=SHR,DSN=ISF.SISFMLIB
> // DD  DISP=SHR,DSN=SYSU.XMITIP.MSGS
> //ISPLLIB  DD  DUMMY
> //ISPPROF  DD  UNIT=WORK,SPACE=(TRK,(9,1,4)),
> // LRECL=80,BLKSIZE=3120,RECFM=FB,DSORG=PO
> //ISPTABL  DD  DISP=(OLD,DELETE),DSN=&
>
> Use of proc
>
> //S010 EXEC ISPFBAT,
> // ISPFREX=ACCTCHGN,
> // ISPFPRM=''
> //BATCHPDF.SYSTSIN  DD  DUMMY
>
>
> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List  För Paul
> Gilmartin
> Skickat: den 11 januari 2021 17:07
> Till: IBM-MAIN@LISTSERV.UA.EDU
> Ämne: Re: Request for help with removing sequence numbers from PDS members
>
> On Mon, 11 Jan 2021 15:37:55 +, Sean Gleann wrote:
>
> >Many thanks to all who responded.
> >I opted to adapt and (try to) use the REXX that Andy Styles gave, but
> >I'm tripping up over something that has to be one of those 'simple, basic'
> >things.
> >The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
> >I think I've got to use an 'ADDRESS ISPEXEC' command or something like
> >that at the start of the REXX, but attempts at variants of this give
> >the same result.
> >
> You need to run your Rexx under ISPF, which implies you need to run under
> TSO.
> This can all be done in batch, with suitably complex DD statements.
>
> Otherwise, RC(20)
>
> -- 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

2021-01-11 Thread Styles, Andy (ITS zPlatform Services)

Classification: Public

ISREDIT MACRO must be the first macro command in a macro. The ISPEXEC doesn't 
count as a macro command; they can certainly be used prior to an ISREDIT MACRO 
command.

I have many examples of this usage to determine whether a command is being 
called as a macro or a command.

Andy Styles
z/Series System Programmer

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: 11 January 2021 16:56
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for help with removing sequence numbers from PDS members

-- This email has reached the Bank via an external source --

On Mon, 11 Jan 2021 16:36:35 +, Sean Gleann  wrote:
>
>The next command in the REXX is "ISREDIT MACRO", but that leads back to 
>the
>RC(20) situation
>"ISPEXEC CONTROL ERRORS RETURN"
>"ISREDIT MACRO"
>  +++ RC(20) +++
> 
"ISREDIT MACRO" must be the first command in a MACRO.  It may not follow 
"ISPEXEC ..."

At times I have needed two SYSEXEC members, one to start Edit with the second 
as the initial MACRO.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555.

Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. 
Registered in England and Wales no. 2065. Telephone 0207626 1500.

Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC327000. Telephone: 03457 801 801.

Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London 
EC2V 7HN. Registered in England and Wales no. 10399850.

Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham 
Street, London EC2V 7HN. Registered in England and Wales no. 11722983.

Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are 
authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority and Prudential Regulation Authority.

Scottish Widows Schroder Personal Wealth Limited is authorised and regulated by 
the Financial Conduct Authority.

Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned 
subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 
6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht 
Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für 
Finanzdienstleistungsaufsicht.

Halifax is a division of Bank of Scotland plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.

--
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 Mon, 11 Jan 2021 16:36:35 +, Sean Gleann  wrote:
>
>The next command in the REXX is "ISREDIT MACRO", but that leads back to the
>RC(20) situation
>"ISPEXEC CONTROL ERRORS RETURN"
>"ISREDIT MACRO"
>  +++ RC(20) +++
> 
"ISREDIT MACRO" must be the first command in a MACRO.  It may not
follow "ISPEXEC ..."

At times I have needed two SYSEXEC members, one to start Edit with
the second as the initial MACRO.

-- gil

--
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-11 Thread Charles Mills

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Monday, January 11, 2021 6:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Code to verify LOGON password

Isn't there a program someone wrote (talked about here many years ago) 
that can try various passwords until something matches the hashed value? 
  If that's the case, hashing doesn't really do as much good as people 
think it does, once someone gets hold of the RACF dataset of course.

--
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 Mon, 11 Jan 2021 16:36:35 +, Sean Gleann wrote:
>
>"ADDRESS ISPEXEC CONTROL ERRORS RETURN" results in
>IKJ56500I COMMAND ADDRESS NOT FOUND
>   +++ RC(-3) +++
> 
ADDRESS is a Rexx bultin instruction.  It should not be quoted
as if it were a host command.

-- 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 Mon, 11 Jan 2021 16:17:43 +, Lars Höglund wrote:

>Example of ISPF-proc
>
>//*  PROC ISPFBAT  
>//ISPFBAT  PROC
>//*
>//*--  
>//* STEPNAME: CREPROF  
>//* STEPINFO: CREATE ISPPROF   
>//*--  
>//CREPROF  EXEC PGM=IEFBR14   
>
Couldn't these allocations be done in the BATCHPDF proc step, saving
one step?
 
>//ISPTLIB  DD DISP=(NEW,PASS), 
>//SPACE=(TRK,(15,15,5)),   
>//LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
>//DSN=&ISPTLIB
>
Where iSPTLIB used?

>//ISPTABL  DD DISP=(NEW,PASS), 
>//SPACE=(TRK,(15,15,5)),   
>//LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
>//DSN=&ISPTABL
>//*
>//*--  
>//* STEPNAME: BATCHPDF 
>//* STEPINFO: EXECUTE ISPF IN BATCH
>//*--  
>//BATCHPDF EXEC PGM=IKJEFT01,DYNAMNBR=128, 
>// PARM='ISPSTART CMD( )'  
>//SYSEXEC  DD  DISP=SHR,DSN=YOUR.ISPEXEC<---   
>// DD  DISP=SHR,DSN=ISP.SISPEXEC  
>
At times I've made SYSEXEC a temp DSN, with the BATCH step an IKJEFT*
beginning with a REPRO to copy SYSIN to a SYSEXEC member.  This makes
the JCL self-contained.

>//SYSPROC  DD  DISP=SHR,DSN=ISP.SISPCLIB   
>//ISPPLIB  DD  DISP=SHR,DSN=ISP.SISPPENU   
>//ISPSLIB  DD  DISP=SHR,DSN=YUOR.ISPSLIB<---   
>// DD  DISP=SHR,DSN=ISP.SISPSLIB   
>// DD  DISP=SHR,DSN=ISP.SISPSENU   
>//ISPMLIB  DD  DISP=SHR,DSN=YOUR.ISPMLIB<---   
>// DD  DISP=SHR,DSN=ISP.SISPMENU   
>// DD  DISP=SHR,DSN=ISF.SISFMLIB   
>// DD  DISP=SHR,DSN=SYSU.XMITIP.MSGS   
>//ISPLLIB  DD  DUMMY   
>//ISPPROF  DD  UNIT=WORK,SPACE=(TRK,(9,1,4)),  
>// LRECL=80,BLKSIZE=3120,RECFM=FB,DSORG=PO 
> 
I endorse such use of a temp DSN for ISPPROF, avoiding ENQ conflicts
and making the PROC more useful to the general public.

>//ISPTABL  DD  DISP=(OLD,DELETE),DSN=&ISPTABL 
>
Is DELETE necessary?  Isn't that automatic for temp DSNs?

Are all the allocations above necessary in batch?  How is ISPMLIB useful?
Could they be made temp DSNs?

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

Jeremy - I tried variants of what you suggest, but all to no avail.

"ISPEXEC CONTROL ERRORS RETURN" appears to be OK - at least, there's no
error message.

"ADDRESS ISPEXEC CONTROL ERRORS RETURN" results in
IKJ56500I COMMAND ADDRESS NOT FOUND
   +++ RC(-3) +++

Splitting the command into two gives
"ADDRESS ISPEXEC"
IKJ56500I COMMAND ADDRESS NOT FOUND
   +++ RC(-3) +++
"CONTROL ERRORS RETURN"
IKJ56500I COMMAND CONTROL NOT FOUND
   +++ RC(-3) +++

So I'm at a bit of a loss, really.
RC(-3) is an environment problem, no?

I'm trying to run the REXX in in a batch job with IKJEFT01.
I've got DD statements for ISP[M,P,S,T,]LIB pointing at relevant datasets
and a (now corrected) DD for ISPPROF, referring to a temporary file.
A SYSEXEC DD points to the PDS containing my REXX program.
For the SYSTSIN, I've got ISPSTART CMD()

The next command in the REXX is "ISREDIT MACRO", but that leads back to the
RC(20) situation
"ISPEXEC CONTROL ERRORS RETURN"
"ISREDIT MACRO"
  +++ RC(20) +++

Regards
Sean

On Mon, 11 Jan 2021 at 16:18, Lars Höglund  wrote:

> Example of ISPF-proc
>
> //*  PROC ISPFBAT
> //ISPFBAT  PROC
> //*
> //*--
> //* STEPNAME: CREPROF
> //* STEPINFO: CREATE ISPPROF
> //*--
> //CREPROF  EXEC PGM=IEFBR14
> //ISPTLIB  DD DISP=(NEW,PASS),
> //SPACE=(TRK,(15,15,5)),
> //LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
> //DSN=&
> //ISPTABL  DD DISP=(NEW,PASS),
> //SPACE=(TRK,(15,15,5)),
> //LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
> //DSN=&
> //*
> //*--
> //* STEPNAME: BATCHPDF
> //* STEPINFO: EXECUTE ISPF IN BATCH
> //*--
> //BATCHPDF EXEC PGM=IKJEFT01,DYNAMNBR=128,
> // PARM='ISPSTART CMD( )'
> //SYSEXEC  DD  DISP=SHR,DSN=YOUR.ISPEXEC<---
> // DD  DISP=SHR,DSN=ISP.SISPEXEC
> //SYSPROC  DD  DISP=SHR,DSN=ISP.SISPCLIB
> //ISPPLIB  DD  DISP=SHR,DSN=ISP.SISPPENU
> //ISPSLIB  DD  DISP=SHR,DSN=YUOR.ISPSLIB<---
> // DD  DISP=SHR,DSN=ISP.SISPSLIB
> // DD  DISP=SHR,DSN=ISP.SISPSENU
> //ISPMLIB  DD  DISP=SHR,DSN=YOUR.ISPMLIB<---
> // DD  DISP=SHR,DSN=ISP.SISPMENU
> // DD  DISP=SHR,DSN=ISF.SISFMLIB
> // DD  DISP=SHR,DSN=SYSU.XMITIP.MSGS
> //ISPLLIB  DD  DUMMY
> //ISPPROF  DD  UNIT=WORK,SPACE=(TRK,(9,1,4)),
> // LRECL=80,BLKSIZE=3120,RECFM=FB,DSORG=PO
> //ISPTABL  DD  DISP=(OLD,DELETE),DSN=&
>
> Use of proc
>
> //S010 EXEC ISPFBAT,
> // ISPFREX=ACCTCHGN,
> // ISPFPRM=''
> //BATCHPDF.SYSTSIN  DD  DUMMY
>
>
> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List  För Paul
> Gilmartin
> Skickat: den 11 januari 2021 17:07
> Till: IBM-MAIN@LISTSERV.UA.EDU
> Ämne: Re: Request for help with removing sequence numbers from PDS members
>
> On Mon, 11 Jan 2021 15:37:55 +, Sean Gleann wrote:
>
> >Many thanks to all who responded.
> >I opted to adapt and (try to) use the REXX that Andy Styles gave, but
> >I'm tripping up over something that has to be one of those 'simple, basic'
> >things.
> >The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
> >I think I've got to use an 'ADDRESS ISPEXEC' command or something like
> >that at the start of the REXX, but attempts at variants of this give
> >the same result.
> >
> You need to run your Rexx under ISPF, which implies you need to run under
> TSO.
> This can all be done in batch, with suitably complex DD statements.
>
> Otherwise, RC(20)
>
> -- 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

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

2021-01-11 Thread Lars Höglund

Example of ISPF-proc

//*  PROC ISPFBAT  
//ISPFBAT  PROC
//*
//*--  
//* STEPNAME: CREPROF  
//* STEPINFO: CREATE ISPPROF   
//*--  
//CREPROF  EXEC PGM=IEFBR14
//ISPTLIB  DD DISP=(NEW,PASS), 
//SPACE=(TRK,(15,15,5)),   
//LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
//DSN=&
//ISPTABL  DD DISP=(NEW,PASS), 
//SPACE=(TRK,(15,15,5)),   
//LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
//DSN=&
//*
//*--  
//* STEPNAME: BATCHPDF 
//* STEPINFO: EXECUTE ISPF IN BATCH
//*--  
//BATCHPDF EXEC PGM=IKJEFT01,DYNAMNBR=128, 
// PARM='ISPSTART CMD( )'  
//SYSEXEC  DD  DISP=SHR,DSN=YOUR.ISPEXEC<---   
// DD  DISP=SHR,DSN=ISP.SISPEXEC   
//SYSPROC  DD  DISP=SHR,DSN=ISP.SISPCLIB   
//ISPPLIB  DD  DISP=SHR,DSN=ISP.SISPPENU   
//ISPSLIB  DD  DISP=SHR,DSN=YUOR.ISPSLIB<---   
// DD  DISP=SHR,DSN=ISP.SISPSLIB   
// DD  DISP=SHR,DSN=ISP.SISPSENU   
//ISPMLIB  DD  DISP=SHR,DSN=YOUR.ISPMLIB<---   
// DD  DISP=SHR,DSN=ISP.SISPMENU   
// DD  DISP=SHR,DSN=ISF.SISFMLIB   
// DD  DISP=SHR,DSN=SYSU.XMITIP.MSGS   
//ISPLLIB  DD  DUMMY   
//ISPPROF  DD  UNIT=WORK,SPACE=(TRK,(9,1,4)),  
// LRECL=80,BLKSIZE=3120,RECFM=FB,DSORG=PO 
//ISPTABL  DD  DISP=(OLD,DELETE),DSN=& 

Use of proc

//S010 EXEC ISPFBAT, 
// ISPFREX=ACCTCHGN, 
// ISPFPRM=''   
//BATCHPDF.SYSTSIN  DD  DUMMY


-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List  För Paul 
Gilmartin
Skickat: den 11 januari 2021 17:07
Till: IBM-MAIN@LISTSERV.UA.EDU
Ämne: Re: Request for help with removing sequence numbers from PDS members

On Mon, 11 Jan 2021 15:37:55 +, Sean Gleann wrote:

>Many thanks to all who responded.
>I opted to adapt and (try to) use the REXX that Andy Styles gave, but 
>I'm tripping up over something that has to be one of those 'simple, basic'
>things.
>The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
>I think I've got to use an 'ADDRESS ISPEXEC' command or something like 
>that at the start of the REXX, but attempts at variants of this give 
>the same result.
> 
You need to run your Rexx under ISPF, which implies you need to run under TSO.
This can all be done in batch, with suitably complex DD statements.

Otherwise, RC(20)

-- 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 Mon, 11 Jan 2021 15:37:55 +, Sean Gleann wrote:

>Many thanks to all who responded.
>I opted to adapt and (try to) use the REXX that Andy Styles gave, but I'm
>tripping up over something that has to be one of those 'simple, basic'
>things.
>The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
>I think I've got to use an 'ADDRESS ISPEXEC' command or something like that
>at the start of the REXX, but attempts at variants of this give the same
>result.
> 
You need to run your Rexx under ISPF, which implies you need to run under TSO.
This can all be done in batch, with suitably complex DD statements.

Otherwise, RC(20)

-- 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-11 Thread Jeremy Nicoll

On Mon, 11 Jan 2021, at 15:37, Sean Gleann wrote:
> Many thanks to all who responded.
> I opted to adapt and (try to) use the REXX that Andy Styles gave, but I'm
> tripping up over something that has to be one of those 'simple, basic'
> things.

> The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
> I think I've got to use an 'ADDRESS ISPEXEC' command or something like that
> at the start of the REXX, but attempts at variants of this give the same
> result.

The code should either have 

  "address ispexec control errors return"
  "address ispexec whatever ispf command is next"

etc (where every ispf command is prefaced by 'address ispexec'), or 

  "address ispexec"
  "control errors return" 
  "whatever ispf command is next"

etc, where one sets the addressing environment to ispexec before issuing
a series of commands all intended to be executed under the ispexec 
environment.  If you also have non-ispf commands following that you will 
need to set their environments appropriately.

And of course it needs run in an ispf environment, so either foreground
ispf or (if in bactch) with all the appropriate batch ispf datasets allocated.

-- 
Jeremy Nicoll - my opinions are my own.

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

Please ignore my last...
yep - it was one of those 'simple basic' things.
I had a DD statement to define a temporary ISPPROF, where I'd coded
'DSORG=PS' instead of 'PO'.
(seems strange that you can code 'SPACE=(TRK,(1,1,1))' along with
'DSORG=PS' without getting at least a warning...)
Regards
Sean

On Mon, 11 Jan 2021 at 15:37, Sean Gleann  wrote:

> Many thanks to all who responded.
> I opted to adapt and (try to) use the REXX that Andy Styles gave, but I'm
> tripping up over something that has to be one of those 'simple, basic'
> things.
> The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
> I think I've got to use an 'ADDRESS ISPEXEC' command or something like
> that at the start of the REXX, but attempts at variants of this give the
> same result.
> Any clues, anyone... please?
>
> Regards
> Sean
>
>
> On Mon, 11 Jan 2021 at 12:26, Lennie Bradshaw <
> 032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote:
>
>> 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 feasible to use
>> IEBGENER with non-empty SYSIN, ICEMAN, or TSO EDIT, or ISPF EDIT, or
>> something else.
>> Caution: things are simple when you just want to replace position 73-80
>> despite of its actual content, that means without checking it.
>>
>> HTH
>>
>> --
>> Radoslaw Skorupka
>> Lodz, Poland
>>
>>
>>
>>
>>
>> ==
>>
>> Jeśli nie jesteś adresatem tej wiadomości:
>>
>> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
>> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
>> zapisałeś na dysku).
>> Wiadomość ta może zawierać chronione prawem informacje, które może
>> wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia
>> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
>> narusza prawo i może podlegać karze.
>>
>> mBank S.A. z siedzibą w Warszawie, ul. 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

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

Many thanks to all who responded.
I opted to adapt and (try to) use the REXX that Andy Styles gave, but I'm
tripping up over something that has to be one of those 'simple, basic'
things.
The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
I think I've got to use an 'ADDRESS ISPEXEC' command or something like that
at the start of the REXX, but attempts at variants of this give the same
result.
Any clues, anyone... please?

Regards
Sean


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

> 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 feasible to use
> IEBGENER with non-empty SYSIN, ICEMAN, or TSO EDIT, or ISPF EDIT, or
> something else.
> Caution: things are simple when you just want to replace position 73-80
> despite of its actual content, that means without checking it.
>
> HTH
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. 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),

Re: Code to verify LOGON password

2021-01-11 Thread Chris Hoelscher

Yes - we used one years ago - as part of a govt audit - one year it got 
accidentally run multiple times and the multiple failed passwords exceeded the 
RACF/ACF2 threshhold - thousands of accounts were locked until unlocked the 
next day ... I do not have firsthand knowledge of the name of the product, only 
that it existed  

Chris Hoelscher
Lead Sys DBA 
IBM Global Technical Services on assignmemt to Humana Inc.
T 502.476.2538  or 502.407.7266

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: Monday, January 11, 2021 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Code to verify LOGON password

[External Email: Use caution with links and attachments]

Isn't there a program someone wrote (talked about here many years ago) that can 
try various passwords until something matches the hashed value?
  If that's the case, hashing doesn't really do as much good as people think it 
does, once someone gets hold of the RACF dataset of course.

On 1/10/2021 7:57 PM, Timothy Sipples wrote:

> Here's a pedantic point: RACF doesn't actually know what the user's 
> password is -- thank goodness. RACF can only determine whether a 
> particular password or passphrase string mathematically corresponds to 
> the hashed value (derived from previous input) that RACF stores. True, 
> good hashing functions minimize collisions, and RACF uses good hashing 
> functions.

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, ancestry, 
age, disability, sex,
marital status, gender, sexual orientation, gender identity, or religion. 
Humana Inc. and its subsidiaries do not
exclude people or treat them differently because of race, color, national 
origin, ancestry, age,
disability, sex, marital status, gender, sexual orientation, gender identity, 
or religion.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.

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

Re: z/OS Git/SSH Help - Configuration Issue ?

2021-01-11 Thread Jousma, David

Speaking of GIT, IBM seems to be distributing Rocket Git z/OS client with their 
ADFz offering.   That is great because we are just moving to mainframe DEVOPS 
with GIT, etc and support for that piece of software now comes through IBM, 
instead of paying Rocket for a separate Support offering...

_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B Dyck
Sent: Monday, January 11, 2021 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS Git/SSH Help - Configuration Issue ?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I have a test lpar that I've been given access to and I have installed Git 
(both 2.14 and 2.26) and have the same issues with either release so I'm 
thinking it is outside of git.

 

When I issue the command: ssh g...@github.com  
git-receive-pack lbdyck/racfadm.git I get a response that looks like ascii text 
yet on my work lpar the text if readable. I have confirmed that both ssh and 
sftp work from my windows pc to this test lpar.  

 

Does anyone have any pointers on where to look to fix this?

 

Thanks in advance.

 

Lionel B. Dyck <

Website:   https://www.lbdsoftware.com

 

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

 


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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


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.

First is obvious.

Effectiveness of the second is disputable, but it rather won't help 
hackers. The idea is to

a) give less time for password cracking.
b) give less time for using of intercepted user/password.
c) give less possibilities to peek co-workers password (next letters).
There is also disadvantage: too complex and too frequently changed 
password lead to yellow stickers.


Third can be surprising for some people, but this method provide much 
more time consuming method of password hashing. Much more is tens of 
thousands. That means brute force attack would take tens of thousands 
times more time. It is still finite, but much longer.


Fourth method provide much more space for passwords. Let's forget about 
social hacking for a while, just "blind" brute force. To simplify - 
8-char password could mean 39^8 combinations (roughly, these 
calculations are not exact). 16-char password is 39^8 * 39^8 - that's 
5 352 009 260 481 times more combinations. And 24-char password gives 
28 644 003 124 274 380 508 351 361 times more.


The above is not exact analysis. Password and passphrase space is 
limited by some rules, but there are also shorter passwords and much 
more lenghts of passphrases - 100,99,98,97,96...11,10,9. A lot of.



My €0.02

--
Radoslaw Skorupka
Lodz, Poland






W dniu 11.01.2021 o 15:39, Tom Brennan pisze:
Isn't there a program someone wrote (talked about here many years ago) 
that can try various passwords until something matches the hashed 
value?  If that's the case, hashing doesn't really do as much good as 
people think it does, once someone gets hold of the RACF dataset of 
course.


On 1/10/2021 7:57 PM, Timothy Sipples wrote:


Here's a pedantic point: RACF doesn't actually know what the user's
password is -- thank goodness. RACF can only determine whether a
particular password or passphrase string mathematically corresponds 
to the

hashed value (derived from previous input) that RACF stores. True, good
hashing functions minimize collisions, and RACF uses good hashing
functions.


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




==

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.

Re: Code to verify LOGON password

2021-01-11 Thread Tom Brennan

Isn't there a program someone wrote (talked about here many years ago) 
that can try various passwords until something matches the hashed value? 
 If that's the case, hashing doesn't really do as much good as people 
think it does, once someone gets hold of the RACF dataset of course.


On 1/10/2021 7:57 PM, Timothy Sipples wrote:


Here's a pedantic point: RACF doesn't actually know what the user's
password is -- thank goodness. RACF can only determine whether a
particular password or passphrase string mathematically corresponds to the
hashed value (derived from previous input) that RACF stores. True, good
hashing functions minimize collisions, and RACF uses good hashing
functions.


--
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-11 Thread Kurt Quackenbush


Does anybody a link where these holddata are downloadable via http/s?
Not exactly what you asked for, but you can order and download the 
HOLDDATA, all with HTTPS, using SMP/E RECEIVE ORDER.  Read about it here 
(watch the wrap:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.gim3000/dsetup.htm

Kurt Quackenbush -- IBM, SMP/E Development
Chuck Norris never uses CHECK when he applies PTFs.

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

z/OS Git/SSH Help - Configuration Issue ?

2021-01-11 Thread Lionel B Dyck

I have a test lpar that I've been given access to and I have installed Git
(both 2.14 and 2.26) and have the same issues with either release so I'm
thinking it is outside of git.

 

When I issue the command: ssh g...@github.com 
git-receive-pack lbdyck/racfadm.git I get a response that looks like ascii
text yet on my work lpar the text if readable. I have confirmed that both
ssh and sftp work from my windows pc to this test lpar.  

 

Does anyone have any pointers on where to look to fix this?

 

Thanks in advance.

 

Lionel B. Dyck <

Website:   https://www.lbdsoftware.com

 

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

 


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

YADRO mainframes?


I just found some IBM document showin parameters of ...YADRO mainframes.
It is dated 30-04-2017.
Yes, the term "mainframe" is used. There are parameters like MSU, 
keywords like PSLC, zNALC, Coupling Facility, z/OS, z/VSE, etc.


YADRO is russian IT company - that's all I know. I'm even not sure it is 
not coincidence.



Can anyone sched some light on that?

--
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: Anyone using IBM Cloud Tape Connector?


W dniu 11.01.2021 o 12:07, David Spiegel pisze:

Hi Tim,
You said: "... but there are at least three choices ..."
Other than RACF, ACF2 and TSS are there others?


Yes. However IMHO none of them is active.
Examples:
1. Deadbolt. It was announced, but I don't know if any shop implemented it.
2. PIES. Polish product (pies = dog), offered by Mainframe Ltd. from 
Raszyn, Poland.



--
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-11 Thread Lennie Bradshaw

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 feasible to use 
IEBGENER with non-empty SYSIN, ICEMAN, or TSO EDIT, or ISPF EDIT, or 
something else.
Caution: things are simple when you just want to replace position 73-80 
despite of its actual content, that means without checking it.

HTH

-- 
Radoslaw Skorupka
Lodz, Poland

==

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

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

mBank S.A. z siedzibą w Warszawie, ul. 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

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

z/OS holddata per https?

2021-01-11 Thread Barbara Nitz

Happy New Year to all of you!

my employer has decided that ftp is not allowed anymore anywhere. Today I tried 
to download the newest holddata from 
http://service.software.ibm.com/holdata/390holddata.html. The file I'm 
interested in (full data, plain text) is a link to 
ftp://public.dhe.ibm.com/s390/holddata/full.txt. This is an ftp-Link, and ftp 
is not allowed anywhere. I get a connection failed error, purely on our side. 
So no holddata :-(

Does anybody a link where these holddata are downloadable via http/s?

Best regards, Barbara

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

Re: Anyone using IBM Cloud Tape Connector?

2021-01-11 Thread David Spiegel

Hi Tim,
You said: "... but there are at least three choices ..."
Other than RACF, ACF2 and TSS are there others?

Thanks and regards,
David

On 2021-01-10 23:23, Timothy Sipples wrote:

Brian Westerman asks:

Is anyone using IBM's Cloud Tape Connector product that can tell me
about the software requirements for it? Is it just the product that
needs to be licensed under z/OS, or do you need to license so "other"
stuff as well?

I can answer the licensing questions unofficially, i.e. based on my best
understanding. In the hopefully unlikely event IBM officially communicates
something at odds with what I'm writing, of course that'd be controlling.

IBM Cloud Tape Connector for z/OS does not have any particular software
product prerequisites or co-requisites except the base z/OS operating
system. Reference:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSS6GQC_2.1.0%2Fconcepts%2Fcuzucon_requirements.htmldata=04%7C01%7C%7Cbb994afea3d94ffaea8708d8b5e8b9d2%7C84df9e7fe9f640afb435%7C1%7C0%7C637459358454931897%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9a95aqrqtqJ9D1yqJUoEtAd8uOOwwBFuZE%2FcJvURMmQ%3Dreserved=0

As a practical matter you'll need a SAF-compatible security manager. The
z/OS Security Server (RACF) is my favorite, but there are at least three
choices. You're highly likely to need some cloud object storage targets,
on and/or off premises, which may have their own licensing or subscription
requirements. However, there are sometimes free tiers available. IBM Cloud
Object Storage, for example, offers a free "Lite" tier that could serve as
a test target at least.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fcloud%2Fobject-storage%2Fpricingdata=04%7C01%7C%7Cbb994afea3d94ffaea8708d8b5e8b9d2%7C84df9e7fe9f640afb435%7C1%7C0%7C637459358454931897%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Bwgxv2con7qADJs4iiBXN4g92f2El91YZAKtwdZ5jTQ%3Dreserved=0

You can license IBM Cloud Tape Connector for z/OS either separately (IBM
Program No. 5698-ABM) or as part of the IBM Advanced Storage Management
Suite for z/OS (5698-AAJ). License quantities are based on Value Unit
Exhibit 007 (VUE007). It's z/OS-based subcapacity licensing eligible,
including Tailored Fit Pricing eligible. On/Off Capacity On Demand (CoD)
licensing is also available. If you'd like me to elaborate on any of these
parts, just ask.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
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-11 Thread Styles, Andy (ITS zPlatform Services)

Classification: Public

Should have pointed out that you obviously needed to have copied your source 
dataset to your target before running this on the target. DFDSS, IEBCOPY, take 
your pick.

Andy Styles
z/Series System Programmer

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Styles, Andy (ITS zPlatform Services)
Sent: 11 January 2021 10:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for help with removing sequence numbers from PDS members

-- This email has reached the Bank via an external source --
 

Classification: Public

Quick and dirty - assumes the profile will put numbers in 73-80, and doesn't do 
much in the way of error checking:

/* REXX */ 
   
parse source . . me .  
   
arg dataset .  
   
"ISPEXEC CONTROL ERRORS RETURN"
"ISREDIT MACRO"
edMac = rc 
"ISPEXEC CONTROL ERRORS CANCEL"
   
if edMac = 0 then do   
   call macroMode  
   exit
end
   
"ISPEXEC LMINIT DATAID(DSN) DATASET('"dataset"') ENQ(SHR)" 
"ISPEXEC LMOPEN DATAID()"  
   
Do until RC > 0 
   "ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMBER) STATS(NO)"
   If RC = 8 Then  
  Leave
   If RC = 0 Then  
  "ISPEXEC EDIT DATAID() MEMBER() MACRO()"   
End
   
"ISPEXEC LMCLOSE DATAID()" 
"ISPEXEC LMFREE DATAID()"  
   
Exit   
   
macroMode: 
   
   "ISREDIT NUM"   
   "ISREDIT UNNUM" 
   "ISREDIT END"   
   
return  

Run it in batch ISPF with an ISPLOG, and you'll get a list of members updated 
(I called this MEMUPD):

TSO - Command  -  - %MEMUPD MY.DATASET 
TSO - Command  -  - %MEMUPD 
   
Edit - Save   - ISRE006  MY.DATASET(MAKEBIG) - member saved.   
TSO - Command  -  - %MEMUPD 
   
Edit - Save   - ISRE006  MY.DATASET(PARMTEST) - member saved.  
TSO - Command  -  - %MEMUPD 
   
Edit - Save   - ISRE006  MY.DATASET(UTF16) - member saved.  
  

Andy Styles
z/Series System Programmer

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Chris Hoelscher
Sent: 11 January 2021 10:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for help with removing sequence numbers from PDS members

-- This email has reached the Bank via an external source --
 

Here is something I am doing (for other reasons) but it might help

Run IEBPTPCH against the old pds(e)
Walk thru the IEBPTPCH output - grabbing the member name and doing what you 
need to do to each line or build iebgener control cards to clear the columns 
When you hit a new member, dispose of the previous lines by making them the 
sysut1 in the aforementioned iebcopy with sysut2 into the corresponding member 
in the new pds(e)

Clear as mud?


Chris Hoelscher
Lead Sys DBA
IBM Global Technical Services on assignmemt to Humana Inc.
T

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

2021-01-11 Thread Styles, Andy (ITS zPlatform Services)

Classification: Public

Quick and dirty - assumes the profile will put numbers in 73-80, and doesn't do 
much in the way of error checking:

/* REXX */ 
   
parse source . . me .  
   
arg dataset .  
   
"ISPEXEC CONTROL ERRORS RETURN"
"ISREDIT MACRO"
edMac = rc 
"ISPEXEC CONTROL ERRORS CANCEL"
   
if edMac = 0 then do   
   call macroMode  
   exit
end
   
"ISPEXEC LMINIT DATAID(DSN) DATASET('"dataset"') ENQ(SHR)" 
"ISPEXEC LMOPEN DATAID()"  
   
Do until RC > 0 
   "ISPEXEC LMMLIST DATAID() OPTION(LIST) MEMBER(MEMBER) STATS(NO)"
   If RC = 8 Then  
  Leave
   If RC = 0 Then  
  "ISPEXEC EDIT DATAID() MEMBER() MACRO()"   
End
   
"ISPEXEC LMCLOSE DATAID()" 
"ISPEXEC LMFREE DATAID()"  
   
Exit   
   
macroMode: 
   
   "ISREDIT NUM"   
   "ISREDIT UNNUM" 
   "ISREDIT END"   
   
return  

Run it in batch ISPF with an ISPLOG, and you'll get a list of members updated 
(I called this MEMUPD):

TSO - Command  -  - %MEMUPD MY.DATASET 
TSO - Command  -  - %MEMUPD 
   
Edit - Save   - ISRE006  MY.DATASET(MAKEBIG) - member saved.   
TSO - Command  -  - %MEMUPD 
   
Edit - Save   - ISRE006  MY.DATASET(PARMTEST) - member saved.  
TSO - Command  -  - %MEMUPD 
   
Edit - Save   - ISRE006  MY.DATASET(UTF16) - member saved.  
  

Andy Styles
z/Series System Programmer

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Chris Hoelscher
Sent: 11 January 2021 10:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for help with removing sequence numbers from PDS members

-- This email has reached the Bank via an external source --
 

Here is something I am doing (for other reasons) but it might help

Run IEBPTPCH against the old pds(e)
Walk thru the IEBPTPCH output - grabbing the member name and doing what you 
need to do to each line or build iebgener control cards to clear the columns 
When you hit a new member, dispose of the previous lines by making them the 
sysut1 in the aforementioned iebcopy with sysut2 into the corresponding member 
in the new pds(e)

Clear as mud?


Chris Hoelscher
Lead Sys DBA
IBM Global Technical Services on assignmemt to Humana Inc.
T 502.476.2538  or 502.407.7266

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Sean Gleann
Sent: Monday, January 11, 2021 4:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Request for help with removing sequence numbers from PDS 
members

[External Email: Use caution with links and attachments]


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

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

2021-01-11 Thread Chris Hoelscher

Here is something I am doing (for other reasons) but it might help

Run IEBPTPCH against the old pds(e)
Walk thru the IEBPTPCH output - grabbing the member name and doing what you 
need to do to each line or build iebgener control cards to clear the columns
When you hit a new member, dispose of the previous lines by making them the 
sysut1 in the aforementioned iebcopy with sysut2 into the corresponding member 
in the new pds(e)

Clear as mud?


Chris Hoelscher
Lead Sys DBA 
IBM Global Technical Services on assignmemt to Humana Inc.
T 502.476.2538  or 502.407.7266

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Sean Gleann
Sent: Monday, January 11, 2021 4:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Request for help with removing sequence numbers from PDS 
members

[External Email: Use caution with links and attachments]


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

Regards
Sean

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, ancestry, 
age, disability, sex,
marital status, gender, sexual orientation, gender identity, or religion. 
Humana Inc. and its subsidiaries do not
exclude people or treat them differently because of race, color, national 
origin, ancestry, age,
disability, sex, marital status, gender, sexual orientation, gender identity, 
or religion.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


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


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 feasible to use 
IEBGENER with non-empty SYSIN, ICEMAN, or TSO EDIT, or ISPF EDIT, or 
something else.
Caution: things are simple when you just want to replace position 73-80 
despite of its actual content, that means without checking it.


HTH

--
Radoslaw Skorupka
Lodz, Poland





==

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

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

mBank S.A. z siedzibą w Warszawie, ul. 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

Request for help with removing sequence numbers from PDS members