Re: Programmatic way to create unrecoverable ABEND?

[Steve Smith]

I think the easiest way to test is to just zap your code to take the
unrecoverable path.  Or, you could try the DETACH, try your other things,
and tell us what happens.

I suppose you could write another ESTAE recovery to set SDWACLUP for the
"real" routine (for testing).

Abends in recovery routines are pretty nasty :-).  So thorough testing is a
really good idea.
sas

On Thu, Apr 11, 2019 at 1:13 AM Tom Brennan 
wrote:

> I spent hours one time trying to figure out why my DC H'0' resulted in
> an 0C4.  Turned out someone coded a bad address in the ESTAE routine, so
> *every* abend turned into an 0C4.
>
> ...
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Charles Mills
> > Sent: Wednesday, April 10, 2019 4:40 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Programmatic way to create unrecoverable ABEND?
> >
> > Is there a reasonably easy way for a task to create an ABEND that ESTAE
> or FRR will indicate is unrecoverable (SDWACLUP)? (I can't use console
> CANCEL because I need the ABEND to occur within a fairly specific range of
> machine
> > instructions.)
> >
> >
> >
> > Will issuing a DETACH "for myself" do it? ABEND X'222',,SYSTEM won't do
> it, right? S222 is normally unrecoverable, but not if done from a normal
> ABEND macro?
> >
> >
> >
> > The doc for DETACH says the issuer cannot have an EUT FRR. What if it
> does?
> >
> >
> >
> > I'm not just trying to make trouble. I am trying to test FRR logic for
> dealing with an unrecoverable ABEND.
> >
> >
> >
> > Charles
> >

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

Re: Programmatic way to create unrecoverable ABEND?

[Binyamin Dissen]

Well, you can CALLRTM your parent task. 

On Wed, 10 Apr 2019 13:39:35 -0700 Charles Mills  wrote:

:>Is there a reasonably easy way for a task to create an ABEND that ESTAE or
:>FRR will indicate is unrecoverable (SDWACLUP)? (I can't use console CANCEL
:>because I need the ABEND to occur within a fairly specific range of machine
:>instructions.) 

:>Will issuing a DETACH "for myself" do it? ABEND X'222',,SYSTEM won't do it,
:>right? S222 is normally unrecoverable, but not if done from a normal ABEND
:>macro?

:>The doc for DETACH says the issuer cannot have an EUT FRR. What if it does?

You cannot issue any SVCs at all under SRB mode or with an EUT FRR. Or with a
lock held. Result is 0F8.

:>I'm not just trying to make trouble. I am trying to test FRR logic for
:>dealing with an unrecoverable ABEND.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Job Posting Question

[Dazzo, Matt]

Are job postings allowed on this forum?

Thanks
Matt

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

Re: Job Posting Question

[John McKown]

On Thu, Apr 11, 2019 at 8:17 AM Dazzo, Matt <
00a854d4f854-dmarc-requ...@listserv.ua.edu> wrote:

> Are job postings allowed on this forum?
>

Generally yes. But only post once, unless replying to specific questions.
People generally want to know the company, location, details of the job,
and especially if they can work remotely when the job site is not local.

Oh, the above is my opinion, based on observation in the past. I am not an
authoritative source of information.



> Thanks
> Matt
>

-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


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: Programmatic way to create unrecoverable ABEND?

[Nick Jones]

For authorized code, you can use the CALLRTM service. This can kill the current 
task or any task you want.  You could have a test program that abends a task in 
your main program.  It also has options to disable retry.

Nick Jones

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

Re: Job completed notification not received TSO logon

[Jesse 1 Robinson]

Managing SYS1.BRODCAST is an endless, thankless job. Suggest moving to user 
logs. You will never look back. 

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elardus Engelbrecht
Sent: Wednesday, April 10, 2019 10:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Job completed notification not received TSO logon

Peter wrote:

>One of our user who has his userid in all the batch job in most of the 
>scheduled batch. So whenever he logs on he usually gets the notification of 
>job completion along with logon message.

>Nothing has changed in batch and notify parameters are all same.

>Not sure why it has stopped working

As Tom Brennan said, consider PROFILE WTPMSG MSGID INTERCOM

Your SYS1.BRODCAST may be full. Empty it out.

Other possibility is that your user is having another TSO session and that 
session is getting the messages.

Groete / Greetings
Elardus Engelbrecht

PS: Another weird reason I once got, is that the user may run a CLIST or 
something during the logon process which disables messaging or just send 
 on the user's behalf.

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

Re: Job Posting Question

[Seymour J Metz]

Yes. In the past the protocol was to check with the moderator, but I don't know 
whether there currently is one.

I second the suggestion that you indicate whether telecommuting is an option, 
and also suggest that you mention any available satellite offices for the 
position. 


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


From: IBM Mainframe Discussion List  on behalf of 
Dazzo, Matt <00a854d4f854-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, April 11, 2019 9:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Job Posting Question

Are job postings allowed on this forum?

Thanks
Matt

--
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: Programmatic way to create unrecoverable ABEND?

[Charles Mills]

Thanks all. CALLRTM RETRY=NO it is.

DC H'0'is simplicity itself, and works without fail, but S0Cx ABENDs are all 
recoverable. I need to test the SDWACLUP path.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nick Jones
Sent: Thursday, April 11, 2019 6:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Programmatic way to create unrecoverable ABEND?

For authorized code, you can use the CALLRTM service. This can kill the current 
task or any task you want.  You could have a test program that abends a task in 
your main program.  It also has options to disable retry.

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

Re: S/360

[Phil Smith III]

Alan Altmark wrote:

>The 3350 is from an era (not so long ago!) when there were no disk "arrays".  
>No striping.  The "location" information in the I/O architecture was physical. 
>If you took the media out of its housing, you could generally point to where 
>the data was located.  Want protection from drive errors?  Write it to another 
>drive.  The good news was that a drive failure was an isolated event.  The 
>drive "next door" wasn't affected.

 

>Today, the I/O architecture remains, but the mapping of logical to physical 
>location is an exercise left to the storage unit itself.  You can't really 
>point to where your data is except to point to the storage unit and say, 
>"Somewhere in there."  My experience is that when something dies, you lose 
>lots of host drives.  But physical drive failures have minimal impact due to 
>striping (RAID).

 

And I'm 99.9% sure that DASD capacity was determined by building the geometry 
and then trying various densities until error rates became unacceptable, then 
backing off slightly. Which would explain the weird, random sizes with each 
generation (until 3390, after which it went to arrays and became 
standardized-on what future generations will consider a weird size).


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

OpenSSH upgrade option

[Paul Jodlowski]

Is there a way to upgrade OpenSSH on z/OS v2.2?
Currently OpenSSH is at 6.4p1, I have been asked by our Network Security Team 
to upgrade to OpenSSH 7.4.

Cheers

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

Re: OpenSSH upgrade option

[Mark Jacobs]

I don't believe so. Latest version shipped with z/OS 2.3 is 6.4p1. IBM does 
issue APARs against it for any problems found that are applicable to OpenSSH on 
zOS. These is/was a list of them in one of the IBM OpenSSH manuals at one time.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Thursday, April 11, 2019 11:44 AM, Paul Jodlowski 
 wrote:

> Is there a way to upgrade OpenSSH on z/OS v2.2?
> Currently OpenSSH is at 6.4p1, I have been asked by our Network Security Team 
> to upgrade to OpenSSH 7.4.
>
> Cheers
>
> -
>
> 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: S/360

[Tom Brennan]

On 4/11/2019 8:40 AM, Phil Smith III wrote:

And I'm 99.9% sure that DASD capacity was determined by building the geometry 
and then trying various densities until error rates became unacceptable, then 
backing off slightly. Which would explain the weird, random sizes with each 
generation (until 3390, after which it went to arrays and became 
standardized-on what future generations will consider a weird size).


This reminds me of my first (junk pile) floppy disk drive back in the 
1970's for my home-made computer.  I had little money so I made my own 
controller out of a dozen chips and wrote some 8080 code to handle the 
I/O.  So the format of the disk was totally up to me, and not compatible 
with anything else.  I did just what you said and settled on about 3K 
per track.  But that was with no separate records or sectors - you had 
to read the entire track if you wanted any data, which I found out later 
(when I took my first computer class) wasn't too smart.


But yeah, I remember looking at my dad's oscilloscope and adjusting the 
timing and size until the end of a track didn't overlay the start of the 
same track :)


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

Re: Job completed notification not received TSO logon

[Cieri, Anthony]

I certainly agree with the move to User logs.
However, in the interim, there is a Broadcast Manager "package" on the 
CBT site (File 247) that may be of some help. If nothing else, there is a 
process documented for "expanding" the broadcast dataset.

Hth
Tony


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, April 11, 2019 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Job completed notification not received TSO logon

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]


Managing SYS1.BRODCAST is an endless, thankless job. Suggest moving to user 
logs. You will never look back. 

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elardus Engelbrecht
Sent: Wednesday, April 10, 2019 10:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Job completed notification not received TSO logon

Peter wrote:

>One of our user who has his userid in all the batch job in most of the 
>scheduled batch. So whenever he logs on he usually gets the notification of 
>job completion along with logon message.

>Nothing has changed in batch and notify parameters are all same.

>Not sure why it has stopped working

As Tom Brennan said, consider PROFILE WTPMSG MSGID INTERCOM

Your SYS1.BRODCAST may be full. Empty it out.

Other possibility is that your user is having another TSO session and that 
session is getting the messages.

Groete / Greetings
Elardus Engelbrecht

PS: Another weird reason I once got, is that the user may run a CLIST or 
something during the logon process which disables messaging or just send 
 on the user's behalf.

--
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: OpenSSH upgrade option

[Allan Staller]

Check the IBM support portal. I am sure that IBM supports (or will support) 
OpenSSH 7.4.
It is most likely in the maintenance stream somewhere in the maintenance stream.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Jodlowski
Sent: Thursday, April 11, 2019 10:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: OpenSSH upgrade option

Is there a way to upgrade OpenSSH on z/OS v2.2?
Currently OpenSSH is at 6.4p1, I have been asked by our Network Security Team 
to upgrade to OpenSSH 7.4.

Cheers

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

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

7340 Hypertape

[R.S.]

I'm looking for IBM 7340 photographs. Both drive and media (casette).
I visitet IBM site and found few images.

Any clue?

--
Radoslaw Skorupka
Lodz, Poland




==

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

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

mBank S.A. z siedzibą w Warszawie, ul. 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, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: S/360

[George Rodriguez]

A ways back, even I can't remember, I attended a Guide (it merged with
Share) meeting and after the conference was over, Jack (a friend I met at
Guide) and I went to the Boston Computer Museum. Once we got in, at a
distance I saw a sign S/360! I tell Jack "let's go see!" When we got there,
there were 3 S/360 on display, the model 20, 30 and 40. Those were the
first computer systems that I worked on in a place called IDPC
(International Data Processing Corp.) on Canal Street in New York. It was a
service bureau but it's main customer was Grove Press (a publishing
company). The 360/20 was used only to print large reports. Tape input
printer output. The 360/30 was used for all production runs and the 360/40
was used for testing. I remember a smart aleck programmer stopping the CPU,
raising and lowering the toggle switches on the model 40 just to impress
his buddies!

The link you included in this post brought me back to that time! I was
hired as an operator, but after they lost the Grove Press as a client, I
got to do programming, and systems work. That first job taught me so much!
After moving to south Florida for a job as an Operator, I finally got into
the career that I liked best! I became a Systems Programmer, first in DOS,
then VSE, then VSE/AF and then I finally joined the big boys and z/OS.

Thanks for bringing back old memories!

*George Rodriguez*

*Specialist II - IT Security*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-332*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District*


On Mon, Apr 8, 2019 at 10:43 AM Dave Jones  wrote:

> is now 55 years old, as of yesterday, April 7th. An interesting story
> about it:
>
> https://spectrum.ieee.org/tech-history/silicon-revolution/building-the-system360-mainframe-nearly-destroyed-ibm
> DJ
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

-- 






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








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

Test:

[John McKown]

Just a test of our Outlook server

-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


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: Job Posting Question

[Lizette Koehler]

I would also suggest using

[JOB] in the subject line

Those that do not want to view, will find that easy to delete.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Seymour J Metz
> Sent: Thursday, April 11, 2019 8:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Job Posting Question
> 
> Yes. In the past the protocol was to check with the moderator, but I don't
> know whether there currently is one.
> 
> I second the suggestion that you indicate whether telecommuting is an option,
> and also suggest that you mention any available satellite offices for the
> position.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on behalf of
> Dazzo, Matt <00a854d4f854-dmarc-requ...@listserv.ua.edu>
> Sent: Thursday, April 11, 2019 9:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Job Posting Question
> 
> Are job postings allowed on this forum?
> 
> Thanks
> Matt
> 
> --
> 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: When is an automatic DETACH issued for an IARV64 SHAREMEMOBJ?

[Binyamin Dissen]

On Tue, 9 Apr 2019 07:52:08 -0500 Steve Partlow  wrote:

:>I'll correct myself again:
:>SHAREMEMOBJ is cleaned up when the job step task (ASCBXTCB) terminates. I had 
misunderstood a previous test. I've confirmed that if a subtask issues the 
SHAREMEMOBJ and terminates, the address space still has access. We also tested 
that when the job step ends, it is no longer accessible. Is that what you are 
seeing? I don't see any evidence that this has changed since it was first 
introduced.

Yes, that is how I expected it to work.

I am seeing a failure at job end, but looking at LOGREC I see the problem
occurred earlier (a silent SRB abend attempting an access). 

Given that the SAHREMEMOBJ is issued in supervisor state with

  IARV64 REQUEST=SHAREMEMOBJ, 
USERTKN=RANGLIST, 
RANGLIST=@RANGLIST,   
ALETVALUE=2,  
COND=YES, 
MF=(E,OIARV64,COMPLETE) 

If the application calls the service to DETACH it, the call is recorded.

How can something else DETACH this object without knowing the token?  

Is there a standard way to trap this?  The problem cannot be reproduced at
will. Seems to only occur under TSO.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Job completed notification not received TSO logon

[Lizette Koehler]

Perhaps in SYSLOG you might see the message 
Mailbox is full.  If that is there, then your actions were correct


As stated by Others, USER Broadcast is easy to do and allows you to make this 
one users broadcast dataset really large.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Tom Brennan
> Sent: Wednesday, April 10, 2019 10:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Job completed notification not received TSO logon
> 
> profile intercom ?
> profile wtpmsg ?
> 
> I forgot which does what.
> 
> On 4/10/2019 9:15 PM, Peter wrote:
> > Hi
> >
> > One of our user who has his userid in all the batch job in most of the
> > scheduled batch. So whenever he logs on he usually gets the
> > notification of job completion along with logon message.
> >
> > Nothing has changed in batch and notify parameters are all same.
> >
> > Not sure why it has stopped working
> >
> > Is there any place I need to be looking in ?
> >
> > Peter
> >
> > --
> > 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: Job Posting Question

[Lizette Koehler]

However, if you are asking can I ask for a job on this list?  Probably not

However there are many sites that have job postings you search

Monster.com
Dice.com
Indeed.com
LinkedIN

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Lizette Koehler
> Sent: Thursday, April 11, 2019 11:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Job Posting Question
> 
> I would also suggest using
> 
> [JOB] in the subject line
> 
> Those that do not want to view, will find that easy to delete.
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Seymour J Metz
> > Sent: Thursday, April 11, 2019 8:04 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Job Posting Question
> >
> > Yes. In the past the protocol was to check with the moderator, but I
> > don't know whether there currently is one.
> >
> > I second the suggestion that you indicate whether telecommuting is an
> > option, and also suggest that you mention any available satellite
> > offices for the position.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Dazzo, Matt <00a854d4f854-dmarc-requ...@listserv.ua.edu>
> > Sent: Thursday, April 11, 2019 9:16 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Job Posting Question
> >
> > Are job postings allowed on this forum?
> >
> > Thanks
> > Matt
> >
> > --
> > 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: Programmatic way to create unrecoverable ABEND?

[Peter Relson]

CALLRTM TYPE=ABTERM,COMPCOD=xxx,RETRY=NO

or CANCEL your job (the CANCEL completion code, and any accompanying 
DETACH-of-subtasks completion codes, will not be retryable and thus will 
have SDWACLUP on).

RETRY=NO is not available via ABEND. CALLRTM requires authorization.

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: Programmatic way to create unrecoverable ABEND?

[Tom Marchant]

On Thu, 11 Apr 2019 14:31:09 -0400, Peter Relson wrote:

>CALLRTM TYPE=ABTERM,COMPCOD=xxx,RETRY=NO
>
>or CANCEL your job (the CANCEL completion code, and any accompanying 
>DETACH-of-subtasks completion codes, will not be retryable and thus will 
>have SDWACLUP on).
>
>RETRY=NO is not available via ABEND. CALLRTM requires authorization.

If you have automation that you can control, you could issue a WTO and have 
your automation trap the message and cancel the job.

-- 
Tom Marchant

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

Re: Address of CSECTs within a load module

[Joseph Reichman]

Yes I’m trying to trace every instruction on a 14 CSECT load module with a 
great number of self modified code instructions a breakpoint on an instruction 
that’s self modified blows up debug tool or test 

 

Test gives you the option of calling a program at a breakpoint using Call 
subcommand 

 

In that program I issue an Estae 

 

I can get the original first 2 bytes that was overlaid by test from the 
sysadata 

 

Since I will be using the sysadata more extensively I would ( for efficiency 
purpose move it to a data space ) 

 

 

 

From: Peter Relson  
Sent: Thursday, April 11, 2019 3:14 PM
To: Joseph Reichman 
Subject: Re: Address of CSECTs within a load module

 

Joseph,

Again I ask: what is the requirement? And what are the answers to my questions?

Is the requirement to produce output showing the execution of every instruction 
on some specific invocation of this specific module?

I choose not to get into further discussion without the answers.

TSO TEST is SVC 61 (decimal), thus 0A3D not 0A61
If you happen to be right that the modification is via an OI of x'F0' you would 
land with x'0AFD', not x'0AF1'..

What this would do is unknowable without examining the system to see whether 
SVC 253 is defined. And if it is defined, then you are potentially doing 
serious harm to the system.


So I look at program name if it’s not there then that field is the address of 
the RB in this case since it’s SVC chain the SVRB chain back the PRB I am able 
to get the RBOPSW and regs to do a retry write the proper info to systsprt via 
PUTX however to do the retry I have to get the original object most of the time 
it’s a nop some times it’s a CLC 

To get the original opcode I have to  read the sysadata 
But as I said the load module is composed of 14 CSECT I do a CSVQUERY before 
the the Estae to get the entry and length 


What is it that you are looking at when you write "I look at program name"? 
Which "field" are you talking about that is the address of the RB? 

Any of the techniques mentioned in the posts can be used to provide/gather the 
CSECT mapping before you do any of this. I think what you're saying is that you 
need that mapping in order to know within which CSECT the blow-up occurred so 
that you can locate the original opcode of the instruction. But couldn't you 
just load and save the entire load module before you set the TSO TEST break 
points? 

If you're going to read the SYSADATA, you can copy it wherever you want, 
whether that be an address space, storage above 2G, or leaving it where it is, 
if there is enough room.

Perhaps your site has available z/OS running under z/VM. Tracing a storage 
range with z/OS running under z/VM is trivial.

Did you consider using a SLIP IF trap for this module, with ACTION=TRACE to 
record the path via GTF? 

Peter



From:Joseph Reichman mailto:reichman...@gmail.com> >
To:Peter Relson mailto:rel...@us.ibm.com> >
Date:04/10/2019 04:12 PM
Subject:Re: Address of CSECTs within a load module

  _  




At the IRS we have very old huge Assembler programs we are trying to trace as 
they are trying to re-write them in Java 

One of the programs is a 14 CSECT load module it is filled with nops and other 
self modified instructions 

So typically the code is BYPASS NOP AROUND 

I have Rexx exec the generates st every sysadata type x’36’ ( machine 
instruction)
The following AT +disp. So AT +1036 (where;go) this writes out to systsprt when 
executed doing a trace 

I have coded a call subcommand on the very first AT in the program I issue an 
ESTAE 

At the nop the code would when the breakpoint is generated 0A61 6044 ( just an 
example ) when the code does OI BYPASS+1,X’F0’ this results rather then a call 
to test SVC 240 resulting in abend 
The PSW in SDWA is that of SVC 240 


So I look at program name if it’s not there then that field is the address of 
the RB in this case since it’s SVC chain the SVRB chain back the PRB I am able 
to get the RBOPSW and regs to do a retry write the proper info to systsprt via 
PUTX however to do the retry I have to get the original object most of the time 
it’s a nop some times it’s a CLC 

To get the original opcode I have to  read the sysadata 
But as I said the load module is composed of 14 CSECT I do a CSVQUERY before 
the the Estae to get the entry and length 

Also since I may have to dump variable via sysadata I had thought of moving the 
sysadata to a dataspace to make for an easier lookup access of the sysadata 

Was interested in your thoughts 

Thanks







On Apr 10, 2019, at 3:03 PM, Peter Relson <  
rel...@us.ibm.com> wrote:

Joe,

I'm still trying to understand better. I thought perhaps I would see you today.

I understand that you have a load module with 14 CSECTs and apparently you have 
ADATA for each of those 14 CSECTs.

Can you start over, describing the problem that you are trying to solve (not 
jumping down towards the problems you were h

Re: Help With IBM-MAIN

[Paul Gilmartin]

(Cross-posting.  This came via ASSEMBLER-LIST):
On 2019-04-11, at 10:57:08, esst...@juno.com wrote:

> Hi, I seem to be having a problem with IBM MAIN.
> Every time I respond to a post, it is returned to me from 
> mailer-dae...@smtpout01.dca.untd.com  
> Unfortunately, your mail was not delivered to the following 
> address::
> Sorry, I couldn't find any host named listserv.ua.edu. (#5.1.2)
> . 
This seems to be a problem with the OP's DNS.  Can't reprodude.
Finger-pointing time:
544 $ nslookup
> listserv.ua.edu
Server: 10.128.128.128
Address:10.128.128.128#53

Non-authoritative answer:
Name:   listserv.ua.edu
Address: 130.160.0.24
> 
> set query=mx
> listserv.ua.edu
Server: 10.128.128.128
Address:10.128.128.128#53
(Seems to be a DHCP server, but I get similar results from OpenDNS.)

Non-authoritative answer:
listserv.ua.edu mail exchanger = 10 mx1.ua.edu.
listserv.ua.edu mail exchanger = 10 mx2.ua.edu.

Authoritative answers can be found from:
> exit

> Is there An Administrator or Support email for for IBM-MAIN@LISTSERV.UA.EDU
> that I can contact.
> . 
Is there still a Darren?

> Paul D'Angelo

-- gil

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

Re: OpenSSH upgrade option

[Paul Jodlowski]

Mark
ok thanks will take a look

Cheers

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs
Sent: Thursday, April 11, 2019 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OpenSSH upgrade option

I don't believe so. Latest version shipped with z/OS 2.3 is 6.4p1. IBM does 
issue APARs against it for any problems found that are applicable to OpenSSH on 
zOS. These is/was a list of them in one of the IBM OpenSSH manuals at one time.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Thursday, April 11, 2019 11:44 AM, Paul Jodlowski 
 wrote:

> Is there a way to upgrade OpenSSH on z/OS v2.2?
> Currently OpenSSH is at 6.4p1, I have been asked by our Network Security Team 
> to upgrade to OpenSSH 7.4.
>
> Cheers
>
> --
> --
> -
>
> 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: OpenSSH upgrade option

[Paul Gilmartin]

On Thu, 11 Apr 2019 16:01:15 +, Mark Jacobs wrote:

>I don't believe so. Latest version shipped with z/OS 2.3 is 6.4p1. IBM does 
>issue APARs against it for any problems found that are applicable to OpenSSH 
>on zOS. These is/was a list of them in one of the IBM OpenSSH manuals at one 
>time.
> 
It's reasonable that Security Team look first at the version number and
reject immediately if it doesn't meet criteria.  They haven't resource to
examine every APAR cover letter (and integrity APARs may not be public.)

Would IBM do better to apply IBM patches to the newest distribution rather
than trying to upgrade an outdated version with APARs?  There's yet no
assurance that IBM's patching won't regress a needed security patch.

Why must IBM patch?  Is EBCDIC a culprit?  I hate EBCDIC!


>‐‐‐ Original Message ‐‐‐
>On Thursday, April 11, 2019 11:44 AM, Paul Jodlowski wrote:
>
>> Is there a way to upgrade OpenSSH on z/OS v2.2?
>> Currently OpenSSH is at 6.4p1, I have been asked by our Network Security 
>> Team to upgrade to OpenSSH 7.4.

-- gil

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

Re: S/360

[Anne & Lynn Wheeler]

li...@akphs.com (Phil Smith III) writes:
> And I'm 99.9% sure that DASD capacity was determined by building the
> geometry and then trying various densities until error rates became
> unacceptable, then backing off slightly. Which would explain the
> weird, random sizes with each generation (until 3390, after which it
> went to arrays and became standardized-on what future generations will
> consider a weird size).

error detecting/correcting started moving to fixed block sizes ... aka,
FBA ... even 3380 had fixed cell size for error correcting ... however
POK's favorite son operating system has had difficulty weening off
CKD. There hasn't been real CKD made for decades, all being simulated on
industry standard fixed block disks.

the recent move from 512byte to 4096byte fixed blocks is largely
motivated by error correct.
fixed-block
https://en.wikipedia.org/wiki/Fixed-block_architecture
FBA 512->4096 migration
https://en.wikipedia.org/wiki/Advanced_Format

original "raid" patent was by IBMer in the 70s
https://en.wikipedia.org/wiki/RAID

first use was IBM S/38 ... because common single disk failure took out
everything. part of S/38 organization simplification was scatter
allocation across all disks (treated as single filesystem) ... and
therefor any single disk failure took out the whole system ... all disks
had to be backed up as single unit/pool (because of scatter allocation)
... and any recovery required complete system restore.

Note originally 3380 had 20 track spacings between each data-track ...
flying lower met adjacent tracks had less interferance and cut the data
track spacing in half (double-density with twice the number of
tracks/cylinders), then spacing cut again for triple-density (three
times the number of tracks/cylinders).

trivia: I got dragged into idea the IBM "father of risc" had for
"wide-head" 16 adjacent datatracks with servo tracks on either side
... read/write all 16 simultaneously (while tracking servo tracks on
both sides of the data tracks). This was in 3090 and 3380 triple-density
time-frame. The problem was that the IBM mainframe data transfer is
16*3mbytes/sec or 48mbytes/sec. Even when ESCON is announced in 1990
(with ES/9000, when ESCON is alread obsolete) it is only 17mbytes/sec.

little more trivia: 70s, engineer was running "air bearing" (floating
heads) simulation (part of reducing head flying height enabling greater
densities) on research 370/195 ... but only getting a couple turn
arounds a month (even with priority designation). I had done enhanced
bullet proof, never fail operating system for bldg 14&15 allowing them
moving from stand-alone testing to doing concurrent development testing
under operating system. Turns out even concurrent testing only used
percent or two of processor ... so we set up private online service
using the machines. Bldg15 had 2ndor3rd engineering 3033 from POK, and
we get the air bearing simulation moved over to the 3033, where he can
get several turn-arounds a day (even tho 3033 has little less than 1/2
processing of 370/195).

more trivia: I had done channel-extender support in 1980 for STL that
was moving 300 people from IMS group to offsite bldg ... but the POK
people playing with what becomes ESCON ... blocks it release to
customer. In 1988, I'm asked to help LLNL standardize some serial stuff
they are playing with which quickly becomes fiber-channel standard,
including some stuff that I had one in 1980 (FCS, originally
100mbyte/sec concurrent in both directions).

Then some POK engineers get involved in FCS and define a protocol
that radically cuts the native throughput ... which is eventually
released as FICON. Most recent published FICON numbers I've seen
is peak I/O z196 test that used 104 FICON (running over 104 FCS)
getting 2M IOPS. About the same time there was FCS announced
for E5-2600 blade claiming over million IOPS (two such FCS,
getting more throughput than 104 FICON running over 104 FCS).

-- 
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: S/360

[Mike Myers]

George:

Your comment reminded me of an experience I had sometime back around 
1967. I was working for IBM in Poughkeepsie at the time and had some 
hands-on time on a 360/40. Nearby at another system was Don Ludlow, who 
was reputed to be the primary designer of IOS for OS/360. He was going 
through the switches changing code and single stepping while watching a 
tape drive to see if it was reacting as desired. It was an obvious 
exercise in doing things directly in machine language, which was pretty 
impressive to a new assembler programmer like myself at the time.


Mike Myers
Mentor Services Corporation
Goldsboro, NC 27530

On 4/11/19 1:42 PM, George Rodriguez wrote:

A ways back, even I can't remember, I attended a Guide (it merged with
Share) meeting and after the conference was over, Jack (a friend I met at
Guide) and I went to the Boston Computer Museum. Once we got in, at a
distance I saw a sign S/360! I tell Jack "let's go see!" When we got there,
there were 3 S/360 on display, the model 20, 30 and 40. Those were the
first computer systems that I worked on in a place called IDPC
(International Data Processing Corp.) on Canal Street in New York. It was a
service bureau but it's main customer was Grove Press (a publishing
company). The 360/20 was used only to print large reports. Tape input
printer output. The 360/30 was used for all production runs and the 360/40
was used for testing. I remember a smart aleck programmer stopping the CPU,
raising and lowering the toggle switches on the model 40 just to impress
his buddies!

The link you included in this post brought me back to that time! I was
hired as an operator, but after they lost the Grove Press as a client, I
got to do programming, and systems work. That first job taught me so much!
After moving to south Florida for a job as an Operator, I finally got into
the career that I liked best! I became a Systems Programmer, first in DOS,
then VSE, then VSE/AF and then I finally joined the big boys and z/OS.

Thanks for bringing back old memories!

*George Rodriguez*

*Specialist II - IT Security*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-332*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District*


On Mon, Apr 8, 2019 at 10:43 AM Dave Jones  wrote:


is now 55 years old, as of yesterday, April 7th. An interesting story
about it:

https://spectrum.ieee.org/tech-history/silicon-revolution/building-the-system360-mainframe-nearly-destroyed-ibm
DJ

--
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: Help With IBM-MAIN

[Edward Finnell]

Last time I saw them at the supermarket, they were having health problems. 
Haven't heard or seen Darren since. AFAIK he's still at dar...@ua.edu but my 
emails have been unanswered.

Definitely a DNS problem. Might try the web interface 
atlistserv.ua.edu/archives/ibm-main.html if you can get to it.In a message 
dated 4/11/2019 2:54:45 PM Central Standard Time, 
000433f07816-dmarc-requ...@listserv.ua.edu writes:
Is there still a Darren?

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

Re: Help With IBM-MAIN

[Chris Hoelscher]

No one wants to switch Darrens - just ask Samantha

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Edward Finnell
Sent: Thursday, April 11, 2019 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Help With IBM-MAIN

Last time I saw them at the supermarket, they were having health problems. 
Haven't heard or seen Darren since. AFAIK he's still at dar...@ua.edu but my 
emails have been unanswered.

Definitely a DNS problem. Might try the web interface 
atlistserv.ua.edu/archives/ibm-main.html if you can get to it.In a message 
dated 4/11/2019 2:54:45 PM Central Standard Time, 
000433f07816-dmarc-requ...@listserv.ua.edu writes:
Is there still a Darren?

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

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

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

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

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

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

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

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

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


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

Re: S/360

[WILLIAM H BLAIR]

On April 11, 2019 at 4:29 PM Mike Myers wrote:
| an experience I had sometime back around 1967. 
| Nearby at another system was Don Ludlow, who 
| was reputed to be the primary designer of IOS 
| for OS/360. 

Donald Ludlow WAS indeed the principal author
of OS/360 IOS. In fact, he wrote ALL of the
code that actually survived and was shipped.
There was another gentleman who CLAIMED to be
the "author" of IOS (whom I knew personally), 
but everything he did had to be redone by Don 
(or mostly, in fact, simply thrown away).

Mr. Ludlow moved to Raleigh, NC and worked on
SPF (as it was then called), incorporating the
SUPERC FDP into ISPF/PDF as what we know today 
as options 3.12, 3.13, and 3.14 (a "recent" 
enhancement adds 3.15).

He wrote some of the slickest, tightest S/360
Assembler code I've ever seen or had to modify
learning a lot about device channel programming
from it (and from him).

William Blair
Houston, TX

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

Re: S/360

[Anne & Lynn Wheeler]

wmhbl...@comcast.net (WILLIAM H BLAIR) writes:
> Donald Ludlow WAS indeed the principal author
> of OS/360 IOS. In fact, he wrote ALL of the
> code that actually survived and was shipped.
> There was another gentleman who CLAIMED to be
> the "author" of IOS (whom I knew personally), 
> but everything he did had to be redone by Don 
> (or mostly, in fact, simply thrown away).
>
> Mr. Ludlow moved to Raleigh, NC and worked on
> SPF (as it was then called), incorporating the
> SUPERC FDP into ISPF/PDF as what we know today 
> as options 3.12, 3.13, and 3.14 (a "recent" 
> enhancement adds 3.15).
>
> He wrote some of the slickest, tightest S/360
> Assembler code I've ever seen or had to modify
> learning a lot about device channel programming
> from it (and from him).

this is reference to getting request to find people that had been
involved in the decision to convert all 370s to virtual memory (i.e. MVT
storage management was so bad, that region sizes typically had to be
four times larger than actually used, as result typical 1mbyte 370/165
only ran four regions, going to virtual memory, could get four times as
many regions with little or no paging)
http://www.garlic.com/~lynn/2011d.html#73

Ludlow was doing initial implementation of MVT for VS2/SVS ... work done
on 360/67. Basically not that different of running MVT in a 16mbyte
cp/67 virtual machine. Build table for single 16mbyte virtual address
space at startup and a little bit of page I/O (not hihgly optimized
because anticipating little or no actual paging). Biggest amount of code
was same as CP/67 ... (EXCP/SV0) got channel programs built with virtual
addresses ... and so had to make a channel program copy replacing the
virtual addresses with real addresses ... and basically borrowed the
code from CP/67 and hacked into EXCP.

Slight topic drift, in my previous post in this thread, I mentioned
doing bullet proof input/output supervisor for doing bldg14 disk
engineering testing and bldg15 product test
http://www.garlic.com/~lynn/2019h.html#52 S/360

They had previously tried MVS, but in that environment MVS had 15min
MTBF requiring manual re-ipl. This is later email just before 3380
customer ship ... FE had regression test of 57 simulated errors that
were expected to occur in normal operations. MVS was still failing in
all 57 error (requiring manual re-ipl) with no indication of what cause
the failure in 2/3rds of the case ... old email
http://www.garlic.com/~lynn/2007.html#email801015

I did an internal report of all the changes/fixes needed to support any
amount of on-demand concurrent dasd development testing (previously they
were running 7x24 pre-scheduled stand-alone testing) ... and
(unfortunately) happened to mention the MVS 15min MTBF ... which brought
down the wrath of the MVS group on my head (I was told initially they
tried to have me separated from the IBM company).

-- 
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: Help With IBM-MAIN

[Paul Gilmartin]

On Thu, 11 Apr 2019 20:48:51 +, Edward Finnell wrote:
>...
>Definitely a DNS problem. ...
>
I said, "finger-pointing."  CenturyLink is giving me an incorrect IP for one
host to which I can readily connect from other hotspots.

CL Support blamed my computer (I tried more than one), my browser
(I tried more than one), had me reset my router (PITA to recover),
blamed the site I was trying to access, http://example.com/
...

I did a "whois" on their DNS and emailed their support address.
They bucked me to a 1-800 number I haven't tried yet.

Grrr... they're not supposed to blame the customer.

-- gil

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

Lousy error from HLASM in USS

[Phil Smith III]

Easy to reproduce. Create an assembler input deck with a line longer than 80 
bytes; it can even be a single line:
*   
x
(that x is in column 81)
Put it in a USS directory as, say, bad.asm. Now cd to that directory in a shell 
and issue:
as ./bad.asm

You'll get this lovely error:
as ./bad.asm
** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on 
SYS00011 data set
  ,PHS3,*OMVSEX ,OMVS,*,SYS00011,GET   ,WRONG LEN 
RECRD,00,QSAM S
,***,***,01,0008002C,,**,
FSUM3401 The assemble step ended with rc = 20.

Really? That's somebody's idea of a coherent error? After much tinkering, it 
turns out that WRONG LEN RECRD means "I found a record too long" (was there a 
shortage of capital Os that day?), and in
,***,***,01,0008002C,,**,
the 01 is the offending record number.

Needless to say, we did not find this on record 01 of a bogus assembler 
file. Instead, we found it on record n of an included macro, which took far 
longer to track down. And yes, the number shown in that case is the record 
number *of the included macro*, whose name appears nowhere in the error. So the 
error isn't even correct in that case, as it appears to be saying that record n 
of the input file is wrong, when it's actually record n of the included macro, 
which of course could be many layers deep.

Errors, kids, should be illuminating. In this case, it knew everything it 
needed to: the offending macro name, the offending record number, and what was 
wrong with it. It could have just said that, but no, it had to be obscure.

I'll admit that this is no worse than a lot of z/OS errors. That's no excuse; 
this isn't 1964.

...phsiii (grumpy after wasting time on this)

--
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: Lousy error from HLASM in USS

[Charles Mills]

Post to the  HLASM list which the development lead monitors. He is very 
responsive. CharlesSent from a mobile; please excuse the brevity.
 Original message From: Phil Smith III  Date: 
4/11/19  4:47 PM  (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Lousy error 
from HLASM in USS Easy to reproduce. Create an assembler input deck with a line 
longer than 80 bytes; it can even be a single line:*
   x(that x is in column 81)Put 
it in a USS directory as, say, bad.asm. Now cd to that directory in a shell and 
issue:as ./bad.asmYou'll get this lovely error:as ./bad.asm** ASMA999U Assembly 
terminated - SYNAD Exit taken - Permanent I/O error on SYS00011 data set
  ,PHS3    ,*OMVSEX ,OMVS,*,SYS00011,GET   ,WRONG LEN RECRD,00,QSAM 
S,***,***,01,0008002C,    ,**,FSUM3401 The assemble step ended 
with rc = 20.Really? That's somebody's idea of a coherent error? After much 
tinkering, it turns out that WRONG LEN RECRD means "I found a record too long" 
(was there a shortage of capital Os that day?), and 
in,***,***,01,0008002C,    ,**,the 01 is the offending 
record number.Needless to say, we did not find this on record 01 of a 
bogus assembler file. Instead, we found it on record n of an included macro, 
which took far longer to track down. And yes, the number shown in that case is 
the record number *of the included macro*, whose name appears nowhere in the 
error. So the error isn't even correct in that case, as it appears to be saying 
that record n of the input file is wrong, when it's actually record n of the 
included macro, which of course could be many layers deep.Errors, kids, should 
be illuminating. In this case, it knew everything it needed to: the offending 
macro name, the offending record number, and what was wrong with it. It could 
have just said that, but no, it had to be obscure.I'll admit that this is no 
worse than a lot of z/OS errors. That's no excuse; this isn't 1964phsiii 
(grumpy after wasting time on 
this)--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: Lousy error from HLASM in USS

[Paul Gilmartin]

That should have been cross-posted to ASSEMBLER-LIST and MVS-OE.

On Thu, 11 Apr 2019 19:47:56 -0400, Phil Smith III wrote:

>Easy to reproduce. Create an assembler input deck with a line longer than 80 
>bytes; it can even be a single line:
>*  
> x
>(that x is in column 81)
>Put it in a USS directory as, say, bad.asm. Now cd to that directory in a 
>shell and issue:
>as ./bad.asm
>
>You'll get this lovely error:
>as ./bad.asm
>** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on 
>SYS00011 data set
>  ,PHS3,*OMVSEX ,OMVS,*,SYS00011,GET   ,WRONG LEN 
> RECRD,00,QSAM S
>,***,***,01,0008002C,,**,
>FSUM3401 The assemble step ended with rc = 20.
> 
That's from SYNADAF.  I'm very familiar with it.  That doesn't mean I like it.
You can get much the same in batch JCL with IEBGENER SYSUT1.

>Really? That's somebody's idea of a coherent error? After much tinkering, it 
>turns out that WRONG LEN RECRD means "I found a record too long" (was there a 
>shortage of capital Os that day?), and in
>,***,***,01,0008002C,,**,
>the 01 is the offending record number.
> 
That message format was designed when storage was a million times
as expensive as today.  But to change it might conflict with automated
operations, or not fit in LRECL=121.

>Needless to say, we did not find this on record 01 of a bogus 
>assembler file. Instead, we found it on record n of an included macro, which 
>took far longer to track down. ...
>
Macro?  the command you cited seems to show it as primary input.

SYS00011?  I'd expect SYSIN or SYSLIB.  Does "as" invoke HLASM with
an alternate DDNAME list?

> ... And yes, the number shown in that case is the record number *of the 
> included macro*, whose name appears nowhere in the error. So the error isn't 
> even correct in that case, as it appears to be saying that record n of the 
> input file is wrong, when it's actually record n of the included macro, which 
> of course could be many layers deep.
>
>Errors, kids, should be illuminating. In this case, it knew everything it 
>needed to: the offending macro name, the offending record number, and what was 
>wrong with it. It could have just said that, but no, it had to be obscure.
>
>I'll admit that this is no worse than a lot of z/OS errors. That's no excuse; 
>this isn't 1964.
>
But it must remain compatible with 1964.

>...phsiii (grumpy after wasting time on this)
>
Me grumpy?  No, I'm merely sarcastic.

-- gil

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

Re: OpenSSH upgrade option

[Kirk Wolf]

z/OS OpenSSH is currently based on OpenSSH 6.4, but IBM also uses the
maintenance stream to include security patches from OpenSSH beyond 6.4.
It isn't clean why your Network Security Team is asking for 7.4 - for a new
feature or for a security fix?If for the latter, you can check the PTFs
to see if a particular patch is available, or check the IBM Security
Portal, or open a PMR.

FWIW, IBM has pre-announced that z/OS V2R4 will include an upgrade to
OpenSSH 7.6:
https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/3/897/ENUS219-013/index.html&request_locale=en


On Thu, Apr 11, 2019 at 10:44 AM Paul Jodlowski <
pgjodlow...@nationalindemnity.com> wrote:

> Is there a way to upgrade OpenSSH on z/OS v2.2?
> Currently OpenSSH is at 6.4p1, I have been asked by our Network Security
> Team to upgrade to OpenSSH 7.4.
>
> Cheers
>
> --
> 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