date:20170313

Don't ask me; ask DB2. 

Seriously, formatting DB2 host variables. I don't get to control their format.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Monday, March 13, 2017 6:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C fprintf() format code for 32-bit float?

It’s a silly question, but why are you using single precession floating point.

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

Re: Jollygiant support (QWS3270 PLUS vendor) has not responded to several emails

2017-03-13 Thread Steve Horein

That's the emulator I use at work - what's the issue you're having?
Sporadic disconnect that outright closes the application?
Communication is not my area of responsibility (anymore), so I have not
attempted to contact them...

On Mon, Mar 13, 2017 at 2:40 PM, Binyamin Dissen  wrote:

> Has anyone had good response from them in the last few months?
>
> --
> 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
>

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

Re: C fprintf() format code for 32-bit float?

2017-03-13 Thread Steve Beaver

It’s a silly question, but why are you using single precession floating point.

The ONLY times I have used floating point is having to do with extremely large 
numbers or some extremely small number of very fine precision
Used in CAD/CAM

Steve

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, March 13, 2017 6:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C fprintf() format code for 32-bit float?

OK. I just coded a static_cast on @Gil's suggestion. Should not hurt anything; 
actually makes the code a little clearer, except for all the <> and () LOL.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Monday, March 13, 2017 4:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C fprintf() format code for 32-bit float?

I believe that formatting types e/E, f/F and g/G will all handle float, double 
and long double without casts.

Example CELEBF30 available in the Runtime Library Reference under:

Library Functions
fprintf(), printf() and sprint() - Format and write data

Shows a float printed with g and G specifiers with no cast.

--
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: C fprintf() format code for 32-bit float?

2017-03-13 Thread David Crayford

Because forintf() has a variadic argument list the float is converted to a 
double. This is called "default argument promotions". You may want to dig out a 
copy of the C99 standard. 

> On 14 Mar 2017, at 7:55 am, Charles Mills  wrote:
> 
> OK. I just coded a static_cast on @Gil's suggestion. Should not hurt 
> anything; actually makes the code a little clearer, except for all the <> and 
> () LOL.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Farley, Peter x23353
> Sent: Monday, March 13, 2017 4:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: C fprintf() format code for 32-bit float?
> 
> I believe that formatting types e/E, f/F and g/G will all handle float, 
> double and long double without casts.
> 
> Example CELEBF30 available in the Runtime Library Reference under:
> 
> Library Functions
> fprintf(), printf() and sprint() - Format and write data
> 
> Shows a float printed with g and G specifiers with no cast.
> 
> --
> 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: curious: why S/360 & decendants are "big endian".

2017-03-13 Thread Mike Schwab

English is a pidgin language, combined from the three Celtic languages
on the British Isles and 4 norther European languages from northern
Europe.

http://learningenglish.voanews.com/a/how-english-evolved-into-a-modern-language/1575959.html
https://www.englishclub.com/history-of-english/
http://www.thehistoryofenglish.com/


On Mon, Mar 13, 2017 at 5:08 PM, Mike Myers  wrote:
> All:
>
> Many years ago, I aided Karl Finkemeyer, an IBMer on assignment in NY at the
> time from Germany, and a great friend of mine to immigrate to the US. He
> eventually became a citizen, and a director at Fidelity Investments. During
> the immigration process, his daughter, who by that time, spoke fluent
> English and German, showed me a paper which made fun of pronunciation of
> words in English. Unfortunately, I did not obtain a copy, but this
> discussion made me go and look on-line, hoping to find it.
>
> Although this is not Friday, for those of you that like language (especially
> English), Google "English pronunciation poem" or "English is a crazy
> language". Lots of good chuckles for language fans. My favorites were:
>
> https://archive.org/stream/EnglishCrazyLanguageEssay/English%20Crazy%20Language%20Essay_djvu.txt
> http://www.thepoke.co.uk/2011/12/23/english-pronunciation/
> the one above as a poem: http://ncf.idallen.com/english.html
>
> Mike Myers
> Mentor Services Corporation
> Goldsboro, NC 27530
> (919) 341-5210 - office
>
>
>  On 03/13/2017 05:28 PM, Jesse 1 Robinson wrote:
>>
>> "English is a _stupid_ language." Every language is stupid in its own way,
>> some more so than others. If English were rational and simple, everybody
>> would be using it. ;-)
>>
>> .
>> .
>> J.O.Skip Robinson
>> Southern California Edison Company
>> Electric Dragon Team Paddler
>> SHARE MVS Program Co-Manager
>> 323-715-0595 Mobile
>> 626-543-6132 Office ⇐=== NEW
>> robin...@sce.com
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of John McKown
>> Sent: Thursday, March 09, 2017 1:56 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: (External):Re: curious: why S/360 & decendants are "big endian".
>>
>> On Thu, Mar 9, 2017 at 3:50 PM, Paul Gilmartin <
>> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>
>>> On Thu, 9 Mar 2017 15:18:03 -0600, Joel C. Ewing wrote:
>>>
>>> It's cultural.  Consider how Europeans write dates.
>>>  https://xkcd.com/1179/
>>>
>>> And significance is subjective.  About 10 years ago, I asked an
>>> astronomer, "When is the equinox on Saturn?"
>>> "Nine fourteen." (orally)
>>>
>>> September 14th seemed too soon until I pondered and realized she
>>> meant, "September, 2014."
>>>
>>> In Boulder, CO, in the '60s (some century), all local phone numbers
>>> were (303)442-xxx or (303)443-.  People routinely exchanged phone
>>> numbers (orally) by only the last 5 digits.  The first 5 were, if not
>>> insignificant, inconsequential.
>>>
>>> Computer science professor W.M. Waite used to say, "Top of memory,"
>>> pointing to the floor, and "Bottom of memory", pointing to the
>>> ceiling.
>>>
>> Same in other books I've seen. Why? Probably because we write from top to
>> bottom. We write the lowest first, at the top, and the highest last, at the
>> bottom. And then we confuse everybody by calling them "ascending" memory
>> addresses while writing them in a descending pattern. English is a _stupid_
>> language.
>>
>>
>>
>>> -- gil
>>>
>>>
>> --
>> "Irrigation of the land with seawater desalinated by fusion power is
>> ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
>>
>> Maranatha! <><
>> John McKown
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send email
>> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>> --
>> 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



-- 
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: C fprintf() format code for 32-bit float?

OK. I just coded a static_cast on @Gil's suggestion. Should not hurt anything; 
actually makes the code a little clearer, except for all the <> and () LOL.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Monday, March 13, 2017 4:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C fprintf() format code for 32-bit float?

I believe that formatting types e/E, f/F and g/G will all handle float, double 
and long double without casts.

Example CELEBF30 available in the Runtime Library Reference under:

Library Functions
fprintf(), printf() and sprint() - Format and write data

Shows a float printed with g and G specifiers with no cast.

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

Re: C fprintf() format code for 32-bit float?

That is certainly a thought. It should promote I guess. But I'd be more 
comfortable with a native format code. I figured maybe 'hg' by analogy to 'hd' 
and so forth, but the manual says nothing about h with g.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, March 13, 2017 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C fprintf() format code for 32-bit float?

On Mon, 13 Mar 2017 15:53:20 -0700, Charles Mills wrote:

>Apologies for the basic question. About everything I know about 
>floating point could be engraved on the back of a postage stamp.
>
>For C fprintf() and friends, how do I specify the formatting of a 
>32-bit floating point number (C type "float" as opposed to "double))? 
>e, f or g with some modifier?
> 
Can you cast to (double)?
MAIN

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

Re: C fprintf() format code for 32-bit float?

2017-03-13 Thread Farley, Peter x23353

I believe that formatting types e/E, f/F and g/G will all handle float, double 
and long double without casts.

Example CELEBF30 available in the Runtime Library Reference under:

Library Functions
fprintf(), printf() and sprint() - Format and write data

Shows a float printed with g and G specifiers with no cast.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, March 13, 2017 7:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C fprintf() format code for 32-bit float?

On Mon, 13 Mar 2017 15:53:20 -0700, Charles Mills wrote:

>Apologies for the basic question. About everything I know about 
>floating point could be engraved on the back of a postage stamp.
>
>For C fprintf() and friends, how do I specify the formatting of a 
>32-bit floating point number (C type "float" as opposed to "double))? 
>e, f or g with some modifier?
> 
Can you cast to (double)?

--

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

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

Re: C fprintf() format code for 32-bit float?

2017-03-13 Thread Paul Gilmartin

On Mon, 13 Mar 2017 15:53:20 -0700, Charles Mills wrote:

>Apologies for the basic question. About everything I know about floating
>point could be engraved on the back of a postage stamp.
>
>For C fprintf() and friends, how do I specify the formatting of a 32-bit
>floating point number (C type "float" as opposed to "double))? e, f or g
>with some modifier?
> 
Can you cast to (double)?

-- gil

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

C fprintf() format code for 32-bit float?

Apologies for the basic question. About everything I know about floating
point could be engraved on the back of a postage stamp.

 

For C fprintf() and friends, how do I specify the formatting of a 32-bit
floating point number (C type "float" as opposed to "double))? e, f or g
with some modifier?

 

I am RTFM with little success.

 

Charles Mills



 


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

Re: curious: why S/360 & decendants are "big endian".

2017-03-13 Thread Paul Gilmartin

On 2017-03-13, at 15:46, Jesse 1 Robinson wrote:

> I've had the scroll up-or-down conversation many times over the years since I 
> learned that my colleagues actually disagreed over which usage is 'correct'. 
> I'm convinced that it's a matter of mental perception embodied in language, 
> not merely a linguistic quirk adopted willy-nilly. 
> 
> Some people truly perceive scrolling on a 3270 screen as a rectangular window 
> moving up or down over a fixed body of text nailed to the background. Others 
> perceive the text itself as moving up or down--like a rolled scroll--behind a 
> rectangular window nailed in front. People will argue their view, and their 
> terminology, quite emphatically.
> 
> The scroll bar on a web screen introduces another wrinkle. You move the bar 
> down to see the bottom of the data, up to see the top. Case closed? I think 
> not. 
>  
Of course not closed.  Earliest full-screen editors followed the
paradigm of moving the window with the file as substrate.  Scroll
bars were consistent with this.

Smartphones and tablets did away with scroll bars, so the natural
paradigm is to drag the subject (file or image) behind the widow.

Recent MacOS releases have switched from move-the-window to
move-the-subject as default, consistent with iOS, but left it
a Preferences option.

Text arrows are yet another wrinkle.  Uniformly (except on brain-dead
block mode terminals), when the cursor collides with the window frame,
the display scrolls to keep the cursor visible.  Scrolling in the
opposite direction is the only thing that would be even dumber than
the common toroidal 2-space in which the cursor moves to the opposite
edge of the screen.

MacOS Preview has dithered.  Early versions were drag-the subject.  Then
it switched to drag-the window.  I think latest versions are back to
drag-the-subject (but I don't have one yet).

-- gil

> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Anne & Lynn Wheeler
> Sent: Thursday, March 09, 2017 4:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: curious: why S/360 & decendants are "big endian".
> 
> john.archie.mck...@gmail.com (John McKown) writes:
>> Same in other books I've seen. Why? Probably because we write from 
>> top to bottom. We write the lowest first, at the top, and the highest 
>> last, at the bottom. And then we confuse everybody by calling them 
>> "ascending" memory addresses while writing them in a descending 
>> pattern. English is a _stupid_ language.
> 
> in the 70s as fullscreen 3270s editors were starting to appear, there was big 
> editor culture wars over up & down.
> 
> prior to that, line-editing was from perspective of the user ...  "up"
> moving towards the "top" (beginning) of the file and "down" was moving 
> towards the "bottom" (end) of the file.
> 
> The side that had enhanced previous line editors to support 3270 fullscreen 
> and preserved the up/down orientation (meaning).
> 
> A couple of "new" 3270 fullscreen editors, done from scratch, insisted on 
> "up" was from the orientation of the program (not the user), the program 
> would move the file up ... towards the bottom of the file or move the file 
> "down" ... towards the top of the file (difference was` whether up/down was 
> from the human perspective or the program/software perspective).
> 
> --
> 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: curious: why S/360 & decendants are "big endian".

2017-03-13 Thread Mike Myers


All:

Many years ago, I aided Karl Finkemeyer, an IBMer on assignment in NY at 
the time from Germany, and a great friend of mine to immigrate to the 
US. He eventually became a citizen, and a director at Fidelity 
Investments. During the immigration process, his daughter, who by that 
time, spoke fluent English and German, showed me a paper which made fun 
of pronunciation of words in English. Unfortunately, I did not obtain a 
copy, but this discussion made me go and look on-line, hoping to find it.


Although this is not Friday, for those of you that like language 
(especially English), Google "English pronunciation poem" or "English is 
a crazy language". Lots of good chuckles for language fans. My favorites 
were:


https://archive.org/stream/EnglishCrazyLanguageEssay/English%20Crazy%20Language%20Essay_djvu.txt
http://www.thepoke.co.uk/2011/12/23/english-pronunciation/
the one above as a poem: http://ncf.idallen.com/english.html

Mike Myers
Mentor Services Corporation
Goldsboro, NC 27530
(919) 341-5210 - office

 On 03/13/2017 05:28 PM, Jesse 1 Robinson wrote:

"English is a _stupid_ language." Every language is stupid in its own way, some 
more so than others. If English were rational and simple, everybody would be using it. ;-)

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, March 09, 2017 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: curious: why S/360 & decendants are "big endian".

On Thu, Mar 9, 2017 at 3:50 PM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:


On Thu, 9 Mar 2017 15:18:03 -0600, Joel C. Ewing wrote:

It's cultural.  Consider how Europeans write dates.
 https://xkcd.com/1179/

And significance is subjective.  About 10 years ago, I asked an
astronomer, "When is the equinox on Saturn?"
"Nine fourteen." (orally)

September 14th seemed too soon until I pondered and realized she
meant, "September, 2014."

In Boulder, CO, in the '60s (some century), all local phone numbers
were (303)442-xxx or (303)443-.  People routinely exchanged phone
numbers (orally) by only the last 5 digits.  The first 5 were, if not
insignificant, inconsequential.

Computer science professor W.M. Waite used to say, "Top of memory,"
pointing to the floor, and "Bottom of memory", pointing to the
ceiling.


Same in other books I've seen. Why? Probably because we write from top to bottom. We 
write the lowest first, at the top, and the highest last, at the bottom. And then we 
confuse everybody by calling them "ascending" memory addresses while writing 
them in a descending pattern. English is a _stupid_ language.




-- gil



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

Maranatha! <><
John McKown

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


--
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: curious: why S/360 & decendants are "big endian".

2017-03-13 Thread Jesse 1 Robinson

I've had the scroll up-or-down conversation many times over the years since I 
learned that my colleagues actually disagreed over which usage is 'correct'. 
I'm convinced that it's a matter of mental perception embodied in language, not 
merely a linguistic quirk adopted willy-nilly. 

Some people truly perceive scrolling on a 3270 screen as a rectangular window 
moving up or down over a fixed body of text nailed to the background. Others 
perceive the text itself as moving up or down--like a rolled scroll--behind a 
rectangular window nailed in front. People will argue their view, and their 
terminology, quite emphatically.

The scroll bar on a web screen introduces another wrinkle. You move the bar 
down to see the bottom of the data, up to see the top. Case closed? I think 
not. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anne & Lynn Wheeler
Sent: Thursday, March 09, 2017 4:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: curious: why S/360 & decendants are "big endian".

john.archie.mck...@gmail.com (John McKown) writes:
> Same in other books I've seen. Why? Probably because we write from 
> top to bottom. We write the lowest first, at the top, and the highest 
> last, at the bottom. And then we confuse everybody by calling them 
> "ascending" memory addresses while writing them in a descending 
> pattern. English is a _stupid_ language.

in the 70s as fullscreen 3270s editors were starting to appear, there was big 
editor culture wars over up & down.

prior to that, line-editing was from perspective of the user ...  "up"
moving towards the "top" (beginning) of the file and "down" was moving towards 
the "bottom" (end) of the file.

The side that had enhanced previous line editors to support 3270 fullscreen and 
preserved the up/down orientation (meaning).

A couple of "new" 3270 fullscreen editors, done from scratch, insisted on "up" 
was from the orientation of the program (not the user), the program would move 
the file up ... towards the bottom of the file or move the file "down" ... 
towards the top of the file (difference was` whether up/down was from the human 
perspective or the program/software perspective).

--
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: curious: why S/360 & decendants are "big endian".

2017-03-13 Thread Jesse 1 Robinson

"English is a _stupid_ language." Every language is stupid in its own way, some 
more so than others. If English were rational and simple, everybody would be 
using it. ;-)

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, March 09, 2017 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: curious: why S/360 & decendants are "big endian".

On Thu, Mar 9, 2017 at 3:50 PM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 9 Mar 2017 15:18:03 -0600, Joel C. Ewing wrote:
>
> It's cultural.  Consider how Europeans write dates.
> https://xkcd.com/1179/
>
> And significance is subjective.  About 10 years ago, I asked an 
> astronomer, "When is the equinox on Saturn?"
> "Nine fourteen." (orally)
>
> September 14th seemed too soon until I pondered and realized she 
> meant, "September, 2014."
>
> In Boulder, CO, in the '60s (some century), all local phone numbers 
> were (303)442-xxx or (303)443-.  People routinely exchanged phone 
> numbers (orally) by only the last 5 digits.  The first 5 were, if not 
> insignificant, inconsequential.
>
> Computer science professor W.M. Waite used to say, "Top of memory," 
> pointing to the floor, and "Bottom of memory", pointing to the 
> ceiling.
>

Same in other books I've seen. Why? Probably because we write from top to 
bottom. We write the lowest first, at the top, and the highest last, at the 
bottom. And then we confuse everybody by calling them "ascending" memory 
addresses while writing them in a descending pattern. English is a _stupid_ 
language.

>
> -- gil
>
>

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

Maranatha! <><
John McKown

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

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

On Mon, 13 Mar 2017 15:29:30 -0400, Tony Harminc wrote:

>On 13 March 2017 at 15:10, Tom Marchant
><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> There isn't much that these stubs can do to figure out what PC to
>> issue without using any registers.
>
>They can use 0, 1, 14, 15. And "General and access registers 0, 1, 14,
>and 15 are not restored", so they can clobber those too.

Those are MVS linkage conventions. In XPLINK, 1 to 3 are for 
arguments, and 8-15 are "preserved"

>> In any case, R14 is the return address. That is standard linkage, not XPLINK.
>
>How does XPLINK know where to return to?

Register 7.
Register 6 might contain the entry point address. 
Or not if the routine was entered via BRAS.

-- 
Tom Marrchant

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

Jollygiant support (QWS3270 PLUS vendor) has not responded to several emails

2017-03-13 Thread Binyamin Dissen

Has anyone had good response from them in the last few months?

--
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: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

2017-03-13 Thread Tony Harminc

On 13 March 2017 at 15:10, Tom Marchant
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
[me]
>>There is no mention of any R13 requirement, and this makes sense
>>because all the callable services are stubs that figure out which PC
>>to issue, and then issue it.
>
> There isn't much that these stubs can do to figure out what PC to
> issue without using any registers.

They can use 0, 1, 14, 15. And "General and access registers 0, 1, 14,
and 15 are not restored", so they can clobber those too.

> I looked for "save area" in that
> manual and found references in Appendices E and F that seem to
> indicate a requirement for a save area address in R13.

Those are examples, not definitions. The calling conventions section
has no reference to R13 that I can find.

>>What is slightly less clear is if R15
>>must point to the entry point of what you call.
>
> It seems clear to me. "Register 15 is set up by the CALL macro; it
> contains the entry point address of the service stub that is being
> called."

Sure - that's if you choose to link the service stubs into your code,
which I can see no reason for LE or C or COBOL or indeed anyone to do.
If you call the service directly, they don't suggest using the CALL
macro; they show a BALR R14,R15 directly. Whether R15 actually needs
to be set is unknown.

> In any case, R14 is the return address. That is standard linkage, not XPLINK.

How does XPLINK know where to return to?

Tony H.

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

On Mon, 13 Mar 2017 13:42:09 -0400, Tony Harminc  wrote:

>There's a good writeup in the z/OS UNIX Assembler Callable Services
>book, under "Linkage conventions for the callable services" in Chapter
>1. (The TCP/IP services are part of the more general UNIX services.)
>There is no mention of any R13 requirement, and this makes sense
>because all the callable services are stubs that figure out which PC
>to issue, and then issue it. 

There isn't much that these stubs can do to figure out what PC to 
issue without using any registers. I looked for "save area" in that 
manual and found references in Appendices E and F that seem to 
indicate a requirement for a save area address in R13. The 
reference to the z/OS MVS Program Management:Advanced Facilities 
manual for detailed linkage information is confusing. It seems to me 
more likely that they meant the Assembler Programmer's Guide rather 
than a binder manual.

>What is slightly less clear is if R15
>must point to the entry point of what you call. 

It seems clear to me. "Register 15 is set up by the CALL macro; it 
contains the entry point address of the service stub that is being 
called."

In any case, R14 is the return address. That is standard linkage, 
not XPLINK.

-- 
Tom Marchant

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

Re: Software vendor trying to force MSU based contract

2017-03-13 Thread Zahir Hemini

Yes but how easy is that to do? I am fairly sure that there is a limit to what 
vendors like Rocket or Serena would want to be supporting.

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

Re: FTP Client for Mac OS

2017-03-13 Thread Howard Turetzky

Here is a list of some Mac FTP clients: 
http://macosxbits.com/2016/04/best-mac-ftp-client/

I generally use either FileZilla or the native Mac/Unix ftp command.

Howard Turetzky
Ricoh Production Print

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

2017-03-13 Thread Tony Harminc

On 13 March 2017 at 13:06, Tom Marchant
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 13 Mar 2017 09:31:54 -0700, Charles Mills  wrote:
>
>>Any idea whether this would be true for Unicode services and TCP/IP? Do those 
>>calls from XPLINK-31 C require shifting into "old save area" linkage mode?
>>
>
> I don't have specific knowledge of the linkage expected by those services. If 
> those services expect the address of a save area in R13, then it must be 
> provided by its callers. That doesn't preclude them from having an alternate 
> entry point that uses some other linkage convention, but it would surprise me 
> if they did.

There's a good writeup in the z/OS UNIX Assembler Callable Services
book, under "Linkage conventions for the callable services" in Chapter
1. (The TCP/IP services are part of the more general UNIX services.)
There is no mention of any R13 requirement, and this makes sense
because all the callable services are stubs that figure out which PC
to issue, and then issue it. What is slightly less clear is if R15
must point to the entry point of what you call. I think it's probably
unnecessary unless you are linking in the quite unnecessary "service
stubs". If you instead use the documented offsets directly, I'd guess
it's unnecessary, though the routines are called with BALR R14,R15 in
AMODE 31 or 64 (24 is not supported). But only examining the (OCO)
code that the CSR table entries point to would give that information.
Or of course it could be documented, and I just missed it.

Whether the XPLINK authors for C/C++ and COBOL have got this all just
right is another question.

Tony H.

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

Re: curious: why S/360 & decendants are "big endian".

On Mon, Mar 13, 2017 at 11:14 AM, Parwez Hamid 
wrote:

> Even though the writing is from right to left, you will find that numbers
> written in Arabic are the same 'format' as in 'west'
>
> e.g 345 will also be 345 in Arabic and not 543, dates are 12/12/1234
> rather than 4321/21/21 or 1234/12/12, page numbers are 123 and not 321
>

Actually, the Arabic order makes perfect sense to me. The write the
"units" first, then then "tens of units", and so on. I wish we in the
"west" had not slavish copied the order from Arabic. I think it is more
logical to write the "units" first. It would definitely make converting
from binary to decimal simpler, if we didn't have the hardware to do it
(CVD instruction).

>
> Happy to be corrected.
>
>

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

Maranatha! <><
John McKown

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

On Mon, 13 Mar 2017 09:31:54 -0700, Charles Mills  wrote:

>Any idea whether this would be true for Unicode services and TCP/IP? Do those 
>calls from XPLINK-31 C require shifting into "old save area" linkage mode?
>

I don't have specific knowledge of the linkage expected by those services. If 
those services expect the address of a save area in R13, then it must be 
provided by its callers. That doesn't preclude them from having an alternate 
entry point that uses some other linkage convention, but it would surprise me 
if they did.

-- 
Tom Marchant

>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Tom Marchant
>Sent: Monday, March 13, 2017 8:12 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous 
>delivery model for new features
>
>Calls to QSAM GET and PUT, as well as other system services expect to be 
>passed the address of a standard save area in R13. 
>XPLINK and XPLINK-64 do things very differently.

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

2017-03-13 Thread Bill Woodger

On Mon, 13 Mar 2017 10:23:12 -0500, John McKown  
wrote:

>I took a quick look at XPLINK. And you're right, that's a whole 'nother
>kettle of fish. I basically understand the why, as explained in the LE
>manuals. But why COBOL decided to go with the same, other than
>inter-operation with C, is beyond my tiny (and shrinking) mind. Even with
>nested COBOL programs, I don't see COBOL programmers writing "tons" of
>"itty bitty" COBOL programs. But C/C++ programs do that a lot, especially
>C++ programmers.
>

COBOL programmers traditionally use paragraphs/SECTIONs and PERFORM for the 
itty-bitty.

There is an interesting development. For "contained/nested" programs, the 
optimiser can now "inline" the CALLs, so that a CALL to a contained program 
looks like a PERFORM of a paragraph/SECTION. Previously with Enterprise COBOL, 
there was a lesser overhead with a CALL to a contained/nested program than to 
an external program.

So you could now have lots of itty-bitty (contained) programs, which behave 
like paragraphs/SECTIONS but with "localised" data-names.

I don't know (no access to V5+) exactly how this pans out (there may be limits 
to how much can be inlined, as with paragrpahs/SECTIONs themselves) but it may 
offer a "different" way to develop COBOL programs. 

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

Any idea whether this would be true for Unicode services and TCP/IP? Do those 
calls from XPLINK-31 C require shifting into "old save area" linkage mode?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Monday, March 13, 2017 8:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous 
delivery model for new features

On Mon, 13 Mar 2017 10:00:41 -0500, John McKown wrote:

>On Mon, Mar 13, 2017 at 9:37 AM, Tom Marchant < 
>000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Every time an XPLINK program issues a GET or PUT, it has to make that 
>> transition.
>>
>
>Would you mind expanding a bit on the above? Are you talking about 
>doing I/O to read or write a z/OS type data set (DCB or ACB)?

Yes, that's what I meant. Calls to QSAM GET and PUT, as well as other system 
services expect to be passed the address of a standard save area in R13. 
XPLINK and XPLINK-64 do things very differently.

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

2017-03-13 Thread Bill Woodger

From the COBOL Cafe: 
https://www.ibm.com/developerworks/community/forums/html/topic?id=e055e63f-4e61-4502-b04c-db9b3d89d213

Allan Kielstra, from Markham, on a question of whether COBOL V5+ uses the 
FASTLINK calling convention.

'This is a bit confusing.  Even I was confused while I was implementing it.  
:-)  There are a number of variants of the basic "OS Linkage."  That's the 
linkage that uses R1 as a pointer to a block of incoming arguments (or outgoing 
parameters.)  One of those variants is called "C private," and it is the one 
that is used by C.  To tell that you are C private, you start by "pretending" 
that you are fastlink.  All the magic is here in the PPA1:

 0003F8  90 =AL1(144)   
   Flags


That's the program flags at offset hex 18 in the PPA1.  The value 1 in the top 
bit says "fastlink stack frame layout."  But that is "waved off" by the value 
001 in the next three bits.  That means "C private" convention.  So we always 
generate a 9x for that field of the PPA1.   (In fact a 90.)

That note about returning a doubleword binary item is something that did change 
between V4 and V5.  The C private calling convention requires that such items 
be returned in storage whose address is passed as a hidden first argument.  The 
V4 compiler didn't implement that quite right but it did everything else 
correctly for C private.  The V5/V6 compiler also implements C private and it 
adheres to the specification correctly even in this case.

So the bottom line is:  we use C private and not fastlink for COBOL.'

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

Re: curious: why S/360 & decendants are "big endian".

2017-03-13 Thread Parwez Hamid

Even though the writing is from right to left, you will find that numbers 
written in Arabic are the same 'format' as in 'west' 

e.g 345 will also be 345 in Arabic and not 543, dates are 12/12/1234 rather 
than 4321/21/21 or 1234/12/12, page numbers are 123 and not 321

Happy to be corrected.

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

Re: curious: why S/360 & decendants are "big endian".

2017-03-13 Thread Farley, Peter x23353

I don't know which Arabic code page they used for that terminal implementation 
(this was early-to-mid-1980's time frame).  I didn't even know what a code page 
was in those days, because I never had to deal with them at all.

We were mainly a VM/VSE/SP shop with an OS/VS1 system available for testing.  
No ISPF at all.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, March 13, 2017 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: curious: why S/360 & decendants are "big endian".

On 2017-03-13, at 09:36, Farley, Peter x23353 wrote:

> From a software company I worked for many distant moons ago that also 
> invented a 3270-like "terminal" for sale to an Arabic company (actually it 
> was an 8-bit micro-processor device with two 8-inch floppy drives) I can 
> actually answer that question:
> 
> FED345CBA
>  
What code page?

> Although Arabic word writing is right to left, numbers are written left to 
> right.  Most disconcerting on a 3270-type device when typing out words and 
> numbers, the cursor suddenly stops moving as the numbers are pushed out in 
> the opposite direction from the text.
>  
ISPF Edit/View now do a pretty good job of supporting Unicode; UTF-8; subject 
to teminal capability.  (Buggy, but support works at it.) I wonder whether the 
terminals have kept up?

> As I remember, the terminal implementation team's leader told me that the 
> trickiest part of that terminal emulation was getting the Arabic 
> letter-connector glyphs correct.  Letter glyphs would literally change shape 
> as subsequent letters were typed, and change back again if you back-spaced 
> over a letter.

--

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

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

2017-03-13 Thread Bill Woodger

On Mon, 13 Mar 2017 09:37:15 -0500, Tom Marchant  
wrote:

>Unless IBM has changed their direction, 64-bit Cobol will only be useful for 
>new applications. It will not interact with existing code unless that code is 
>also converted to AMODE 64.
>
>The reason for that is that 64-bit Cobol will only be supported with 
>XPLINK-64. The design of XPLINK-64 makes it incompatible with 31-bit XPLINK. 
>XPLINK-64 can call non-XPLINK programs, but since it passes a save area 
>located above the bar, it can only call AMODE 64 programs.
>
>XPLINK is touted as a performance improvement over standard linkage. The small 
>improvement in performance makes a big difference with C programs, with its 
>tendency to create very small subroutines. However, the cost of calling a 
>program that uses standard linkage is considerably higher.
>
>Every time an XPLINK program issues a GET or PUT, it has to make that 
>transition.

Unless something really dramatic happens, which means unequivocal benefit for 
everything from 64-bit addressing for a COBOL program, a reasonable expectation 
is of at least one to two decades where almost all COBOL programs will continue 
to use 31-bit addressing.

As I understand it, if there are sufficient exceptional cases where clients 
want 64-bit addressing, and what they ask for is genuinely resolved by 64-bit 
addressing, and there are enough such requests, then Enterprise COBOL, in a 
future release, will have the option (probably as a compiler option) to 
generate 64-bit addressing executable code from COBOL source programs.

Enterprise COBOL: no longer only knows about ESA OP-codes; uses Program 
Objects; has a CALLINTERFACE compiler directive; is geared up to react quickly 
(relative term) in response to change (V6.1, supporting ARCH(11) was announced 
on announcement of z13); probably lots of other stuff. V5 wasn't only for 2013, 
but included a lot of "enablement" for future change.

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

On Mon, 13 Mar 2017 10:23:12 -0500, John McKown  
wrote:

>I took a quick look at XPLINK. And you're right, that's a whole 'nother
>kettle of fish. I basically understand the why, as explained in the LE
>manuals. But why COBOL decided to go with the same, other than
>inter-operation with C, is beyond my tiny (and shrinking) mind. Even with
>nested COBOL programs, I don't see COBOL programmers writing "tons" of
>"itty bitty" COBOL programs. But C/C++ programs do that a lot, especially
>C++ programmers.

I agree. I don't understand why they don't use F4SA/F5SA, as documented 
in the Assembler Services Guide. I hope that they reconsider.

-- 
Tom Marchant

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

Re: INIT terminated at end of memory

2017-03-13 Thread Jim Mulder

  PDSE processing has its own latch manager, which predates the design and 

implementation of GRS latches. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> And yes, we definitely had PDSE Latch contention, and *something* 
> was very wrong. Note that there is no data set name in the display:
> V SMS,PDSE1,ANALYSIS
> IGW031I PDSE ANALYSIS  Start of Report(SMSPDSE1) 214 
> -data set name-- -vsgt--- 
>   01-ASPIL0-00011C
> ++ Unable to latch DIB:7E9BE0A0 
>   Latch:7F7D5F08 Holder(0040:009C7248) 
>   Holding Job:AUTO39P 
>   CallingSequence:IGWLHJIN IGWDACND IGWDBPAR IGWFARR3 
> ++ Unable to latch LSDLTDW:7F6BF680 
>Latch:7F6BF798 Holder(0040:009C7248) 
>Holding Job:AUTO39P 
> ++ Lock GLOBAL DIRECTORY SHARED 
> held for at least 842 seconds 
> Hl1b:7F7D5DB0 HOLDER(0040:009C7248) 
> Holding Job:AUTO39P 
>  ++ Lock GLOBAL FORMATWRITE SHARED 
> held for at least 842 seconds 
> Hl1b:7F7D5DB0 HOLDER(0040:009C7248) 
>Holding Job:AUTO39P 
> 
> There was no ENQ contention when we first had this latch contention.
> It looks a bit like oa51460, except the address space in question 
> never got canceled. There was an abend913 earlier in PDSE processing
> showing the same calling sequence as mentioned in oa5160, but that 
> was another address space.
> I have no clue if or how MIM handles Latches.



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

Re: curious: why S/360 & decendants are "big endian".

2017-03-13 Thread Paul Gilmartin

On 2017-03-13, at 09:36, Farley, Peter x23353 wrote:

> From a software company I worked for many distant moons ago that also 
> invented a 3270-like "terminal" for sale to an Arabic company (actually it 
> was an 8-bit micro-processor device with two 8-inch floppy drives) I can 
> actually answer that question:
> 
> FED345CBA
>  
What code page?

> Although Arabic word writing is right to left, numbers are written left to 
> right.  Most disconcerting on a 3270-type device when typing out words and 
> numbers, the cursor suddenly stops moving as the numbers are pushed out in 
> the opposite direction from the text.
>  
ISPF Edit/View now do a pretty good job of supporting Unicode; UTF-8;
subject to teminal capability.  (Buggy, but support works at it.)
I wonder whether the terminals have kept up?

> As I remember, the terminal implementation team's leader told me that the 
> trickiest part of that terminal emulation was getting the Arabic 
> letter-connector glyphs correct.  Letter glyphs would literally change shape 
> as subsequent letters were typed, and change back again if you back-spaced 
> over a letter.

-- gil

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

Re: curious: why S/360 & decendants are "big endian".

2017-03-13 Thread Farley, Peter x23353

From a software company I worked for many distant moons ago that also invented 
a 3270-like "terminal" for sale to an Arabic company (actually it was an 8-bit 
micro-processor device with two 8-inch floppy drives) I can actually answer 
that question:

FED345CBA

Although Arabic word writing is right to left, numbers are written left to 
right.  Most disconcerting on a 3270-type device when typing out words and 
numbers, the cursor suddenly stops moving as the numbers are pushed out in the 
opposite direction from the text.

As I remember, the terminal implementation team's leader told me that the 
trickiest part of that terminal emulation was getting the Arabic 
letter-connector glyphs correct.  Letter glyphs would literally change shape as 
subsequent letters were typed, and change back again if you back-spaced over a 
letter.

Thanks for the memories!

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith
Sent: Monday, March 13, 2017 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: curious: why S/360 & decendants are "big endian".

Mohammad, I’m confused. You said:
>In Arabic while writing from right to left 345 is written exactly in that 
>order and it's read "five forty three hundred".
I’m trying to understand. Given the number 345. You’re writing a series of 
letters, starting with A (yes, of course it’s not an A, but I can’t do the 
Arabic!). So if the “word” you’re writing is A through F, you’d write what 
would appear on the page as:

FEDCBA

Now we’re going to insert 345 between the D and the C (“after” the C). So would 
that look like:

FED345CBA
or
FED543CBA

? I’m sure what you wrote was clear to everyone but me!

--


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


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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

On Mon, Mar 13, 2017 at 10:12 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 13 Mar 2017 10:00:41 -0500, John McKown wrote:
>
> >On Mon, Mar 13, 2017 at 9:37 AM, Tom Marchant <
> >000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Every time an XPLINK program issues a GET or PUT, it has to make that
> >> transition.
> >>
> >
> >Would you mind expanding a bit on the above? Are you talking about doing
> >I/O to read or write a z/OS type data set (DCB or ACB)?
>
> Yes, that's what I meant. Calls to QSAM GET and PUT, as well as other
> system
> services expect to be passed the address of a standard save area in R13.
> XPLINK and XPLINK-64 do things very differently.
>

I took a quick look at XPLINK. And you're right, that's a whole 'nother
kettle of fish. I basically understand the why, as explained in the LE
manuals. But why COBOL decided to go with the same, other than
inter-operation with C, is beyond my tiny (and shrinking) mind. Even with
nested COBOL programs, I don't see COBOL programmers writing "tons" of
"itty bitty" COBOL programs. But C/C++ programs do that a lot, especially
C++ programmers.



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



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

Maranatha! <><
John McKown

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

Re: curious: why S/360 & decendants are "big endian".

2017-03-13 Thread Phil Smith

Mohammad, I’m confused. You said:
>In Arabic while writing from right to left 345 is written exactly in that 
>order and it's read "five forty three hundred".
I’m trying to understand. Given the number 345. You’re writing a series of 
letters, starting with A (yes, of course it’s not an A, but I can’t do the 
Arabic!). So if the “word” you’re writing is A through F, you’d write what 
would appear on the page as:

FEDCBA

Now we’re going to insert 345 between the D and the C (“after” the C). So would 
that look like:

FED345CBA
or
FED543CBA

? I’m sure what you wrote was clear to everyone but me!

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

On Mon, 13 Mar 2017 10:00:41 -0500, John McKown wrote:

>On Mon, Mar 13, 2017 at 9:37 AM, Tom Marchant <
>000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Every time an XPLINK program issues a GET or PUT, it has to make that
>> transition.
>>
>
>Would you mind expanding a bit on the above? Are you talking about doing
>I/O to read or write a z/OS type data set (DCB or ACB)?

Yes, that's what I meant. Calls to QSAM GET and PUT, as well as other system 
services expect to be passed the address of a standard save area in R13. 
XPLINK and XPLINK-64 do things very differently.

-- 
Tom Marchant

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

On Mon, Mar 13, 2017 at 9:37 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 11 Mar 2017 18:44:01 -0600, Bill Woodger wrote:
>
> >Enterprise COBOL is now, with the re-write, prepared for 64-bit
> addressing.
>
> Unless IBM has changed their direction, 64-bit Cobol will only be useful
> for new applications. It will not interact with existing code unless that
> code is also converted to AMODE 64.
>
> The reason for that is that 64-bit Cobol will only be supported with
> XPLINK-64. The design of XPLINK-64 makes it incompatible with 31-bit
> XPLINK. XPLINK-64 can call non-XPLINK programs, but since it passes a save
> area located above the bar, it can only call AMODE 64 programs.
>
> XPLINK is touted as a performance improvement over standard linkage. The
> small improvement in performance makes a big difference with C programs,
> with its tendency to create very small subroutines. However, the cost of
> calling a program that uses standard linkage is considerably higher.
>
> Every time an XPLINK program issues a GET or PUT, it has to make that
> transition.
>

Would you mind expanding a bit on the above? Are you talking about doing
I/O to read or write a z/OS type data set (DCB or ACB)?



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



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

Maranatha! <><
John McKown

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

Re: 3270 emulator display/translation oddity with windows 10

2017-03-13 Thread Pommier, Rex

Thanks, list, especially Bill and Tom.  Your timely explanations about how the 
GE works confirmed my suspicions about it being a missing font.  My coworker 
with W10 was back in the office today, and we were able to do compares between 
W7 and W10.  Turns out the people who did the build of W10 neglected to install 
the font libraries included with the emulator.  My coworker copied the fonts 
from the emulator directory to the W10 font directory and all started working 
again.  We will pass the information to our PC build folks and have them 
correct their build procedure.

To those who recommended switching to a different 3270 emulator, all I can say 
is "Not my decision."  

Thanks again!

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Friday, March 10, 2017 4:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 3270 emulator display/translation oddity with windows 10

Bill Godfrey wrote:

> Not necessarily the  _ and | characters. I think those would probably display 
> correctly on the OP's emulator.
> The 3270 character for a graphics horizontal line is displayed using 2 bytes, 
> the "Graphics Escape" (hex 08) followed by hex A2, and in the Windows-1252 
> character encoding, hex A2 is a cent sign.
> The 3270 character for a graphics vertical line is a GE followed by hex 85, 
> and in the Windows-1252 character encoding, hex 85 is an ellipsis, three 
> horizontal dots.
> So the OP's emulator is probably handling Graphics Escape differently on W10.

Great explanation!

Warning:  Windows-related notes below.  Beware :)

Like you say, two bytes are coming in, but there's only one spot on the screen 
for a character, so the 08 has to be stored somewhere else.  In Vista that's a 
separate character set buffer.  That 08 tells the program to switch from the 
normal font to the supplied GE font when drawing those special characters.  Now 
if the GE font is not available on the system, Windows will typically revert 
back to the existing font, and you get the cent sign (or other non-GE 
character) in error.

So to solve the problem I'd look for a GE font file supplied with the emulator, 
and drag it to the c:\windows\fonts folder to install it and see if that helps.

Another bit of information for the original poster:  Vista (and perhaps some 
other emulators), doesn't actually install the font into c:\windows\fonts.  
That's because that directory is often protected from non-admin writes, and I 
want people to be able to install and use the program without admin authority, 
or run from a USB drive.  Instead, the font library is dynamically loaded, kind 
of like LOAD EP= at run time using the Windows function AddFontResource().

I've heard of cases where AddFontResource() is blocked as a security exposure 
by some company policies, with the only solution to temporarily switch to admin 
and copy the font to c:\windows\fonts.  Just guessing that could be the case 
here with Win 10 involved.

Tom

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

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

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

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

On Sat, 11 Mar 2017 18:44:01 -0600, Bill Woodger wrote:

>Enterprise COBOL is now, with the re-write, prepared for 64-bit addressing.

Unless IBM has changed their direction, 64-bit Cobol will only be useful for 
new applications. It will not interact with existing code unless that code is 
also converted to AMODE 64.

The reason for that is that 64-bit Cobol will only be supported with XPLINK-64. 
The design of XPLINK-64 makes it incompatible with 31-bit XPLINK. XPLINK-64 can 
call non-XPLINK programs, but since it passes a save area located above the 
bar, it can only call AMODE 64 programs.

XPLINK is touted as a performance improvement over standard linkage. The small 
improvement in performance makes a big difference with C programs, with its 
tendency to create very small subroutines. However, the cost of calling a 
program that uses standard linkage is considerably higher.

Every time an XPLINK program issues a GET or PUT, it has to make that 
transition.

-- 
Tom Marchant

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

Re: timely

2017-03-13 Thread Mark Zelden

On Mon, 13 Mar 2017 01:13:21 -0500, Elardus Engelbrecht 
 wrote:

>Paul Gilmartin wrote:
>
>>>I see what you did there
 http://www.gocomics.com/nonsequitur/2017/03/12
>
>>What did I do there?  Did it work?
>
>You posted a link to a good joke. Now I know why Stonehenge was abandoned... 
>;-D
>
>Many thanks Paul for sharing it!
>
>Groete / Greetings
>Elardus Engelbrecht
>


When I saw the 2nd frame, I thought this was going to be a reference to big 
endian thread. 

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

Re: Servicelink selections getting errors

2017-03-13 Thread Steve Thompson

I'm able to get into SR, and have updated one (where I had just 
gotten notification that a PTF is now ready). I was able to 
update it.


OTOH -- AST and SIS both fail. I have tracking that should have 
been updated (the APAR for the PTF...).


Regards,
Steve Thompson



On 03/13/2017 08:39 AM, Richards, Robert B. wrote:

I can log into Servicelink just fine. But whenever I try any of the selections 
(SIS, AST, etc.) I get errors.

Can someone verify that they are getting these errors as well?

Bob


--
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: Bridging the Distance: Remote system control, despite its complexity, is worth it

2017-03-13 Thread Joel C. Ewing

On 03/12/2017 11:34 PM, Gabe Goldberg wrote:
> Bridging the Distance
> Remote system control, despite its complexity, is worth it
>
> Remote system programming used to mean using a keypunch machine
> outside the data center. But card decks still needed to get to the
> clunky 2540 or equivalent unit record device. Maybe we had a key or
> door code to do this ourselves, or maybe we handed it to an operator.
> Then, 3270-style devices allowed for increased distance—and hike—to
> and from our systems. Finally, networked terminals and workstations
> made location irrelevant. Whether in an office or working from home, z
> Systems programmers/administrators can now work from the next office,
> building, city, time zone or continent.
>
> But should this be happening? Do today's system programmers need
> physical access to data centers? Why or why not? Does being able to
> see and touch one's systems hold real value, or is it just a matter of
> professional pride? And to what extent is it practical to have a lack
> of immediacy to data centers, operations staff, users or matters?
>
> http://destinationz.org/Mainframe-Solution/Business-Case/Bridging-the-Distance
>
>
>
Hardware is certainly more reliable than in the old days and in some
ways simpler, but in other ways more complex. 

20 years ago at the organization I worked, it was the System Programmers
and Technical Services that were familiar on some level with everything
relevant to the availability and maintenance of equipment in the data
center.  We had input on the design of a new data center and the
environmental systems to support it. We were directly involved in
decisions on where to place new equipment or how to remove old
equipment, even to the extent of knowing where spare floor tiles were
kept and occasionally cutting some of the tiles our selves.  We owned
the area beneath the raised floor, planned I/O device addresses and
channel assignments, planned cable routing, knew and documented where
the inter-equipment and power cables were laid and connected and in most
cases were the ones who had installed them.  We were familiar with
building environmental systems: power, cooling, UPS, fire-suppression,
(and even some plumbing) to the extent those impacted on the data center
availability.

This put the System Programmers in a position to be aware when something
wasn't quite right in the Data Center, to be aware when something was
planned that might be disruptive, and even to look over the shoulder of
an IBM CE doing "concurrent" maintenance to double check they didn't
accidentally take offline that last interface to a critical controller.

With that experience, I have some concern that at some point those most
familiar with the logical structure of the data center will become so
isolated from those that deal with the physical aspects of the data
center that some bad decisions will be made that could have been avoided
had the collective knowledge been left more centralized and coordinated. 

I appreciated the increased ability  over the years to resolve problems
from the relative warmth of my desk, or from the convenience of my house
at 2 AM; but one of the things that attracted me to computing and
Systems Programming in the first place was a fascination with the
physical computer hardware.
 Joel C. Ewing

-- 
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: INIT terminated at end of memory

2017-03-13 Thread Barbara Nitz

Hi Greg,

>A FORCE command becomes a CALLRTM TYPE=MEMTERM request which will drive
>address space level resource manager routines in the *MASTER* address
>space for the memterm'd address space.  Ideally a resource manager
>routine should never need, or at least wait for, serialization of a
>resource during its processing.  But the ideal is rarely the reality,
>and resource manager routines can, and often do, get delayed or
>deadlocked.

I am guessing that this is what happened here. When I wrote the management 
summary after analysis (after I had posted here), it seems as if the initiator 
*did* terminate, but about 20 minutes later after causing problems in 
production (the original latch contention was on an AD system):
D GRS,CONTENTION,ENQ
ISG343I 11.30.00 GRS STATUS 419 
S=SYSTEM  SYSZRACF SYS1.RACF.BACK   
SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS 
AWE2  CTSACS 010F   009C68F8 EXCLUSIVEOWN   
AWE2  MIMGR  00CF   008E2398 EXCLUSIVEWAIT  
S=SYSTEM  SYSZRAC2 SYS1.RACF
SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS 
AWE2  INIT   0040   009FF6C8 EXCLUSIVEOWN
AWE2  TCPTNS01   00DC   009CAE88   SHARE  WAIT  
AWE2     0030   00919838   SHARE  WAIT  
AWE2  INIT   00B2   009FF6C8   SHARE  WAIT  
S=SYSTEM  SYSZRAC2 SYS1.RACF.BACK   
SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS 
AWE2  CTSACS 010F   009C68F8 EXCLUSIVEOWN   
AWE2  INIT   0040   009FF6C8 EXCLUSIVEWAIT  

After I had forced CTSACS out of the system, the dump I had taken (of the GRS 
address space only) finally came through and got written out. And I found 
IEF403I INIT - STARTED - TIME=11.44.01 for the initiator in question right 
after the force completed. It is quite possible that the contention in 
production started to resolve itself at this point, but we all were rather 
frazzled and had already decided to reIPL the system.
 
I am guessing that CTSACS was caught up in the parallel Unix Latch contention 
we had that does not show up on any D GRS,C  or D GRS,LATCH,C displays. (That 
address space uses USS due to IP connections to work stations.) I also cannot 
find latch contention information in my dump, although there definitely was 
some at that point.

>RTM *does* monitor resource manager routine execution (Paul and I added
>this support many years ago), expecting the task it is running under to
>have executed something across an interval of time.  If two intervals
>pass without any execution occurring then RTM will ABTERM the task with
>an ABEND 30D (
>).
>
>It sounds like an address space level resource manager routine became
>hung, possibly due to the same latching issue you issued the FORCE for.
>I suggest you check in LOGREC for any ABEND 30D records during the
>interval to see if a hung resource manager routine was detected by RTM,
>and go from there.
No abend30D in logrec, and aside from my dump of GRS no other dump, either. 
Traditionally, this installation has never had sadump configured or I would 
have taken one. (I plan to fix that this year!)

Interestingly enough, ASCBEWST from CTSACS in my dump shows a timestamp of 
11:08. At 11:04 we had the first IGW038A Possible PDSE Problem(s) (SMSPDSE1) 
and at 11:05 we had the first BPXM123E UNIX SYSTEM SERVICES HAS DETECTED THAT A 
GRS LATCH HAS BEEN HELD BY JOB xx FOR AN EXTENDED PERIOD OF TIME.

And yes, we definitely had PDSE Latch contention, and *something* was very 
wrong. Note that there is no data set name in the display:
V SMS,PDSE1,ANALYSIS
IGW031I PDSE ANALYSIS  Start of Report(SMSPDSE1) 214  
-data set name-- -vsgt--- 
  01-ASPIL0-00011C
++ Unable to latch DIB:7E9BE0A0   
  Latch:7F7D5F08 Holder(0040:009C7248)   
  Holding Job:AUTO39P
  CallingSequence:IGWLHJIN IGWDACND IGWDBPAR IGWFARR3
++ Unable to latch LSDLTDW:7F6BF680   
   Latch:7F6BF798 Holder(0040:009C7248)   
   Holding Job:AUTO39P
++ Lock GLOBAL DIRECTORY SHARED   
held for at least 842 seconds  
Hl1b:7F7D5DB0 HOLDER(0040:009C7248)
Holding Job:AUTO39P
 ++ Lock GLOBAL FORMATWRITE SHARED 
held for at least 842 seconds  
Hl1b:7F7D5DB0 HOLDER(0040:009C7248)
   Holding Job:AUTO39P

Re: Servicelink selections getting errors

2017-03-13 Thread Richards, Robert B.

For the record, SR appears to be working. On hold with the helpdesk as I 
type..expected wait time is greater than 5 minutes

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Monday, March 13, 2017 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Servicelink selections getting errors

On 3/13/2017 8:39 AM, Richards, Robert B. wrote:
> I can log into Servicelink just fine. But whenever I try any of the 
> selections (SIS, AST, etc.) I get errors.
>
> Can someone verify that they are getting these errors as well?
>
> Bob
>
Bob,

It's not you.  IBMLinky no worky:  Error 500: 
java.lang.NullPointerException.  I'm at 30,000 ft, so I'll let you call the 
IBMLink Help Desk.

Regards,
Tom Conley

--
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: Servicelink selections getting errors

2017-03-13 Thread Carmen Vitullo

Same thing here Bob :( 

- Original Message -

From: "Robert B. Richards"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, March 13, 2017 7:39:44 AM 
Subject: Servicelink selections getting errors 

I can log into Servicelink just fine. But whenever I try any of the selections 
(SIS, AST, etc.) I get errors. 

Can someone verify that they are getting these errors as well? 

Bob 

-- 
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: Mainframe JOBS in Austin

2017-03-13 Thread Todd Last

I live in Austin but I'm not going to attend SXSW.  Way too many people.  Are 
mainframe jobs open around here or are companies just recruiting?  I haven't 
heard of any sysprog job open lately but I'm always looking.

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

Re: Servicelink selections getting errors

2017-03-13 Thread Tom Conley


On 3/13/2017 8:39 AM, Richards, Robert B. wrote:

I can log into Servicelink just fine. But whenever I try any of the selections 
(SIS, AST, etc.) I get errors.

Can someone verify that they are getting these errors as well?

Bob


Bob,

It's not you.  IBMLinky no worky:  Error 500: 
java.lang.NullPointerException.  I'm at 30,000 ft, so I'll let you call 
the IBMLink Help Desk.


Regards,
Tom Conley

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

Re: curious: why S/360 & decendants are "big endian".

2017-03-13 Thread Mohammad Khan

On Thu, 9 Mar 2017 16:04:49 -0600, Paul Gilmartin  wrote:

>
>How would you enter that number in a bilingual editor/word processor?  Which
>digit would you press first?
>
>I once had Google translate a short sentence to Arabic.  I was puzzled
>to see the period on the right.  But, ah, that's a Latin period, so it belongs
>on the right in bilingual text.  Can't reproduce the behavior today.
>
>--gil
>

I have rarely worked with a word processor for a right to left language so I 
don't remember which digit is entered first. But the numbers do come out to be 
in the same order and yes the decimal point does appear on the right. 
Interestingly the same order is used in some other languages, for example Urdu, 
 that use adapted Arabic script although numbers are read from most significant 
side i.e. three hundred forty five.

MKK

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

Re: timely

2017-03-13 Thread Elardus Engelbrecht

Pommier, Rex wrote:

>I think Steve was commenting on your subject line tying nicely into the comic. 
> It was quite well done.  

Indeed! Just in time before you timed out! ;-)

Groete / Greetings
Elardus Engelbrecht

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

Re: timely

2017-03-13 Thread Pommier, Rex

I think Steve was commenting on your subject line tying nicely into the comic.  
It was quite well done.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, March 12, 2017 6:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: timely

On Sun, 12 Mar 2017 18:16:42 -0500, Steve Horein wrote:

>I see what you did there
>
>On Sunday, March 12, 2017, Paul Gilmartin < 
>000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>> http://www.gocomics.com/nonsequitur/2017/03/12
>>
What did I do there?  Did it work?

-- gil

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

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

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

Re: INIT terminated at end of memory

2017-03-13 Thread Greg Dyck

On 3/13/2017 6:00 AM, Barbara Nitz wrote:

According to the books, IEF743I means "System action: The job and address space
end." Unfortunately that does not seem to be the case. There is no indication that I
can find in hardcopy log that the address space (Initiator) got restarted, and the dump
that I took 17 minutes later shows the address space still up with ASCBEWST (address
space last lost control) about 1s after $HASP310 INIT TERMINATED AT END OF MEMORY. I
do see the initiator restarted 25 minutes after.

Barbara,
FORCE processing does not know or care what an address space is running,
beyond the requirement that if an address space is allowed to be
cancelled (CSCB field CHCL is on), then a CANCEL must be attempted
before a FORCE will be accepted for it.

A FORCE command becomes a CALLRTM TYPE=MEMTERM request which will drive
address space level resource manager routines in the *MASTER* address
space for the memterm'd address space. Ideally a resource manager
routine should never need, or at least wait for, serialization of a
resource during its processing. But the ideal is rarely the reality,
and resource manager routines can, and often do, get delayed or
deadlocked.

RTM *does* monitor resource manager routine execution (Paul and I added
this support many years ago), expecting the task it is running under to
have executed something across an interval of time. If two intervals
pass without any execution occurring then RTM will ABTERM the task with
an ABEND 30D (
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa800/resmgr.htm
).

It sounds like an address space level resource manager routine became
hung, possibly due to the same latching issue you issued the FORCE for.
I suggest you check in LOGREC for any ABEND 30D records during the
interval to see if a hung resource manager routine was detected by RTM,
and go from there.

Regards,
Greg

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

Servicelink selections getting errors

2017-03-13 Thread Richards, Robert B.

I can log into Servicelink just fine. But whenever I try any of the selections 
(SIS, AST, etc.) I get errors.

Can someone verify that they are getting these errors as well?

Bob


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

Re: INIT terminated at end of memory

2017-03-13 Thread Elardus Engelbrecht

Barbara Nitz wrote:

>Apparently we ran into another of those PDSE latch contention bugs. While 
>terminating the holder of the latch, we had to force the batch job since 
>cancel had absolutely no effect.

[ ... snipped ... ] 

At what z/OS version are you? Latest fix level?

What is your PDSESHARING statement?
Are you in a SysPlex? MonoPlex? A$$uming you're not sharing that outside the 
SysPlex?

Is this an once-off or a problem occuring repeately? I'm asking because you 
said 'ran into another ... '

>Our problem turned from Latch contention into ENQ contention, with that INIT 
>holding a vital ENQ and not releasing it.

Can you post the ENQ on IBM-MAIN? Say, if you could do a D GRS,C or something 
like that during the holding?

Groete / Greetings
Elardus Engelbrecht

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

Re: INIT terminated at end of memory

2017-03-13 Thread Tom Conley


On 3/13/2017 7:00 AM, Barbara Nitz wrote:

Apparently we ran into another of those PDSE latch contention bugs. While 
terminating the holder of the latch, we had to force the batch job since cancel 
had absolutely no effect.

We got messages
IEF743I INIT FORCED - CODE SA22 - IN ADDRESS SPACE 0040
IEF743I AUTO39P  FORCED - CODE SA22 - IN ADDRESS SPACE 0040
$HASP310 AUTO39P  TERMINATED AT END OF MEMORY
$HASP310 INIT TERMINATED AT END OF MEMORY

According to the books, IEF743I means "System action: The job and address space 
end." Unfortunately that does not seem to be the case. There is no indication that I 
can find in hardcopy log that the address space (Initiator) got restarted, and the dump 
that I took 17 minutes later shows the address space still up with ASCBEWST (address 
space last lost control) about 1s after $HASP310 INIT TERMINATED AT END OF MEMORY. I 
do see the initiator restarted 25 minutes after.

I don't have a batch job that is non-cancelable, so I cannot test the force 
command on a batch job running in an initiator. Does anyone know for sure how 
memterm processing due to force goes for an initiator? Does the initiator 
really terminate?

Our problem turned from Latch contention into ENQ contention, with that INIT 
holding a vital ENQ and not releasing it.

Thanks and regards, Barbara



Hi Barbara,

PDSE's causing issues?  Say it ain't so!  Did you try a $PI for the 
offending initiator before the FORCE?  I've never had to FORCE an 
initiator before.  Hopefully you got some dumps and sent this to IBM 
with a PMR.  I'd be interested to see how this works out.


Regards,
Tom Conley

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

Re: DSN=&,DISP=(,DELETE) vs DSN=HLQ.MLQ.LLQ,DISP=(,DELETE)