Ah, that new 'baby' mainframe smell: IBM shows off z13s from a different POV

[Ed Gould]

http://www.theregister.co.uk/2016/02/16/ 
ibm_z13s_mainframe_security_enhancements/



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

IBM z13s article. - Multi-Factor Authentication for z/OS

[Timothy Sipples]

Here's a direct link to the announcement letter for IBM Multi-Factor
Authentication for z/OS:

http://www-01.ibm.com/common/ssi/rep_ca/9/897/ENUS216-069/ENUS216-069.PDF

It's a tremendously important new capability -- or, more precisely, newly
integrated set of security capabilities -- I agree.

There's a LOT of new, very important stuff announced this week, and I'm
sure we'll get to discuss much of it in the coming hours, days, and weeks.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

[Rich Alderson]

Thanks, everyone, for the interesting comments and stories.

I have used Hercules in the past (3 or 4 years ago, briefly) and am familiar 
with it.  I was already planning to involve it in setting up the real hardware.

The 4341 which we used at UChicago to move from SVS on an Amdahl 470/v7 to MVS 
on a 3031 used CKD disks, as it happens.  MVS ran as a preferred guest under 
VM/370 on the 4341.

I did receive one off-line response to my actual question which will save our 
education budget a few thousand dollars, to the effect that the modern 
descendants of the operating systems I used to know are managed very 
differently and knowledge of them would not help me in the least.  A special 
thank you for that one.


Best regards,
Rich Alderson


Rich Alderson
Sr. Systems Engineer
Living Computer Museum
2245 1st Ave S
Seattle, WA 98134


http://www.LivingComputerMuseum.org/

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

Re: Meaning of CSV0002I

[Tom Marchant]

On Tue, 16 Feb 2016 16:46:29 -0600, Mike Schwab wrote:

>When you issue a LOAD for a Load Module, when done you should issue a
>DELETE for the load module, 

true.

>but some programs don't, and it is an
>non-fatal, non-harmful bug.

It won't hurt the system, but the program has failed.

>If the total number of LOADs exceed the DELETEs by 32K, you get this message.

And you get abend S906-8 unless the LOAD macro has ERRET coded, in which case 
the error routine receives control with the abend code in R1 and the reason 
code in R15. 
In any case, the LOAD fails.

-- 
Tom Marchant

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

Enterprise COBOL 6.1 announced

[Bill Woodger]

There used to be a lot more 97s, before Language Environment. Now LE CLOSEs 
open files at the end (ab or otherwise) of a run-unit.

The description of 97 from the COBOL Language Reference seems, to me, cavalier:

"For VSAM only: OPEN statement execution successful:  File integrity verified."

Hidden beneath this "File integrity verified" is the kicker, "Data integrity - 
go sing". Here's what z/OS DFSMS Using Data Sets has to say about it: "You can 
use a VSAM VERIFY macro call with certain types of opened VSAM data sets to 
ensure that fields in the VSAM control blocks are accurate. The VERIFY macro 
does not change the data in the data set. VERIFY does not correct missing or 
duplicate records or repair any damage in the index structure. The verification 
of control-block fields enables you to perform recovery actions on the 
improperly closed data set, if necessary.

Besides the VSAM VERIFY macro, you can use the IDCAMS VERIFY command to verify 
a VSAM data set. When you issue this command, IDCAMS opens the VSAM data set 
for output, issues a VSAM VERIFY macro call, and closes the data set. The 
IDCAMS VERIFY command (without the RECOVER parameter) and the verification by 
VSAM OPEN are the same. Neither changes the data in the verified data set."

Programmers cling so dearly to that "File integrity verified". 

It shouldn't happen in a program. There shouldn't be a "verify step" before 
each program.

Mostly, accurate use of a scheduler keeps things straight. Doesn't it? Let's 
hope so. That's a great thing to say in programming. 

And yes, now that there are fewer 97s there are fewer easy ways to spot this 
if/when it happens.

VSAMOPENFS(SUCKS) is a compiler option I'm not going to use by choice.

On Tuesday, 16 February 2016 21:20:54 UTC, John McKown  wrote:
> On Tue, Feb 16, 2016 at 3:16 PM, Bill Woodger 
> wrote:
> 
> > A quote from 2009:
> >
> > "In fact, the fact that it is rare and should not happen for 'normal'
> > processing tells me that you perhaps *shouldn't* just treat '97' as
> > "everything is ok" and ignore it.  Seems to me that even if you elect to
> > continue processing it would be nice to know that the 97 status occured."
> >
> 
> ​We have had the 97 happen to us too. Most of the time it is due to the
> data set not being CLOSEd, usually due to an ABEND. However, in the past,
> we ran two z/OS images with shared DASD. And shared data sets. But not in a
> sysplex (long ago). What the 97 _could_ mean is "the VSAM file is currently
> OPEN to a job on the other system". If you just "go ahead" in this case,
> and are doing updates on both sides, you are just begging for a corrupted
> file. Especially if one of the jobs causes a CA split. Real fun (not)
> recovering from that mess.​
> 
> 

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

› Default overrides for binder?

[Bill Woodger]

Well, I suppose every time the product was updated. Periodically checking would 
not be a problem.

I assume this is all for checking out little bits and pieces, where it is 
convenient to have fixed (even more than one set of fixed) but 
non-site-standard options available.

With the COBOL options, it is very neat and convenient. 


On Tuesday, 16 February 2016 18:11:41 UTC, Tom Marchant  wrote:
> On Tue, 16 Feb 2016 11:36:12 -0600, Bill Woodger wrote:
> 
> >Yes. Perhaps attempt to set it up in a library of your own?
> 
> I wonder how long it would take to have an obsolete copy of the module.
> 
> -- 
> Tom Marchant
> 
> >On Tuesday, 16 February 2016 16:55:00 UTC, Frank Swarbrick  wrote:
> >> Thanks.  It looks like this behaves a bit differently than the others, in 
> >> that 
> >>it is a CSECT directly linked in to IEWBLINK, rather than being separate 
> >>modules.  
> >>I was hoping I could place a module in its own STEPLIB ...
> 
> --
> 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: Meaning of CSV0002I

[Mike Schwab]

Here is a local fix from last November.  Does it fit?
http://www-01.ibm.com/support/docview.wss?uid=isg1OA47098

When you issue a LOAD for a Load Module, when done you should issue a
DELETE for the load module, but some programs don't, and it is an
non-fatal, non-harmful bug.
If the total number of LOADs exceed the DELETEs by 32K, you get this message.



2016-02-16 15:07 GMT-06:00 R.S. :
> I'm getting the following message:
> CSV002I REQUESTS FOR MODULE GXLIMODV EXCEED MAXIMUM USE COUNT
>
> I did RTFM, but stlll I don't know: Should I worry about it or just ignore?
>
>
> --
> 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



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Meaning of CSV0002I

[R.S.]

Yes, it looks like, but it is not.
The PTF UK77627 is SUPBU UK95352, which was APPlied several weeks ago.

It seems the new PTF provided the old error.


--
Radoslaw Skorupka
Lodz, Poland






W dniu 2016-02-16 o 22:16, Farley, Peter x23353 pisze:

Maybe this APAR?

http://www-01.ibm.com/support/docview.wss?uid=isg1PM60289

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, February 16, 2016 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Meaning of CSV0002I

I'm getting the following message:
CSV002I REQUESTS FOR MODULE GXLIMODV EXCEED MAXIMUM USE COUNT

I did RTFM, but stlll I don't know: Should I worry about it or just ignore?






---
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: Enterprise COBOL 6.1 announced

[John McKown]

On Tue, Feb 16, 2016 at 3:16 PM, Bill Woodger 
wrote:

> A quote from 2009:
>
> "In fact, the fact that it is rare and should not happen for 'normal'
> processing tells me that you perhaps *shouldn't* just treat '97' as
> "everything is ok" and ignore it.  Seems to me that even if you elect to
> continue processing it would be nice to know that the 97 status occured."
>

​We have had the 97 happen to us too. Most of the time it is due to the
data set not being CLOSEd, usually due to an ABEND. However, in the past,
we ran two z/OS images with shared DASD. And shared data sets. But not in a
sysplex (long ago). What the 97 _could_ mean is "the VSAM file is currently
OPEN to a job on the other system". If you just "go ahead" in this case,
and are doing updates on both sides, you are just begging for a corrupted
file. Especially if one of the jobs causes a CA split. Real fun (not)
recovering from that mess.​



>
> I agree with you.
>
> I surely don't give Operations a defence of Justifiable Homicide.
>
>
>

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

Re: Real Storage Allocation

[phil yogendran]

Thank you all for your replies. My immediate concern was whether there were
any issues/problems with over-allocating storage and with your responses, I
am confident I can plough ahead. Thanks also for all the tips on how to
debug and what to analyze. That's a step for later. Your time
and assistance are much appreciated.

Regards,

Phil


On Mon, Feb 15, 2016 at 9:22 AM, John Abell <
john.ab...@intnlsoftwareproducts.com> wrote:

> As long as your z/OS isn't running under, z/VM like may smaller ISVs,
> where LFAREA is not yet supported.
>
> John T. Abell
> Tel:800-295-7608Option 4
> President
> International:  1-416-593-5578  Option 4
> E-mail:  john.ab...@intnlsoftwareproducts.com
> Fax:800-295-7609
>
> International:  1-416-593-5579
>
>
> International Software Products
> www.ispinfo.com
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient(s). Any review, use, retention, distribution
> or disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive on behalf of the named recipient),
> please contact the sender by reply email and delete all copies of this
> message. Also,email is susceptible to data corruption, interception,
> tampering, unauthorized amendment and viruses. We only send and receive
> emails on the basis that we are not liable for any such corruption,
> interception, tampering, amendment or viruses or any consequence thereof.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ed Jaffe
> Sent: Sunday, February 14, 2016 5:05 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Real Storage Allocation
>
> On 2/14/2016 11:19 AM, Graham Harris wrote:
> > Ed Jaffe wrote:
> >
> >
> >> The nice thing about an overabundance of real storage is the ability
> >> to
> > create a very large LFAREA with plenty of room for 1MB >pageable pages
> > and
> > -- if you have software that can truly benefit from it (which we
> > don't) -- 2G fixed pages.
> >
> >
> > LFAREA does of course only generally hold fixed large pages, although
> > it does also handle overflow of PLAREA when that becomes full, which
> > maybe what you were thinking.
>
> LFAREA (Large Frame Area) provides frame space for both fixed and pageable
> large pages. We specify:
>
> LFAREA=7782M,  Large frame area
>
> which is more than enough for our needs. Right after IPL I see some fairly
> small numbers:
>
> D VS,LFAREA
> IAR019I  13.56.52 DISPLAY VIRTSTOR 507
>   SOURCE =  20
>   TOTAL LFAREA = 7782M , 0G
>   LFAREA AVAILABLE = 7257M , 0G
>   LFAREA ALLOCATED (1M) = 0M
>   LFAREA ALLOCATED (4K) = 311M
>   MAX LFAREA ALLOCATED (1M) = 0M
>   MAX LFAREA ALLOCATED (4K) = 311M
>   LFAREA ALLOCATED (PAGEABLE1M) = 214M
>   MAX LFAREA ALLOCATED (PAGEABLE1M) = 214M
>   LFAREA ALLOCATED NUMBER OF 2G PAGES = 0
>   MAX LFAREA ALLOCATED NUMBER OF 2G PAGES = 0
>
> Of course, these numbers grow over time...
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> --
> 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: Meaning of CSV0002I

[Farley, Peter x23353]

Maybe this APAR?

http://www-01.ibm.com/support/docview.wss?uid=isg1PM60289

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, February 16, 2016 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Meaning of CSV0002I

I'm getting the following message:
CSV002I REQUESTS FOR MODULE GXLIMODV EXCEED MAXIMUM USE COUNT

I did RTFM, but stlll I don't know: Should I worry about it or just ignore?


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

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

Enterprise COBOL 6.1 announced

[Bill Woodger]

A quote from 2009:

"In fact, the fact that it is rare and should not happen for 'normal' 
processing tells me that you perhaps *shouldn't* just treat '97' as "everything 
is ok" and ignore it.  Seems to me that even if you elect to continue 
processing it would be nice to know that the 97 status occured."

I agree with you. 

I surely don't give Operations a defence of Justifiable Homicide.

On Tuesday, 16 February 2016 18:17:24 UTC, Frank Swarbrick  wrote:
> So what do your programs do when they get an FC97 on an OPEN?  Display a 
> message to the console and wait for a response?  Display a message to the 
> console and continue on?  Something else?
> 
> > Date: Tue, 16 Feb 2016 11:28:28 -0600
> > From: bill.wood...@gmail.com
> > Subject: Enterprise COBOL 6.1 announced
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > 

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

Re: Meaning of CSV0002I

[John McKown]

2016-02-16 15:07 GMT-06:00 R.S. :

> I'm getting the following message:
> CSV002I REQUESTS FOR MODULE GXLIMODV EXCEED MAXIMUM USE COUNT
>
> I did RTFM, but stlll I don't know: Should I worry about it or just ignore?
>

​Personally, I would not worry much. What it means is that something, or
somethings, has attempted to LOAD the module GXLIMODV more that 255 times
without doing a DELETE. Personally, I take this as a "you have a bug" type
error which is not fatal.​ Again, if it were me, I'd look at my source to
see what is doing a LOAD and seeing if it is somehow being called over and
over improperly. What I might do (depending) would be to change the program
(if it is only one) to do a CSVQUERY to see if GXLIMODV is already loaded
and branch over the LOAD if it is. Of course, if you have 300 programs
which are doing a LOAD on that program, you might have a bigger problem you
need to address.

Or maybe it's this:
http://www-01.ibm.com/support/docview.wss?uid=isg1PM60289


>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>

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

Meaning of CSV0002I

[R.S.]

I'm getting the following message:
CSV002I REQUESTS FOR MODULE GXLIMODV EXCEED MAXIMUM USE COUNT

I did RTFM, but stlll I don't know: Should I worry about it or just ignore?


--
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: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[R.S.]

W dniu 2016-02-15 o 12:48, Robert S. Hansel (RSH) pisze:

I wholeheartedly agree with Joel's recommendation for having a backup copy of 
the RACF database readily available for recovery. I just want to add that it is 
crucial to use RACF utilities to create the backup and to allocate it with the 
proper characteristics. The preferred utility to use to create the backup is 
IRRUT200 which momentarily serializes the database, thereby preventing updates, 
while it copies the database. IRRUT400 can also be used, but it locks the 
database which you then have to unlock. The backup should be allocated as one 
extent, contiguous, and non-movable and, if using IRRUT200, with the exact same 
size as the source.


While I still support to use UT200 to perform copy of RACF db, I have to 
admit I did many tests in the past when I intentionally used RACF db 
done by ICEGENER, IEBGENER or ADRDSSU DUMP. With no "luck", that mean I 
never got inconsistent result. At least none of RACF utilities detected 
the inconsistency. In other words even such copy was usable.

Of course I still recommend to use proper tool for that.

BTW: all my tests were done against monoplex configurations.
BTW2: the tests had some reason behind, it wasn't just "hey, let's put 
egg to microwave owen and see". ;-)



--
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: Using IBM z/OS TDMF Product to Migrate 3390-9 to 3390-27's

[Mike Schwab]

I have moved z/VM volumes from z/OS with z/VM shut down.  Should apply
to z/Linux too.

On Tue, Feb 16, 2016 at 2:29 PM, Jasi Grewal  wrote:
> Thank You Mike , Jerry and Steve for your recommendations and suggestions. We 
> only have z/VM and zLinux DASD minidisk/fullvolumes left to migrate as I have 
> completed all z/OS DASD through DFDSS and we just have to migrate zVM and 
> zLinux minidisks to new targets and hopefully it would be easier.
>
> Thank you again for your expert advise,
>
> Regards,
> Jasi.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Using IBM z/OS TDMF Product to Migrate 3390-9 to 3390-27's

[Jasi Grewal]

Thank You Mike , Jerry and Steve for your recommendations and suggestions. We 
only have z/VM and zLinux DASD minidisk/fullvolumes left to migrate as I have 
completed all z/OS DASD through DFDSS and we just have to migrate zVM and 
zLinux minidisks to new targets and hopefully it would be easier.

Thank you again for your expert advise,

Regards,
Jasi.

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

Re: Enterprise COBOL 6.1 announced

[Ed Gould]

Long live 1.13 and may it last until 2050 (at least).

Ed

On Feb 16, 2016, at 12:14 PM, Jim Mulder wrote:


The requirement for z/OS 2.1 is disappointing.  We haven't been on
1.13 for all that long, and I don't know that we have an upgrade due
any time soon... :-(


Support for z/OS 1.13 ends soon (Sept. 30, 2016).

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY


--
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: Using IBM z/OS TDMF Product to Migrate 3390-9 to 3390-27's

[Mike Schwab]

Yes, you can use TDMF / FDRPAS / etc, to move a volume to the same
size or larger.  After the move is complete TDMF or you run ICKDSF to
pick up the new size.

The VTOC and VTOCIX are not extended.  You should select the volumes
with the hardest to move datasets.  If you need to increase the VTOC /
VTOCIX, you can do that right after you get the new size.  Or you can
create new volumes and migrate the datasets from all old volumes.

Remaining volumes will need to have the datasets moved to volumes on
your new hardware.

https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieag100/v1stor.htm
VARY SMS,VOLUME(volser,sysx),QUIESCE or (V SMS,VOLUME(volser,sysx),Q)
will disable allocations to old volumes, unless it does not have
enough space on non-Quiesce volumes.

https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.arcf000/migratesmsvolume.htm?lang=en
After setting volser to Q, command MIGRATE VOLUME(volser) DAYS(0) will
migrate datasets to other volumes in the storage group.  Datasets in
use or not eligible to migrate will be left behind.

https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.arcf000/s6068.htm?lang=en
VSAM datasets with 2+ AIXs must be migrated with a command to the base
cluster name.

LDMF (Part of TDMF) can help move up datasets left on old volumes.


On Tue, Feb 16, 2016 at 1:53 PM, Jasi Grewal  wrote:
> Greetings, I would like to know, if we can use IBM z/OS TDMF to migrate z/VM 
> and zLinux DASD to newer model 3390-27's from 3390-09.
> The other problem is that we don't have that many targets as Source vols so 
> every MDISK would have to be migrated to consume DASD Space and does TDMF 
> supports the feature of copying MDISK's from Source to Targets or does it 
> only supports Full Volumes migration.
>
> Or do we use copyddr tool to copy mdisks from source to targets from z/VM 
> System.
> Any experiences or recommendations would be greatly appreciated.
>
> Thanks in advance,
> Regards,
> Jasi Grewal.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Using IBM z/OS TDMF Product to Migrate 3390-9 to 3390-27's

[Jerry Whitteridge]

You can use TDMF to move z/VM volumes - but the z/VM system will need to be 
down while doing so. z/Linux disks under z/VM move just like any z/VM disk. Be 
careful in your z/VM config files as to what volumes are online/offline at IPL 
**BEFORE** you shutdown the z/VM system. I'd suggest setting up your CF2 config 
to IPL back to the old configuration and also to omit the ranges of the newly 
copied volumes.

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jasi Grewal
Sent: Tuesday, February 16, 2016 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Using IBM z/OS TDMF Product to Migrate 3390-9 to 3390-27's

Greetings, I would like to know, if we can use IBM z/OS TDMF to migrate z/VM 
and zLinux DASD to newer model 3390-27's from 3390-09.
The other problem is that we don't have that many targets as Source vols so 
every MDISK would have to be migrated to consume DASD Space and does TDMF 
supports the feature of copying MDISK's from Source to Targets or does it only 
supports Full Volumes migration.

Or do we use copyddr tool to copy mdisks from source to targets from z/VM 
System.
Any experiences or recommendations would be greatly appreciated.

Thanks in advance,
Regards,
Jasi Grewal.

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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

Re: Using IBM z/OS TDMF Product to Migrate 3390-9 to 3390-27's

[Steve Beaver]

I would suggest if you DONOT a full copy migration, that you user an ADRDSSU 
COPY/Catalogue that would
Allow you to be selective

Steve   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jasi Grewal
Sent: Tuesday, February 16, 2016 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Using IBM z/OS TDMF Product to Migrate 3390-9 to 3390-27's

Greetings, I would like to know, if we can use IBM z/OS TDMF to migrate z/VM 
and zLinux DASD to newer model 3390-27's from 3390-09.
The other problem is that we don't have that many targets as Source vols so 
every MDISK would have to be migrated to consume DASD Space and does TDMF 
supports the feature of copying MDISK's from Source to Targets or does it only 
supports Full Volumes migration.

Or do we use copyddr tool to copy mdisks from source to targets from z/VM 
System.
Any experiences or recommendations would be greatly appreciated.

Thanks in advance,
Regards,
Jasi Grewal.

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

Using IBM z/OS TDMF Product to Migrate 3390-9 to 3390-27's

[Jasi Grewal]

Greetings, I would like to know, if we can use IBM z/OS TDMF to migrate z/VM 
and zLinux DASD to newer model 3390-27's from 3390-09.
The other problem is that we don't have that many targets as Source vols so 
every MDISK would have to be migrated to consume DASD Space and does TDMF 
supports the feature of copying MDISK's from Source to Targets or does it only 
supports Full Volumes migration.

Or do we use copyddr tool to copy mdisks from source to targets from z/VM 
System.
Any experiences or recommendations would be greatly appreciated.

Thanks in advance,
Regards,
Jasi Grewal.

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

Re: CSVFETCH exit

[Tom Marchant]

On Tue, 16 Feb 2016 19:17:10 +, Gibney, David Allen,Jr wrote:

>I am finding this interesting. One thing I think you are missing was the 
>advisability 
>to use STMG/LMG to save and restore all 64 bits of the registers. Not a lot of 
>stuff 
>running above the bar as yet, but it will be there sooner than we expect. :)

It isn't because of things running above the bar. Nor is it about referencing 
storage 
above the bar

Your program can't know whether your caller or anyone who called him is using 
the 
high halves of the registers for anything, so the linkage conventions require 
that if 
you alter the high halves in any way, you must restore them. For example, if 
your 
program issues a LG, XGR, or AG instruction, among many others, you should save 
and restore the high halves. It isn't hard to do it correctly when you are 
passed a 
144-byte save area, as this exit is.

By the way, for a long time (z/OS 1.3 maybe, but I'm not sure), the system 
provides 
any program that it calls with a 144-byte save area.

-- 
Tom Marchant

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

Re: CSVFETCH exit

[Leonardo Vaz]

I should not be playing with storage above the bar but I guess I'll use STMG to 
be sure.

Thanks everyone for their input! Much appreciated!

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 16, 2016 2:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

On Tue, 16 Feb 2016 19:11:38 +, Leonardo Vaz wrote:

>I see. In the case of CSVFETCH there is a 1024-byte work-area passed, 
>so no getmain should be needed, in this case, STM should be the best option?

You are passed a 144-byte save area, so I would use STMG to save the registers 
in F4SA format as documented in Chapter 2 of the Assembler Services Guide.

If you are sure that you won't be altering the high halves of registers 2 
through 12, STM is adequate.

--
Tom Marchant

--
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: z14 Drops Support for ESA/390 Mode (Was: Re: zEC12)

[Tony Harminc]

On 16 February 2016 at 11:31, Joel C. Ewing  wrote:
> That seems pretty explicit to me that the plan is that on z14 and beyond
> an operating system will be required to start and run exclusively in
> z/Architecture mode and that there will simply be no hardware capability
> to run in ESA/390 mode, period.

Yup - I'm now convinced. Jim Mulder said "Well, for one thing, there
won't be any ESA/390 mode Dynamic Address Translation, either at SIE
Guest 1 (in an LPAR) or at Guest 2 (under VM).  So you certainly will
not be able to run any operating system that uses ESA/390 virtual
addressing, even under VM."  That's quite definitive enough for me.

I do think IBM could've been somewhat clearer with their
announcements. On a z13 or earlier it's certainly possible to run z/VM
entirely in zArch mode (after the initial and brief IPL sequence)
without ever switching the archmode back to ESA/390, and yet run
ESA/390 guests using SIE. For performance reasons alone, it is
implausible that zSIE would internally issue SIGP to set the archmode
to ESA/390 every time it dispatches an ESA/390 guest, so presumably
there is code in SIE that either exploits an underlying ESA/390 DAT
facility, and probably other ESA/390 things I haven't thought about,
all while remaining in zArch mode, or maintains shadow DAT tables to
map between guest ESA/390 and host zArch DAT. I don't know if the
latter is architecturally possible with the current definitions, but
it's not immediately out of the question.

What Jim has now said clearly is that IBM will remove the ability to
perform ESA/390 DAT entirely at any SIE level in z14+. Presumably
issuing SIE with a SIE block indicating ESA/390 archmode will simply
fail, and it's game over.

The remaining question of interest is the fate of XC mode and a
putative zXC mode on these new machines.

Tony H.

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

Re: CSVFETCH exit

[Tom Marchant]

On Tue, 16 Feb 2016 19:11:38 +, Leonardo Vaz wrote:

>I see. In the case of CSVFETCH there is a 1024-byte work-area passed, so no 
>getmain should be needed, in this case, STM should be the best option?

You are passed a 144-byte save area, so I would use STMG to save the registers 
in F4SA format as documented in Chapter 2 of the Assembler Services Guide.

If you are sure that you won't be altering the high halves of registers 2 
through 12, 
STM is adequate.

-- 
Tom Marchant

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

Re: CSVFETCH exit

[Gibney, David Allen,Jr]

I am finding this interesting. One thing I think you are missing was the 
advisability to use STMG/LMG to save and restore all 64 bits of the registers. 
Not a lot of stuff running above the bar as yet, but it will be there sooner 
than we expect. :)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Leonardo Vaz
> Sent: Tuesday, February 16, 2016 11:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CSVFETCH exit
> 
> I see. In the case of CSVFETCH there is a 1024-byte work-area passed, so no
> getmain should be needed, in this case, STM should be the best option?
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Blaicher, Christopher Y.
> Sent: Tuesday, February 16, 2016 1:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CSVFETCH exit
> 
> BAKR/PR does take a lot more time then STM/LM, but most times you can't
> just use STM/LM, you also have a GETMAIN/FREEMAIN for a register save
> area and other setup/restore things to do.
> 
> So, once you factor in those other overheads, which is faster?  I don't know 
> as
> I haven't set up the tests to validly compare the different methods possible. 
>  I
> have seen several different ways to avoid the GETMAIN/FREEMAIN
> overheads.
> 
> Chris Blaicher
> Technical Architect
> Software Development
> Syncsort Incorporated
> 50 Tice Boulevard, Woodcliff Lake, NJ 07677
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Leonardo Vaz
> Sent: Tuesday, February 16, 2016 1:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CSVFETCH exit
> 
> Well, I guess using the linkage stack is cleaner because the state of the 
> caller
> is preserved.
> 
> Thanks for your reply, that is what I wanted to know, I was going to use STM
> but I remember reading somewhere before (maybe linkedin?) that they would
> never approve any assembler code written in the past 20 years starting with
> STM  R14,R12,12(R13). I just would like to hear someone that would prefer
> BAKR and why.
> 
> Thanks,
> Leo
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tom Marchant
> Sent: Tuesday, February 16, 2016 12:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CSVFETCH exit
> 
> On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:
> 
> >I apologize if the question is silly, but I am wondering if for a
> >performance sensitive exit like this one I should use STM/LM instead of
> >BAKR/PR. I believe it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR,
> right?
> 
> Why do you think BAKR is "cleaner"?
> 
> BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the
> high halves of any of registers 2-12).
> 
> --
> Tom Marchant
> 
> --
> 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
> 
> 
> 
> 
> 
> ATTENTION: -
> 
> The information contained in this message (including any files transmitted
> with this message) may contain proprietary, trade secret or other confidential
> and/or legally privileged information. Any pricing information contained in
> this message or in any files transmitted with this message is always
> confidential and cannot be shared with any third parties without prior written
> approval from Syncsort. This message is intended to be read only by the
> individual or entity to whom it is addressed or by their designee. If the 
> reader
> of this message is not the intended recipient, you are on notice that any use,
> disclosure, copying or distribution of this message, in any form, is strictly
> prohibited. If you have received this message in error, please immediately
> notify the sender and/or Syncsort and destroy all copies of this message in
> your possession, custody or control.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: CSVFETCH exit

[Blaicher, Christopher Y.]

I had not followed the discussion very closely, but it sounds like they have 
given the exit enough working storage so that no GETMAIN/FREEMAIN is needed.
In that case it is clearly a performance advantage to use STM/LM over BAKR/PR.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803    
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Tuesday, February 16, 2016 2:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I see. In the case of CSVFETCH there is a 1024-byte work-area passed, so no 
getmain should be needed, in this case, STM should be the best option?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Tuesday, February 16, 2016 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

BAKR/PR does take a lot more time then STM/LM, but most times you can't just 
use STM/LM, you also have a GETMAIN/FREEMAIN for a register save area and other 
setup/restore things to do.

So, once you factor in those other overheads, which is faster?  I don't know as 
I haven't set up the tests to validly compare the different methods possible.  
I have seen several different ways to avoid the GETMAIN/FREEMAIN overheads.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Tuesday, February 16, 2016 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Well, I guess using the linkage stack is cleaner because the state of the 
caller is preserved.

Thanks for your reply, that is what I wanted to know, I was going to use STM 
but I remember reading somewhere before (maybe linkedin?) that they would never 
approve any assembler code written in the past 20 years starting with STM  
R14,R12,12(R13). I just would like to hear someone that would prefer BAKR and 
why.

Thanks,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 16, 2016 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:

>I apologize if the question is silly, but I am wondering if for a 
>performance sensitive exit like this one I should use STM/LM instead of 
>BAKR/PR. I believe it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR, 
>right?

Why do you think BAKR is "cleaner"?

BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the high 
halves of any of registers 2-12).

--
Tom Marchant

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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

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

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

Re: CSVFETCH exit

[Tom Marchant]

On Tue, 16 Feb 2016 18:49:36 +, Blaicher, Christopher Y. wrote:

>BAKR/PR does take a lot more time then STM/LM, but most times you can't just 
>use STM/LM, you also have a GETMAIN/FREEMAIN for a register save area and 
>other setup/restore things to do.
>
>So, once you factor in those other overheads, which is faster?  I don't know 
>as 
>I haven't set up the tests to validly compare the different methods possible.  
>I 
>have seen several different ways to avoid the GETMAIN/FREEMAIN overheads.

The CSVFETCH exit is passed a 1K work area, likely eliminating the need to 
GETMAIN 
in many cases.

-- 
Tom Marchant

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

Re: CSVFETCH exit

[Leonardo Vaz]

I see. In the case of CSVFETCH there is a 1024-byte work-area passed, so no 
getmain should be needed, in this case, STM should be the best option?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Tuesday, February 16, 2016 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

BAKR/PR does take a lot more time then STM/LM, but most times you can't just 
use STM/LM, you also have a GETMAIN/FREEMAIN for a register save area and other 
setup/restore things to do.

So, once you factor in those other overheads, which is faster?  I don't know as 
I haven't set up the tests to validly compare the different methods possible.  
I have seen several different ways to avoid the GETMAIN/FREEMAIN overheads.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Tuesday, February 16, 2016 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Well, I guess using the linkage stack is cleaner because the state of the 
caller is preserved.

Thanks for your reply, that is what I wanted to know, I was going to use STM 
but I remember reading somewhere before (maybe linkedin?) that they would never 
approve any assembler code written in the past 20 years starting with STM  
R14,R12,12(R13). I just would like to hear someone that would prefer BAKR and 
why.

Thanks,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 16, 2016 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:

>I apologize if the question is silly, but I am wondering if for a 
>performance sensitive exit like this one I should use STM/LM instead of 
>BAKR/PR. I believe it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR, 
>right?

Why do you think BAKR is "cleaner"?

BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the high 
halves of any of registers 2-12).

--
Tom Marchant

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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
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: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

[Clark Morris]

On 16 Feb 2016 09:11:30 -0800, in bit.listserv.ibm-main you wrote:

>For the record, I was once zookeeper for a 4341. West Coast technology 
>subsidiary of a major East Coast bank. It ran native 'commercial' MVS (no VM) 
>in the early 80s. It may have been an oddball for having been delivered with 
>CKD DASD, but the goal was to simulate the bank's much larger boxes in their 
>'real' data centers. I don't know how one would recreate that anachronistic 
>world today, but I can say that the configuration was very doable. System was 
>initialized BTW using standalone restore of backup tapes from another data 
>center.
>
The 4341 that had MVT installed on it on an emergency basis was there
because it was being used to upgrade to MVT using a 4 MEG machine for
a TCAM based order entry system and about 20 - 40 people on TSO.  We
had to get a second 4341 to continue the upgrade.  We gradually
increased memory up to 16 MEG and then upgraded through the 4381
series.  They had a 3081 when I left in 1991.

Clark Morris
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler 
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>jo.skip.robin...@att.net
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Mike Schwab
>> Sent: Monday, February 15, 2016 10:58 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [Bulk] Re: Query: Will modern z/OS and z/VM classes suffice for MVS
>> and VM/370
>> 
>> I heavily recommend signing up for the Hercules yahoo groups for installing
>> VM/370, MVS 3.8, DOS/VS, Music, PDOS, MVT 21.8F with APL\360, etc.  Yes,
>> they have been working on emulators, but using these versions of software.
>> They even have install tape images and scripts to load empty volumes.
>> 
>> http://www.jaymoseley.com/hercules/installMVS/install.htm
>> MVS 3.7 starter system then build 3.8.
>> 
>> http://www.bsp-gmbh.com/turnkey/
>> http://www.bsp-gmbh.com/turnkey/cookbook/
>> Turnkey 3 CD-ROM with MVS 3.8J.  The Hercules on the CD-Rom is quite old.
>> 
>> http://mvs380.sourceforge.net/ Turnkey 3 MVS 3.8J with 31 bit extensions so
>> GCC can recompile itself.  Of course the extentions won't work on real
>> hardware, but just skip the enabling instruction.
>> 
>> http://wotho.ethz.ch/tk4-/ Turnkey 3 with cleanups and improvements
>> without the 31 bit changes for GCC.
>> 
>> So, pick one, install on hercules, xmit370 to disk files, download to PC, 
>> load up
>> to your disks.
>> 
>> How will you install your starter system?
>> 
>> On Mon, Feb 15, 2016 at 8:42 PM, Anne & Lynn Wheeler 
>> wrote:
>> > ri...@livingcomputermuseum.org (Rich Alderson) writes:
>> >> We are currently in the process of restoring a 4341 to operating
>> >> condition.  We have just last week corrected a fault in the power
>> >> system, and are able to power the system up and IML it from floppy.
>> >>
>> >> We are now deciding what operating system to run on the restored
>> >> system.  Most likely, we will run VM/370, but possibly we will run an
>> >> MVS guest as well.  I used to be an MVS systems programmer, but that
>> >> was more than 30 years ago, and even the rust has eroded away.
>> >>
>> >> I would like to brush up on operations and systems programming, which
>> >> would be much simpler if a modern z/OS and/or z/VM course would
>> >> suffice for the older operating systems.  Have the operator commands
>> >> and programming utilities changed radically since 1984 (JES2, CMS)?
>> >>
>> >> Please feel free to reply privately if you wish to tell me how foolish 
>> >> this
>> sounds.
>> >>
>> >> Thanks,
>> >> Rich Alderson
>> >
>> >
>> > Hercules comes with 4341 era vm370
>> > https://en.wikipedia.org/wiki/Hercules_%28emulator%29
>> >
>> > vast majority of 4341s were shipped with FBA disks ... you would need
>> > some sort of CKD disks in order to bring up MVS.
>> >
>> > huge percentage of 4341s went out into departmental areas with 3370
>> > FBA disks, sort of leading edge of distributed computing tsunami ...
>> > not requiring datacenter provisioning.
>> >
>> > --
>> > 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

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

Re: CSVFETCH exit

[Blaicher, Christopher Y.]

BAKR/PR does take a lot more time then STM/LM, but most times you can't just 
use STM/LM, you also have a GETMAIN/FREEMAIN for a register save area and other 
setup/restore things to do.

So, once you factor in those other overheads, which is faster?  I don't know as 
I haven't set up the tests to validly compare the different methods possible.  
I have seen several different ways to avoid the GETMAIN/FREEMAIN overheads.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Tuesday, February 16, 2016 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Well, I guess using the linkage stack is cleaner because the state of the 
caller is preserved.

Thanks for your reply, that is what I wanted to know, I was going to use STM 
but I remember reading somewhere before (maybe linkedin?) that they would never 
approve any assembler code written in the past 20 years starting with STM  
R14,R12,12(R13). I just would like to hear someone that would prefer BAKR and 
why.

Thanks,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 16, 2016 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:

>I apologize if the question is silly, but I am wondering if for a
>performance sensitive exit like this one I should use STM/LM instead of
>BAKR/PR. I believe it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR, 
>right?

Why do you think BAKR is "cleaner"?

BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the high 
halves of any of registers 2-12).

--
Tom Marchant

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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

Re: CSVFETCH exit

[Leonardo Vaz]

Well, I guess using the linkage stack is cleaner because the state of the 
caller is preserved.

Thanks for your reply, that is what I wanted to know, I was going to use STM 
but I remember reading somewhere before (maybe linkedin?) that they would never 
approve any assembler code written in the past 20 years starting with STM  
R14,R12,12(R13). I just would like to hear someone that would prefer BAKR and 
why.

Thanks,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 16, 2016 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:

>I apologize if the question is silly, but I am wondering if for a 
>performance sensitive exit like this one I should use STM/LM instead of 
>BAKR/PR. I believe it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR, 
>right?

Why do you think BAKR is "cleaner"?

BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the high 
halves of any of registers 2-12).

--
Tom Marchant

--
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: › Default overrides for binder?

[Frank Swarbrick]

Set what up?  I compiled the IEWBODEF CSECT to a library of my own and then did 
a STEPLIB to it, but the binder did not appear to "see" it.  

> Date: Tue, 16 Feb 2016 11:36:12 -0600
> From: bill.wood...@gmail.com
> Subject: › Default overrides for binder?
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> Yes. Perhaps attempt to set it up in a library of your own?
> 
> On Tuesday, 16 February 2016 16:55:00 UTC, Frank Swarbrick  wrote:
> > Thanks.  It looks like this behaves a bit differently than the others, in 
> > that it is a CSECT directly linked in to IEWBLINK, rather than being 
> > separate modules.  I was hoping I could place a module in its own STEPLIB 
> > and have it picked up (this is how I'm doing ASMADOPT and IGYCDOPT), but 
> > looks like I'm out of luck.  Not sure the sysprogs would be open to 
> > changing the defaults for the entire system...  Ah well, I can continue 
> > using PARM or maybe use IEWPARMS.
> > 
> > Frank
> > 
> >   
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: › Default overrides for binder?

[Tom Marchant]

On Tue, 16 Feb 2016 11:36:12 -0600, Bill Woodger wrote:

>Yes. Perhaps attempt to set it up in a library of your own?

I wonder how long it would take to have an obsolete copy of the module.

-- 
Tom Marchant

>On Tuesday, 16 February 2016 16:55:00 UTC, Frank Swarbrick  wrote:
>> Thanks.  It looks like this behaves a bit differently than the others, in 
>> that 
>>it is a CSECT directly linked in to IEWBLINK, rather than being separate 
>>modules.  
>>I was hoping I could place a module in its own STEPLIB ...

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

Re: Enterprise COBOL 6.1 announced

[Frank Swarbrick]

So what do your programs do when they get an FC97 on an OPEN?  Display a 
message to the console and wait for a response?  Display a message to the 
console and continue on?  Something else?

> Date: Tue, 16 Feb 2016 11:28:28 -0600
> From: bill.wood...@gmail.com
> Subject: Enterprise COBOL 6.1 announced
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> I'm one of those who prefers to see the 97, and take a little time out to 
> wonder why it happened. "the file was being updated, and something went wrong 
> because the file was not closed properly - I've fixed the statistics for you" 
> always makes me wary.
> 
> Of course, there is the fun where a program gets the 97, abends deliberately, 
> and run-instructions are "verify the file and resubmit".
> 
> I do wonder what "for certain VSAM OPEN statements" means exactly.
> 
> 
> On Tuesday, 16 February 2016 17:08:45 UTC, Frank Swarbrick  wrote:
> > Yay for the VSAMOPENFS(SUCC).  I submitted the RFE for this.  (Probably 
> > others did as well.)
> > 
> > I am curious what opinions other might have for this being a compile option 
> > rather than a runtime option.  I spoke with COBOL development and they were 
> > insistent that having it as a compile option was the only way to go so-as 
> > to not change existing runtime behavior and perhaps cause issues.  My 
> > argument was that if a shop currently always treated 97 and 00 in the same 
> > manner, and now 97 was never returned, the programs would still behave the 
> > same.  No need for recompile (and perhaps could work even for downlevel 
> > compiled programs, as long as they used the most recent runtime).
> > 
> > Oh well, water under the bridge I suppose.  I'm fairly happy they at least 
> > addressed it.  IMO status 97 should have never existed in the first place.
> > 
> > The INITIALIZE enhancements are pretty nice as well.  As are ALLOCATE/FREE. 
> >  I was kind of hoping for more language enhancements, but progress is 
> > progress.
> > 
> > The requirement for z/OS 2.1 is disappointing.  We haven't been on 1.13 for 
> > all that long, and I don't know that we have an upgrade due any time 
> > soon... :-(
> > 
> > Frank
> > 
> > > Date: Tue, 16 Feb 2016 08:47:13 -0600
> > > From: john.archie.mck...@gmail.com
> > > Subject: Enterprise COBOL 6.1 announced
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > 
> > > Announcement
> > > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-059
> > > 
> > > trial version
> > > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-060
> > > 
> > > One Time Charge version?
> > > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-061
> > > 
> > > ===
> > > 
> > > New ALLOCATE, FREE, and JSON GENERATE verbs. Allows ALLOCATE and FREE of
> > > dynamic memory (GETMAIN / FREEMAIN) and to generate JSON output, similar 
> > > to
> > > XML GENERATE is my guess. New option to automatically convert 
> > > FILESTATUS=97
> > > to FILESTATUS=0. Way past time for that!
> > > 
> > > Requires z/OS 2.1 or above.
> > > 
> > > ===
> > > 
> > > -- 
> > > The man has the intellect of a lobotomized turtle.
> > > 
> > > 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
> 
> --
> 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: Enterprise COBOL 6.1 announced

[Jim Mulder]

> The requirement for z/OS 2.1 is disappointing.  We haven't been on 
> 1.13 for all that long, and I don't know that we have an upgrade due
> any time soon... :-(

Support for z/OS 1.13 ends soon (Sept. 30, 2016).

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY


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

Re: CSVFETCH exit

[Tom Marchant]

On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:

>I apologize if the question is silly, but I am wondering if for a performance 
>sensitive 
>exit like this one I should use STM/LM instead of BAKR/PR. I believe it's 
>"cheaper" to 
>do STM/LM, bur "cleaner" to do BAKR, right? 

Why do you think BAKR is "cleaner"?

BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the high 
halves 
of any of registers 2-12).

-- 
Tom Marchant

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

› Default overrides for binder?

[Bill Woodger]

Yes. Perhaps attempt to set it up in a library of your own?

On Tuesday, 16 February 2016 16:55:00 UTC, Frank Swarbrick  wrote:
> Thanks.  It looks like this behaves a bit differently than the others, in 
> that it is a CSECT directly linked in to IEWBLINK, rather than being separate 
> modules.  I was hoping I could place a module in its own STEPLIB and have it 
> picked up (this is how I'm doing ASMADOPT and IGYCDOPT), but looks like I'm 
> out of luck.  Not sure the sysprogs would be open to changing the defaults 
> for the entire system...  Ah well, I can continue using PARM or maybe use 
> IEWPARMS.
> 
> Frank
> 
> 
> --
> 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

Enterprise COBOL 6.1 announced

[Bill Woodger]

I agree, but I guess it must be coming. I saw someone looking for such a thing 
(they only have V4.2) the other day, two-way processing of JSON.

XML is already used for inter-system data-transfer, so JSON is a natural 
progression. 

Using XMLSS is one of the few ways that COBOL gets the chance to use a zIIP. No 
JSONSS yet?

On Tuesday, 16 February 2016 17:14:50 UTC, John McKown  wrote:
> What "bothers" me is the lack of JSON PARSE to go with the JSON GENERATE.
> That greatly decreases the utility of using COBOL for an AJAX application.
> 
> -- 
> The man has the intellect of a lobotomized turtle.
> 
> 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

Enterprise COBOL 6.1 announced

[Bill Woodger]

I'm one of those who prefers to see the 97, and take a little time out to 
wonder why it happened. "the file was being updated, and something went wrong 
because the file was not closed properly - I've fixed the statistics for you" 
always makes me wary.

Of course, there is the fun where a program gets the 97, abends deliberately, 
and run-instructions are "verify the file and resubmit".

I do wonder what "for certain VSAM OPEN statements" means exactly.


On Tuesday, 16 February 2016 17:08:45 UTC, Frank Swarbrick  wrote:
> Yay for the VSAMOPENFS(SUCC).  I submitted the RFE for this.  (Probably 
> others did as well.)
> 
> I am curious what opinions other might have for this being a compile option 
> rather than a runtime option.  I spoke with COBOL development and they were 
> insistent that having it as a compile option was the only way to go so-as to 
> not change existing runtime behavior and perhaps cause issues.  My argument 
> was that if a shop currently always treated 97 and 00 in the same manner, and 
> now 97 was never returned, the programs would still behave the same.  No need 
> for recompile (and perhaps could work even for downlevel compiled programs, 
> as long as they used the most recent runtime).
> 
> Oh well, water under the bridge I suppose.  I'm fairly happy they at least 
> addressed it.  IMO status 97 should have never existed in the first place.
> 
> The INITIALIZE enhancements are pretty nice as well.  As are ALLOCATE/FREE.  
> I was kind of hoping for more language enhancements, but progress is progress.
> 
> The requirement for z/OS 2.1 is disappointing.  We haven't been on 1.13 for 
> all that long, and I don't know that we have an upgrade due any time soon... 
> :-(
> 
> Frank
> 
> > Date: Tue, 16 Feb 2016 08:47:13 -0600
> > From: john.archie.mck...@gmail.com
> > Subject: Enterprise COBOL 6.1 announced
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > 
> > Announcement
> > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-059
> > 
> > trial version
> > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-060
> > 
> > One Time Charge version?
> > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-061
> > 
> > ===
> > 
> > New ALLOCATE, FREE, and JSON GENERATE verbs. Allows ALLOCATE and FREE of
> > dynamic memory (GETMAIN / FREEMAIN) and to generate JSON output, similar to
> > XML GENERATE is my guess. New option to automatically convert FILESTATUS=97
> > to FILESTATUS=0. Way past time for that!
> > 
> > Requires z/OS 2.1 or above.
> > 
> > ===
> > 
> > -- 
> > The man has the intellect of a lobotomized turtle.
> > 
> > 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

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

Re: Manipulating system symbols

[Skip Robinson]

My suggestion for using the SHARE code as prefix goes back to the 1980s when
IBM made a similar recommendation for the (then new) mainframe networking
function (MSNF?) that provided for world-wide peer-to-peer connections. The
idea was to establish a naming convention that, if everyone followed it,
would keep all the disparate critters in their own cages. SHARE members have
always been guaranteed a unique two- or three-character installation code.
Non-members of course are on their own. As non-members so often are. ;-)

As for the practicality of living with only five 'meaningful' characters in
an eight-character name, we have since the 90s maintained a stable of over
60 installation defined system symbols. Amazing how much significance you
can pack into one character if you plan carefully. These symbols needless to
say are not 'self-documenting'. ;-) 

An expanded name is certainly welcome, but one poster pointed out,
conversion is more or less painful. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Peter Relson
> Sent: Tuesday, February 16, 2016 06:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Manipulating system symbols
> 
> As with a huge number of things, the best thing for any "owner" is to use
a 3-
> character prefix that they own. This is necessary for avoiding conflicts,
> whether in part names, messages, name/token names, data space names,
> ENQ qnames/rnames, etc.
> 
> I'm not sure how a customer's Share installation code fits into that
scheme.
> We probably all have heard of the general situation that IBM "owns" names
> beginning A through I and SYS. There are some exceptions (mostly due to
> "grandfathering").
> 
> Going forward, any future IBM-created system symbol(s) would begin with
SYS
> (at least as long as I'm involved), unless (perhaps) the symbol is created
> conditionally under control of some (non-default) customer-specified
option.
> 
> For example, if we ever make the LPAR name into a system symbol, it won't
be
> 
> 
> Peter Relson
> z/OS Core Technology Design

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

Re: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

[Richard Pinion]

I worked for a company in 1983-85 that had dual 4341's running MVS SP 1.3.
The 4341 was attached to 3350 DASD.



--- jo.skip.robin...@att.net wrote:

From: Skip Robinson 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370
Date: Tue, 16 Feb 2016 09:11:29 -0800

For the record, I was once zookeeper for a 4341. West Coast technology 
subsidiary of a major East Coast bank. It ran native 'commercial' MVS (no VM) 
in the early 80s. It may have been an oddball for having been delivered with 
CKD DASD, but the goal was to simulate the bank's much larger boxes in their 
'real' data centers. I don't know how one would recreate that anachronistic 
world today, but I can say that the configuration was very doable. System was 
initialized BTW using standalone restore of backup tapes from another data 
center.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mike Schwab
> Sent: Monday, February 15, 2016 10:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Query: Will modern z/OS and z/VM classes suffice for MVS
> and VM/370
> 
> I heavily recommend signing up for the Hercules yahoo groups for installing
> VM/370, MVS 3.8, DOS/VS, Music, PDOS, MVT 21.8F with APL\360, etc.  Yes,
> they have been working on emulators, but using these versions of software.
> They even have install tape images and scripts to load empty volumes.
> 
> http://www.jaymoseley.com/hercules/installMVS/install.htm
> MVS 3.7 starter system then build 3.8.
> 
> http://www.bsp-gmbh.com/turnkey/
> http://www.bsp-gmbh.com/turnkey/cookbook/
> Turnkey 3 CD-ROM with MVS 3.8J.  The Hercules on the CD-Rom is quite old.
> 
> http://mvs380.sourceforge.net/ Turnkey 3 MVS 3.8J with 31 bit extensions so
> GCC can recompile itself.  Of course the extentions won't work on real
> hardware, but just skip the enabling instruction.
> 
> http://wotho.ethz.ch/tk4-/ Turnkey 3 with cleanups and improvements
> without the 31 bit changes for GCC.
> 
> So, pick one, install on hercules, xmit370 to disk files, download to PC, 
> load up
> to your disks.
> 
> How will you install your starter system?
> 
> On Mon, Feb 15, 2016 at 8:42 PM, Anne & Lynn Wheeler 
> wrote:
> > ri...@livingcomputermuseum.org (Rich Alderson) writes:
> >> We are currently in the process of restoring a 4341 to operating
> >> condition.  We have just last week corrected a fault in the power
> >> system, and are able to power the system up and IML it from floppy.
> >>
> >> We are now deciding what operating system to run on the restored
> >> system.  Most likely, we will run VM/370, but possibly we will run an
> >> MVS guest as well.  I used to be an MVS systems programmer, but that
> >> was more than 30 years ago, and even the rust has eroded away.
> >>
> >> I would like to brush up on operations and systems programming, which
> >> would be much simpler if a modern z/OS and/or z/VM course would
> >> suffice for the older operating systems.  Have the operator commands
> >> and programming utilities changed radically since 1984 (JES2, CMS)?
> >>
> >> Please feel free to reply privately if you wish to tell me how foolish this
> sounds.
> >>
> >> Thanks,
> >> Rich Alderson
> >
> >
> > Hercules comes with 4341 era vm370
> > https://en.wikipedia.org/wiki/Hercules_%28emulator%29
> >
> > vast majority of 4341s were shipped with FBA disks ... you would need
> > some sort of CKD disks in order to bring up MVS.
> >
> > huge percentage of 4341s went out into departmental areas with 3370
> > FBA disks, sort of leading edge of distributed computing tsunami ...
> > not requiring datacenter provisioning.
> >
> > --
> > 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




_
Netscape.  Just the Net You Need.

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

Re: Enterprise COBOL 6.1 announced

[Frank Swarbrick]

Baby steps, I guess.  Personally I am not convinced that the COBOL language is 
the proper place for either JSON or XML processing.  But I've never been able 
to come up with good enough requirements for an API that would be both simply 
and powerful for use within COBOL applications.  Oh well...  I don't think 
we'll ever do JSON on the mainframe anyway.  All JSON "stuff" is done on our 
distributed application side.  (We do use XML using a vendor product that is 
pretty good.)

Frank

> Date: Tue, 16 Feb 2016 11:14:38 -0600
> From: john.archie.mck...@gmail.com
> Subject: Re: Enterprise COBOL 6.1 announced
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> What "bothers" me is the lack of JSON PARSE to go with the JSON GENERATE.
> That greatly decreases the utility of using COBOL for an AJAX application.
> 
> On Tue, Feb 16, 2016 at 11:08 AM, Frank Swarbrick <
> frank.swarbr...@outlook.com> wrote:
> 
> > Yay for the VSAMOPENFS(SUCC).  I submitted the RFE for this.  (Probably
> > others did as well.)
> >
> > I am curious what opinions other might have for this being a compile
> > option rather than a runtime option.  I spoke with COBOL development and
> > they were insistent that having it as a compile option was the only way to
> > go so-as to not change existing runtime behavior and perhaps cause issues.
> > My argument was that if a shop currently always treated 97 and 00 in the
> > same manner, and now 97 was never returned, the programs would still behave
> > the same.  No need for recompile (and perhaps could work even for downlevel
> > compiled programs, as long as they used the most recent runtime).
> >
> > Oh well, water under the bridge I suppose.  I'm fairly happy they at least
> > addressed it.  IMO status 97 should have never existed in the first place.
> >
> > The INITIALIZE enhancements are pretty nice as well.  As are
> > ALLOCATE/FREE.  I was kind of hoping for more language enhancements, but
> > progress is progress.
> >
> > The requirement for z/OS 2.1 is disappointing.  We haven't been on 1.13
> > for all that long, and I don't know that we have an upgrade due any time
> > soon... :-(
> >
> > Frank
> >
> > > Date: Tue, 16 Feb 2016 08:47:13 -0600
> > > From: john.archie.mck...@gmail.com
> > > Subject: Enterprise COBOL 6.1 announced
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > >
> > > Announcement
> > >
> > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-059
> > >
> > > trial version
> > >
> > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-060
> > >
> > > One Time Charge version?
> > >
> > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-061
> > >
> > > ===
> > >
> > > New ALLOCATE, FREE, and JSON GENERATE verbs. Allows ALLOCATE and FREE of
> > > dynamic memory (GETMAIN / FREEMAIN) and to generate JSON output, similar
> > to
> > > XML GENERATE is my guess. New option to automatically convert
> > FILESTATUS=97
> > > to FILESTATUS=0. Way past time for that!
> > >
> > > Requires z/OS 2.1 or above.
> > >
> > > ===
> > >
> > > --
> > > The man has the intellect of a lobotomized turtle.
> > >
> > > 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
> >
> 
> 
> 
> -- 
> The man has the intellect of a lobotomized turtle.
> 
> 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: Enterprise COBOL 6.1 announced

[Frank Swarbrick]

One of our sysprogs just read this and he is starting then plans for z/OS 2.2.  
So Yay!

> Date: Tue, 16 Feb 2016 10:08:34 -0700
> From: frank.swarbr...@outlook.com
> Subject: Re: Enterprise COBOL 6.1 announced
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> Yay for the VSAMOPENFS(SUCC).  I submitted the RFE for this.  (Probably 
> others did as well.)
> 
> I am curious what opinions other might have for this being a compile option 
> rather than a runtime option.  I spoke with COBOL development and they were 
> insistent that having it as a compile option was the only way to go so-as to 
> not change existing runtime behavior and perhaps cause issues.  My argument 
> was that if a shop currently always treated 97 and 00 in the same manner, and 
> now 97 was never returned, the programs would still behave the same.  No need 
> for recompile (and perhaps could work even for downlevel compiled programs, 
> as long as they used the most recent runtime).
> 
> Oh well, water under the bridge I suppose.  I'm fairly happy they at least 
> addressed it.  IMO status 97 should have never existed in the first place.
> 
> The INITIALIZE enhancements are pretty nice as well.  As are ALLOCATE/FREE.  
> I was kind of hoping for more language enhancements, but progress is progress.
> 
> The requirement for z/OS 2.1 is disappointing.  We haven't been on 1.13 for 
> all that long, and I don't know that we have an upgrade due any time soon... 
> :-(
> 
> Frank
> 
> > Date: Tue, 16 Feb 2016 08:47:13 -0600
> > From: john.archie.mck...@gmail.com
> > Subject: Enterprise COBOL 6.1 announced
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > 
> > Announcement
> > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-059
> > 
> > trial version
> > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-060
> > 
> > One Time Charge version?
> > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-061
> > 
> > ===
> > 
> > New ALLOCATE, FREE, and JSON GENERATE verbs. Allows ALLOCATE and FREE of
> > dynamic memory (GETMAIN / FREEMAIN) and to generate JSON output, similar to
> > XML GENERATE is my guess. New option to automatically convert FILESTATUS=97
> > to FILESTATUS=0. Way past time for that!
> > 
> > Requires z/OS 2.1 or above.
> > 
> > ===
> > 
> > -- 
> > The man has the intellect of a lobotomized turtle.
> > 
> > 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
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Enterprise COBOL 6.1 announced

[John McKown]

What "bothers" me is the lack of JSON PARSE to go with the JSON GENERATE.
That greatly decreases the utility of using COBOL for an AJAX application.

On Tue, Feb 16, 2016 at 11:08 AM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Yay for the VSAMOPENFS(SUCC).  I submitted the RFE for this.  (Probably
> others did as well.)
>
> I am curious what opinions other might have for this being a compile
> option rather than a runtime option.  I spoke with COBOL development and
> they were insistent that having it as a compile option was the only way to
> go so-as to not change existing runtime behavior and perhaps cause issues.
> My argument was that if a shop currently always treated 97 and 00 in the
> same manner, and now 97 was never returned, the programs would still behave
> the same.  No need for recompile (and perhaps could work even for downlevel
> compiled programs, as long as they used the most recent runtime).
>
> Oh well, water under the bridge I suppose.  I'm fairly happy they at least
> addressed it.  IMO status 97 should have never existed in the first place.
>
> The INITIALIZE enhancements are pretty nice as well.  As are
> ALLOCATE/FREE.  I was kind of hoping for more language enhancements, but
> progress is progress.
>
> The requirement for z/OS 2.1 is disappointing.  We haven't been on 1.13
> for all that long, and I don't know that we have an upgrade due any time
> soon... :-(
>
> Frank
>
> > Date: Tue, 16 Feb 2016 08:47:13 -0600
> > From: john.archie.mck...@gmail.com
> > Subject: Enterprise COBOL 6.1 announced
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > Announcement
> >
> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-059
> >
> > trial version
> >
> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-060
> >
> > One Time Charge version?
> >
> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-061
> >
> > ===
> >
> > New ALLOCATE, FREE, and JSON GENERATE verbs. Allows ALLOCATE and FREE of
> > dynamic memory (GETMAIN / FREEMAIN) and to generate JSON output, similar
> to
> > XML GENERATE is my guess. New option to automatically convert
> FILESTATUS=97
> > to FILESTATUS=0. Way past time for that!
> >
> > Requires z/OS 2.1 or above.
> >
> > ===
> >
> > --
> > The man has the intellect of a lobotomized turtle.
> >
> > 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
>



-- 
The man has the intellect of a lobotomized turtle.

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: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

[Skip Robinson]

For the record, I was once zookeeper for a 4341. West Coast technology 
subsidiary of a major East Coast bank. It ran native 'commercial' MVS (no VM) 
in the early 80s. It may have been an oddball for having been delivered with 
CKD DASD, but the goal was to simulate the bank's much larger boxes in their 
'real' data centers. I don't know how one would recreate that anachronistic 
world today, but I can say that the configuration was very doable. System was 
initialized BTW using standalone restore of backup tapes from another data 
center.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mike Schwab
> Sent: Monday, February 15, 2016 10:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Query: Will modern z/OS and z/VM classes suffice for MVS
> and VM/370
> 
> I heavily recommend signing up for the Hercules yahoo groups for installing
> VM/370, MVS 3.8, DOS/VS, Music, PDOS, MVT 21.8F with APL\360, etc.  Yes,
> they have been working on emulators, but using these versions of software.
> They even have install tape images and scripts to load empty volumes.
> 
> http://www.jaymoseley.com/hercules/installMVS/install.htm
> MVS 3.7 starter system then build 3.8.
> 
> http://www.bsp-gmbh.com/turnkey/
> http://www.bsp-gmbh.com/turnkey/cookbook/
> Turnkey 3 CD-ROM with MVS 3.8J.  The Hercules on the CD-Rom is quite old.
> 
> http://mvs380.sourceforge.net/ Turnkey 3 MVS 3.8J with 31 bit extensions so
> GCC can recompile itself.  Of course the extentions won't work on real
> hardware, but just skip the enabling instruction.
> 
> http://wotho.ethz.ch/tk4-/ Turnkey 3 with cleanups and improvements
> without the 31 bit changes for GCC.
> 
> So, pick one, install on hercules, xmit370 to disk files, download to PC, 
> load up
> to your disks.
> 
> How will you install your starter system?
> 
> On Mon, Feb 15, 2016 at 8:42 PM, Anne & Lynn Wheeler 
> wrote:
> > ri...@livingcomputermuseum.org (Rich Alderson) writes:
> >> We are currently in the process of restoring a 4341 to operating
> >> condition.  We have just last week corrected a fault in the power
> >> system, and are able to power the system up and IML it from floppy.
> >>
> >> We are now deciding what operating system to run on the restored
> >> system.  Most likely, we will run VM/370, but possibly we will run an
> >> MVS guest as well.  I used to be an MVS systems programmer, but that
> >> was more than 30 years ago, and even the rust has eroded away.
> >>
> >> I would like to brush up on operations and systems programming, which
> >> would be much simpler if a modern z/OS and/or z/VM course would
> >> suffice for the older operating systems.  Have the operator commands
> >> and programming utilities changed radically since 1984 (JES2, CMS)?
> >>
> >> Please feel free to reply privately if you wish to tell me how foolish this
> sounds.
> >>
> >> Thanks,
> >> Rich Alderson
> >
> >
> > Hercules comes with 4341 era vm370
> > https://en.wikipedia.org/wiki/Hercules_%28emulator%29
> >
> > vast majority of 4341s were shipped with FBA disks ... you would need
> > some sort of CKD disks in order to bring up MVS.
> >
> > huge percentage of 4341s went out into departmental areas with 3370
> > FBA disks, sort of leading edge of distributed computing tsunami ...
> > not requiring datacenter provisioning.
> >
> > --
> > 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: Enterprise COBOL 6.1 announced

[Frank Swarbrick]

Yay for the VSAMOPENFS(SUCC).  I submitted the RFE for this.  (Probably others 
did as well.)

I am curious what opinions other might have for this being a compile option 
rather than a runtime option.  I spoke with COBOL development and they were 
insistent that having it as a compile option was the only way to go so-as to 
not change existing runtime behavior and perhaps cause issues.  My argument was 
that if a shop currently always treated 97 and 00 in the same manner, and now 
97 was never returned, the programs would still behave the same.  No need for 
recompile (and perhaps could work even for downlevel compiled programs, as long 
as they used the most recent runtime).

Oh well, water under the bridge I suppose.  I'm fairly happy they at least 
addressed it.  IMO status 97 should have never existed in the first place.

The INITIALIZE enhancements are pretty nice as well.  As are ALLOCATE/FREE.  I 
was kind of hoping for more language enhancements, but progress is progress.

The requirement for z/OS 2.1 is disappointing.  We haven't been on 1.13 for all 
that long, and I don't know that we have an upgrade due any time soon... :-(

Frank

> Date: Tue, 16 Feb 2016 08:47:13 -0600
> From: john.archie.mck...@gmail.com
> Subject: Enterprise COBOL 6.1 announced
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> Announcement
> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-059
> 
> trial version
> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-060
> 
> One Time Charge version?
> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-061
> 
> ===
> 
> New ALLOCATE, FREE, and JSON GENERATE verbs. Allows ALLOCATE and FREE of
> dynamic memory (GETMAIN / FREEMAIN) and to generate JSON output, similar to
> XML GENERATE is my guess. New option to automatically convert FILESTATUS=97
> to FILESTATUS=0. Way past time for that!
> 
> Requires z/OS 2.1 or above.
> 
> ===
> 
> -- 
> The man has the intellect of a lobotomized turtle.
> 
> 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: › Default overrides for binder?

[Frank Swarbrick]

Thanks.  It looks like this behaves a bit differently than the others, in that 
it is a CSECT directly linked in to IEWBLINK, rather than being separate 
modules.  I was hoping I could place a module in its own STEPLIB and have it 
picked up (this is how I'm doing ASMADOPT and IGYCDOPT), but looks like I'm out 
of luck.  Not sure the sysprogs would be open to changing the defaults for the 
entire system...  Ah well, I can continue using PARM or maybe use IEWPARMS.

Frank

> Date: Tue, 16 Feb 2016 02:09:32 -0600
> From: bill.wood...@gmail.com
> Subject: › Default overrides for binder?
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> Something like this? 
> http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ieab200/bnddef.htm%23bnddef
> 
> On Monday, 15 February 2016 23:45:25 UTC, Frank Swarbrick  wrote:
> > The assembler has the ASMAOPT macro to build the ASMADOPT CSECT containing 
> > the shop defaults for HLASM.  COBOL has the  IGYCOPT macro to build the 
> > IGYCDOPT CSECT containing the shop defaults for COBOL. There does not 
> > appear to be anything similar for the binder.  Am I overlooking it?  (I 
> > know about using the PARM and/or IEWPARMS DD or OPTIONS(ddname) to override 
> > the defaults).
> > 
> > Thanks,
> > Frank
> >   
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CSVFETCH exit

[Leonardo Vaz]

Hello again list!

I apologize if the question is silly, but I am wondering if for a performance 
sensitive exit like this one I should use STM/LM instead of BAKR/PR. I believe 
it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR, right? 

Thanks,
Leo



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Friday, February 12, 2016 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I agree, unsafe.  But I could probably argue that just letting a system 
programmer logon is unsafe :)  I had various checks to try to prevent the hooks 
from causing issues, including (if I remember correctly) using the LRA 
instruction to check for a valid address in ECSA prior to access.  I didn't 
want to cause an 0C4 in someone's SVC 8 just because I messed up.

Over the 4 years or so the hooks were in place I was kind of proud they had 
never caused problems or crashed a system.  And they had to co-exist with 
various vendor product hooks on the same SVC's.  That work gave me a good look 
at what the poor vendors have to go through when no better interface exists.

Leonardo Vaz wrote:
> More difficult indeed, but at least it is now a documented programming 
> interface, which is a huge jump from having to play around with 
> arguably unsafe hooks :)

--
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: z14 Drops Support for ESA/390 Mode (Was: Re: zEC12)

[Joel C. Ewing]

On 02/10/2016 04:09 PM, Tony Harminc wrote:
> On 10 February 2016 at 15:50, Joel C. Ewing  wrote:
>>> Why do you think that SIE would not continue to provide virtual
>>> ESA/390 support? Today, when z/VM is running in zArch mode on the
>>> metal on e.g. a z12, it can surely have an ESA/390 mode guest OS. I
>>> see no reason that wouldn't continue just because the host processor
>>> doesn't IPL in ESA/390 mode.
>>>
>>> Tony H.
>>>
>>>
>> Well that was sort of my first thought too, but the actual wording in
>> z/VM Statement of Direction was that  "the IBM z13 server family will be
>> the last to support ESA/390 architecture mode", not that it wouldn't
>> support ESA/390 mode on IPL.  That sure sounds like there will no longer
>> be any hardware ability to switch ARCHLVL mode, and that z14 and later
>> will run only in ARCHLVL2 mode.
> Well I don't know what IBM has actually said, or what they mean, so
> I'm speculating as much as you are. Hopefully one of our friendly
> IBMers will step in and clarify. But my understanding of "the IBM z13
> server family will be the last to support ESA/390 architecture mode"
> is simply that on z14+ the IPL sequence will not start in or pass
> through ESA/390 mode, and it will not be possible to issue a SIGP to
> set ESA/390 mode. OK, but none of this suggests that a guest under SIE
> will not be able to run in ESA/390 mode. Perhaps the IPL will take
> some assistance from z/VM, but no one cares if that has high emulation
> overhead.
>
> BTW, this whole "switch architecture modes on the fly" reminds me of
> the famous Gordon Letwin "turning the ignition off and back on when
> the car's doing 60 MPH" scheme for the Intel 286 on OS/2. Only it's
> architected, rather than being a fortuitous kludge.
>
> http://www.google.com/patents/US4825358
>
> Tony H.
>
>
>
The announcement for z/VM V6.4 on Feb 16 says (emphasis added):
"ESA/390 removal. Enhancements enable hypervisor initialization and
termination, SAPL, and stand-alone utilities to run entirely in
z/Architecture® mode. The z13 is planned to be the last z Systems server
to support running an operating system in ESA/390 architecture mode. All
future systems will support only operating systems that run **entirely**
in z/Architecture mode."

"In addition, support will be added to simulate a z/Architecture-only
environment, by providing a virtual machine environment that is always
in the z/Architecture architectural mode and **cannot switch** to the
ESA/390 architectural mode. This can be useful for testing software in a
**z/Architecture-only environment**, in advance of deploying software on
a future z/Architecture-only machine."

That seems pretty explicit to me that the plan is that on z14 and beyond
an operating system will be required to start and run exclusively in
z/Architecture mode and that there will simply be no hardware capability
to run in ESA/390 mode, period.  I think in this context z/VM  must also
be classed as an operating system. It is also, I think, significant that
the z/VM V6.4 "enhancement" topic is titled "ESA/390 removal", not
"ESA/390 future emulation" or "ESA/390 future support".

-- 
Joel C. Ewing, Bentonville, AR jcew...@acm.org

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

Re: IBM z13s article.

[Dana Mitchell]

Did you see this other announcement today?:

IBM Multi-Factor Authentication for z/OS works with RACF Security Server 
infrastructure to create a layered defense
IBM United States Software Announcement 216-069



On Tue, 16 Feb 2016 15:17:54 +, Bigendian Smalls 
 wrote:

>Two factor auth in the OS is a big (and long overdue) deal.   Has anyone heard 
>of this in a general flavor of z/os or know what version / add-on might 
>contain such a thing for the rest of us?
>
>

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

Re: IBM z13s article.

[Bigendian Smalls]

Two factor auth in the OS is a big (and long overdue) deal.   Has anyone heard 
of this in a general flavor of z/os or know what version / add-on might contain 
such a thing for the rest of us?


> On Feb 16, 2016, at 9:10 AM, Dana Mitchell  wrote:
> 
> I found support for SSL on OSA ICC interesting.  That would eventually allow 
> us to move consoles off a dedicated network.
> 
> Dana
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: IBM z13s article.

[Dana Mitchell]

I found support for SSL on OSA ICC interesting.  That would eventually allow us 
to move consoles off a dedicated network.

Dana

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

Re: zEC12

[Blake, Daniel J [CTR]]

EC12 being withdrawn from marketing.

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS916-037


Thank You


Dan Blake - TL
  

dbl...@fdic.gov
FDIC ISC-3 O Service Delivery | Room B4072
O: (703) 516-5497 | BB: (703) 314-0501 | M: (703) 946-2967 


Advanced Out of Office Notice:
 
Telecommute March 14-18, 2016.


-Original Message-
From: Blake, Daniel J [CTR] 
Sent: Tuesday, February 09, 2016 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RE: zEC12

It doesn't appear to be on the radar for end of marketing yet.  And IBM won't 
give us an advance warning until they announce it.

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/5cb5ed706d254a8186256c71006d2e0a/74f007db22182c6b86257e06006f7a73/$FILE/IBM%20Mainframe%20Life%20Cycle%20History%20V1.7.pdf


Thank You


Dan Blake - TL
  

dbl...@fdic.gov
FDIC ISC-3 O Service Delivery | Room B4072
O: (703) 516-5497 | BB: (703) 314-0501 | M: (703) 946-2967 


Advanced Out of Office Notice:
 
Telecommute February 8th-12th.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Tuesday, February 09, 2016 2:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zEC12

Does anyone know when the z/EC12 will be end of marketing and end of support?

Thanks in advance!



Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

Enterprise COBOL 6.1 announced

[John McKown]

Announcement
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-059

trial version
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-060

One Time Charge version?
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=iSource=897=ENUS216-061

===

New ALLOCATE, FREE, and JSON GENERATE verbs. Allows ALLOCATE and FREE of
dynamic memory (GETMAIN / FREEMAIN) and to generate JSON output, similar to
XML GENERATE is my guess. New option to automatically convert FILESTATUS=97
to FILESTATUS=0. Way past time for that!

Requires z/OS 2.1 or above.

===

-- 
The man has the intellect of a lobotomized turtle.

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: Manipulating system symbols

[Peter Relson]

As with a huge number of things, the best thing for any "owner" is to use 
a 3-character prefix that they own. This is necessary for avoiding 
conflicts, whether in part names, messages, name/token names, data space 
names, ENQ qnames/rnames, etc.

I'm not sure how a customer's Share installation code fits into that 
scheme. We probably all have heard of the general situation that IBM 
"owns" names beginning A through I and SYS. There are some exceptions 
(mostly due to "grandfathering").

Going forward, any future IBM-created system symbol(s) would begin with 
SYS (at least as long as I'm involved), unless (perhaps) the symbol is 
created conditionally under control of some (non-default) 
customer-specified option.

For example, if we ever make the LPAR name into a system symbol, it won't 
be 

Peter Relson
z/OS Core Technology Design


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

Re: IBM z13s article.

[Charles Mills]

Machine type 2965.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Monday, February 15, 2016 11:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM z13s article.

http://www.pcworld.com/article/3033464/ibm-unveils-z13s-mainframe-focused-on-security-and-hybrid-clouds.html
N10 with 1TB or N20 with 4TB.

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

Re: Concatenation order in LPALST

[william janulin]

Your security product, whatever it is, may have a requirement for a library to 
be in the LPA concatenation, I believe.
Bill J.
 

On Tuesday, February 16, 2016 8:19 AM, John McKown 
 wrote:
 

 On Tue, Feb 16, 2016 at 6:51 AM, Nathan Astle  wrote:

> Hi,
>
> Apology for asking dummy question.
>
> Is there a reason on why we need to place Security product LPALIB after the
> System LPALIB in LPALST00 ?
>

​Because the vendor said to? [grin].

I would guess that it would be for the same reason as with a STEPLIB. If a
duplicate named module exists​, the one in the data set "higher" in the
list is the one actually used. Perhaps your security vendor has
deliberately done some "nasty" things to replace modules which are in other
LPA libraries and want to be sure that _their_ module is loaded. I'd scan
the names to see if there are any duplicates of those in libraries "below"
the security product library. And perhaps ask the vendor why they are doing
that. No, I don't have an example.


> Nathan
>
>
-- 
The man has the intellect of a lobotomized turtle.

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: Concatenation order in LPALST

[John McKown]

On Tue, Feb 16, 2016 at 6:51 AM, Nathan Astle  wrote:

> Hi,
>
> Apology for asking dummy question.
>
> Is there a reason on why we need to place Security product LPALIB after the
> System LPALIB in LPALST00 ?
>

​Because the vendor said to? [grin].

I would guess that it would be for the same reason as with a STEPLIB. If a
duplicate named module exists​, the one in the data set "higher" in the
list is the one actually used. Perhaps your security vendor has
deliberately done some "nasty" things to replace modules which are in other
LPA libraries and want to be sure that _their_ module is loaded. I'd scan
the names to see if there are any duplicates of those in libraries "below"
the security product library. And perhaps ask the vendor why they are doing
that. No, I don't have an example.


> Nathan
>
>
-- 
The man has the intellect of a lobotomized turtle.

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: Concatenation order in LPALST

[Itschak Mugzach]

Sys1.lpalib is alwaya first forced by mvs if u dont specify it. The only
exception is if you use the syslib statement to override ir's name.

ITschak
בתאריך 16 בפבר 2016 15:13,‏ "Mark Jacobs - Listserv" <
mark.jac...@custserv.com> כתב:

> It's not required but a good practice to have SYS1.LPALIB first in the
> LPALST unless you know what you're doing.
>
> Mark Jacobs
>
> Nathan Astle 
>> February 16, 2016 at 7:51 AM
>> Hi,
>>
>> Apology for asking dummy question.
>>
>> Is there a reason on why we need to place Security product LPALIB after
>> the
>> System LPALIB in LPALST00 ?
>>
>> Nathan
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>> Please be alert for any emails that may ask you for login information or
>> directs you to login via a link. If you believe this message is a phish or
>> aren't sure whether this message is trustworthy, please send the original
>> message as an attachment to 'phish...@timeinc.com'.
>>
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Concatenation order in LPALST

[Mark Jacobs - Listserv]

It's not required but a good practice to have SYS1.LPALIB first in the 
LPALST unless you know what you're doing.


Mark Jacobs


Nathan Astle 
February 16, 2016 at 7:51 AM
Hi,

Apology for asking dummy question.

Is there a reason on why we need to place Security product LPALIB 
after the

System LPALIB in LPALST00 ?

Nathan

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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




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

Concatenation order in LPALST

[Nathan Astle]

Hi,

Apology for asking dummy question.

Is there a reason on why we need to place Security product LPALIB after the
System LPALIB in LPALST00 ?

Nathan

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

› Default overrides for binder?

[Bill Woodger]

Something like this? 
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ieab200/bnddef.htm%23bnddef

On Monday, 15 February 2016 23:45:25 UTC, Frank Swarbrick  wrote:
> The assembler has the ASMAOPT macro to build the ASMADOPT CSECT containing 
> the shop defaults for HLASM.  COBOL has the  IGYCOPT macro to build the 
> IGYCDOPT CSECT containing the shop defaults for COBOL. There does not appear 
> to be anything similar for the binder.  Am I overlooking it?  (I know about 
> using the PARM and/or IEWPARMS DD or OPTIONS(ddname) to override the 
> defaults).
> 
> Thanks,
> Frank
> 
> --
> 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