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

[Mike Myers]

Warren:

My God, you've been around even longer than me. I only joined IBM on 
Nov. 9, 1964 and started programming school the day before OS/360 went 
GA. How many other old f***s (friends) have we out here on this forum?


Mike Myers
Mentor Services Corporation
(919) 341-5210

On 03/09/2017 07:39 PM, Warren Brown wrote:

  I thought it was me . .joined IBM the same day as the 360 was announced

On Thu, 3/9/17, Anne & Lynn Wheeler  wrote:

  Subject: Re: curious: why S/360 & decendants are "big endian".
  To: IBM-MAIN@LISTSERV.UA.EDU
  Date: Thursday, March 9, 2017, 7:26 PM
  
  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



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

Re: Mobile Workload Pricing

[Frank Swarbrick]

Thanks!  Since we have only a single production LPAR and only two production 
CICS AORs (one for a specialized application and one for all the rest) this is 
probably our most likely option.


Does anyone have a "mobile LPAR" (or set of them) within your production 
Sysplex?  How about dedicated "mobile CICS" regions?


I see that IMS is also a candidate.  Is this just IMS TM, or is IMS DB also 
eligible?


Frank


From: IBM Mainframe Discussion List  on behalf of 
Graham Harris 
Sent: Thursday, March 9, 2017 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mobile Workload Pricing

Mobile workload reuses a reasonable chunk of our existing CICS capability,
and shares the same regions as everything else. Unique userids in CICS
allows the mobile transactions be be fully identified (userid, usefully,
propagates through the whole UOW starburst).  An hourly summarisation of
CICS 110s provides the input to MWP.


On 9 March 2017 at 16:53, Frank Swarbrick 
wrote:

> I believe I understand the options.  I'm just wondering which of the
> options other shops have chosen.  And why.  (I assume if you choose a
> separate LPAR you also utilize Parallel Sysplex to share the data...?)
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of R.S. 
> Sent: Thursday, March 9, 2017 5:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Mobile Workload Pricing
>
> W dniu 2017-03-09 o 02:22, Frank Swarbrick pisze:
> > There hasn't been much (any?) discussion here on MWP since it was
> announced in May 2014.  Is anyone doing this?  What methodology did you
> choose to allow you to track mobile vs. non-mobile "transactions"?  Why did
> you choose that method?  Which subsystems are you doing MWP for?
>
> Yes, some shops do this.
> The methodology is custom, because it higly depends on your
> applications. This methodology has to be analyzed and accepted by IBM.
> Clue: the more higl-level division the better. The best would be
> separate LPAR for mobile workload. However it can be dedicated CICS
> region, DB2 subsystem or even transactions.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> --
> Tre   tej wiadomo ci mo e zawiera  informacje prawnie chronione Banku
> przeznaczone wy  cznie do u ytku s u bowego adresata. Odbiorc  mo e by
> jedynie jej adresat z wy  czeniem dost pu osób trzecich. Je eli nie jeste
> adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej
> przekazania adresatowi, informujemy,  e jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie
> zabronione i mo e by  karalne. Je eli otrzyma e  t  wiadomo   omy kowo,
> prosimy niezw ocznie zawiadomi  nadawc  wysy aj c odpowied  oraz trwale
> usun   t  wiadomo   w  czaj c w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorized to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
>
> mBank S.A. z siedzib  w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl
Kredyty, lokaty, konta bankowe, karty, ubezpieczenia online | 
mBank.pl
www.mbank.pl
Oferta dla indywidualnych klientów banku. Zapoznaj się z naszą ofertą 
indywidualną na kredyty, lokaty, konta i ubezpieczenia.


> Kredyty, lokaty, konta bankowe, karty, ubezpieczenia online | mBank.pl<
> http://www.mbank.pl/>
Kredyty, lokaty, konta bankowe, karty, ubezpieczenia online | 
mBank.pl
www.mbank.pl
Oferta dla indywidualnych klientów banku. Zapoznaj się z naszą ofertą 
indywidualną na kredyty, lokaty, konta i ubezpieczenia.


> www.mbank.pl
Kredyty, lokaty, konta bankowe, karty, ubezpieczenia online | 
mBank.pl
www.mbank.pl
Oferta dla indywidualnych klientów banku. Zapoznaj się z naszą ofertą 
indywidualną na kredyty, lokaty, konta i ubezpieczenia.


> Oferta dla indywidualnych klientów banku. Zapoznaj się z naszą ofertą
> indywidualną na kredyty, lokaty, konta i ubezpieczenia.
>
>
> S d Rejonowy dla m. st. Warszawy XII Wydzia  Gospodarczy Krajowego
> Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP:
> 526-021-50-88. Wed ug stanu na dzie 

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

[Tom Brennan]

I believe there is at least one web program for panning images where you 
move the mouse left and the bits on the screen image move to the right. 
 I get so confused!  When moving the mouse to the left I expect the 
bits to drag along with it to the left.  The wars continue :)


Anne & Lynn Wheeler wrote:

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


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

[Warren Brown]

 I thought it was me . .joined IBM the same day as the 360 was announced

On Thu, 3/9/17, Anne & Lynn Wheeler  wrote:

 Subject: Re: curious: why S/360 & decendants are "big endian".
 To: IBM-MAIN@LISTSERV.UA.EDU
 Date: Thursday, March 9, 2017, 7:26 PM
 
 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".

[Anne & Lynn Wheeler]

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

[Paul Gilmartin]

On Thu, 9 Mar 2017 17:16:09 -0600, Bill Woodger wrote:

>Four-and-twenty is not poetic, it is archaic, with continuing regional use in 
>the UK. Although probably originally more thorough, I've only heard it used 
>with 20. I grew up with five-and-20-past and five-and-20-to for the time. I 
>didn't pick it up myself. Also for non-time things, but only with 20.
>
>What's the French for 83? Four-twenties-three. What if the 360 had been 
>developed in Toulon, or Lincolnshire (the real one)?
> 
Google says, for:
eighty-three
three hundred sixty

quatre vingt trois
Trois cent soixante
Capitalization?

and KJV:
his [the beast's] number is Six hundred threescore and six
Capitalization?

And a long cwt is eight stone.

Other powerful arguments for metrication:

http://www.denverpost.com/2017/03/08/error-shows-colorado-drivers-licenses-taller/
("Sir, please do *not* step out of the vehicle!")
https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_failure
https://en.wikipedia.org/wiki/Gimli_Glider#Refueling

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

[J R]

Originally archaic, of course.  But these days it's also poetic.  "Twenty-four 
blackbirds" would not maintain the meter/metre.  ;-) 

Sent from my iPhone

> On Mar 9, 2017, at 18:16, Bill Woodger  wrote:
> 
> Four-and-twenty is not poetic, it is archaic, with continuing regional use in 
> the UK. Although probably originally more thorough, I've only heard it used 
> with 20. I grew up with five-and-20-past and five-and-20-to for the time. I 
> didn't pick it up myself. Also for non-time things, but only with 20.
> 
> What's the French for 83? Four-twenties-three. What if the 360 had been 
> developed in Toulon, or Lincolnshire (the real one)?
> 
> --
> 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: Mobile Workload Pricing

[Graham Harris]

Mobile workload reuses a reasonable chunk of our existing CICS capability,
and shares the same regions as everything else. Unique userids in CICS
allows the mobile transactions be be fully identified (userid, usefully,
propagates through the whole UOW starburst).  An hourly summarisation of
CICS 110s provides the input to MWP.


On 9 March 2017 at 16:53, Frank Swarbrick 
wrote:

> I believe I understand the options.  I'm just wondering which of the
> options other shops have chosen.  And why.  (I assume if you choose a
> separate LPAR you also utilize Parallel Sysplex to share the data...?)
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of R.S. 
> Sent: Thursday, March 9, 2017 5:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Mobile Workload Pricing
>
> W dniu 2017-03-09 o 02:22, Frank Swarbrick pisze:
> > There hasn't been much (any?) discussion here on MWP since it was
> announced in May 2014.  Is anyone doing this?  What methodology did you
> choose to allow you to track mobile vs. non-mobile "transactions"?  Why did
> you choose that method?  Which subsystems are you doing MWP for?
>
> Yes, some shops do this.
> The methodology is custom, because it higly depends on your
> applications. This methodology has to be analyzed and accepted by IBM.
> Clue: the more higl-level division the better. The best would be
> separate LPAR for mobile workload. However it can be dedicated CICS
> region, DB2 subsystem or even transactions.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> --
> Tre   tej wiadomo ci mo e zawiera  informacje prawnie chronione Banku
> przeznaczone wy  cznie do u ytku s u bowego adresata. Odbiorc  mo e by
> jedynie jej adresat z wy  czeniem dost pu osób trzecich. Je eli nie jeste
> adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej
> przekazania adresatowi, informujemy,  e jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie
> zabronione i mo e by  karalne. Je eli otrzyma e  t  wiadomo   omy kowo,
> prosimy niezw ocznie zawiadomi  nadawc  wysy aj c odpowied  oraz trwale
> usun   t  wiadomo   w  czaj c w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorized to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
>
> mBank S.A. z siedzib  w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl
> Kredyty, lokaty, konta bankowe, karty, ubezpieczenia online | mBank.pl<
> http://www.mbank.pl/>
> www.mbank.pl
> Oferta dla indywidualnych klientów banku. Zapoznaj się z naszą ofertą
> indywidualną na kredyty, lokaty, konta i ubezpieczenia.
>
>
> S d Rejonowy dla m. st. Warszawy XII Wydzia  Gospodarczy Krajowego
> Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP:
> 526-021-50-88. Wed ug stanu na dzie  01.01.2016 r. kapita  zak adowy mBanku
> S.A. (w ca o ci wp acony) wynosi 168.955.696 z otych.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> 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".

[Bill Woodger]

Four-and-twenty is not poetic, it is archaic, with continuing regional use in 
the UK. Although probably originally more thorough, I've only heard it used 
with 20. I grew up with five-and-20-past and five-and-20-to for the time. I 
didn't pick it up myself. Also for non-time things, but only with 20.

What's the French for 83? Four-twenties-three. What if the 360 had been 
developed in Toulon, or Lincolnshire (the real one)?

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

Re: z/OS 2.3 preview announcement

[Paul Gilmartin]

On 2017-03-09, at 00:18, Vernooij, Kees (ITOPT1) - KLM wrote:
> 
> How many DLM's do you use per year? How many department codes, projectnames, 
> daily/weekly variations and sequence numbers do you have to code into 8 
> chars? All problems are serious, but some problems are more serious than 
> others. Come on, the 18 chars DLM limit will be at the bottom of my list.
>  
There's a good argument here for using UNIX files where possible
instead of Legacy data sets: the former are blessedly free of
the 44(8) limitation.  (Yes, there is a 1023(255) limitation;
lots more elbow room for department codes, projectnames, daily/weekly
variations and sequence numbers.)

For comparison, I tried the analog of DLM= on Linux and MacOS.
Both were happy with 380-character strings.  ("No one should
ever need more ...")  I didn't probe for the ultimate limit.

Both allowed broken/continued strings on the defining occurrence.
MacOS allowed broken/continued at the terminating occurrence;
Linux did not.

Why should z/OS strive for less than other OSes have supported
for decades?

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

[J R]

"Four-and-twenty blackbirds ..."?

When poetic licence kicks in, all bets are off!

Sent from my iPhone

On Mar 9, 2017, at 17:05, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu>
 wrote:

On Thu, 9 Mar 2017 15:27:58 -0600, Mohammad Khan wrote:

No idea why S/360 folks did it this way but among the natural languages there 
is at least one, likely more, where they do like you desire. In Arabic while 
writing from right to left 345 is written exactly in that order and it's read 
"five forty three hundred".

"Four-and-twenty blackbirds ..."?

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

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

[Paul Gilmartin]

On Thu, 9 Mar 2017 15:27:58 -0600, Mohammad Khan wrote:
>
>No idea why S/360 folks did it this way but among the natural languages there 
>is at least one, likely more, where they do like you desire. In Arabic while 
>writing from right to left 345 is written exactly in that order and it's read 
>"five forty three hundred".
> 
"Four-and-twenty blackbirds ..."?

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

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

[John McKown]

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

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

[Paul Gilmartin]

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

>I think it's much more fundamental than that.  At least in Western
>civilizations our methods of numeric notation are essentially
>"big-endian":  we write numbers from left to right, most significant
>digits first, and if one were asked to count the number of symbols
>written down, most would instinctively count from left to right as well,
>like the standard orientation of the positive x direction in Cartesian
>coordinates.  That corresponds to the concept of regarding higher memory
>addresses as proceeding to the right.
> 
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.

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

[Mohammad Khan]

On Wed, 8 Mar 2017 10:11:44 -0600, John McKown  
wrote:

>This is more a Friday type topic. But I'm curious about why the original
>designers of the S/360 went with "big endian" instead of "small endian"?
>The _only_ reason that I can think of is because our arithmetic "system" is
>"big endian". The more I think about it, the more Intel's "little endian"
>architecture makes more sense. I also wish the same were true of our
>writing (e.g. one hundred would be written 001, not 100). This latter would
>actually make outputting formatted numbers easier to program.
>

No idea why S/360 folks did it this way but among the natural languages there 
is at least one, likely more, where they do like you desire. In Arabic while 
writing from right to left 345 is written exactly in that order and it's read 
"five forty three hundred".

>Oh, well, feel free to ignore this musing of mine.
>
>--
>"Irrigation of the land with seawater desalinated by fusion power is
>ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
>
>Maranatha! <><
>John McKown
>

MKK

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

[Joel C. Ewing]

I think it's much more fundamental than that.  At least in Western
civilizations our methods of numeric notation are essentially
"big-endian":  we write numbers from left to right, most significant
digits first, and if one were asked to count the number of symbols
written down, most would instinctively count from left to right as well,
like the standard orientation of the positive x direction in Cartesian
coordinates.  That corresponds to the concept of regarding higher memory
addresses as proceeding to the right.

Conventions on punched cards simply followed the same convention as
manual notation, as did hardware registers on early mainframes and the
ordering of characters and digits when mapped to memory in mainframes.

I don't think little-endian usage got popularized until it became
practical to design inexpensive mini-computers and eventually
microprocessors, and there were no doubt some design simplifications
which made using little-endian ordering a cheaper solution at the time. 
An overriding design requirement in those days was to keep things simple
at the hardware level, even if it made things more difficult or
unnatural for humans that had to deal with programming and debugging.

Computers whose evolution can be traced back to early mainframes tend to
be big-endian.  Computers that evolved from mini-computer,
microprocessor roots tend to use little-endian conventions.
 Joel C. Ewing

On 03/08/2017 04:16 PM, Charles Mills wrote:
> Two words: punched cards. 
>
> Numbers on punched cards were "big-endian." IBM was the dominant power in 
> tabulating machines and never wanted to let that advantage slip away. 
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of John McKown
> Sent: Wednesday, March 8, 2017 12:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: curious: why S/360 & decendants are "big endian".
>
> On Wed, Mar 8, 2017 at 1:39 PM, Tom Marchant < 
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>> On Wed, 8 Mar 2017 11:33:31 -0700, Paul Gilmartin wrote:
>>
>>> It probably save hardware to decrement as well as increment in 
>>> accessing storage.  Consider that CLC goes left-to-right but AP goes 
>>> right-to-left.
>> AP goes right to left because it would otherwise have to do more work 
>> to propagate carry.
>>
> ​Right. But it could go to the left if the nybbles in the packed decimal 
> number were in reverse order, with the sign nybble being the first
> (leftmost) nybble in the data stream. I.e. instead of 01234F be F43210 .
> But that was likely not acceptable because one reason that programmers love 
> packed rather than binary is that they can read it directly in the hex dump. 
> Said dump being far more prevalent tool for debugging in the far past. Some 
> decisions are not really hardware dictated. They're cultural.
>
>
>> CLC goes left to right because it can stop as soon as it finds a 
>> mismatch and recognize which is greater. If all you wanted to check 
>> for was that the two are equal, you could go either way, but that's not as 
>> useful.
>>
>> --
>> Tom Marchant
>>
>>
> ...


-- 
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: JES2 Spool Volume size

[Richards, Robert B.]

Thanks Mark!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Thursday, March 09, 2017 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 Spool Volume size

On Thu, 9 Mar 2017 18:17:04 +0100, R.S.  wrote:

>W dniu 2017-03-09 o 15:37, Richards, Robert B. pisze:  
>
>> Anyone using the larger volume MOD  sizes for spool volumes?  Any issues?
>> 
>>  
>> 
>> Largest SYS1.HASPACE ?  :)   
>> 
>>  
>> 
>> Activating LEVEL=z22 this weekend. Anyone seen issues after setting the new 
>> mode?


>Current limit is 1TB.  
>
>That require LARGEDS.  
>


>Personally I'm using full mod-27's for several years.  
>


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

Ditto - one some sysplexes.   Largest spool farm is 15 mod-27s.   This is the 
JCL
I've been using for years to allocate the space:

//STEP1EXEC PGM=IEFBR14 
//SYSPRINT DD  SYSOUT=* 
//SPOOLX   DD  DSN=SYS1.HASPACE,UNIT=SYSDA,DISP=(,KEEP),
// SPACE=(CYL,1,,MXIG), USE LARGEST CONTIG SPACE
// DSNTYPE=LARGE,   ANYTHING LARGER THAN 64K TRACKS 
// VOL=SER=SPLP16   


Best Regards,

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



   

--
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: JES2 Spool Volume size

[Mark Zelden]

On Thu, 9 Mar 2017 18:17:04 +0100, R.S.  wrote:

>W dniu 2017-03-09 o 15:37, Richards, Robert B. pisze:  
>
>> Anyone using the larger volume MOD  sizes for spool volumes?  Any issues?
>> 
>>  
>> 
>> Largest SYS1.HASPACE ?  :)   
>> 
>>  
>> 
>> Activating LEVEL=z22 this weekend. Anyone seen issues after setting the new 
>> mode?


>Current limit is 1TB.  
>
>That require LARGEDS.  
>


>Personally I'm using full mod-27's for several years.  
>


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

Ditto - one some sysplexes.   Largest spool farm is 15 mod-27s.   This is the 
JCL
I've been using for years to allocate the space:

//STEP1EXEC PGM=IEFBR14 
//SYSPRINT DD  SYSOUT=* 
//SPOOLX   DD  DSN=SYS1.HASPACE,UNIT=SYSDA,DISP=(,KEEP),
// SPACE=(CYL,1,,MXIG), USE LARGEST CONTIG SPACE
// DSNTYPE=LARGE,   ANYTHING LARGER THAN 64K TRACKS 
// VOL=SER=SPLP16   


Best Regards,

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





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

Re: JES2 Spool Volume size

[R.S.]

W dniu 2017-03-09 o 15:37, Richards, Robert B. pisze:

Anyone using the larger volume MOD  sizes for spool volumes?  Any issues?

Largest SYS1.HASPACE ?  :)

Activating LEVEL=z22 this weekend. Anyone seen issues after setting the new 
mode?


Current limit is 1TB.
That require LARGEDS.

Personally I'm using full mod-27's for several years.

--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


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

Re: Which C library functions imply dub?

[Charles Mills]

Thank you all for your help and patience with my RACF command ignorance ...

Yes, the explanation for "OMVS auto-create" is of course FACILITY 
BPX.UNIQUE.USER. I RDELETEd that and now the program fails as expected.

Well, more or less as expected. I think I knew this before but I got excited by 
the thread on the MVS-OE list about testing for the OMVS segment and issuing a 
diagnostic. However the program in question is written in C++ and any "no OMVS 
segment" failure occurs before the first line of user (my) code gets executed, 
so there is no diagnosing it in the program. Yes, I could front-end LE 
initialization but I think that is overkill for this particular problem.

Don't get me wrong: BPX.UNIQUE.USER seems to be goodness and I will put that 
back now that testing is completed.

Thanks again,

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, March 8, 2017 7:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which C library functions imply dub?

A snippet from Robert's presentation

To help replace BPX.DEFAULT.USER, z/OS 1.11 introduced the FACILITY class 
profile BPX.UNIQUE.USER. Defining this newer profile causes RACF to 
automatically add OMVS segments and assign ids to users and groups that do not 
already have segments. RACF creates the segments when the user first accesses 
Unix (i.e., dubs). BPX.UNIQUE.USER works in combination with FACILITY class 
profile BPX.NEXT.USER, which defines the uid and gid number ranges to be used 
for automatic id assignment. Use of these profiles requires your databases to 
be in the Application Identity Mapping (AIM) structure.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Wednesday, March 08, 2017 8:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which C library functions imply dub?
> 
> What version of z/OS is this on?
> 
> I am thinking that RACF (or your SAF) is using an auto assign of the UID.
> There was a change when you had to specify the UID in the OMVS 
> Segment, then a change happened and the system went from 
> BPX.UNIQUE.USER To BPX.NEXT.USER
> 
> See Robert H's very nice presentation
> http://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__April
> _2011.pd
> f
> 
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills
> > Sent: Wednesday, March 08, 2017 7:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Which C library functions imply dub?
> >
> > So do OMVS segments get "auto-created?"
> >
> > I run ALU ROMVSNO NOOMVS and then LU ROMVSNO OMVS. I get
> >
> > NO OMVS INFORMATION
> >
> > Then I run a program that ought to require an OMVS segment. It runs 
> > to a normal completion.
> >
> > I then do another LU ROMVSNO OMVS and I get
> >
> > OMVS INFORMATION
> > 
> > UID= 990013
> > HOME= /u
> > PROGRAM= /bin/sh
> > CPUTIMEMAX= NONE
> > ASSIZEMAX= NONE
> > FILEPROCMAX= NONE
> >
> > What gives?
> >
> > Charles
> >

--
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: Mobile Workload Pricing

[Frank Swarbrick]

I believe I understand the options.  I'm just wondering which of the options 
other shops have chosen.  And why.  (I assume if you choose a separate LPAR you 
also utilize Parallel Sysplex to share the data...?)


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Thursday, March 9, 2017 5:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mobile Workload Pricing

W dniu 2017-03-09 o 02:22, Frank Swarbrick pisze:
> There hasn't been much (any?) discussion here on MWP since it was announced 
> in May 2014.  Is anyone doing this?  What methodology did you choose to allow 
> you to track mobile vs. non-mobile "transactions"?  Why did you choose that 
> method?  Which subsystems are you doing MWP for?

Yes, some shops do this.
The methodology is custom, because it higly depends on your
applications. This methodology has to be analyzed and accepted by IBM.
Clue: the more higl-level division the better. The best would be
separate LPAR for mobile workload. However it can be dedicated CICS
region, DB2 subsystem or even transactions.

--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Kredyty, lokaty, konta bankowe, karty, ubezpieczenia online | 
mBank.pl
www.mbank.pl
Oferta dla indywidualnych klientów banku. Zapoznaj się z naszą ofertą 
indywidualną na kredyty, lokaty, konta i ubezpieczenia.


Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


--
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: Problem Generating CA-7 SASSBSTR Batch LJOB Output

[Gibney, Dave]

Sorry, should have continued
datasets are generated

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Thursday, March 09, 2017 7:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Problem Generating CA-7 SASSBSTR Batch LJOB Output
> 
> It's just JCL. Neither SASSBSTR or the CA-7 main program in the STC have any
> idea how the DSNAME for the input and output datasets are
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > On Behalf Of Robert S. Hansel (RSH)
> > Sent: Thursday, March 09, 2017 6:45 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Problem Generating CA-7 SASSBSTR Batch LJOB Output
> >
> > Hi Jeffrey,
> >
> > I did read the documentation, several times, but unbeknownst to me at
> > the time, it was the wrong version - v11.3. Your reply prompted me to
> > look for more recent documentation, and in the documentation for v12,
> > CA added the following sentence to the description of
> DSNPFX='batch.dsn.prefix.':
> > "This hlq must match the hlq for the BATCHI#x and BATCHO#x data sets
> > that are defined to the CA 7 started task."
> >
> > IMHO, it seems nonsensical that the program would let you specify a
> > prefix that didn't match the started tasks ones and not give some sort
> > of a warning or error message. Why else would you have such an option
> > if not to specify your own datasets (and perhaps this is how it worked prior
> to v12).
> >
> > Regards, Bob
> >
> > -Original Message-
> > Date:Wed, 8 Mar 2017 10:43:15 -0600
> > From:Jeffrey Holst 
> > Subject: Re: Problem Generating CA-7 SASSBSTR Batch LJOB Output
> >
> > If you read the documentation, DSNPFX must match the DSNPFX for the
> > BATCHI#n and BATCHO#n datasets that are defined to the CA7 started
> task.
> > If DSNPFX is not specified, the prefix specified for the COMMDS is used.
> > DSNPFX need only be specified if those prefixes do not match. There is
> > no intent that one can create his own BATCHI#n and BACTHO#n datasets.
> >
> > That it gives RC=0 shows it is probably working as designed, What is
> > documented is that it copies the SYSIN to the BATCHI#n dataset that
> > you specified, and puts something in the COMMDS to tell CA-7 to
> > process the BATCHI#n that it has defined. There is nothing there, so
> > it quickly writes something to its BATCHO#n and puts something in
> > COMMDS to tell your BTI that it is done processing, and with what
> > return code. (It is documented that unless there is a message table
> > defined, most results produce RC=0). Finally BTI reads your BATCHO#n
> > (which is empty) and writes it contents to SYSPRINT.
> >
> > Jeffrey Holst
> >
> > On Tue, 7 Mar 2017 14:14:37 -0500, Robert S. Hansel (RSH)
> >  wrote:
> >
> > >Greetings all,
> > >
> > >I was able to get SASSBSTR running successfully, but in the process
> > >may have discovered a bug in the program. SASSBSTR allows you to
> > >specify your own pair of BATCHIN DD and BATCHOUT DD datasets using
> > >PARM
> > DSNPFX.
> > >SASSBSTR allocates datasets for BATCHIN and BATCHOUT using the prefix
> > >specified by DSNPFX and appending .BATCHI#n and BATCHO#n ('n' is a
> > >pseudo terminal ID number). If you don't specify DSNPFX, SASSBSTR by
> > >default uses the BATCHIN and BATCHOUT datasets specified in CA7's
> > >configuration. When I run the job with my own DSNPFX, I get no output.
> > >When I use the ones in CA7's configuration, I get output as expected.
> > >Yet, the job runs successfully with
> > >RC=0 in both cases, and there are no error messages of any sort.
> > >
> > >Thank you to all who offered suggestions and advice.
> > >
> > >Regards, Bob
> > >
> > >Robert S. Hansel  *** Celebrating 30 years working with RACF ***
> > >Lead RACF Specialist
> > >RSH Consulting, Inc.
> > >617-969-8211
> > >www.linkedin.com/in/roberthansel
> > >https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__twitter.com_RSH-
> > 5FR
> > >ACF=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> > Je7sw=u9g8rUevBo
> > >yCPAdo5sWE9w=6VJfz-
> > O_4wgPaFUf_2dMX7xBZcIfPgcogeA3eEaIsZQ=qzsoHQvTSi
> > >FhH1BTMn3vEMd6doSrodK4bzJMUkaeTFA=
> > >www.rshconsulting.com
> > >
> > >-Original Message-
> > >From: Robert S. Hansel (RSH) [mailto:r.han...@rshconsulting.com]
> > >Sent: Friday, March 03, 2017 3:16 PM
> > >To: IBM-MAIN (ibm-m...@bama.ua.edu)
> > >Subject: Problem Generating CA-7 SASSBSTR Batch LJOB Output
> > >
> > >Greetings all,
> > >
> > >I am trying to generate listings of job information from CA-7 with
> > >the LJOB command using the Batch Terminal Interface (BTI) program
> > >SASSBSTR (PROC CA7BTI). The job runs successfully, but the output in
> > >SYSPRINT simply shows the LJOB command I executed and not, as I'd
> > >hoped, the output from the LJOB command. I've searched the manuals
> > >and cannot figure out how to the get the 

Re: Problem Generating CA-7 SASSBSTR Batch LJOB Output

[Gibney, Dave]

It's just JCL. Neither SASSBSTR or the CA-7 main program in the STC have any 
idea how the DSNAME for the input and output datasets are 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Robert S. Hansel (RSH)
> Sent: Thursday, March 09, 2017 6:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Problem Generating CA-7 SASSBSTR Batch LJOB Output
> 
> Hi Jeffrey,
> 
> I did read the documentation, several times, but unbeknownst to me at the
> time, it was the wrong version - v11.3. Your reply prompted me to look for
> more recent documentation, and in the documentation for v12, CA added
> the following sentence to the description of DSNPFX='batch.dsn.prefix.':
> "This hlq must match the hlq for the BATCHI#x and BATCHO#x data sets that
> are defined to the CA 7 started task."
> 
> IMHO, it seems nonsensical that the program would let you specify a prefix
> that didn't match the started tasks ones and not give some sort of a warning
> or error message. Why else would you have such an option if not to specify
> your own datasets (and perhaps this is how it worked prior to v12).
> 
> Regards, Bob
> 
> -Original Message-
> Date:Wed, 8 Mar 2017 10:43:15 -0600
> From:Jeffrey Holst 
> Subject: Re: Problem Generating CA-7 SASSBSTR Batch LJOB Output
> 
> If you read the documentation, DSNPFX must match the DSNPFX for the
> BATCHI#n and BATCHO#n datasets that are defined to the CA7 started task.
> If DSNPFX is not specified, the prefix specified for the COMMDS is used.
> DSNPFX need only be specified if those prefixes do not match. There is no
> intent that one can create his own BATCHI#n and BACTHO#n datasets.
> 
> That it gives RC=0 shows it is probably working as designed, What is
> documented is that it copies the SYSIN to the BATCHI#n dataset that you
> specified, and puts something in the COMMDS to tell CA-7 to process the
> BATCHI#n that it has defined. There is nothing there, so it quickly writes
> something to its BATCHO#n and puts something in COMMDS to tell your BTI
> that it is done processing, and with what return code. (It is documented that
> unless there is a message table defined, most results produce RC=0). Finally
> BTI reads your BATCHO#n (which is empty) and writes it contents to
> SYSPRINT.
> 
> Jeffrey Holst
> 
> On Tue, 7 Mar 2017 14:14:37 -0500, Robert S. Hansel (RSH)
>  wrote:
> 
> >Greetings all,
> >
> >I was able to get SASSBSTR running successfully, but in the process may
> >have discovered a bug in the program. SASSBSTR allows you to specify
> >your own pair of BATCHIN DD and BATCHOUT DD datasets using PARM
> DSNPFX.
> >SASSBSTR allocates datasets for BATCHIN and BATCHOUT using the prefix
> >specified by DSNPFX and appending .BATCHI#n and BATCHO#n ('n' is a
> >pseudo terminal ID number). If you don't specify DSNPFX, SASSBSTR by
> >default uses the BATCHIN and BATCHOUT datasets specified in CA7's
> >configuration. When I run the job with my own DSNPFX, I get no output.
> >When I use the ones in CA7's configuration, I get output as expected.
> >Yet, the job runs successfully with
> >RC=0 in both cases, and there are no error messages of any sort.
> >
> >Thank you to all who offered suggestions and advice.
> >
> >Regards, Bob
> >
> >Robert S. Hansel  *** Celebrating 30 years working with RACF ***
> >Lead RACF Specialist
> >RSH Consulting, Inc.
> >617-969-8211
> >www.linkedin.com/in/roberthansel
> >https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_RSH-
> 5FR
> >ACF=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw=u9g8rUevBo
> >yCPAdo5sWE9w=6VJfz-
> O_4wgPaFUf_2dMX7xBZcIfPgcogeA3eEaIsZQ=qzsoHQvTSi
> >FhH1BTMn3vEMd6doSrodK4bzJMUkaeTFA=
> >www.rshconsulting.com
> >
> >-Original Message-
> >From: Robert S. Hansel (RSH) [mailto:r.han...@rshconsulting.com]
> >Sent: Friday, March 03, 2017 3:16 PM
> >To: IBM-MAIN (ibm-m...@bama.ua.edu)
> >Subject: Problem Generating CA-7 SASSBSTR Batch LJOB Output
> >
> >Greetings all,
> >
> >I am trying to generate listings of job information from CA-7 with the
> >LJOB command using the Batch Terminal Interface (BTI) program SASSBSTR
> >(PROC CA7BTI). The job runs successfully, but the output in SYSPRINT
> >simply shows the LJOB command I executed and not, as I'd hoped, the
> >output from the LJOB command. I've searched the manuals and cannot
> >figure out how to the get the output I desire and was hoping someone
> could be of assistance. TIA.
> >
> >Regards, Bob
> >
> >Robert S. Hansel  *** Celebrating 30 years working with RACF ***
> >Lead RACF Specialist
> >RSH Consulting, Inc.
> >617-969-8211
> >www.linkedin.com/in/roberthansel
> >https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_RSH-
> 5FR
> >ACF=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw=u9g8rUevBo
> >yCPAdo5sWE9w=6VJfz-
> O_4wgPaFUf_2dMX7xBZcIfPgcogeA3eEaIsZQ=qzsoHQvTSi
> >FhH1BTMn3vEMd6doSrodK4bzJMUkaeTFA=
> 

Re: JES2 Spool Volume size

[Richards, Robert B.]

Thanks to Allan, George, Paul and Curtis for their replies.

Caveats noted. Now to go find my storage admin guy :-) 

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pew, Curtis G
Sent: Thursday, March 09, 2017 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 Spool Volume size

On Mar 9, 2017, at 8:37 AM, Richards, Robert B.  wrote:
> 
> Anyone using the larger volume MOD  sizes for spool volumes?  Any issues?

I’m using mod-54, with no issues.

> 
> Largest SYS1.HASPACE ?  :)

SPACE=(CYL,(65519)),DSNTYPE=LARGE

> 
> Activating LEVEL=z22 this weekend. Anyone seen issues after setting the new 
> mode?

nope.

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


--
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: JES2 Spool Volume size

[Pew, Curtis G]

On Mar 9, 2017, at 8:37 AM, Richards, Robert B.  wrote:
> 
> Anyone using the larger volume MOD  sizes for spool volumes?  Any issues?

I’m using mod-54, with no issues.

> 
> Largest SYS1.HASPACE ?  :)

SPACE=(CYL,(65519)),DSNTYPE=LARGE

> 
> Activating LEVEL=z22 this weekend. Anyone seen issues after setting the new 
> mode?

nope.

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: JES2 Spool Volume size

[Feller, Paul]

We have two mod 27s for our spool for our tech lpars.  Also have lots of mod 9s 
for our production and test lpars.  We are still z11 mode because we have not 
gone to the CYL_MANAGED mode.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Thursday, March 09, 2017 08:42
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 Spool Volume size

Have used full volume mod 9's for spoolLARGEDS? Req'd 

No issues.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Thursday, March 9, 2017 8:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 Spool Volume size

Anyone using the larger volume MOD  sizes for spool volumes?  Any issues?

Largest SYS1.HASPACE ?  :)

Activating LEVEL=z22 this weekend. Anyone seen issues after setting the new 
mode?



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

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

Re: JES2 Spool Volume size

[George Rodriguez]

​I'm on v1.13 of z/OS and I've been using model 9 for at least 5 years
without any issues.


*George Rodriguez*
*Specialist II - IT Solutions*
*IT Enterprise Applications*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eight Consecutive Years*

On Thu, Mar 9, 2017 at 9:37 AM, Richards, Robert B.  wrote:

> Anyone using the larger volume MOD  sizes for spool volumes?  Any issues?
>
> Largest SYS1.HASPACE ?  :)
>
> Activating LEVEL=z22 this weekend. Anyone seen issues after setting the
> new mode?
>
>
>
> --
> 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

Re: Problem Generating CA-7 SASSBSTR Batch LJOB Output

[Robert S. Hansel (RSH)]

Hi Jeffrey,

I did read the documentation, several times, but unbeknownst to me at the time, 
it was the wrong version - v11.3. Your reply prompted me to look for more 
recent documentation, and in the documentation for v12, CA added the following 
sentence to the description of DSNPFX='batch.dsn.prefix.': "This hlq must match 
the hlq for the BATCHI#x and BATCHO#x data sets that are defined to the CA 7 
started task."

IMHO, it seems nonsensical that the program would let you specify a prefix that 
didn't match the started tasks ones and not give some sort of a warning or 
error message. Why else would you have such an option if not to specify your 
own datasets (and perhaps this is how it worked prior to v12).

Regards, Bob

-Original Message-
Date:Wed, 8 Mar 2017 10:43:15 -0600
From:Jeffrey Holst 
Subject: Re: Problem Generating CA-7 SASSBSTR Batch LJOB Output

If you read the documentation, DSNPFX must match the DSNPFX for the BATCHI#n 
and BATCHO#n datasets that are defined to the CA7 started task. If DSNPFX is 
not specified, the prefix specified for the COMMDS is used. DSNPFX need only be 
specified if those prefixes do not match. There is no intent that one can 
create his own BATCHI#n and BACTHO#n datasets.

That it gives RC=0 shows it is probably working as designed, What is documented 
is that it copies the SYSIN to the BATCHI#n dataset that you specified, and 
puts something in the COMMDS to tell CA-7 to process the BATCHI#n that it has 
defined. There is nothing there, so it quickly writes something to its BATCHO#n 
and puts something in COMMDS to tell your BTI that it is done processing, and 
with what return code. (It is documented that unless there is a message table 
defined, most results produce RC=0). Finally BTI reads your BATCHO#n (which is 
empty) and writes it contents to SYSPRINT. 

Jeffrey Holst

On Tue, 7 Mar 2017 14:14:37 -0500, Robert S. Hansel (RSH) 
 wrote:

>Greetings all,
>
>I was able to get SASSBSTR running successfully, but in the process may have
>discovered a bug in the program. SASSBSTR allows you to specify your own
>pair of BATCHIN DD and BATCHOUT DD datasets using PARM DSNPFX. SASSBSTR
>allocates datasets for BATCHIN and BATCHOUT using the prefix specified by
>DSNPFX and appending .BATCHI#n and BATCHO#n ('n' is a pseudo terminal ID
>number). If you don't specify DSNPFX, SASSBSTR by default uses the BATCHIN
>and BATCHOUT datasets specified in CA7's configuration. When I run the job
>with my own DSNPFX, I get no output. When I use the ones in CA7's
>configuration, I get output as expected. Yet, the job runs successfully with
>RC=0 in both cases, and there are no error messages of any sort.
>
>Thank you to all who offered suggestions and advice.
>
>Regards, Bob
>
>Robert S. Hansel  *** Celebrating 30 years working with RACF ***
>Lead RACF Specialist
>RSH Consulting, Inc.
>617-969-8211
>www.linkedin.com/in/roberthansel
>http://twitter.com/RSH_RACF
>www.rshconsulting.com
>
>-Original Message-
>From: Robert S. Hansel (RSH) [mailto:r.han...@rshconsulting.com]
>Sent: Friday, March 03, 2017 3:16 PM
>To: IBM-MAIN (ibm-m...@bama.ua.edu)
>Subject: Problem Generating CA-7 SASSBSTR Batch LJOB Output
>
>Greetings all,
>
>I am trying to generate listings of job information from CA-7 with the LJOB
>command using the Batch Terminal Interface (BTI) program SASSBSTR (PROC
>CA7BTI). The job runs successfully, but the output in SYSPRINT simply shows
>the LJOB command I executed and not, as I'd hoped, the output from the LJOB
>command. I've searched the manuals and cannot figure out how to the get the
>output I desire and was hoping someone could be of assistance. TIA.
>
>Regards, Bob
>
>Robert S. Hansel  *** Celebrating 30 years working with RACF ***
>Lead RACF Specialist
>RSH Consulting, Inc.
>617-969-8211
>www.linkedin.com/in/roberthansel
>http://twitter.com/RSH_RACF
>www.rshconsulting.com
>
>Upcoming RSH RACF Training - WebEx
>- RACF Audit & Compliance Roadmap - MAY 15-19, 2017
>- RACF Level I Administration - APR 25-28, 2017
>- RACF Level II Administration - FEB 27 - MAR 3, 2017
>- RACF Level III Admin, Audit, & Compliance - APR 3-7, 2017
>- RACF - Securing z/OS UNIX  - OCT 23-27, 2017
>
>
>--
>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: JES2 Spool Volume size

[Allan Staller]

Have used full volume mod 9's for spoolLARGEDS? Req'd 

No issues.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Thursday, March 9, 2017 8:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 Spool Volume size

Anyone using the larger volume MOD  sizes for spool volumes?  Any issues?

Largest SYS1.HASPACE ?  :)

Activating LEVEL=z22 this weekend. Anyone seen issues after setting the new 
mode?



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

JES2 Spool Volume size

[Richards, Robert B.]

Anyone using the larger volume MOD  sizes for spool volumes?  Any issues?

Largest SYS1.HASPACE ?  :)

Activating LEVEL=z22 this weekend. Anyone seen issues after setting the new 
mode?



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

Re: Mobile Workload Pricing

[R.S.]

W dniu 2017-03-09 o 02:22, Frank Swarbrick pisze:

There hasn't been much (any?) discussion here on MWP since it was announced in May 2014.  
Is anyone doing this?  What methodology did you choose to allow you to track mobile vs. 
non-mobile "transactions"?  Why did you choose that method?  Which subsystems 
are you doing MWP for?


Yes, some shops do this.
The methodology is custom, because it higly depends on your 
applications. This methodology has to be analyzed and accepted by IBM. 
Clue: the more higl-level division the better. The best would be 
separate LPAR for mobile workload. However it can be dedicated CICS 
region, DB2 subsystem or even transactions.


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


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

Re: Which C library functions imply dub?

[David Crayford]

On 8/03/2017 10:28 PM, David Griffiths1 wrote:

I understood the original question to be how to avoid OMVS and you almost
certainly need OMVS for printf. For Metal C I wrote my own printf subset
that calls WTO - you at least have varargs.


To me Metal/C is best used for system level programming like AR mode 
programs. It's great for that with __far pointers. For LE I wouldn't use 
C at all.
Why use C when you've got a decent C++ compiler with the STL and the 
other goodies? I hope that z/OS V2.3 delivers more C++11 features. It's 
becoming
difficult to port stuff because of the disparity with compilers from 
other platforms.



Cheers,

Dave Griffiths
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
  




From:   David Crayford 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/03/2017 13:52
Subject:Re: Which C library functions imply dub?
Sent by:IBM Mainframe Discussion List 



On 8/03/2017 9:15 PM, David Griffiths1 wrote:

Hi, not sure of the definitive answer but you can probably take a guess

by

comparing with the Metal C library. By definition Metal C calls don't
require access to the unix kernel. In fact if you don't want to connect

to

OMVS why not use Metal C anyway?

That's a no-brainer! For a simple example how about just being able to
use printf().


Cheers,

Dave Griffiths
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK





From:   Charles Mills 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/03/2017 02:30
Subject:Which C library functions imply dub?
Sent by:IBM Mainframe Discussion List 



X-posted from a thread on MVS-OE



How would I determine which standard C library functions imply or cause

a

dub? (Other than by trying them without an OMVS segment and seeing if

they

blow up?) Is this documented somewhere? I guess another way of phrasing
the
question is "how would I determine which standard C library functions

are

'UNIX functions'?"



Do most of them? Surely not strlen()? Does fopen()? Only if you

reference

a
UNIX file as opposed to //DD:FOO?



Charles




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


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