AW: Re: ADR144E

[Peter Hunkeler]

>>I am trying to troubleshoot a user's job which is using ADRDSSU.
 >>
>That job is DELETING the datasets on the selected volsers. Is that what the 
>user wants?


Does it? The JCL is referring to the tape by VOL=SER=, not via catalog. Non-SMS 
DASD data sets are deleted from the volume but not removed from the catalog 
when located via VOL=SER=.


I'm not sure what the system does in the case of tape data sets. The data set 
cannot be physically deleted from the tape, because there might be more data 
sets after the one to be deleted. I never cared to investigate, but I assume 
that deleting a tape data set will only remove the catalog entry and leave 
alone the physical data on the tape.


I'm not a storage guy, and I don't have experience with tape catalog systems 
(RMM, CA-1, etc). Would those recognize the reference by VOL=SER= and delete 
the entry from their inventory?




Curious to know.


--
Peter Hunkeler




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

Re: Broken VBS and ICE141A

[Edward Gould]

Radoslaw:

Take a look at CBTTAPE.ORG  they used to have there.
We wrote our own and no longer have access to it.

Ed
> On Mar 20, 2017, at 12:29 PM, R.S.  wrote:
> 
> I have a broken PS VBS file (incomplete records), when I try to read it with 
> IEBGENER or IFASMFDP (it is SMF dump) I get abend S002.
> I used to fix it with ICEGENER and SPANINC=RC4 option.
> 
> However it does not work - ICEGENER job ends with RC16 and
> ICE141A 2 SPANNED RECORD ON SORTIN   COULD NOT BE ASSEMBLED - REASON CODE IS 
> 03
> 
> I did RTFM, but the only advice I got is to fix the dataset.
> How???
> Any clue?
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> --
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być 
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś 
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej 
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, 
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie 
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, 
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale 
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub 
> zapisane na dysku.
> 
> This e-mail may contain legally privileged information of the Bank and is 
> intended solely for business use of the addressee. This e-mail may only be 
> received by the addressee and may not be disclosed to any third parties. If 
> you are not the intended addressee of this e-mail or the employee authorized 
> to forward it to the addressee, be advised that any dissemination, copying, 
> distribution or any other similar activity is legally prohibited and may be 
> punishable. If you received this e-mail by mistake please advise the sender 
> immediately by using the reply facility in your e-mail software and delete 
> permanently this e-mail including any copies of it either printed or saved to 
> hard drive.
> 
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
> www.mBank.pl, e-mail: kont...@mbank.pl
> Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
> Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
> Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
> wpłacony) wynosi 168.955.696 złotych.
> 
> 
> --
> 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: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2017c.html#60 [EXTERNAL] ComputerWorld Says: Cobol 
plays major role in U.S. government breaches
http://www.garlic.com/~lynn/2017c.html#61 [EXTERNAL] ComputerWorld Says: Cobol 
plays major role in U.S. government breaches
http://www.garlic.com/~lynn/2017c.html#69 ComputerWorld Says: Cobol plays major 
role in U.S. government breaches
http://www.garlic.com/~lynn/2017c.html#70 ComputerWorld Says: Cobol plays major 
role in U.S. government breaches
http://www.garlic.com/~lynn/2017c.html#71 ComputerWorld Says: Cobol plays major 
role in U.S. government breaches

more on the enormous outsourcing that occurred last decade

Why does WikiLeaks keep publishing U.S. state secrets? Private
contractors. By outsourcing key intelligence work, the government has
made classified material more vulnerable.
https://www.washingtonpost.com/posteverything/wp/2017/03/16/the-reason-wikileaks-receives-so-many-u-s-state-secrets-private-contractors/

The crux of the problem may be privatized intelligence itself. That's
the view of veteran intelligence reporter Edward Epstein in his
contentious but informative new book, "How America Lost Its Secrets."

... snip ...

the above article glosses over security clearances had also been
outsourced and was found to not be done to required standards.

Former CEO of IBM last century ... leaves to become head of one of the
large private-equity companies that acquires the beltway bandit that
will employ Snowden. One of the issues is that government contractors
(and beltway bandits) can't use money from gov. contracts to lobby
congress (recent convictions for some contractors involved in Hanford
cleanup) ... however private-equity companies can lobby on behalf of
their owned companies (70% of budget and over half of the people).
http://www.investingdaily.com/17693/spies-like-us
and futher contributes to the rapidly spreading "success of failure"
culture
http://www.govexec.com/excellence/management-matters/2007/04/the-success-of-failure/24107/

past posts
http://www.garlic.com/~lynn/submisc.html#private.equity
and
http://www.garlic.com/~lynn/submisc.html#success.of.failure
and
http://www.garlic.com/~lynn/submisc.html#gerstner

so major part of the enormous outsourcing that went on last decade
... is the enormous lobbying of congress. A counter folklore
justification was that cyber & dataprocessing competitive salaries had
increased to point that it would place thousands more people at grade
requiring congressional approval. It would be easier to approve large
number of contract appropriations (which would also result in large
amounts spent on congressional lobbying) rather than figuring out how to
deal with the congressional approval needed for all those gov employees
(that would have consumed all congressional hours).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Broken VBS and ICE141A

[Paul Gilmartin]

On Mon, 20 Mar 2017 17:25:09 -0500, Bill Woodger wrote:

>Paul, that doesn't answer the question of whether data was written to the 
>dataset with LRECL=X, the question I asked. Provides a way that the data is 
>actually valid.
>
>Otherwise the data is invalid. 
> 
IIRC, without reviewing the thread or RTFM, that R.S. posted JCL attempting to 
read
the data set and that it should have been SMF data (does that imply 
LRECL<=32760?)

>Are you really so sure that a program, with no knowledge of the expected 
>structure of the data, can determine exactly how a VBS is pickled?
>
Of course there's no way to be sure.

>Because if it is not exactly, it is no use. 
>
Yet there may be some use.  Inspect the data.  If it doesn't appear to be
VBS SMF data (enough redundancy to make a good guess), first verify that
the DSN in the JCL is correct ... etc.  (OK.  Should have checked that first.)

>Someone will just fix what the message says, then find out later 
>undeterminable bits of the data were missing or otherwise nonsense. 
>
Likely the BOFH.  I once got a punched deck with one card punched backward.
Only plausable explanation is that before it was punched the card was loaded
in the hopper backward.  BOFH noticed the wrong corner cut and fixed the
symptom.

Or they'll waste time looking at "this is what it says the error is", when the 
error is something else.
>
I've done that.  Then, I blame z/OS.  If I miscode a PATH in a DD statement
(typo), z/OS reports a catalog error.  I no longer try to diagnose a catalog
problem.  (The catalog was never searched; the message was inappropriately
repurposed.)  I believe I went to SR; WAD; who cares about UNIX paths,
anyway.

>If it's broke in a really weird way, a message to say "it's broke in a really 
>weird way, you fix it, I don't want to give you a false sense of security" is 
>fine with me. Mileage may vary.
>
Yup.  I once got a data error in an early record on a tape (not IBM equipment).
I *happened* to have a dump of the first several blocks from the program
that created the tape.  Block n was simply missing entirely.  Or, blocks
n, n+1, n+2, ... were corrupted so they matched the intended content of
blocks n+1, n+2, n+3, ...  Even more unlikely than that an entire block
got dropped.  I unwrapped the first couple plies of the tape and noticed a
transverse crease.  Can an entire block levitate over the read head with
no error detected?  NRZI?  Not IBM equipment.  Recovery involved scissors,
new reflective spot; re-create data set.

Sometimes human wisdom gained from experience is better than Watson
(sometimes not).  And an intuitive maximum likelihood selection from
various failure modes is guidance to selecting the best recovery scenario.
(Perhaps the value of that day's SMF data is exceed by the cost to
recover it.)

HLASM's ASMA435I Record n in xxx on volume: vv
is precious, and rarely misleading.  And it reports UNIX paths
meaningfully.

-- gil

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

Re: Broken VBS and ICE141A

[Bill Woodger]

Paul, that doesn't answer the question of whether data was written to the 
dataset with LRECL=X, the question I asked. Provides a way that the data is 
actually valid.

Otherwise the data is invalid. 

Are you really so sure that a program, with no knowledge of the expected 
structure of the data, can determine exactly how a VBS is pickled? Because if 
it is not exactly, it is no use. 

Someone will just fix what the message says, then find out later undeterminable 
bits of the data were missing or otherwise nonsense. Or they'll waste time 
looking at "this is what it says the error is", when the error is something 
else.

If it's broke in a really weird way, a message to say "it's broke in a really 
weird way, you fix it, I don't want to give you a false sense of security" is 
fine with me. Mileage may vary.

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

Re: LE Pre-initialization again - catch-22 situation

[Farley, Peter x23353]

Further investigation and some additional coding has shown that the problem I 
have is that the (term) call to CEEPIPI apparently DELETE's all LOADed modules 
whether they were loaded by LE functions or by user code following the 
(init_sub) and (add_entry) calls.  Displaying the storage at the loaded program 
address before and after the (term) call, the program is clearly present before 
the (term) call and clearly deleted from memory following the (term) call.

This is not a documented effect of the (term) operation.  Do I have an APARABLE 
LE bug here or just an RFC for a documentation change and then code a 
workaround for the undocumented result? (i.e., re-LOAD the requested module 
after the (term) call).

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Monday, March 20, 2017 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LE Pre-initialization again - catch-22 situation

I have been experimenting with dynamic mixing of LE pre-initialization and 
non-le initialization in the same assembler main program, and I do know that 
they cannot be both used at the same time; you can only do one or the other at 
a time.  So I tried to set things up so that if I found the module to be called 
was non-LE I would terminate the LE (init_sub) environment with a (term) call 
and then call IGZERRE to set up for a non-LE call.

I have encountered a catch-22 situation - in order to find out if a module to 
be called later is LE or non-LE, I have to set up the pre-initialization 
environment first and do an (add_entry) call.  If RC = 12 (X'0C') from 
(add_entry) it is a non-le subroutine and I need to use the older IGZERRE 
initialization routine.

Even when I terminate the pre-initialization environment using the (term) call, 
when I invoke IGZERRE following the (term) call I get a S0C1 abend in CEEPIRA.

What am I missing here?  Can I not use IGZERRE after setting up and then 
terminating the pre-initialization environment?

The issue I am trying to solve is that we have some old utility COBOL 
subroutines called from assembler main programs that were compiled with VS 
COBOL II V1.2, and that version of COBOL does NOT generate an LE-enabled 
executable program.  You must use IGZERRE to set up to call such subroutines.

Re-compiling the old VS COBOL II V1.2 subroutines with an LE-generating 
compiler is obviously a better option, but I need to provide for downward 
compatibility before that conversion can be scheduled.

I could just LOAD the subroutine first and manually examine it to determine if 
it is VS COBOL II V1.2 or earlier (the eye-catcher "C2 1.2.0" near the 
beginning of the program allows that fairly easily), and then DELETE the module 
if it is actually an LE mocule, but that seems inefficient for future use when 
it gets converted to a later COBOL version.  (I try not to be perfectionist 
about efficiency, but sometimes I can't help myself.)

TIA for any assistance or RTFM you can provide.

Peter
--

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

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

Re: Broken VBS and ICE141A

[Paul Gilmartin]

On Mon, 20 Mar 2017 16:07:18 -0500, Bill Woodger wrote:

>Simple, John. You produce the message Paul wants. Can't be clearer.
> 
Block sequence, offset, segment sequence, record sequence, cause.
Note that segment sequence and record sequence may be indeterminate
if the VBS is broken badly enough.

Cause can be any of:
o garbage bits in lower half of SDW
o SDW count exceeds remainder of block
o Initial segment followed by another initial segment
o Continuation segment preceded by end segment
o ...

Tell the programmer exactly what's wrong and how to find it in a dump.
The program knows what's wrong when it discovers the flaw.  Why
leave it to the programmer to guess or repeat the analysis.

>Was the data set written with LRECL=X, to get "long" records? What is the 
>data? Why is it VBS?
>
IIRC, he said LRECL=32760.  SMF.

Why isn't LRECL=32767 allowed for RECFM=VBS?  A 32767-byte record
might span blocks that don't exceed 32760.

-- gil

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

Re: Broken VBS and ICE141A

[Bill Woodger]

Simple, John. You produce the message Paul wants. Can't be clearer.

Radoslav,

Was the data set written with LRECL=X, to get "long" records? What is the data? 
Why is it VBS?

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

Re: Broken VBS and ICE141A

[John McKown]

On Mon, Mar 20, 2017 at 3:36 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On 2017-03-20, at 12:45, R.S. wrote:
> >
> > //SYSINDD *
> > OPTION COPY,SPANINC=RC4
> > SRSK.INPUT.BROKEN dataset is DSORG=PS,RECFM=VBS,LRECL=
> 32760,BLKSIZE=27998
> >
> It appears not to tell you which record is broken.  Alas.
>
> > BTW: Using STOPAFT= I found the first 27019 records are OK, the next
> one causes RC16 and ICE141A
> > Tools like IEBGENER or IDCAMS simply abend with S002.
> >
> Rather than leaping without looking, it would be valuable to have
> a tool that identifies and dumps the broken record.
>

​The aforementioned code at  https://gist.github.com/JohnArchieMckown/
d7ddef0c7ddf95c72c5978b099768d9b will do this. Sort of. It puts the valid
records out to one DD and the invalid ones out to another. What it doesn't
do is tell you the relative record number(s) of the invalid ones in the
original dataset. ​One possible problem with trying to do that is how to
count the number of records. That is, is the number the logical record
number (reassembled VBS) or the relative segment number. That is, suppose
you have 3 logical records. The first is broken into three segments and the
second has two segments (and is "broken") and the third has one segment.
How would your report that? Something like: Second logical record is
broken. Or: Third logical record, from relative segments 4 & 5, are broken.



>
> -- gil
>
>

-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

Re: Can SMPPTS datasets be consolidated?

[Mark Zelden]

On Mon, 20 Mar 2017 15:27:25 -0500, Paul Gilmartin  wrote:

>On Mon, 20 Mar 2017 13:51:43 -0500, Mark Zelden wrote:
>>
>>Thanks for the explanation.  Normally I have no reason to run REJECT PURGE 
>>since I do purge at accept time.  For my z/OS zones I do have to do that 
>>because
>>the 2 companies each have their own dlib zone to go along with the 2 target 
>>zones, so I can't purge on accept. 
>> 
>An obvious enhancement would be a command to "purge when accepted in
>all zones."
>
>Do you process the output of a cross-zone query or an API quiery to
>generate the REJECT commands?
>

No, it's simply reject in purge mode after accept is done to both sets of 
zones.  The zones to consider are part of the reject command:


  SETBOUNDARY (GLOBAL).  
  REJECT PURGE  (AAAD101,BBBD101) COMPRESS(ALL). 

(aaa and bbb are not the real prefixes of those zones, the name is related
to the company and not shown). 

Best regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Broken VBS and ICE141A

[Paul Gilmartin]

On 2017-03-20, at 12:45, R.S. wrote:
> 
> //SYSINDD *
> OPTION COPY,SPANINC=RC4
> SRSK.INPUT.BROKEN dataset is DSORG=PS,RECFM=VBS,LRECL=32760,BLKSIZE=27998
>  
It appears not to tell you which record is broken.  Alas.

> BTW: Using STOPAFT= I found the first 27019 records are OK, the next one 
> causes RC16 and ICE141A
> Tools like IEBGENER or IDCAMS simply abend with S002.
>  
Rather than leaping without looking, it would be valuable to have
a tool that identifies and dumps the broken record.
 
-- gil

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

Re: Can SMPPTS datasets be consolidated?

[Paul Gilmartin]

On Mon, 20 Mar 2017 13:51:43 -0500, Mark Zelden wrote:
>
>Thanks for the explanation.  Normally I have no reason to run REJECT PURGE 
>since I do purge at accept time.  For my z/OS zones I do have to do that 
>because
>the 2 companies each have their own dlib zone to go along with the 2 target 
>zones, so I can't purge on accept. 
> 
An obvious enhancement would be a command to "purge when accepted in
all zones."

Do you process the output of a cross-zone query or an API quiery to
generate the REJECT commands?

-- gil

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

Re: Can SMPPTS datasets be consolidated?

[Longabaugh, Robert E]

Restore also does a reject if the options entry is set to "REJECT".

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Monday, March 20, 2017 1:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can SMPPTS datasets be consolidated?

On Mon, 20 Mar 2017 09:36:28 -0400, Kurt Quackenbush  wrote:

>> Kirt - if you are still listening:  Why oh why has "CLEANUP 
>> COMPRESS(ALL)" never been enhanced to include the SMPPTS or made an 
>> additional option?
>
>Mostly I think because the REJECT PURGE command with the COMPRESS 
>option provides essentially the same function I think you are asking 
>CLEANUP to provide.  That is, delete MCS entries from the SMPPTS data 
>sets and then compress those data sets.
>

Thanks for the explanation.  Normally I have no reason to run REJECT PURGE 
since I do purge at accept time.  For my z/OS zones I do have to do that 
because the 2 companies each have their own dlib zone to go along with the 2 
target zones, so I can't purge on accept. 

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mzelden.com_mvsutil.html&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=y5oDE0-qCY5zwbERo3GTHhtTzhLL6riW6CHUW01bH2A&s=vr_-_rlWwiEcn_tk_wV9KzH_X0EpeHwRyoKryLzDNio&e=
 

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

LE Pre-initialization again - catch-22 situation

[Farley, Peter x23353]

I have been experimenting with dynamic mixing of LE pre-initialization and 
non-le initialization in the same assembler main program, and I do know that 
they cannot be both used at the same time; you can only do one or the other at 
a time.  So I tried to set things up so that if I found the module to be called 
was non-LE I would terminate the LE (init_sub) environment with a (term) call 
and then call IGZERRE to set up for a non-LE call.

I have encountered a catch-22 situation - in order to find out if a module to 
be called later is LE or non-LE, I have to set up the pre-initialization 
environment first and do an (add_entry) call.  If RC = 12 (X'0C') from 
(add_entry) it is a non-le subroutine and I need to use the older IGZERRE 
initialization routine.

Even when I terminate the pre-initialization environment using the (term) call, 
when I invoke IGZERRE following the (term) call I get a S0C1 abend in CEEPIRA.

What am I missing here?  Can I not use IGZERRE after setting up and then 
terminating the pre-initialization environment?

The issue I am trying to solve is that we have some old utility COBOL 
subroutines called from assembler main programs that were compiled with VS 
COBOL II V1.2, and that version of COBOL does NOT generate an LE-enabled 
executable program.  You must use IGZERRE to set up to call such subroutines.

Re-compiling the old VS COBOL II V1.2 subroutines with an LE-generating 
compiler is obviously a better option, but I need to provide for downward 
compatibility before that conversion can be scheduled.

I could just LOAD the subroutine first and manually examine it to determine if 
it is VS COBOL II V1.2 or earlier (the eye-catcher "C2 1.2.0" near the 
beginning of the program allows that fairly easily), and then DELETE the module 
if it is actually an LE mocule, but that seems inefficient for future use when 
it gets converted to a later COBOL version.  (I try not to be perfectionist 
about efficiency, but sometimes I can't help myself.)

TIA for any assistance or RTFM you can provide.

Peter


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

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

Re: Can SMPPTS datasets be consolidated?

[Mark Zelden]

On Mon, 20 Mar 2017 09:36:28 -0400, Kurt Quackenbush  wrote:

>> Kirt - if you are still listening:  Why oh why has "CLEANUP COMPRESS(ALL)" 
>> never
>> been enhanced to include the SMPPTS or made an additional option?
>
>Mostly I think because the REJECT PURGE command with the COMPRESS option
>provides essentially the same function I think you are asking CLEANUP to
>provide.  That is, delete MCS entries from the SMPPTS data sets and then
>compress those data sets.
>

Thanks for the explanation.  Normally I have no reason to run REJECT PURGE 
since I do purge at accept time.  For my z/OS zones I do have to do that because
the 2 companies each have their own dlib zone to go along with the 2 target 
zones, so I can't purge on accept. 

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

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

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Anne & Lynn Wheeler]

j...@crossno.us (John Crossno) writes:
> It had everything to do with "legacy" network security, not following
> best security practices, etc. Where the research talks about
> investments in modernization, they imply that the problem is "archaic"
> 30-year old COBOL systems, when that really isn't supported by the
> research at all (contradictions?). They really mean that when the
> distributed network security is modernized with security best
> practices, advanced intrusion and malware detection, use of
> MFA/PIV/etc, there's a reduction in the number of incidents.

re:
http://www.garlic.com/~lynn/2017c.html#60 [EXTERNAL] ComputerWorld Says: Cobol 
plays major role in U.S. government breaches
http://www.garlic.com/~lynn/2017c.html#61 [EXTERNAL] ComputerWorld Says: Cobol 
plays major role in U.S. government breaches
http://www.garlic.com/~lynn/2017c.html#69 ComputerWorld Says: Cobol plays major 
role in U.S. government breaches
http://www.garlic.com/~lynn/2017c.html#70 ComputerWorld Says: Cobol plays major 
role in U.S. government breaches

the enormous outsourcing to "for-profit" operations (especially owned by
private-equity company) that occured last decade ... and the rapidly
spreading "success of failure" culture ... especially failures of
dataprocessing projects, a series of failures is more profit than
immediate success
http://www.govexec.com/excellence/management-matters/2007/04/the-success-of-failure/24107/
including example of outsourcing security clearances to private-equity
owned beltway bandits that were filling out the paperwork, but not
bothering to do background checks
http://www.investingdaily.com/17693/spies-like-us

His security clearance was handled by yet another private firm, one now
being probed on suspicion of insufficient diligence in such
investigations.

... snip ...

there was subsequent news that possibly all clearances performed these
firms would have to be redone by in-house gov. agencies.

note, not just new dataprocessing (including networks), but article also
mentions failed legacy dataprocessing modernization efforts.

past posts
http://www.garlic.com/~lynn/submisc.html#success.of.failure

we had consulted (essentially for free) on the backend dataprocessing
for the year 2000 census (when the effort was audited, I was asked to
standup in front of the room and answer all the questions). In the early
part of the century, we tried to do something similar for the VA
hospital dataprocessing and met with the head staffer on the hill for
the VA. They had just come off failed billion dollar dataprocessing
modernization effort and was gearing up for a couple billion dollar
followon. Turns out what we wanted to do was one of the biggest threats
to beltway bandits ... impacting their bottom line.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Broken VBS and ICE141A

[R.S.]

Sri,
Here is my job:

// SET WEJ=SRSK.INPUT.BROKEN
//**
//K10  EXEC PGM=ICEMAN
//SYSOUT   DD SYSOUT=*
//SORTIN   DD DISP=SHR,DSN=&WEJ
//SORTOUT  DD DSN=SRSK.VBSFIX.TMP,DISP=(,CATLG),
//  LIKE=&WEJ
//SYSINDD *
 OPTION COPY,SPANINC=RC4

SRSK.INPUT.BROKEN dataset is DSORG=PS,RECFM=VBS,LRECL=32760,BLKSIZE=27998


BTW: Using STOPAFT= I found the first 27019 records are OK, the next 
one causes RC16 and ICE141A

Tools like IEBGENER or IDCAMS simply abend with S002.

Answering to offline question, I don't have SAS.
However it seems File Manager (which I have) is able to read all the 
dataset.


--
Radoslaw Skorupka
Lodz, Poland








W dniu 2017-03-20 o 19:15, Sri h Kolusu pisze:

I used to fix it with ICEGENER and SPANINC=RC4 option.
However it does not work - ICEGENER job ends with RC16 and  ICE141A 2

SPANNED RECORD ON SORTIN   COULD NOT BE ASSEMBLED - REASON
  CODE IS 03

R.S,

SPANINC=RC4 specifies that DFSORT should issue message ICE197I (once), set
a return code of 4 and eliminate all incomplete spanned records it
detects. Valid records will be recovered.  Did you get an ICE141A when
using SPANINC=RC4?

The reason code 3 specifies that "The total length of segments was greater
than the LRECL."

Do you have an hardcoded LRECL in the JCL?

DFSORT can automatically calculate the DCB properties, so you don't have
to specify them.

Can you share the JCL that you used?

Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on
03/20/2017 10:29:50 AM:


From: "R.S." 
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 03/20/2017 10:30 AM
Subject: Broken VBS and ICE141A
Sent by: IBM Mainframe Discussion List 

I have a broken PS VBS file (incomplete records), when I try to read it
with IEBGENER or IFASMFDP (it is SMF dump) I get abend S002.
I used to fix it with ICEGENER and SPANINC=RC4 option.

However it does not work - ICEGENER job ends with RC16 and
ICE141A 2 SPANNED RECORD ON SORTIN   COULD NOT BE ASSEMBLED - REASON
CODE IS 03

I did RTFM, but the only advice I got is to fix the dataset.
How???
Any clue?

--
Radoslaw Skorupka
Lodz, Poland





---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: Broken VBS and ICE141A

[Sri h Kolusu]

>>> I used to fix it with ICEGENER and SPANINC=RC4 option.

>>> However it does not work - ICEGENER job ends with RC16 and  ICE141A 2 
SPANNED RECORD ON SORTIN   COULD NOT BE ASSEMBLED - REASON 
 CODE IS 03

R.S,

SPANINC=RC4 specifies that DFSORT should issue message ICE197I (once), set 
a return code of 4 and eliminate all incomplete spanned records it 
detects. Valid records will be recovered.  Did you get an ICE141A when 
using SPANINC=RC4?

The reason code 3 specifies that "The total length of segments was greater 
than the LRECL."

Do you have an hardcoded LRECL in the JCL? 

DFSORT can automatically calculate the DCB properties, so you don't have 
to specify them. 

Can you share the JCL that you used?

Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on 
03/20/2017 10:29:50 AM:

> From: "R.S." 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 03/20/2017 10:30 AM
> Subject: Broken VBS and ICE141A
> Sent by: IBM Mainframe Discussion List 
> 
> I have a broken PS VBS file (incomplete records), when I try to read it 
> with IEBGENER or IFASMFDP (it is SMF dump) I get abend S002.
> I used to fix it with ICEGENER and SPANINC=RC4 option.
> 
> However it does not work - ICEGENER job ends with RC16 and
> ICE141A 2 SPANNED RECORD ON SORTIN   COULD NOT BE ASSEMBLED - REASON 
> CODE IS 03
> 
> I did RTFM, but the only advice I got is to fix the dataset.
> How???
> Any clue?
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> --
> Treść tej wiadomości może zawierać informacje prawnie chronione 
> Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą
> może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. 
> Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem 
> upoważnionym do jej przekazania adresatowi, informujemy, że jej 
> rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o 
> podobnym charakterze jest prawnie zabronione i może być karalne. 
> Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
> zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę 
> wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisanena 
dysku.
> 
> This e-mail may contain legally privileged information of the Bank 
> and is intended solely for business use of the addressee. This e-
> mail may only be received by the addressee and may not be disclosed 
> to any third parties. If you are not the intended addressee of this 
> e-mail or the employee authorized to forward it to the addressee, be
> advised that any dissemination, copying, distribution or any other 
> similar activity is legally prohibited and may be punishable. If you
> received this e-mail by mistake please advise the sender immediately
> by using the reply facility in your e-mail software and delete 
> permanently this e-mail including any copies of it either printed or
> saved to hard drive.
> 
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
> www.mBank.pl, e-mail: kont...@mbank.pl
> Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego 
> Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 
> 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy
> mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
> 
> 
> --
> 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: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Phil Smith]

To find John Crossno's comments, go to 
https://www.linkedin.com/company-beta/163187/

Then hit END 4 or 5 times (to cause the page to autoload more stuff) and search 
the page for COBOL. Beware, as he noted, they reposted it; you want the one 
from yesterday, not Friday (which has two comments). His are three of (to date) 
six comments:

The underlying research that the article references is full of false 
information, partly because it misconstrues the Congressional report about the 
OPM breaches that occurred from 2012-2015, and partly because it implies that 
legacy = mainframe as opposed to legacy = "a system that is out of date and 
obsolete", as defined by the MGT Act legislation in 2015. Mainframes and COBOL 
have both been consistently enhanced, improved, and kept up with technology, or 
led the way. They are in no way obsolete or archaic technology. While a system 
written in COBOL was indeed the hackers target, the 34 documents that were 
taken were about the mainframe application, and some contained information from 
the mainframe database, but taken from file servers on the distributed network, 
not from the mainframe itself. The report also says that OPM was using old 
(legacy) technology to secure their network, and not employing then modern 
technologies, like MFA, PIV, as well as available intrusion detection software, 
etc. It's time to leave anything mainframe related out of further discussion 
and research, and focus on the legacy aspects of network security. Bottom line 
is that COBOL is NOT causing , nor attributing to the cause of security 
breaches.


The research report used references mainframe and COBOL through the OPM report. 
Otherwise they just say legacy systems, legacy infrastructure, etc. thus 
implying, and leading the reader to believe that legacy=mainframe (and COBOL), 
although it doesn't say that anywhere. Done on purpose that way I imagine to be 
able to deny they said it. Regardless, perception=reality, right? The research 
talks about enhancements and improvements, investments, etc. made to legacy 
systems, and thus reducing the number of security breach incidents. So, I'll 
propose that the legacy systems and infrastructure in this article is about 
distributed networks, legacy desktop and file server operating systems, legacy 
network intrusion detection, legacy malware detection systems, and legacy 
authentication policies, practices, and methods... While implying that COBOL 
and mainframes are the cause of security breaches, and that modernization 
(moving off the mainframe) improves the security posture.

The article, which seems to take the magical leap from the references of COBOL 
and mainframe to those systems being the cause of security breaches in U.S. 
Government systems. While it is most likely the investments in distributed 
systems security (intrusion detection, malware/virus scanners, updated versions 
of the operating systems used, probably newer network switches), use of MFA, 
PIV, and other security best practices, that are the real reasons why there are 
reductions in the number of incidents where hackers are successful. Security is 
like an onion. You must use various technologies, tools, methods, practices to 
protect each layer; and they must be kept up to date. Failure to do so invites 
the bad guys into your home. Do you leave a key to your house under a mat? Do 
you leave the keys or combination to your safe where it can easily be found? Of 
course, not. Do you have an alarm system on your home, possibly electronic 
locks, maybe some hidden cameras? Quite possibly. I sure do. Why do you treat 
your network, and system security any differently?

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

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Anne & Lynn Wheeler]

martin_pac...@uk.ibm.com (Martin Packer) writes:
> Not to disagree with anything anyone has said, I think one thing might 
> work against us:
>
> I don't know when restrictions on encryption were lifted but when I first 
> was involved with encryption in the late 1980's it was pretty restrictive 
> who could have it.
>
> So the point is - because of the restricted availability - it's possible 
> the injection of encryption into sites and applications might be less than 
> desirable.
>
> But I hope the world has changed enough for most sites to have caught up 
> with the need to implement it.

re:
http://www.garlic.com/~lynn/2017c.html#60 [EXTERNAL] ComputerWorld Says: Cobol 
plays major role in U.S. government breaches
http://www.garlic.com/~lynn/2017c.html#61 [EXTERNAL] ComputerWorld Says: Cobol 
plays major role in U.S. government breaches
http://www.garlic.com/~lynn/2017c.html#69 ComputerWorld Says: Cobol plays major 
role in U.S. government breaches

financial has had special dispensation for some (stronger) crypto
... and there was regular gov. representation at financial standards
meetings.

in the 90s, as gov. was loosing control of encryption ... for a time
there was a gov. push for (allowing crypto but) official escrow of all
(encyrption) keys ... I was rep to the key escrow meetings. I did make
the case of differentiation between keys used for authentication and
keys used for encruyption ... and that it is basic security violation
for any but the individual have possession of their authentication
keys. the gov.  whined that people could cheat and use their
authentication keys for encryption  but that was about the last key
escrow meeting.

trivia: in the big 1jan1983 change over of arpanet to internetworking
protocol ... there was approx. 100 IMP network nodes and 255 connected
hosts ... at the time when the internal network was rapidly approaching
1000 nodes. This is old post with list of corporate locations that added
one or more network nodes during 1983:
http://www.garlic.com/~lynn/2006k.html#8 Arpa address


there was especially difficult problems when links (between corporate
nodes) cross national boundaries (and all internal links required
encryption). ... past internal network posts
http://www.garlic.com/~lynn/subnetwork.html#internalnet

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Broken VBS and ICE141A

[John McKown]

On Mon, Mar 20, 2017 at 12:29 PM, R.S. 
wrote:

> I have a broken PS VBS file (incomplete records), when I try to read it
> with IEBGENER or IFASMFDP (it is SMF dump) I get abend S002.
> I used to fix it with ICEGENER and SPANINC=RC4 option.
>
> However it does not work - ICEGENER job ends with RC16 and
> ICE141A 2 SPANNED RECORD ON SORTIN   COULD NOT BE ASSEMBLED - REASON CODE
> IS 03
>
> I did RTFM, but the only advice I got is to fix the dataset.
> How???
> Any clue?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
​If you wish to, I have an HLASM program whose source you can download. It
will "fix" broken VBS files by dropping records which cannot be properly
reconstructed. You can get it here:
https://gist.github.com/JohnArchieMckown/d7ddef0c7ddf95c72c5978b099768d9b

The JCL would look something like:

//STEP010  EXEC  PGM=VBSCOPY2,
// REGION=0M
//STEPLIB  DD  DSN=your.library,
// DISP=SHR
//SYSUDUMP DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*
//SMFINDD  DSN=your.broken.vbs.input.file,
// DISP=OLD
//SMFOUT   DD  DSN=your.fixed.vbs.input.file,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA
//* change blksize, if desired
// DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=4096)
//SMFBAD   DD  DSN=your.broken.vbs.records,
// DISP=(NEW,CATLG),
// UNIT=SYSDA,
// SPACE=(CYL,20,RLSE),
// DCB=(RECFM=VB,LRECL=4096,BLKSIZE=0,BUFNO=1)




-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Anne & Lynn Wheeler]

arno...@us.ibm.com (Todd Arnold) writes:
> Gee, I've been developing crypto technology for 30+ years that runs in
> those environments - so it's certainly news to me that it can't be
> done :-)

re:
http://www.garlic.com/~lynn/2017c.html#60 [EXTERNAL] ComputerWorld Says: Cobol 
plays major role in U.S. government breaches
http://www.garlic.com/~lynn/2017c.html#61 [EXTERNAL] ComputerWorld Says: Cobol 
plays major role in U.S. government breaches

I had project HSDT that started out dealing with T1.
http://www.garlic.com/~lynn/subnetwork.html#hsdt

The internal network was larger than arpanet/internet from just about
the beginning until sometime mid-80s. A major difference between the
internal network and arpanet/internet (besides being larger network) was
corporate required all links to be encrypted.
http://www.garlic.com/~lynn/subnetwork.html#internalnet

One of my problems was that my slowest speed line was 1.5mbites/sec
second, or around 300kbytes/sec full-duplex. Turns out that software DES
on 3081 ran at 150kbytes/sec per processor. Needed 100% of both 3081
processors dedicated for any software DES encryption. some old crypto
email
http://www.garlic.com/~lynn/lhwemail.html#crypto

so external boxes were required for doing any reasonable amount of
encryption. However I hated what I had to pay for T1 link encryptors
... and it was almost impossible to find faster link encryption
boxes. As a result, I got involved in doing a box that would support at
least 3mbyte/sec and cost less than $100 to build. I got slammed by the
corporate crypto products group that it significantly weakened the
strength of standard DES standard. It took me three months to figure out
how to explain to them what was going on (significantly stronger than
DES standard rather than signnificantly weaker). It was a hollow victory
... I was then told that there was only one organization in the world
that could use such crypto, I could make as many boxes as I wanted but I
had to send all boxes to an address in Maryland. It was when I realized
that there are three kinds of crypto in the world, 1) the kind they
don't care about, 2) the kind you can't do, 3) the kind you can only do
for them.

My other conflict with the communication group ... HSDT was having some
equipment built on the other side of the pacific. The friday before a
trip to the other side of the pacific ... the communication group
distributes an announcement for new online discussion group on high
speed with the following definition:

low-speed: <9.6kbits
medium-speed: 19.2kbits
high-speed: 56kbits
very high-speed: 1.5mbits

on Monday morning, in a conference room on the other side of the
pacific was the following definitions

low-speed: <20mbits
medium-speed: 100mbits
high-speed: 200-300mbits
very high-speed: >600mbits

of course, part of the problem was the fastest that the communicaton
group controller boxes supported was 56kbits. They had even done a study
for the corporate executive committee claiming that customers wouldn't
want T1 before the 90s. They had studied customers running "fat pipes"
(two or more parallel 56kbit links operating as single logical link)
where they found no customers with more than five 56kbit links. What
they didn't know (or failed to present) was that typical tariff for six
56kbit links was the same as single T1 link (1.5mbit) ... so customers
got real T1 and operated them with non-IBM controller.

Upthread I referenced getting roped into doing standard for financial
transactions  transaction information has been involved in the
majority of the breaches ... from data breach notification work, past
posts
http://www.garilc.com/~lynn/submisc.html#data.breach.notification

We identified that the information could be reused for fraudulent
financial transactions ... so previous transaction information had to be
kept confidential and never divulged.  However previous transaction
information was also required in dozens in business processes at
millions of locations around the world. This sets up diametrically
opposing requirements ... never divulged and always available
... resulting in the comments that even if the planet was buried under
miles of information hiding encryption wouldn't stop information
leakage. The standard we came up with eliminated such replay attacks,
eliminating crooks motivation for breaches and therefor no need to
encrypt/hide the information (the problem was while it was minor tweak
to the protocol, it resulted in major hit to vested interests trying to
preserve some status quo).

I've also pushed the "security proportional to risk" meme (for the
financial transaction breach theme). The value of the transaction
information to the merchant is profit from the transaction can be a
couple dollars (and a few cents to the transaction processor). The value
of the information to the crooks is the account balance or credit
limit. As a results, the crooks can afford to spend 100 times more on
attacking than merchants can afford spen

Re: Can SMPPTS datasets be consolidated?

[R.S.]

W dniu 2017-03-20 o 14:54, John Eells pisze:

R.S. wrote:


Once upon a time I had to change SMPPTS to PDS because of ...size
limits. The limit of *single member( for PDSE was not enough to keep my
big fat PTF (yes, it was WAS). PDS has no such limit - the limit is full
PDS (64k TRK).
However nowadays we have PDSE v2 with much bigger limit for member size.


It's for that reason, among others, that we have PTF size limits, and 
the maximum size of a PDSE V1 member was one of the things on the list 
(now replaced by the maximum size of a PDS member, because we do not 
require the use of PDSEs for SMPPTS data sets). If you got the sysmod 
from IBM, I would be very interested in knowing when it was and what 
product it was for (if you have that information handy) so I can 
"educate" the perpetr--um, that is, packager.


Other limits, internal ones aside, are imposed by tape, DVD, and 
commonly-deployed DASD volume sizes.


It was approx 2-3 years ago. I'm 99% sure it was PTF for WAS - Websphere 
Application Server.

I'll try to find it out.

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Broken VBS and ICE141A

[R.S.]

I have a broken PS VBS file (incomplete records), when I try to read it 
with IEBGENER or IFASMFDP (it is SMF dump) I get abend S002.

I used to fix it with ICEGENER and SPANINC=RC4 option.

However it does not work - ICEGENER job ends with RC16 and
ICE141A 2 SPANNED RECORD ON SORTIN   COULD NOT BE ASSEMBLED - REASON 
CODE IS 03


I did RTFM, but the only advice I got is to fix the dataset.
How???
Any clue?

--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: RACF Non-expiring passwords

[retired mainframer]

Are you saying that attempting to change the password with the RACF panels 
fails but using ALU with the same password and options succeeds?  Do you have a 
password validation exit?  Can you show us your password rules and the panel 
data (use X, x, 1, and $ as appropriate for the password)?  Ditto for the ALU 
command.  Can you show us the password section of the LU output?

In what way did the original password fail?  Does the new password not work in 
the same way?  What is the full text of the error messages?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elaine Beal
> Sent: Monday, March 20, 2017 9:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RACF Non-expiring passwords
> 
> We have a non-expiring password that we've used for years and somehow failed 
> the other
> night. I reset with an alu line command but the new password doesn't work. 
> When I go
> through the panels it says the current password isn't valid.
> We have changed password rules but I don't see where that matters. I set the 
> new password
> to existing rules and do not get any errors on the alu.

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

Re: Mainframe JOBS in Austin

[John McKown]

On Mon, Mar 20, 2017 at 11:59 AM, Jon Butler  wrote:

> It's not libel if it's true...although they may know where you live ;¬))
>
>
​But remember that, regardless of truth (per Pilate: "What is truth?"; John
18:38) you can still get sued and convicted for libel if the  has
good enough lawyers and enough money. ​


-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Bill Woodger]

Martin, I doubt the US government was ever restricted, since they were 
effectively the source of the restrictions...

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

Re: Mainframe JOBS in Austin

[Jon Butler]

It's not libel if it's true...although they may know where you live ;¬))

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

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Bill Woodger]

On Mon, 20 Mar 2017 11:33:10 -0400, George Rodriguez 
 wrote:

>Does anyone think that Computerworld is going to write a retraction?
>
>


No. And it is not just Computerworld, a search-engine finds at least 23 similar 
references to the report. Maybe some are plagiarised from Computerworld :-)

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

Re: RACF Non-expiring passwords

[Elardus Engelbrecht]

Elaine Beal wrote:

>We have a non-expiring password that we've used for years and somehow failed 
>the other night. I reset with an alu line command but the new password doesn't 
>work. When I go through the panels it says the current password isn't valid.
>We have changed password rules but I don't see where that matters. I set the 
>new password to existing rules and do not get any errors on the alu.

There are many reasons why that non-expiring psw failed like these possible 
reasons:

The id was unused for x days.
Someone entered an invalid password or if that id was used in a FTP script, 
incorrect password was used.

There are different ways to reset an id:

ALU  RESUME - remove revoke attribute, but leave psw unchanged.
ALU  PASSWORD(???) - give a TEMPORARY password. The id needs to enter the 
TEMP psw and then the new psw [twice].
ALU  PASSWORD(???) NOEXPIRED - That password can be used just as you give 
it. Of course your password rules applies.

Or any combination of above ALU and other keywords you used.

Of course, do you have the right access to reset that id? (Group scope, System 
Special or relevant IRR.??? profile in FACILITY class)

Please post your ICH408I messages when that id failed to log on. 

Also post your ALU command and keywords used. You can mask out actual id and 
psw before posting on IBM-MAIN.

Can you see any SMF records why your ALU failed?

Alternatively, go over to RACF-L for guidance from real RACF gurus.

Groete / Greetings
Elardus Engelbrecht

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

Re: Can SMPPTS datasets be consolidated?

[Chris Hoelscher]

However you CAN change what smp/e to smppts entries on an accept with the purge 
setting

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of CM Poncelet
> Sent: Monday, March 20, 2017 12:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Can SMPPTS datasets be consolidated?
> 
> Yes, ACCEPT deletes its PTFs from SMPPTS - I had overlooked that.
> 
> On 20/03/2017 11:30, R.S. wrote:
> > W dniu 2017-03-17 o 23:28, CM Poncelet pisze:
> >> [...]
> >> BTW SMPPTS is written to only during RECEIVE. Else it is only read.
> >
> > What about ACCEPT?
> >
> 
> --
> 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.


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

RACF Non-expiring passwords

[Elaine Beal]

We have a non-expiring password that we've used for years and somehow failed 
the other night. I reset with an alu line command but the new password doesn't 
work. When I go through the panels it says the current password isn't valid.
We have changed password rules but I don't see where that matters. I set the 
new password to existing rules and do not get any errors on the alu.

Thanks,
Elaine

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

Re: Can SMPPTS datasets be consolidated?

[CM Poncelet]

Yes, ACCEPT deletes its PTFs from SMPPTS - I had overlooked that.

On 20/03/2017 11:30, R.S. wrote:
> W dniu 2017-03-17 o 23:28, CM Poncelet pisze:
>> [...]
>> BTW SMPPTS is written to only during RECEIVE. Else it is only read.
> 
> What about ACCEPT?
> 

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

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Martin Packer]

Not to disagree with anything anyone has said, I think one thing might 
work against us:

I don't know when restrictions on encryption were lifted but when I first 
was involved with encryption in the late 1980's it was pretty restrictive 
who could have it.

So the point is - because of the restricted availability - it's possible 
the injection of encryption into sites and applications might be less than 
desirable.

But I hope the world has changed enough for most sites to have caught up 
with the need to implement it.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2



From:   Todd Arnold 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   20/03/2017 16:06
Subject:Re: ComputerWorld Says: Cobol plays major role in U.S. 
government breaches
Sent by:IBM Mainframe Discussion List 



Gee, I've been developing crypto technology for 30+ years that runs in 
those environments - so it's certainly news to me that it can't be done 
:-)
 
Looking at the ICSF Application Programmer's Guide, which defines the ways 
most z/OS applications get cryptographic services, I see this:

  ICSF callable services can be called from application programs written 
in a number
  of high-level languages as well as assembler. The high-level languages 
are:
- C
- COBOL
- FORTRAN
- PL/I

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[George Rodriguez]

Does anyone think that Computerworld is going to write a retraction?


*George Rodriguez*
*Specialist II - IT Solutions*
*IT Enterprise Applications*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eight Consecutive Years*

On Mon, Mar 20, 2017 at 9:12 AM, John Crossno  wrote:

> If one reads the article, then digs into the underlying research, and
> finally the Congressional report on the OPM incidents (all 250 pages of
> it), it's quite easy to see that the authors of the research and subsequent
> article are implying that legacy=mainframe/COBOL, while the real problem(s)
> really had nothing to do with either, at the end of the day. It had
> everything to do with "legacy" network security, not following best
> security practices, etc. Where the research talks about investments in
> modernization, they imply that the problem is "archaic" 30-year old COBOL
> systems, when that really isn't supported by the research at all
> (contradictions?). They really mean that when the distributed network
> security is modernized with security best practices, advanced intrusion and
> malware detection, use of MFA/PIV/etc, there's a reduction in the number of
> incidents.
>
> I wrote up a longer response to it, as comments to the FB and LinkedIn
> postings, that starts with the OPM report and works it's way back up to the
> article. Seemingly, Computerworld didn't like some of the original comments
> from their posting last week on LinkedIn, and felt the need to repost it
> yesterday. That's where my longer comments can be found, vs their original
> posting. Can't link directly to it or the FB posting.. You'll have to
> search for Computerworld's page, then scroll.
>
> At the end of the day, it really has nothing to do with COBOL "security" at
> all, but everything to do with network security. The article is just an
> example of taking at face value poor research, taking liberties with and
> cherry picking bits of a report and quotes from people who probably don't
> understand the technology to begin with, and just plain old fashioned bad
> journalism... Fake News!
>
>
>
> "Common sense is not so common."
>  * Voltaire, Dictionnaire Philosophique (1764)
>
>
>
> On Mon, Mar 20, 2017 at 8:51 AM, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
>
> > Todd Arnold wrote:
> >
> > >Gee, I've been developing crypto technology for 30+ years that runs in
> > those environments - so it's certainly news to me that it can't be done
> :-)
> >
> > Amazing! ;-)
> >
> > No one said those cards are that *fast* !
> >
> >
> > >Looking at the ICSF Application Programmer's Guide, which defines the
> > ways most z/OS applications get cryptographic services, I see this:
> >
> > >  ICSF callable services can be called from application programs written
> > in a number of high-level languages as well as assembler. The high-level
> > languages are:
> > >- C
> > >- COBOL
> > >- FORTRAN
> > >- PL/I
> >
> > And REXX + Assembler too. Look in Redbook - 'System z Crypto and TKE
> > Update' (SG24-7848-00) for samples.
> >
> > Note from that bookie: The code supplied has not been subjected to any
> > formal IBM test 
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >
> > --
> > 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
>

-- 


*Disclaimer: *Under Florida law, e-mail addresses are public records. If 
you do not want your e-mail address released in response to a public 
records request, do not send electronic mail to this entity. Instead, 
contact this office by phone or in writing.


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

Re: Can SMPPTS datasets be consolidated?

[Edward Gould]

> On Mar 20, 2017, at 8:54 AM, John Eells  wrote:
> 
> R.S. wrote:
> 
>> Once upon a time I had to change SMPPTS to PDS because of ...size
>> limits. The limit of *single member( for PDSE was not enough to keep my
>> big fat PTF (yes, it was WAS). PDS has no such limit - the limit is full
>> PDS (64k TRK).
>> However nowadays we have PDSE v2 with much bigger limit for member size.
> 
> It's for that reason, among others, that we have PTF size limits, and the 
> maximum size of a PDSE V1 member was one of the things on the list (now 
> replaced by the maximum size of a PDS member, because we do not require the 
> use of PDSEs for SMPPTS data sets).  If you got the sysmod from IBM, I would 
> be very interested in knowing when it was and what product it was for (if you 
> have that information handy) so I can "educate" the perpetr--um, that is, 
> packager.
> 
> Other limits, internal ones aside, are imposed by tape, DVD, and 
> commonly-deployed DASD volume sizes.

John:
I vaguely remember it was the JAVA people. But its been so long ago.

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

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Edward Gould]

> On Mar 20, 2017, at 8:12 AM, John Crossno  wrote:
> 
> If one reads the article, then digs into the underlying research, and
> finally the Congressional report on the OPM incidents (all 250 pages of
> it), it's quite easy to see that the authors of the research and subsequent
> article are implying that legacy=mainframe/COBOL, while the real problem(s)
> really had nothing to do with either, at the end of the day. It had
> everything to do with "legacy" network security, not following best
> security practices, etc. Where the research talks about investments in
> modernization, they imply that the problem is "archaic" 30-year old COBOL
> systems, when that really isn't supported by the research at all
> (contradictions?). They really mean that when the distributed network
> security is modernized with security best practices, advanced intrusion and
> malware detection, use of MFA/PIV/etc, there's a reduction in the number of
> incidents.
———SNIP———

This goes along side of Computerworld disliking the mainframe. This started 
happening in the mid 1990’s.
I got the idea that a lot of Gartner people wound up there.

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

Re: ADR144E

[Elardus Engelbrecht]

willie bunter wrote:

>I am trying to troubleshoot a user's job which is using ADRDSSU. 

That job is DELETING the datasets on the selected volsers. Is that what the 
user wants?

>I cannot find the reason why the job fails on a :

Others kindly gave you good replies about the INCLUDE filter. Just make sure 
these datasets are those you want to DELETE.

But at least there is that safety NORUN parameter. That parameter saved us many 
embarrasements over the years... ;-)

Groete / Greetings
Elardus Engelbrecht

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

Re: ADR144E

[willie bunter]

John,

Thanks for pointing out the error :  ** -

Thanks to all who responded.


On Mon, 3/20/17, John McKown  wrote:

 Subject: Re: ADR144E
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Monday, March 20, 2017, 9:18 AM
 
 On Mon, Mar 20, 2017 at
 8:12 AM, willie bunter <
 001409bd2345-dmarc-requ...@listserv.ua.edu>
 wrote:
 
 > Good Day To
 All,
 >
 > I am trying
 to troubleshoot a user's job which is using ADRDSSU.  I
 cannot
 > find the reason why the job
 fails on a :
 >
 >
 ADR144E (002)-RI03P(02), INCOMPLETE SPECIFICATION IN DATA
 SET REFERENCED
 > BY DDNAME FILTERDD
 >
 > ​
 >
 > Below is the
 FILTERDD  DD (TST.FILTDD)
 >
 >  INCLUDE( -
 >     
       )
 >
 > I think
 the problem could be with the parm DATASET(FDD I
 would
 > appreciate it someone could point
 out my error.
 >
 
 ​That is it. The INCLUDE doesn't have
 _any_ entries in it. It needs to have
 at
 least one.​ If you meant to select "all", then
 use ** as the DSN. E.g.
 
 INCLUDE( -
   ** -
 )
 
 ​Or
 perhaps some patterns:
 
 INCLUDE(-
    SYS1.**
 -
    SYS2.USER.** -
 )​
 
 
 
 
 >
 > Thanks in advance.
 >
 >
 --
 > For IBM-MAIN subscribe / signoff / archive
 access instructions,
 > send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 >
 
 
 
 -- 
 "Irrigation of the
 land with seawater desalinated by fusion power is
 ancient. It's called 'rain'."
 -- Michael McClary, in alt.fusion
 
 Maranatha! <><
 John
 McKown
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: Can SMPPTS datasets be consolidated?

[Paul Gilmartin]

On Mon, 20 Mar 2017 09:54:38 -0400, John Eells wrote:
>
>> However nowadays we have PDSE v2 with much bigger limit for member size.
>
>It's for that reason, among others, that we have PTF size limits, and
>the maximum size of a PDSE V1 member was one of the things on the list
>(now replaced by the maximum size of a PDS member, because we do not
>require the use of PDSEs for SMPPTS data sets).  ...
> 
The SMP/E Ref. still recommends PDSE.  I won't bother with an RCF
mentioning PDSE V2.

Does IBM break enormous PTFs into mutualy coREQ pieces?

-- gil

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

Re: Can SMPPTS datasets be consolidated?

[John Eells]

R.S. wrote:


Once upon a time I had to change SMPPTS to PDS because of ...size
limits. The limit of *single member( for PDSE was not enough to keep my
big fat PTF (yes, it was WAS). PDS has no such limit - the limit is full
PDS (64k TRK).
However nowadays we have PDSE v2 with much bigger limit for member size.


It's for that reason, among others, that we have PTF size limits, and 
the maximum size of a PDSE V1 member was one of the things on the list 
(now replaced by the maximum size of a PDS member, because we do not 
require the use of PDSEs for SMPPTS data sets).  If you got the sysmod 
from IBM, I would be very interested in knowing when it was and what 
product it was for (if you have that information handy) so I can 
"educate" the perpetr--um, that is, packager.


Other limits, internal ones aside, are imposed by tape, DVD, and 
commonly-deployed DASD volume sizes.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Can SMPPTS datasets be consolidated?

[Kurt Quackenbush]

Kirt - if you are still listening:  Why oh why has "CLEANUP COMPRESS(ALL)" never
been enhanced to include the SMPPTS or made an additional option?


Mostly I think because the REJECT PURGE command with the COMPRESS option 
provides essentially the same function I think you are asking CLEANUP to 
provide.  That is, delete MCS entries from the SMPPTS data sets and then 
compress those data sets.


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[PINION, RICHARD W.]

FWIW, I was notified that my personal information was part of the OPM
data breach.  Only problem is I've never worked for, nor applied for a
federal job.  However, back in 2007 I did work for an outsourcer who
had a federal account.  Perhaps that is how my personal information
got there.  

I contacted OPM and requested to know how my personal information was
on their system.  The response was they could not find my personal
information.  I contacted my U.S. Representative, and asked him to
contact OPM.  Basically got the same reply.  At that point I gave
up.  
   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Crossno
Sent: Monday, March 20, 2017 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ComputerWorld Says: Cobol plays major role in U.S. government 
breaches

If one reads the article, then digs into the underlying research, and finally 
the Congressional report on the OPM incidents (all 250 pages of it), it's quite 
easy to see that the authors of the research and subsequent article are 
implying that legacy=mainframe/COBOL, while the real problem(s) really had 
nothing to do with either, at the end of the day. It had everything to do with 
"legacy" network security, not following best security practices, etc. Where 
the research talks about investments in modernization, they imply that the 
problem is "archaic" 30-year old COBOL systems, when that really isn't 
supported by the research at all (contradictions?). They really mean that when 
the distributed network security is modernized with security best practices, 
advanced intrusion and malware detection, use of MFA/PIV/etc, there's a 
reduction in the number of incidents.

I wrote up a longer response to it, as comments to the FB and LinkedIn 
postings, that starts with the OPM report and works it's way back up to the 
article. Seemingly, Computerworld didn't like some of the original comments 
from their posting last week on LinkedIn, and felt the need to repost it 
yesterday. That's where my longer comments can be found, vs their original 
posting. Can't link directly to it or the FB posting.. You'll have to search 
for Computerworld's page, then scroll.

At the end of the day, it really has nothing to do with COBOL "security" at 
all, but everything to do with network security. The article is just an example 
of taking at face value poor research, taking liberties with and cherry picking 
bits of a report and quotes from people who probably don't understand the 
technology to begin with, and just plain old fashioned bad journalism... Fake 
News!



"Common sense is not so common."
 * Voltaire, Dictionnaire Philosophique (1764)



On Mon, Mar 20, 2017 at 8:51 AM, Elardus Engelbrecht < 
elardus.engelbre...@sita.co.za> wrote:

> Todd Arnold wrote:
>
> >Gee, I've been developing crypto technology for 30+ years that runs 
> >in
> those environments - so it's certainly news to me that it can't be 
> done :-)
>
> Amazing! ;-)
>
> No one said those cards are that *fast* !
>
>
> >Looking at the ICSF Application Programmer's Guide, which defines the
> ways most z/OS applications get cryptographic services, I see this:
>
> >  ICSF callable services can be called from application programs 
> > written
> in a number of high-level languages as well as assembler. The 
> high-level languages are:
> >- C
> >- COBOL
> >- FORTRAN
> >- PL/I
>
> And REXX + Assembler too. Look in Redbook - 'System z Crypto and TKE 
> Update' (SG24-7848-00) for samples.
>
> Note from that bookie: The code supplied has not been subjected to any 
> formal IBM test 
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> 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
FIRST TENNESSEE

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: ADR144E

[John McKown]

On Mon, Mar 20, 2017 at 8:12 AM, willie bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> Good Day To All,
>
> I am trying to troubleshoot a user's job which is using ADRDSSU.  I cannot
> find the reason why the job fails on a :
>
> ADR144E (002)-RI03P(02), INCOMPLETE SPECIFICATION IN DATA SET REFERENCED
> BY DDNAME FILTERDD
>
> ​
>
> Below is the FILTERDD  DD (TST.FILTDD)
>
>  INCLUDE( -
>)
>
> I think the problem could be with the parm DATASET(FDD I would
> appreciate it someone could point out my error.
>

​That is it. The INCLUDE doesn't have _any_ entries in it. It needs to have
at least one.​ If you meant to select "all", then use ** as the DSN. E.g.

INCLUDE( -
  ** -
)

​Or perhaps some patterns:

INCLUDE(-
   SYS1.** -
   SYS2.USER.** -
)​




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



-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

Re: ADR144E

[Burrell, Todd]

Shouldn't the filter be something like INCLUDE( ** )?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of willie bunter
Sent: Monday, March 20, 2017 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ADR144E

Good Day To All,

I am trying to troubleshoot a user's job which is using ADRDSSU.  I cannot find 
the reason why the job fails on a :

ADR144E (002)-RI03P(02), INCOMPLETE SPECIFICATION IN DATA SET REFERENCED BY 
DDNAME FILTERDD   

Below is the jcl:

/* 
//S4112  EXEC PGM=ADRDSSU,REGION=0K,PARM='TYPRUN=NORUN' 
//TD9101   DD UNIT=3390,VOL=SER=TD9101,DISP=SHR 
//TD9102   DD UNIT=3390,VOL=SER=TD9102,DISP=SHR 
//TD9103   DD UNIT=3390,VOL=SER=TD9103,DISP=SHR 
//TD9104   DD UNIT=3390,VOL=SER=TD9104,DISP=SHR 
//NOTAPE   DD DUMMY 
//SYSPRINT DD SYSOUT =*
//SYSUDUMP DD SYSOUT=D  
//SYSINDD DSN=PROD.DATALIB(SYSDAU),DISP=SHR 
//FILTERDD DD DSN=TST.FILTDD,DISP=SHR   

Below is the SYSIN DD contents:

DUMP INDDNAME(TD9101) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  
DUMP INDDNAME(TD9102) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  
DUMP INDDNAME(TD9103) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  
DUMP INDDNAME(TTD9104) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  

Below is the FILTERDD  DD (TST.FILTDD)

 INCLUDE( -
   )   

I think the problem could be with the parm DATASET(FDD I would appreciate 
it someone could point out my error.

Thanks in advance.

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



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email.


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

ADR144E

[willie bunter]

Good Day To All,

I am trying to troubleshoot a user's job which is using ADRDSSU.  I cannot find 
the reason why the job fails on a :

ADR144E (002)-RI03P(02), INCOMPLETE SPECIFICATION IN DATA SET REFERENCED BY 
DDNAME FILTERDD   

Below is the jcl:

/* 
//S4112  EXEC PGM=ADRDSSU,REGION=0K,PARM='TYPRUN=NORUN' 
//TD9101   DD UNIT=3390,VOL=SER=TD9101,DISP=SHR 
//TD9102   DD UNIT=3390,VOL=SER=TD9102,DISP=SHR 
//TD9103   DD UNIT=3390,VOL=SER=TD9103,DISP=SHR 
//TD9104   DD UNIT=3390,VOL=SER=TD9104,DISP=SHR 
//NOTAPE   DD DUMMY 
//SYSPRINT DD SYSOUT =*
//SYSUDUMP DD SYSOUT=D  
//SYSINDD DSN=PROD.DATALIB(SYSDAU),DISP=SHR 
//FILTERDD DD DSN=TST.FILTDD,DISP=SHR   

Below is the SYSIN DD contents:

DUMP INDDNAME(TD9101) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  
DUMP INDDNAME(TD9102) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  
DUMP INDDNAME(TD9103) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  
DUMP INDDNAME(TTD9104) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  

Below is the FILTERDD  DD (TST.FILTDD)

 INCLUDE( -
   )   

I think the problem could be with the parm DATASET(FDD I would appreciate 
it someone could point out my error.

Thanks in advance.

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

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[John Crossno]

If one reads the article, then digs into the underlying research, and
finally the Congressional report on the OPM incidents (all 250 pages of
it), it's quite easy to see that the authors of the research and subsequent
article are implying that legacy=mainframe/COBOL, while the real problem(s)
really had nothing to do with either, at the end of the day. It had
everything to do with "legacy" network security, not following best
security practices, etc. Where the research talks about investments in
modernization, they imply that the problem is "archaic" 30-year old COBOL
systems, when that really isn't supported by the research at all
(contradictions?). They really mean that when the distributed network
security is modernized with security best practices, advanced intrusion and
malware detection, use of MFA/PIV/etc, there's a reduction in the number of
incidents.

I wrote up a longer response to it, as comments to the FB and LinkedIn
postings, that starts with the OPM report and works it's way back up to the
article. Seemingly, Computerworld didn't like some of the original comments
from their posting last week on LinkedIn, and felt the need to repost it
yesterday. That's where my longer comments can be found, vs their original
posting. Can't link directly to it or the FB posting.. You'll have to
search for Computerworld's page, then scroll.

At the end of the day, it really has nothing to do with COBOL "security" at
all, but everything to do with network security. The article is just an
example of taking at face value poor research, taking liberties with and
cherry picking bits of a report and quotes from people who probably don't
understand the technology to begin with, and just plain old fashioned bad
journalism... Fake News!



"Common sense is not so common."
 * Voltaire, Dictionnaire Philosophique (1764)



On Mon, Mar 20, 2017 at 8:51 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Todd Arnold wrote:
>
> >Gee, I've been developing crypto technology for 30+ years that runs in
> those environments - so it's certainly news to me that it can't be done :-)
>
> Amazing! ;-)
>
> No one said those cards are that *fast* !
>
>
> >Looking at the ICSF Application Programmer's Guide, which defines the
> ways most z/OS applications get cryptographic services, I see this:
>
> >  ICSF callable services can be called from application programs written
> in a number of high-level languages as well as assembler. The high-level
> languages are:
> >- C
> >- COBOL
> >- FORTRAN
> >- PL/I
>
> And REXX + Assembler too. Look in Redbook - 'System z Crypto and TKE
> Update' (SG24-7848-00) for samples.
>
> Note from that bookie: The code supplied has not been subjected to any
> formal IBM test 
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> 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: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Elardus Engelbrecht]

Todd Arnold wrote:

>Gee, I've been developing crypto technology for 30+ years that runs in those 
>environments - so it's certainly news to me that it can't be done :-)

Amazing! ;-)

No one said those cards are that *fast* ! 


>Looking at the ICSF Application Programmer's Guide, which defines the ways 
>most z/OS applications get cryptographic services, I see this:

>  ICSF callable services can be called from application programs written in a 
> number of high-level languages as well as assembler. The high-level languages 
> are:
>- C
>- COBOL
>- FORTRAN
>- PL/I

And REXX + Assembler too. Look in Redbook - 'System z Crypto and TKE Update' 
(SG24-7848-00) for samples.

Note from that bookie: The code supplied has not been subjected to any formal 
IBM test 

Groete / Greetings
Elardus Engelbrecht

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

Re: [EXTERNAL] Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Dyck, Lionel B. (TRA)]

Todd - you're bringing logic and fact to the table and those who distribute FUD 
hate that and do all they can to both ignore it and obscure it.

:-)

--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10)
Information and Technology, IT Operations and Services

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Todd Arnold
Sent: Monday, March 20, 2017 7:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: ComputerWorld Says: Cobol plays major role in U.S. 
government breaches

Gee, I've been developing crypto technology for 30+ years that runs in those 
environments - so it's certainly news to me that it can't be done :-)
 
Looking at the ICSF Application Programmer's Guide, which defines the ways most 
z/OS applications get cryptographic services, I see this:

  ICSF callable services can be called from application programs written in a 
number
  of high-level languages as well as assembler. The high-level languages are:
- C
- COBOL
- FORTRAN
- PL/I

--
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: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Todd Arnold]

Gee, I've been developing crypto technology for 30+ years that runs in those 
environments - so it's certainly news to me that it can't be done :-)
 
Looking at the ICSF Application Programmer's Guide, which defines the ways most 
z/OS applications get cryptographic services, I see this:

  ICSF callable services can be called from application programs written in a 
number
  of high-level languages as well as assembler. The high-level languages are:
- C
- COBOL
- FORTRAN
- PL/I

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

Re: SSL on tso

[Elardus Engelbrecht]

saurabh khandelwal wrote:

>We have requirement to enable SSL for two access with ibm PCOOM emulator

Are you referring to IBM PCOM emulater? Just checking about your spelling.


>with port 992 for secure connection. 

It depends on what your TCP/IP staff is using that port or any other port for 
TSO logon.


>I tried looking at document and rebook but didn't find any implementation 
>steps.

Really? There are many books and discussion lists sitting worldwide about this 
topic. Did you asked Mr. G. O. Ogle (Google) for it?


>Can anybody help to make this setup work.

Ask your TELNET server staff for assistance. Also ask your RACF staff for 
assistance for setting up a Digital Certificate for TELNET server. 

Just ensure you have a default TELNET non-SSL port in case you can't login in 
the first place.

Good luck, this is a major project. (I and my colleagues have been there and it 
was quite a journey, trust me.)

Groete / Greetings
Elardus Engelbrecht

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

Re: Can SMPPTS datasets be consolidated?

[R.S.]

W dniu 2017-03-17 o 23:28, CM Poncelet pisze:

[...]
BTW SMPPTS is written to only during RECEIVE. Else it is only read.


What about ACCEPT?

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: Can SMPPTS datasets be consolidated?

[R.S.]

W dniu 2017-03-18 o 22:38, Mark Zelden pisze:

On Fri, 17 Mar 2017 22:00:52 +, Jesse 1 Robinson  
wrote:


Pretty sure I used to do exactly this for the same reason Mark does. However,
now SMPPTS% is all PDSE, compression becomes a non-issue. The system knows
not to try compressing SMPPTS%, so it does not need to be in the RETRY exclude 
list.

I meant to mention this, but I forgot.   I have to use PDS for my SMPPTSes 
because we share
the global zone between 2 business units / sysplxes that have their own target 
zones.  This
is needed due to different customization / usermods for each of the business 
units.

Not just the global zone is shared, all the CSIs associated with each target 
zone for each
sysres set in each environment is on the shared string of DASD.  This way I can 
look
from any LPAR and see what sysres sets a PTF is applied to.   The sysres sets 
themselves
are not shared, so the apply has to be done in the proper sysplex.



Once upon a time I had to change SMPPTS to PDS because of ...size 
limits. The limit of *single member( for PDSE was not enough to keep my 
big fat PTF (yes, it was WAS). PDS has no such limit - the limit is full 
PDS (64k TRK).

However nowadays we have PDSE v2 with much bigger limit for member size.


--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: Can SMPPTS datasets be consolidated?

[R.S.]

W dniu 2017-03-17 o 22:03, Paul Gilmartin pisze:

On 2017-03-17, at 14:44, Jesse 1 Robinson wrote:


By 'compress', I mean plain old IEBCOPY to squeeze out the gas left by deleted 
members. I realize after my previous post that I now routinely create SMPPTS% 
as PDSE, so compression is not an option. Back when multiple SMPPTS% became 
available, SMPE/E would try to compress every PTS% that got x37. Every time. 
The only thing wrong with that is the churn in I/O and CPU plus SYSPRINT lines 
trying futilely on every RECEIVE to compress a full PDS. The SMP/E OPTIONS 
entry allows for list of exceptions for RECOVERY, but I don't have any DDDEFs 
listed there.
  

Oh.  That COMPRESS.

Not harmful except for being wasteful.  That may be a reason that
SMP/E recommends allocating SMPPTS as PDSE.


IMHO the main reason is size restriction. PDS - 64k TRK (~3GB), PDSE - 
full volume (up to 1 TB nowadays).



--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


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

Re: "embedded" ISPF panels/message/etc

[Robert Prins]

On 2017-03-14 15:27, John McKown wrote:

I want to write an ISPF application which is self contained. I vaguely
remembered that someone, sometime, said it is possible to "embed" the ISPF
panels / message / et al in the REXX itself. The only thing that I've seen
is more like an shell HERE document. This function basically creates a
temporary file, writes the HERE data to it, then uses that temporary file.
The ISPF equivalent is to write the ISPF panels / messages and so on into
"temporary" PDSes. And then use the LIBDEF to make the PDSes active. Is
this the way it is done? That is, by "cheating", rather than some ISPF
function?


Convert anything into REXX QUEUE statements:
https://prino.neocities.org/zOS/epanq.exec.html

An example:
https://prino.neocities.org/zOS/e123.exec.html

Invoke as "epanq ?" or "e123 ?@s" to get the builtin help.

Note that it's perfectly possible to store LOAD libraries in your exec. Just 
AMATERSE them, convert them into QUEUE statements, load a dataset and unpack them.


Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com

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

SSL on tso

[saurabh khandelwal]

Hello group,

We have requirement to enable SSL for two access with ibm PCOOM emulator
with port 992 for secure connection. I tried looking at document and rebook
but didn't find any implementation steps.

Can anybody help to make this setup work.

Regards
Saurabh

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