Re: SMF41 VLF info and ALERTAGE

[Peter Relson]

It is relatively unlikely that we would implement this in the service 
stream.  Not impossible.

The information is nice, but it is obtainable via HC as I mentioned and 
customers have not thought it overly necessary since it seems that no one 
ever asked for it. We implemented it to help our service team.

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: Cannot allocate Steplib?

[Peter Relson]

Regarding IEFA110I:

Sadly, I see that the book mentions that this is "new" but the message 
itself isn't in the book. I will have someone look into that.

I was surprised to see that the display did not show XCFAS (unless someone 
had used the PROGxx LNKLST UNALLOCATE statement), since by default LNKLST 
data sets are allocated SHR by XCFAS (whether or not LLA is active), 
precisely to help keep someone from allocating one of those data sets 
"OLD" which in turn is intended to help keep someone from, if they're 
doing it right, allocating the data set OLD in order to compress it . To 
me, it has always been strange that you do not need to allocate a data set 
OLD in order to compress it. But I'd say that doing so is right. I even 
suggested some customer-configuration option "enforce DISP=OLD for 
compress" so that a customer could set that option in parmlib and have it 
apply to their whole z/OS. No one seemed to interested in implementing 
that, though. The option is necessary for compatibility reasons.

The IEFA110I message is intended to show up to about 20 ENQ holders (it's 
not necessarily exactly "20"), after which it will add the line 
"SOME OWNERS SUPPRESSED"

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: Friday, but not funny at all...

[Cannaerts, Jan]

Can't say I follow.

Would the builtin (which should be a library if anything) create a .tex
file, which would still need to run through TeX itself to create a .pdf?

Or would the builtin take a .tex file and create a .pdf (or other format)?

The latter already exists of course, except that TeX has not been ported to 
z/OS.
The former would still need to derive the markup from something. Does text get
marked up based on where it exists in a structure? Will there be a new PL/1
markup language that gets ported to TeX markup by this builtin?

It all seems a bit comical. Perhaps I don't understand what the initial state
is before the builtin is called. But from what I gather, the RFE submitter is
asking for the PL/1 compiler to translate an arbitrary, new markup syntax to
the markup syntax used by MS Word, and then creating a valid .docx file.

Might as well mark your text up in the .docx format yourself no?



-Original Message-

Whereas anyone with even a bit of sense would ask for something that is
LaTex compatible!​ Actually, I still like the SGML used by DCF & Waterloo
Script. I have gone to the URL posted and entered the following comment:

===

Rather than a proprietary format, such as MS "docx", I would prefer a truly
open format used by professional organizations. In particular, I think that
TeX or, especially, LaTeX2e would be far superior to "docx". LaTex2e is the
preferred document format for the American Mathematical Society and the
Institute for Operations Research and the Management Sciences. Many
graduate schools prefer the use of some sort of TeX document for papers and
theses.

===

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

Re: Grace didn't coin the term "bug"?

[Ted MacNEIL]

Relay #70.

-teD
  Original Message  
From: John Ehrman
Sent: Friday, March 18, 2016 00:17
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Grace didn't coin the term "bug"?

The association of bugs with computers may go back to the Mark I (I think 
it was) relay computer at Harvard. An error was traced to a moth between 
two relay contacts.

In the Computer History Museum in Mountain View CA there's a copy of the 
logbook page with the moth pasted in place. The display is near other 
early computers like the Atanasoff=Berry machine, the Johnniac, a German 
Enigma and examples of Konrad Zuse's work. If you're in Silicon Valley, I 
urge you to visit; more info at computerhistory.org .

Regards... John 



--
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: Grace didn't coin the term "bug"?

[Jesse 1 Robinson]

SHARE will be back in San Jose March 2017. In the hood. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Ehrman
Sent: Thursday, March 17, 2016 9:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Grace didn't coin the term "bug"?

The association of bugs with computers may go back to the Mark I (I think it 
was) relay computer at Harvard.  An error was traced to a moth between two 
relay contacts.

In the Computer History Museum in Mountain View CA there's a copy of the 
logbook page with the moth pasted in place.  The display is near other early 
computers like the Atanasoff=Berry machine, the Johnniac, a German Enigma and 
examples of Konrad Zuse's work.  If you're in Silicon Valley, I urge you to 
visit; more info at computerhistory.org .

Regards... 

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

Re: Grace didn't coin the term "bug"?

[Ted MacNEIL]

Yes, it was.

-teD
  Original Message  
From: Clark Morris
Sent: Friday, March 18, 2016 09:09
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Grace didn't coin the term "bug"?

On 18 Mar 2016 05:18:44 -0700, in bit.listserv.ibm-main Ted wrote:

>Relay #70.

Was the Grace Hopper quote actually something to the effect that in
the case in question it was a real bug (the moth)?

Clark Morris
>
>-teD
>  Original Message  
>From: John Ehrman
>Sent: Friday, March 18, 2016 00:17
>To: IBM-MAIN@LISTSERV.UA.EDU
>Reply To: IBM Mainframe Discussion List
>Subject: Re: Grace didn't coin the term "bug"?
>
>The association of bugs with computers may go back to the Mark I (I think 
>it was) relay computer at Harvard. An error was traced to a moth between 
>two relay contacts.
>
>In the Computer History Museum in Mountain View CA there's a copy of the 
>logbook page with the moth pasted in place. The display is near other 
>early computers like the Atanasoff=Berry machine, the Johnniac, a German 
>Enigma and examples of Konrad Zuse's work. If you're in Silicon Valley, I 
>urge you to visit; more info at computerhistory.org .
>
>Regards... John 
>
>
>
>--
>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: Raised Floor

[Ed Gould]

On Mar 17, 2016, at 3:27 AM, Elardus Engelbrecht wrote:


Timothy Sipples wrote:

Sometimes even if a certain practice is legal it might not be  
legally prudent. Civil lawsuits exist in many jurisdictions.


It depends. If someone cuts a hole and left that hole open, someone  
can fall in that hole. Result - messy lawsuits, because you may not  
leave a hole open + unsupervised. (raised floor, sewer pipes, cable  
ducts, etc.)


ABout 30 years ago I put my foot through such a hole. Ruined the  
suit. Should have sued the company.


Ed

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

Re: SYSPROC Concatenation?

[Ed Gould]

On Mar 16, 2016, at 11:22 AM, Paul Gilmartin wrote:


On Wed, 16 Mar 2016 10:58:28 -0500, John McKown wrote:


Q).  How did I get my CLIST Concatenated permanently?  I would  
like to do

it again.


​Actually, nobody here can tell you -- exactly. ... There is not  
"IBM standard"

way to do this.



Pretty much confirmed by:
Writing a logon procedure
z/OS TSO/E Customization
SA32-0976-00

Grrr...  I hate MVS!  It seems to have a philosophy of denying  
flexibility

to end users and elevating it to administrators.  The default PARM for
IKJEFT01 ought to be something such as "EXEC 'prefix.CLIST(PROFILE)'"

The chapter cited above mentions the COMMAND field of the LOGON
panel.  I believe this is persistent and could be a script to  
perform the

concatenation you want.

Gil:

Don't blame MVS. *YOU* can set it up to your own local standards.

Ed

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

Re: SYSPROC Concatenation?

[Ed Gould]

The way I learned to do it was that logon procs did a universal ex  
sysproc(logon) and if you had a pds that had the member logon in it  
it would exec that clist and in that clist you could allocate the  
libraries to your liking. With the understanding that if didn't have  
IBM libraries first don't come trouble shooting to us.


Ed
On Mar 16, 2016, at 10:58 AM, John McKown wrote:


On Wed, Mar 16, 2016 at 10:51 AM, Hansen, Dave L - Eagan, MN <
00d83826d62b-dmarc-requ...@listserv.ua.edu> wrote:


Hi,

  I went to https://listserv.ua.edu/cgi-bin/wa and did a search on
IBM-MAIN and IBM-MAIN-ARCHIVES (1986-2004).  I did a search for  
SYSPROC and

got no match.

  On one system I have ISRDDN showing SYSPROC with my CLIST  
concatenated.
I can use ALTLIB (or SPROC) to add it in to the other system.  But  
I have

to manually add these and repeat it.

  My logon Procedure is xxxACCNT.  I looked in SYS2.LOG and
SYS2.CLIST(SPFALLOC) for my userid to find userid.CLIST but am not  
finding

it.

   I looked through the userid.lpar.ISPF .PROFILE datasets.  ISRPLIST
shows the last 30 referenced data sets.

Q).  How did I get my CLIST Concatenated permanently?  I would  
like to do

it again.



​Actually, nobody here can tell you -- exactly. We do the same. In  
our
logon PROCEDURE, we have a //TSOISPF EXEC  
PGM=IKJEFT01,PARM='LOGON'. In the
SYSPROC DD concatenation, we hav​e a member called LOGON which is  
what that
executes. It is a REXX exec. One of the things that it does is re- 
allocate

the SYSPROC DD to include, if it exists, the equivalent of
DSN= . Something like that is most likely what is
happening at your shop. But you'll need to track down the CLIST/REXX
programs invoked by the "xxxACCNT" logon procedure to determine  
what you

need to do. There is not "IBM standard" way to do this.






   Thank you,  Dave




--
A fail-safe circuit will destroy others. -- Klipstein

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: CeBIT and mainframes

[Ed Gould]

On Mar 18, 2016, at 1:00 PM, Clark Morris wrote:


On 18 Mar 2016 07:27:09 -0700, in bit.listserv.ibm-main Itschak wrote:


no recompile involved. Just relink to replace IBM's LE modules.

So what processor(s) is this code running on? What exactly is being
done?

Clark Morris


--SNIP

So ... how do you know when an LE module changes?

Manual effort?

Ed

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

Re: Enterprise COBOL V6 documentation available

[Ed Gould]

I think its a good idea. Pity it took IBM 10+ years to put out a  
Messages and Codes for the same product.


Ed
On Mar 18, 2016, at 9:53 AM, Bill Woodger wrote:


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

This includes a new Performance Tuning guide, from Day One, by  
following the link on the 6.1 tab


--
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: CeBIT and mainframes

[Mike Schwab]

Sounds a lot like http://www.z390.org/ .
It took about 5 years for one guy to develop.
It emulates hardware instructions and operating system calls.  No IBM
software (other than macro definitions for the system calls).

On Thu, Mar 17, 2016 at 10:37 AM, Joel C. Ewing  wrote:
> On 03/17/2016 08:01 AM, Elardus Engelbrecht wrote:
>> Hi
>>
>> I played around the CeBIT website and came across this interesting thing:
>>
>> http://www.cebit.de/exhibitor/lzlabs/E363469
>>
>> http://www.bankingtech.com/454942/lzlabs-unveils-worlds-first-software-defined-mainframe/
>>
>> I see this note:
>>
>> LzLabs Software Defined Mainframe (TM) enables both Red Hat Linux and Cloud 
>> infrastructure such as Microsoft's Azure to process thousands of 
>> transactions per second, while maintaining enterprise requirements for 
>> reliability, scalability, serviceability and security. This software 
>> solution includes a faithful re-creation of the primary online, batch and 
>> database environments, which enables unrivaled compatibility and exceptional 
>> performance, to dramatically reduce IT costs.
>>
>> Wonder what is big blue saying of this interesting development?
>>
>> PS: I am NOT with CeBIT or LzLabs or anything with them.
>>
>> Groete / Greetings
>> Elardus Engelbrecht
>>
>> ...
> I notice they also claim
> "no need for recompilation of Cobol or PL/1 application programmes, no
> source code changes, or changes to operational procedures".
>
> So they have somehow managed to replicate the functional behavior of all
> the SVC and PC interfaces and control blocks that application code might
> be using in z/OS batch and CICS environments, to replicate the
> functional behavior of I/O to data sets that batch jobs and CICS
> transactions might be doing, to replicate all the CICS APIs and CICS
> control blocks CICS applications might be using, to replicate all the LE
> run time support needed to execute COBOL and PL/I programs in batch and
> CICS, to replicate all the related DB2 functional APIs, and to emulate
> the execution of z-architecture application program code in batch and
> CICS environments, and to replicate operational interfaces. And since
> security was "maintained", that implies they have also managed to
> replicate the functionality of RACF for their batch, CICS, and DB2
> environments, and integrated that security somehow into the supporting
> physical operating environment to secure the "mainframe" data from
> external tampering.  In other words, to do what they seem to claim, they
> have re-implemented a significant portion of z/OS and some major
> subsystems of z/OS for another hardware platform.  All correctly and
> without infringing on any IBM patents or licensing restrictions?  And
> have achieved  reasonable transaction rates without sacrificing
> "reliability, scalability, serviceability, and security" on hardware
> platforms that have historically been less robust than z-architecture?
>
> Color me skeptical.
>
> They don't say no re-linking of load modules, which makes me suspect
> that to be legal you would have to re-link and somehow replace any
> linked-in LE run time modules, since those modules would be IBM-licensed
> code.
>
> Even "stabilized" applications may require occasional minor changes
> --e.g.,to adapt to trivial changes in local sales tax rates.  Without a
> mainframe compiler even a trivial change becomes a difficult load module
> patch.
>
> --
> 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



-- 
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: CeBIT and mainframes

[Clark Morris]

On 18 Mar 2016 07:27:09 -0700, in bit.listserv.ibm-main Itschak wrote:

>no recompile involved. Just relink to replace IBM's LE modules.
So what processor(s) is this code running on? What exactly is being
done?

Clark Morris
>
>Itschak
>
>
>
>On Fri, Mar 18, 2016 at 12:01 PM, Mark Regan  wrote:
>
>> There is a ComputerWeekly article on this product at
>>
>> http://www.computerweekly.com/blogs/quocirca-insights/2016/03/the-software-defined-mainframe.html
>> .
>> I noticed that the article author needs to know how to spell the acronym
>> for EBCDIC correctly. He spells it 'EBSDIC' and did it twice.
>>
>>
>> On Fri, Mar 18, 2016 at 4:04 AM Elardus Engelbrecht <
>> elardus.engelbre...@sita.co.za> wrote:
>>
>> > Joel C. Ewing wrote:
>> >
>> > >I notice they also claim "no need for recompilation of Cobol or PL/1
>> > application programmes, no source code changes, or changes to operational
>> > procedures".
>> >
>> > I am really struggling to swallow that claim...
>> >
>> > and Dave_Craig wrote:
>> >
>> > >Queue the IP lawyers, and action!
>> >
>> > This is why I said this is 'interesting development'. I am very sure big
>> > blue and their lawyers won't like that one bit unless there is an
>> agreement.
>> >
>> > >  I'll be slow to migrate off that proven decades-old mission-critical
>> > platform, that's for sure.
>> >
>> > I will also be slow to get off the mainframes.
>> >
>> > Joel C. Ewing wrote:
>> >
>> > >Color me skeptical.
>> >
>> > With all the colors of the rainbow! ;-)
>> >
>> > Groete / Greetings
>> > Elardus Engelbrecht
>> >
>> > --
>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> >
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>--
>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

Testing to see if I am still subscribed

[Ed Gould]

Testing 1 2 3

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

Re: Linking C module with SSL

[Robin Atwood]

Charles -
We are already attaching C programs to each other, the problem seems to be the 
POSIX option is not inherited.

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: 17 March 2016 21:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linking C module with SSL

I am trying to remember ... I had some sort of a problem where I could not load 
a particular C++ program from a COBOL program because of some incompatibility 
(POSIX? I *think* so) and I solved it by building a tiny stub program (in C++) 
to be called from COBOL and ATTACH the "real" C++ program. I know it works but 
I do not find my notes on *exactly* why I did it.

Perhaps some approach like that might be a help?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robin Atwood
Sent: Thursday, March 17, 2016 7:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linking C module with SSL

Now I have hit the problem I thought might be lurking. The module I fixed 
before with the POSIX(ON) pragma is the listener. It attaches a number of 
worker tasks it givesockets an incoming session to. When the worker does its 
takesocket it must then do a gsk_secure_socket_open() to start the SSL 
handshake. This failed with a EDC5167I so I added the POSIX(ON) pragma. 
Restarting, the STC immediately failed in a call to BPX1MSS, rc=156, rsn= 
0D070201, which means:

JRAlreadySigSetUp: BPX1MSS found the process already set up for signals  
Action: Only one task can be set up for signals at any one time.  Issue the 
signal unset (BPX1MSD) service on the task that did the last setup and then 
reissue this service.   

So it seems I can only have POSIX(ON) in one TCB? That's a bit of a 
showstopper. :(

--
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: How can I use Library Manager to download the non-OS manuals such as CICS, IMS, DB2?

[Jantje.]

After having installed the 5.1 version of the SoftCopy Libaray Manager, the 
Knowledge center for CICS pops up in the list when you select the Internet 
source.

Apart from that, I don't know.

Cheers,

Jantje.

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

Friday, but not funny at all...

[Bill Woodger]

You need to be logged-in with your IBM ID before going to the individual RFE. 
Catches me every time.


On Friday, 18 March 2016 17:49:21 UTC, Paul Gilmartin  wrote:
> The URL doesn't work for me:
> 
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=85255
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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