Looking for an appropriate system exit

[Steff Gladstone]

Greetings,

In our installation we would like to implement certain checks and document
certain run-time characteristics at the beginning and during  program
initialization and duration (chiefly Cobol programs).  We would like to
implement this in a manner transparent to the application, without
requiring the programmer to add lines of JCL or calls to subroutines (we
have thousands of legacy programs and jobs and don't want to have to go
through a massive conversion project).

We are looking at initialization routines like CEEBINT.   Can anyone
recommend any other system exits that could be candidates for this sort of
thing.  Any potential pitfalls we should be aware of?

Thank you,
Steff Gladstone

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

Note on COBOL 5.x

[Sankaranarayanan, Vignesh]

Hello List,

Here's something fun I noticed.
Apparently, from COBOL 5.x, compilations are tracked through SMF 89.
I don't remember the exact wording but it said something like a newer version 
of the SCRTTool being needed for this, and that it will not accept the 'facts' 
that we give it through the //NO89 DD, i.e., through that DD, we used to be 
able to specify what product runs where.
Now there seems to be some actual tracking through SMF.
So just a friendly reminder to put a leash on products via IFAPRDxx.

- Vignesh
Mainframe Infrastructure


MARKSANDSPENCER.COM

Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Re: LE Recovery

[Peter Hunkeler]

>I call out to assembler and establish the ESTAE after LE initialization -- in 
>my application code, in other words. 


From the LE Programming Guide, topic "System Services available to assembler 
routines":
"The system-provided service should not be used. If you use this service, 
itdirectly interferes with the Language Environment environment. For example, 
any ESTAE or ESPIE that you issue interferes with Language Environment 
condition handling."


The interference may result in LE unregistering — what it considers to be its 
own — current ESTAE routine as result of some error handling invoked via LE's 
ESPIE routine. But the current ESTAE routine is in fact the one you established 
after LE's initialization. So your ESTAE routine may not get control in certain 
(program check) cases. 


You may think that you then better establish your own ESPIE routine as well, 
thereby disabling LE's ESPIE routine, so the case describe above cannot occur. 
That is true, however, modern COBOL compilers (i.e. V5 and up) may generate 
code that may raise 00A program checks when you would not expect them. LE's 
ESPIE routine handles them efficiently. Without LE's ESPIE routine, this may 
become a performance nightmare.


I've learned all this from the analyzing and finally solving problem we've been 
facing with RAI's Smart/Restart earlier this year. Search the archive for 
"Smart/Reestart", or "00A program check", or "S0CA", if you're interested in 
the whole story.


-- 
Peter Hunkeler

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

Cobol 5/6 - Compile listing integrated into load module

[Steff Gladstone]

In versions 5 and 6 of Cobol, IBM has introduced the option of including
the compile listing (or at least the data from which a compile listing can
be derived) into the load module for subsequent debug processing.
Presumably this obviates the need to maintain something like the DDIO file
required by Compuware's Expeditor product.

My question is: does anybody know where this option is documented in
detail, including:

  - all of the various compile-time parameters provided for specifying
this option

  -  how the compile information in the load module can be retrieved?
 Or is this totally proprietary information that IBM keeps under
tabs?

Thanks in advance for any assistance,
Steff Gladstone

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

Re: SFTP

[Edward Gould]

> On Dec 5, 2017, at 9:00 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> ——SNIP--
> 
> FTP grew in a heterogeneous envirnment and has accommodations for UNIX,
> OS/360, VAX, TOPS-10, ...  Somewhat dismayingly, sftp is inexorably 
> UNIX-centric.
> Co:Z tries to address this deficiency.
>https://dovetail.com/products/sftp.html
> 
> FTPS (is this the same as FTP with AT/TLS?) requires elaborate setup and 
> firewall
> exceptions, partly because of the auxiliary data socket.
> 
> — gil

Gil (or anyone):
Does dovetail ship their products in SMPE installable format or ? The company I 
am helping has a issue with *ANY* product that is not SMPE installable.
Before I go to bat for Dovetail, I would like to know that issue, if not I 
won’t bother. I tried to use their forum and it won’t let me ask the question 
as to cost for Gold for all 3 of their products. I refuse to spend my time  for 
a simple question.

Ed

> 

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

Re: IBM does what IBM does best: Raises the chopper again

[Art Gutowski]

On Fri, 1 Dec 2017 16:54:18 +, Stone, Marshall  
wrote:
>HEX 42 in Binary - 0100 0010  - now using fingers up/down to represent 
>digits...

Brilliant!

Art

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

Re: NFS on Mainframe

[Paul Gilmartin]

On Tue, 5 Dec 2017 19:52:17 -0600, John McKown wrote:
>> >
>> We tried that once.  Failed because of a certain application that used
>> commas in filenames.
>
>​Why would a comma cause a problem? I'm not NFS literate. But wouldn't
>PATH='/some/directory,me/file.txt' work on NFS as well as zFS?​
>
Network File System Guide and Reference Version 2 Release 3
Naming MVS files
The z/OS NFS server uses the comma (,) as a delimiter to a list of file 
attributes.
Do not use a comma as a special character in file name. For example, 
you can
enter this command:
$ vi "/u/smith/new,text"

This indicates to NFS that a file called new is being edited in the 
attribute text
mode, not file new,text.

And while the delimiter can be changed, (perhaps entirely disabled, unlike 
ISPF's
delimiter), this is in global options and may adversely affect other users who
depent on using ',' as a delimiter.

-- gil

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

Re: SFTP

[Paul Gilmartin]

On Wed, 6 Dec 2017 01:47:08 +, W Mainframe wrote:

>Come on.For years FTP works Now... Every OS needs to upgrade for 
>SFTP?Only now, this protocol is unsure One more stupid option... bla. bla 
>bla
> 
Yup.   Technology advances alike on the benign and the malicious sides.  The 
former
must advance to keep up with the latter.
https://en.wikipedia.org/wiki/Red_Queen%27s_race

FTP grew in a heterogeneous envirnment and has accommodations for UNIX,
OS/360, VAX, TOPS-10, ...  Somewhat dismayingly, sftp is inexorably 
UNIX-centric.
Co:Z tries to address this deficiency.
https://dovetail.com/products/sftp.html

FTPS (is this the same as FTP with AT/TLS?) requires elaborate setup and 
firewall
exceptions, partly because of the auxiliary data socket.

-- gil

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

Re: NFS on Mainframe

[John McKown]

On Tue, Dec 5, 2017 at 5:11 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 4 Dec 2017 23:23:18 -0600, Munif Sadek wrote:
>
> >To start with. I am planning to l configure NFS client on my Sandbox zOS
> 2.3  LPAR  and NFS server  on sandbox AIX 7.1 LPAR (using classic IBM
> Hypervisor).
> >
> >Depending on the outcome, I may switch zOS to be the NFS server. Our main
> objective is stop  FTPing tens of reports but write them to NFS so that
> end-users (non mainframers)  can pick them up.
> >
> We tried that once.  Failed because of a certain application that used
> commas in filenames.
>

​Why would a comma cause a problem? I'm not NFS literate. But wouldn't
PATH='/some/directory,me/file.txt' work on NFS as well as zFS?​



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



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

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: some software withdrawal from marketing announcements (to me)

[John McKown]

On Tue, Dec 5, 2017 at 4:03 PM, Pommier, Rex 
wrote:

> ​S​
> o this simply means we won't be able to order them any more, correct?  IBM
> will still fix bugs and support the products for the foreseeable future.
>

​Right. It is a kind of warning to be sure to make some very secure back
ups of the products because you won't be able to re-order them should they
somehow "disappear".​



>
> Rex
>
>

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

SFTP

[W Mainframe]

Come on.For years FTP works Now... Every OS needs to upgrade for 
SFTP?Only now, this protocol is unsure One more stupid option... bla. bla 
bla



Sent from Yahoo Mail for iPhone

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

Re: NFS on Mainframe

[Munif Sadek]

Hi Andrew

Thanks for the hint. Last time I read about HTTPS, when I was  attempting to 
implement SSL on our ezasocket CICS Listener. I just hope that I do not need 
another licensed product.  I do not think HTTPS is the solution in our case but 
may be a replacement for FTP.

NFS is such a *out of box things* in non-Mainframe world and surprise to see 
its not popular/standard in Mainframe which is taken for granted to be large 
Data server.

I have got  NFS Guide and reference 640 Pages manual to review and was 
expecting if any kind lister  can give some pointer to implement NFS with and 
without security.

(neither I have LDAP or Kerberos customized in our mainframe, so there will be 
heavy lifting)

Thanks a lot,
Kind regards
Munif

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

Re: NFS on Mainframe

[Paul Gilmartin]

On Wed, 6 Dec 2017 10:57:21 +1100, Andrew Rowley wrote:

>On 5/12/2017 4:23 PM, Munif Sadek wrote:
>> Depending on the outcome, I may switch zOS to be the NFS server. Our main 
>> objective is stop  FTPing tens of reports but write them to NFS so that 
>> end-users (non mainframers)  can pick them up.
>>
>Have you considered serving them via HTTPS instead?
> 
Are the "reports" all text; no binary; no packed decimal?

Might be practical with a script to add headers and footers and entify
"dangerous" characters, "&", "<", and ">".

And some browsers will treat a document lacking HTML headers as
preformatted text.

-- gil

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

Re: NFS on Mainframe

[Andrew Rowley]

On 5/12/2017 4:23 PM, Munif Sadek wrote:

Depending on the outcome, I may switch zOS to be the NFS server. Our main 
objective is stop  FTPing tens of reports but write them to NFS so that 
end-users (non mainframers)  can pick them up.


Have you considered serving them via HTTPS instead?

--
Andrew Rowley
Black Hill Software

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

Re: NFS on Mainframe

[Longnecker, Dennis]

I'm jumping in on thisis there any quickstarts out there to get NFS (Client 
or server?) installed on z/os?

Dennis

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 5, 2017 3:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS on Mainframe

On Mon, 4 Dec 2017 23:23:18 -0600, Munif Sadek wrote:

>To start with. I am planning to l configure NFS client on my Sandbox zOS 2.3  
>LPAR  and NFS server  on sandbox AIX 7.1 LPAR (using classic IBM Hypervisor).
>
>Depending on the outcome, I may switch zOS to be the NFS server. Our main 
>objective is stop  FTPing tens of reports but write them to NFS so that 
>end-users (non mainframers)  can pick them up.
>
We tried that once.  Failed because of a certain application that used commas 
in filenames.

-- gil

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

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

Re: NFS on Mainframe

[Paul Gilmartin]

On Mon, 4 Dec 2017 23:23:18 -0600, Munif Sadek wrote:

>To start with. I am planning to l configure NFS client on my Sandbox zOS 2.3  
>LPAR  and NFS server  on sandbox AIX 7.1 LPAR (using classic IBM Hypervisor).
>
>Depending on the outcome, I may switch zOS to be the NFS server. Our main 
>objective is stop  FTPing tens of reports but write them to NFS so that 
>end-users (non mainframers)  can pick them up.
>
We tried that once.  Failed because of a certain application that used
commas in filenames.

-- gil

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

Re: TECHDOCS 404 error

[Daniel S. Dalby]

When I manually go through the web page I get ...
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/Web/FL-ByDate

Note:  HTTP not HTTPS and it successfully shows the flashes by date.

Dan

"Richards, Robert B."  wrote in message
news:...
>
https://www.ibm.com/;www-03.ibm.com/support/techdocs/atsmastr.nsf/Web/FL-ByD
ate
> 
> Anyone else seeing the 404 message when using BYDATE criteria?
> 
> Bob 

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

Re: some software withdrawal from marketing announcements (to me)

[Pommier, Rex]

So this simply means we won't be able to order them any more, correct?  IBM 
will still fix bugs and support the products for the foreseeable future.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, December 05, 2017 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: some software withdrawal from marketing announcements (to me)

From
http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/9/897/ENUS917-189/index.html=en_locale=en

COBOL 4.2 on March 12, 2018.
PL/I 4.x on March 12, 2018

The only reason I mentioned the above is because they are the last versions
of those compilers which can be linked into a standard PDS rather than a
PDSE.

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: [TSO-REXX] Fwd: Pipelines in the z/OS base.

[Edward Finnell]

We were ESP for MVS in early 80's and found a few. No Eye-catcher, not RENT, RC 
.ne. 0. The IMS BMP's used to stub out to BR14 for development after XA started 
getting alignment errors with the call.
 
We didn't have time to investigate fully just put in CNOP(0,4) and it went away.
 
Later I remember some release of ESA we skipped-maybe 4.4 it was left out of 
the base completely. Last time I looked the eye-catcher had disappeared.
 
In a message dated 12/4/2017 4:50:40 PM Central Standard Time, 
zedgarhoo...@gmail.com writes:

 
I've also heard that there was some structural problem in IEFBR14 fixed via
APAR -- no comma on END or some such trivial thing that mostly didn't
matter but did in some linkedit cases. Anyone?

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

Re: XCF large message traffic bursts (BMC SQL Performance)

[Jesse 1 Robinson]

BMC never met a resource that they didn't gobble up and demand more of, like 
Oliver's porridge. Just say no. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Derrick Haugan
Sent: Tuesday, December 05, 2017 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: XCF large message traffic bursts (BMC SQL Performance)

A peek inside the STCs on the sysplex that's experienced issues, shows these 
XCF groups in use:

BMCLGC0277I Found registration record for DBC GROUP DCPLEX
REGDSN: x, XCF GROUP: LGCGRP01, DBC GROUP: DCPLEX 
also -
BMC24820 DC01 DOMPLEX member x joined XCF group DCPLEX$  
successfully

My understanding from BMC, is that 'reporting' can generate the XCF activity, 
by shipping data around the sysplex for focal point reporting. We intend to 
isolate the product's traffic into its own set of transport classes.


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

some software withdrawal from marketing announcements (to me)

[John McKown]

From
http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/9/897/ENUS917-189/index.html=en_locale=en

COBOL 4.2 on March 12, 2018.
PL/I 4.x on March 12, 2018

The only reason I mentioned the above is because they are the last versions
of those compilers which can be linked into a standard PDS rather than a
PDSE.

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

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: XCF large message traffic bursts (BMC SQL Performance)

[Derrick Haugan]

A peek inside the STCs on the sysplex that's experienced issues, shows these 
XCF groups in use:

BMCLGC0277I Found registration record for DBC GROUP DCPLEX
REGDSN: x, XCF GROUP: LGCGRP01, DBC GROUP: DCPLEX
also -
BMC24820 DC01 DOMPLEX member x joined XCF group DCPLEX$  
successfully

My understanding from BMC, is that 'reporting' can generate the XCF activity, 
by shipping data around the sysplex for focal point reporting. We intend to 
isolate the product's traffic into its own set of transport classes.

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

Re: LE Recovery

[Charles Mills]

Yep. Exactly.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Tuesday, December 5, 2017 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE Recovery

Charles:

You have a LE Assembler driver who establishes the ESTAE and then comes back to 
the main code ??

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

Re: STC @ IPL - how to wait for OMVS to be initialized with no automation product.

[John McKown]

On Tue, Dec 5, 2017 at 11:00 AM, Charles Mills  wrote:

> Late to this thread -- sorry.
>
> I am responsible for an STC that is dubbed immediately and that most
> customers start early in the IPL. I have never heard any "you fail because
> OMVS is not up" problems from customers. Perhaps we have just been lucky
> and/or customers have solved it on their own with automation. I have to
> think most of our customers use IPL automation.
>

​No, I made a mistake in my code which _appeared_ to be a UNIX problem
because I didn't zero out some fields.​



>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rob Scott
> Sent: Tuesday, December 5, 2017 8:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: STC @ IPL - how to wait for OMVS to be initialized with no
> automation product.
>
> If ENFREQ listen for event code 46 is out of the question, you could call
> BPXEKDA for the global OMVS options and wait+retry if you get rc=28
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

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: LE Recovery

[scott Ford]

Charles:

You have a LE Assembler driver who establishes the ESTAE and then comes
back to the main code ??

Scott

On Tue, Dec 5, 2017 at 12:02 PM, Charles Mills  wrote:

> I call out to assembler and establish the ESTAE after LE initialization --
> in my application code, in other words.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Marchant
> Sent: Tuesday, December 5, 2017 4:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LE Recovery
>
> On Mon, 4 Dec 2017 17:28:41 -0500, scott Ford wrote:
>
> >If i had a main line in assembler and set a ESTAE before calling a
> >Cobol main routine, could i intercept the 'C stcname' and be able to
> >recovery ?
>
> I'm not sure. Having set your ESTAE(X), then calling your Cobol main
> routine, I'm pretty sure LE would establish its own ESTAE(X), which would
> receive control first. Will it percolate to you in all the cases you are
> interested in? If I wanted to do something like this, I would establish the
> LE environment before setting your ESTAE(X).
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: LE Recovery

[Charles Mills]

I call out to assembler and establish the ESTAE after LE initialization -- in 
my application code, in other words.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, December 5, 2017 4:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE Recovery

On Mon, 4 Dec 2017 17:28:41 -0500, scott Ford wrote:

>If i had a main line in assembler and set a ESTAE before calling a 
>Cobol main routine, could i intercept the 'C stcname' and be able to 
>recovery ?

I'm not sure. Having set your ESTAE(X), then calling your Cobol main routine, 
I'm pretty sure LE would establish its own ESTAE(X), which would receive 
control first. Will it percolate to you in all the cases you are interested in? 
If I wanted to do something like this, I would establish the LE environment 
before setting your ESTAE(X).

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

Re: STC @ IPL - how to wait for OMVS to be initialized with no automation product.

[Charles Mills]

Late to this thread -- sorry.

I am responsible for an STC that is dubbed immediately and that most customers 
start early in the IPL. I have never heard any "you fail because OMVS is not 
up" problems from customers. Perhaps we have just been lucky and/or customers 
have solved it on their own with automation. I have to think most of our 
customers use IPL automation.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Scott
Sent: Tuesday, December 5, 2017 8:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STC @ IPL - how to wait for OMVS to be initialized with no 
automation product.

If ENFREQ listen for event code 46 is out of the question, you could call 
BPXEKDA for the global OMVS options and wait+retry if you get rc=28

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

Re: STC @ IPL - how to wait for OMVS to be initialized with no automation product.

[Rob Scott]

If ENFREQ listen for event code 46 is out of the question, you could call 
BPXEKDA for the global OMVS options and wait+retry if you get rc=28

Rob Scott

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, December 4, 2017 8:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STC @ IPL - how to wait for OMVS to be initialized with no 
automation product.

On Mon, Dec 4, 2017 at 2:31 PM, Jackson, Rob 
wrote:

> Won't it just wait on its own?  We've never done anything special, and
> we've never had any issues with things requiring OMVS.  Every time we
> IPL we get message BPXP022E . . . .
>

​Hum, maybe I'm doing some else wrong. I assumed my problem was that the START 
was due to OMVS not being completely up. ​



>
> First Tennessee Bank
> Mainframe Technical Support
> 1638 Robert C Jackson Dr
> Maryville, TN 37801
> O:  865-977-5343
> C:  334-201-8516
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John McKown
> Sent: Monday, December 04, 2017 2:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: STC @ IPL - how to wait for OMVS to be initialized with no
> automation product.
>
> [External Email]
>
> This is for another system, not my employer's, which I sometime help
> to customize. I need to run a task at IPL time. The simplest way is to
> use the COMMNDxx member of PARMLIB to do a START command. But the
> program I'm running requires UNIX to be completely initialized. If I
> had automation, I'd do the START when the BPXI004I message is issused.
> But I don't have automation. I don't see any BPX1* callable UNIX
> service which says "wait for UNIX to become ready and then return". I
> do see an ENFREQ request which can receive the "UNIX initiation
> complete" message, but an ENFREQ REQUEST=LISTEN is a PITA in my opinion. Or 
> maybe I'm just really lazy.
>
> Any ideas?
>
> --
> I have a theory that it's impossible to prove anything, but I can't
> prove it.
>
> Maranatha! <><
> John McKown
>
> --
> 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
>



--
I have a theory that it's impossible to prove anything, but I can't prove it.

Maranatha! <><
John McKown

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 877.328.2932
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Since it's Friday

[Barry Merrill]

Button 287 "VSAM is the COBOL of Access Methods" was by Tom McSloy at GUIDE
in 1975.  And COBOL programmers at the time thought that was a compliment!

www.mxg.com/thebuttonman/search.asp 

Merrilly yours,

Barry Merrill


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, December 5, 2017 7:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Since it's Friday

I'm not so "young" to remember that, however I vaguely remember I read some 
VSAM book (bought for many $$$). The book was awfully outdated, so I learned 
mostly VSAM history and obsolete features. It was ~13 years ago, but I would 
bet VSAM was born in 1974.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2017-12-05 o 09:19, Wayne Bickerdike pisze:
> VSAM was no later than 1975. I was in a PL/I class at Sudbury in 1975.
> Happened to be the week England beat Cyprus at Wembley 5-0 and Malcolm
> MacDonald scored all 5 goals.
>
> Anyway, our teacher at Sudbury asked this question:
>
> "Why is VSAM like a cow in the middle of a meadow".
>
> Answer:
>
> "They are both outstanding in their field".
>
> 16 April 1975: England's Malcolm Macdonald scores five against Cyprus
>
> Funny how things stick in your memory.
>
> We were still ISAM many years later.
>
> On Tue, Dec 5, 2017 at 9:00 AM, Seymour J Metz  wrote:
>
>> ICF came in with DF/EF, which preceded MVS/XA.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf
>> of Mike Schwab 
>> Sent: Monday, December 4, 2017 4:29 PM
>> To: IBM-MAIN@listserv.ua.edu
>> Subject: Re: Since it's Friday
>>
>> I think CVOL / VSAM catalogs in MVS was version 1.  ICF catalogs
>> introduced during XA switchover period is version 2.
>>
>> On Mon, Dec 4, 2017 at 8:56 AM, R.S. 
>> wrote:
>>> W dniu 2017-12-01 o 21:43, Pew, Curtis G pisze:
 This is just a curiosity question, but I’ve wondered about this.

 The JCL reference says:

 All temporary data set names begin as follows:
 SYSyyddd.Thhmmss.RA000.jjobname

 Does anyone know the story behind the ‘RA000’ part? It seems unnecessary
 and arbitrary.

>>> Well, we used to answer "Frankie did this and he said >> do't change it<<
>>> but Frankie died..."
>>>
>>> BTW: almost every LISTCAT output contains "VERSION: 2" statement. Why
>> it's
>>> 2?
>>>
>>>
>>> --
>>> 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.plsą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: XCF large message traffic bursts (BMC SQL Performance)

[Vernooij, Kees (ITOPT1) - KLM]

My DB2 colleagues are sure they configured XCF and I see 3 groups: DCPLEX, 
DCPLEX$ and DCPLEX@. Could you share the corresponding settings?

I am interested in the differences between our installations and, of course, 
the 'magic command' that might unexpectedly trigger the XCF bursts at our site.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Derrick Haugan
> Sent: 05 December, 2017 16:19
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: XCF large message traffic bursts (BMC SQL Performance)
> 
> As I understand it, in a "DOMPLEX" (BMC lingo for the base product
> configuration), you can choose to use XCF, or you can turn it off for
> use with the SQL product's query traffic. maybe its turned off at your
> shop? Our database team configures the product at our shop, so I'm not
> that familiar with it, other than evaluating measurements that tell me
> its choking all our transport class buffers from time to time.
> 
> I noticed the product(s) use more than one XCF group, I also see
> "DCPLEX" in use, whereas the actual data transfers we are concerned
> about use the group "DCPLEX$", I believe this is configurable (the grp
> name). We are setting up a mtg with BMC (and our database team) to
> discuss this issue in detail. Thanks for the feedback.
> 
> -Derrick
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: XCF large message traffic bursts (BMC SQL Performance)

[Derrick Haugan]

As I understand it, in a "DOMPLEX" (BMC lingo for the base product 
configuration), you can choose to use XCF, or you can turn it off for use with 
the SQL product's query traffic. maybe its turned off at your shop? Our 
database team configures the product at our shop, so I'm not that familiar with 
it, other than evaluating measurements that tell me its choking all our 
transport class buffers from time to time.

I noticed the product(s) use more than one XCF group, I also see "DCPLEX" in 
use, whereas the actual data transfers we are concerned about use the group 
"DCPLEX$", I believe this is configurable (the grp name). We are setting up a 
mtg with BMC (and our database team) to discuss this issue in detail. Thanks 
for the feedback.

-Derrick

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

Re: VSAM Release 2 (was Since it's Friday)

[Steve Smith]

I've occasionally wondered why LISTCAT has RELEASE-2 on
every entity listing (1974 is "before my time").  It's amazing how
release & version numbers deteriorate in various ways (Browser
Identity strings are the worst (maybe - hideous examples abound)).

I guess we can give up waiting for "Release 3".

sas

On Tue, Dec 5, 2017 at 6:43 AM, Mike Kerford-Byrnes  wrote:
> Going back a looong way, I worked on VSAM Release 1 (OS/VS1 Rel 2.6-ish) in
> 1974.  It was not the happiest of times, with a significant number of errors
> and problems, especially when VSAM limits were tested.  Eventually peace
> returned, and then VSAM Release 2 was announced.(I think late 1975 or early
> 1976).  It supported Alternate Indexes, Improved CI Processing, GET-Previous
> (Read Backwards)  and introduced RRDS and spanned records.
>
>
>
> Having endured a "busy" time dealing with Release 1, we were not best
> pleased at having to demonstrate to our masters that Release 2 would not
> visit yet further challenges to our production systems.  The effort of
> proving that was almost as great as that of the original problems, which
> included a genuine Severity 1 (NO production at all) for a period of over 24
> hours.
>
>
>
> The LISTC output indicated which release had created the file and hence the
> processing that was (or was not) permitted.  VSAM Catalogs could describe
> files created by either or both versions.  Of course once a
> REPRO/DELETE/DEFINE/REPRO or EXPORT/IMPORT was carried out on the new
> system, it would be a 'Version 2' file and the check on how to process the
> file was un-necessary.
>
>
>
> I have just realised that was 43 years ago!  It must have hurt - I can still
> remember.  The phone calls to STL - with the 8-hour time difference - and
> the dump 'lost' by one of the couriers necessitating an IBM SE personally
> transporting its replacement to California in his carry on bag!
>
>
>
> MKB
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
sas

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

Re: DR Question across time zones?

[Steve Smith]

What's the valid reason for setting the CLOCK00 to the physical
location? I can't think of one.

Generally, I'd think consistency would be the primary reason, and if
there's any automatic processing (e.g. batch scheduling) based on the
local time, you (I assume) would not want that going out-of-synch with
the users.

sas

On Tue, Dec 5, 2017 at 9:51 AM, Dana Mitchell  wrote:
> Not strictly only for DR,  back in the 00's I worked with moving several 
> CEC's and datacenters around some,  we had CEC's in Eastern, Central time 
> zones,  users in Eastern,  Central and Mountain zones,  and CECS moved to 
> Central,  then Mountain time zone, we always kept the local time offset set 
> to the user's local time.   This was a 'Bronzeplex'  so the users mostly 
> stayed with their primary LPARs.
> Dana
>
> On Tue, 5 Dec 2017 12:44:14 +, Dyck, Lionel B. (TRA)  
> wrote:
>
>>A question came up this morning - when doing a DR where the DR environment is 
>>in a different time zone from the production environment, should the CLOCK00 
>>TIMEZONE be updated for the physical location of the DR environment?
>>
>>I can see valid reasoning for doing either - what is your approach (and why)?
>>
>>
>>--
>>Lionel B. Dyck <
>>Mainframe Systems Programmer - TRA
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
sas

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

Re: DR Question across time zones?

[Dana Mitchell]

Not strictly only for DR,  back in the 00's I worked with moving several CEC's 
and datacenters around some,  we had CEC's in Eastern, Central time zones,  
users in Eastern,  Central and Mountain zones,  and CECS moved to Central,  
then Mountain time zone, we always kept the local time offset set to the user's 
local time.   This was a 'Bronzeplex'  so the users mostly stayed with their 
primary LPARs.  
Dana

On Tue, 5 Dec 2017 12:44:14 +, Dyck, Lionel B. (TRA)  
wrote:

>A question came up this morning - when doing a DR where the DR environment is 
>in a different time zone from the production environment, should the CLOCK00 
>TIMEZONE be updated for the physical location of the DR environment?
>
>I can see valid reasoning for doing either - what is your approach (and why)?
>
>
>--
>Lionel B. Dyck <
>Mainframe Systems Programmer - TRA
>

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

Re: DR Question across time zones?

[van der Grijn, Bart (B)]

I see no reason to have the physical location of the device dictate what 
timezone it runs on. The hardware runs at UTC. Most of our LPARs run UTC. A 
couple of older systems run a timezone defined by the majority of application 
users (one runs EST/EDT, the other CET/CEST). The logic doesn't change when the 
hardware moves. 
Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Tuesday, December 05, 2017 7:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DR Question across time zones?

This email originated from outside of the organization.


A question came up this morning - when doing a DR where the DR environment is 
in a different time zone from the production environment, should the CLOCK00 
TIMEZONE be updated for the physical location of the DR environment?

I can see valid reasoning for doing either - what is your approach (and why)?


--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA

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

Re: TECHDOCS 404 error

[Richards, Robert B.]

https://www.ibm.com/;www-03.ibm.com/support/techdocs/atsmastr.nsf/Web/FL-ByDate

Anyone else seeing the 404 message when using BYDATE criteria?

Bob

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

Re: LE Recovery

[John McKown]

On Tue, Dec 5, 2017 at 6:47 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 4 Dec 2017 17:28:41 -0500, scott Ford wrote:
>
> >If i had a main line in assembler and set a ESTAE before calling a Cobol
> >main routine,
> >could i intercept the 'C stcname' and be able to recovery ?
>
> I'm not sure. Having set your ESTAE(X), then calling your Cobol main
> routine, I'm pretty sure LE would establish its own ESTAE(X), which
> would receive control first. Will it percolate to you in all the cases
> you are interested in? If I wanted to do something like this, I would
> establish the LE environment before setting your ESTAE(X).
>

​I was wondering about that. But then I thought that if I have an ESTAEX
with a TERM=YES specified. And I then LINK to an LE main program, which
issues an ESTAE(X) with TERM=NO, will the second ESTAEX exit be invoked for
a CANCEL command (shouldn't because TERM=NO) or will my ESTAEX exit be
invoked because it does have TERM=YES. I suppose that if I were really
interested, I could test that myself. And I may later.​



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



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

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: Since it's Friday

[R.S.]

I'm not so "young" to remember that, however I vaguely remember I read 
some VSAM book (bought for many $$$). The book was awfully outdated, so 
I learned mostly VSAM history and obsolete features. It was ~13 years 
ago, but I would bet VSAM was born in 1974.


--
Radoslaw Skorupka
Lodz, Poland






W dniu 2017-12-05 o 09:19, Wayne Bickerdike pisze:

VSAM was no later than 1975. I was in a PL/I class at Sudbury in 1975.
Happened to be the week England beat Cyprus at Wembley 5-0 and Malcolm
MacDonald scored all 5 goals.

Anyway, our teacher at Sudbury asked this question:

"Why is VSAM like a cow in the middle of a meadow".

Answer:

"They are both outstanding in their field".

16 April 1975: England's Malcolm Macdonald scores five against Cyprus

Funny how things stick in your memory.

We were still ISAM many years later.

On Tue, Dec 5, 2017 at 9:00 AM, Seymour J Metz  wrote:


ICF came in with DF/EF, which preceded MVS/XA.


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


From: IBM Mainframe Discussion List  on behalf
of Mike Schwab 
Sent: Monday, December 4, 2017 4:29 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Since it's Friday

I think CVOL / VSAM catalogs in MVS was version 1.  ICF catalogs
introduced during XA switchover period is version 2.

On Mon, Dec 4, 2017 at 8:56 AM, R.S. 
wrote:

W dniu 2017-12-01 o 21:43, Pew, Curtis G pisze:

This is just a curiosity question, but I’ve wondered about this.

The JCL reference says:

All temporary data set names begin as follows:
SYSyyddd.Thhmmss.RA000.jjobname

Does anyone know the story behind the ‘RA000’ part? It seems unnecessary
and arbitrary.


Well, we used to answer "Frankie did this and he said >> do't change it<<
but Frankie died..."

BTW: almost every LISTCAT output contains "VERSION: 2" statement. Why

it's

2?


--
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.plsą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: Passing data from step-to-step in single job using memory??

[Allan Staller]

Now I get it. Thanks for the clarification.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Monday, December 4, 2017 9:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Passing data from step-to-step in single job using memory??

It's not the individual 2k which is the problem, it's the fact that (since we 
are dealing with automation of tasks, messages, and other "stuff") that we 
could have hundreds or thousands of them existing at any one point in time, and 
if they were all persistent, (meaning they were the life of the IPL), and there 
were a loooggg time between IPL's, we could be talking some serious memory 
drain issues.

While this would not actually be "our" fault, providing the easy mechanism for 
someone to shoot themselves tends to make one look bad.

Brian

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

 The contents of this e-mail and any attachment(s) are confidential and 
intended for the named recipient(s) only. E-mail transmission is not guaranteed 
to be secure or error-free as information could be intercepted, corrupted, 
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents (with or without referred errors) 
shall therefore not attach any liability on the originator or HCL or its 
affiliates. Views or opinions, if any, presented in this email are solely those 
of the author and may not necessarily reflect the views or opinions of HCL or 
its affiliates. Any form of reproduction, dissemination, copying, disclosure, 
modification, distribution and / or publication of this message without the 
prior written consent of authorized representative of HCL is strictly 
prohibited. If you have received this email in error please delete it and 
notify the sender immediately. Before opening any email and/or attachments, 
please check them for viruses and other defects. 


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

Re: DR Question across time zones?

[Roach, Dennis]

I have always kept the production system clock settings so the users see no 
difference. If the user sets a TZ value, it would be off due to the clock 
change. Job schedulers would also be off as far as the users and operations 
view.

Dennis Roach, CISSP
AIG

Identity & Access Management | Technology Services

2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019
Phone:  713-591-1059 (cell)

dennis.ro...@aig.com | www.aig.com 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Tuesday, December 05, 2017 6:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DR Question across time zones?

A question came up this morning - when doing a DR where the DR environment is 
in a different time zone from the production environment, should the CLOCK00 
TIMEZONE be updated for the physical location of the DR environment?

I can see valid reasoning for doing either - what is your approach (and why)?


--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


--
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: LE Recovery

[Tom Marchant]

On Mon, 4 Dec 2017 17:28:41 -0500, scott Ford wrote:

>If i had a main line in assembler and set a ESTAE before calling a Cobol
>main routine,
>could i intercept the 'C stcname' and be able to recovery ?

I'm not sure. Having set your ESTAE(X), then calling your Cobol main 
routine, I'm pretty sure LE would establish its own ESTAE(X), which 
would receive control first. Will it percolate to you in all the cases 
you are interested in? If I wanted to do something like this, I would 
establish the LE environment before setting your ESTAE(X).

-- 
Tom Marchant

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

DR Question across time zones?

[Dyck, Lionel B. (TRA)]

A question came up this morning - when doing a DR where the DR environment is 
in a different time zone from the production environment, should the CLOCK00 
TIMEZONE be updated for the physical location of the DR environment?

I can see valid reasoning for doing either - what is your approach (and why)?


--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


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

Re: Since it's Friday

[Elardus Engelbrecht]

Wayne Bickerdike wrote:

>"Why is VSAM like a cow in the middle of a meadow".
>Answer: "They are both outstanding in their field".

What  a "moo-ving" joke... ;-)

>16 April 1975: England's Malcolm Macdonald scores five against Cyprus
>Funny how things stick in your memory.

Ya, tell me. Sometimes you remember things you rather want to forget.

Or, worse, your wife or your mother-in-law remember something you really want 
them to forget... ;-D


>We were still ISAM many years later.

I remember that struggle in my start of my career, where I was tasked to scan 
disks and try to read those ISAM datasets and copy the contents to VSAM or PS 
datasets.

No, of course, I will NOT retry that ISAM thing... ;-)

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

VSAM Release 2 (was Since it's Friday)

[Mike Kerford-Byrnes]

Going back a looong way, I worked on VSAM Release 1 (OS/VS1 Rel 2.6-ish) in
1974.  It was not the happiest of times, with a significant number of errors
and problems, especially when VSAM limits were tested.  Eventually peace
returned, and then VSAM Release 2 was announced.(I think late 1975 or early
1976).  It supported Alternate Indexes, Improved CI Processing, GET-Previous
(Read Backwards)  and introduced RRDS and spanned records.  

 

Having endured a "busy" time dealing with Release 1, we were not best
pleased at having to demonstrate to our masters that Release 2 would not
visit yet further challenges to our production systems.  The effort of
proving that was almost as great as that of the original problems, which
included a genuine Severity 1 (NO production at all) for a period of over 24
hours. 

 

The LISTC output indicated which release had created the file and hence the
processing that was (or was not) permitted.  VSAM Catalogs could describe
files created by either or both versions.  Of course once a
REPRO/DELETE/DEFINE/REPRO or EXPORT/IMPORT was carried out on the new
system, it would be a 'Version 2' file and the check on how to process the
file was un-necessary.

 

I have just realised that was 43 years ago!  It must have hurt - I can still
remember.  The phone calls to STL - with the 8-hour time difference - and
the dump 'lost' by one of the couriers necessitating an IBM SE personally
transporting its replacement to California in his carry on bag!  

 

MKB 


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

Re: Since it's Friday

[Wayne Bickerdike]

VSAM was no later than 1975. I was in a PL/I class at Sudbury in 1975.
Happened to be the week England beat Cyprus at Wembley 5-0 and Malcolm
MacDonald scored all 5 goals.

Anyway, our teacher at Sudbury asked this question:

"Why is VSAM like a cow in the middle of a meadow".

Answer:

"They are both outstanding in their field".

16 April 1975: England's Malcolm Macdonald scores five against Cyprus

Funny how things stick in your memory.

We were still ISAM many years later.

On Tue, Dec 5, 2017 at 9:00 AM, Seymour J Metz  wrote:

> ICF came in with DF/EF, which preceded MVS/XA.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Mike Schwab 
> Sent: Monday, December 4, 2017 4:29 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Since it's Friday
>
> I think CVOL / VSAM catalogs in MVS was version 1.  ICF catalogs
> introduced during XA switchover period is version 2.
>
> On Mon, Dec 4, 2017 at 8:56 AM, R.S. 
> wrote:
> > W dniu 2017-12-01 o 21:43, Pew, Curtis G pisze:
> >>
> >> This is just a curiosity question, but I’ve wondered about this.
> >>
> >> The JCL reference says:
> >>
> >> All temporary data set names begin as follows:
> >> SYSyyddd.Thhmmss.RA000.jjobname
> >>
> >> Does anyone know the story behind the ‘RA000’ part? It seems unnecessary
> >> and arbitrary.
> >>
> >
> > Well, we used to answer "Frankie did this and he said >> do't change it<<
> > but Frankie died..."
> >
> > BTW: almost every LISTCAT output contains "VERSION: 2" statement. Why
> it's
> > 2?
> >
> >
> > --
> > 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.plsą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
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wayne V. Bickerdike

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

Re: XCF large message traffic bursts (BMC SQL Performance)

[Vernooij, Kees (ITOPT1) - KLM]

Derrick,

I checked in our installation and to my surprise we don't see any XCF traffic 
during the day. According to DISPLAY XCF, some 25 messages have been exchanged. 
From CMF output, I can see that they were exchanged during startup of the DC's.

My DB2 colleagues do run reports on all members of a data sharing group, but 
apparently in our configuration without any XCF traffic. What could be the 
difference between these installations?

Regards,
Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Derrick Haugan
> Sent: 04 December, 2017 15:34
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: XCF large message traffic bursts (BMC SQL Performance)
> 
> Just an inquiry, to see if others have had issues with this products
> use/abuse of XCF. BMC product is sending large bursts of XCF traffic
> between systems, and the messages are the maximum size (62464). Over the
> past few months, it has sent bursts like these (over 8K large messages
> in 1 minute interval), and filled up XCF buffers on the sending system
> (transport class we use for large message traffic). We are going to
> isolate the product's XCF group (DCPLEX$) into its own transport class,
> so it cant block other users of the our general-purpose large message
> transport class.
> 
> Product does reporting, and sends its results back to a focal point
> (sessions used by DBAs etc) for analysis. Spoke with the vendor, they
> stated the options are - a) turn off the XCF mechanism in the product or
> b) enable it for XCF communication, but there is no control over what it
> may send (unlimited). These seem like poor choice of options for tuning
> it. If XCF is disabled, DBAs would not be able to assemble reports for
> DB2 using data sharing for multi-system operation.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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