Re: "break" (was: Someone just too smart ...?)

[Paul Gilmartin]

On Fri, 4 Aug 2017 23:19:13 +, Smith III, Phil (HPE Data Security 
(Voltage)) wrote:

>Paul Gilmartin wrote:
>>Rexx has no GOTO.  "break" is LEAVE [control-variable] (and "continue is
>>ITERATE [control-variable]).  I never use Rexx SIGNAL other than to force
>>an error; its side effects are dreadful.
>
>By "to force an error", do you mean "to say that something bad happened and 
>end the program"? ...
>
I begin every Rexx program with SIGNAL ON NOVALUE but code no handler.
I consider reference to an undefined symbol a coding error, and fatal because
there's really no way to recover.

>... Because if so, I agree 100% (well, except for the slightly perverse 
>"calculated goto" via "SIGNAL VALUE", which is useful in *very* specific, 
>rare, heavily documented instances).
>
>That is, I find this code much easier to read and maintain:
>
>do 
>   ...
>   if  signal BadCase1
>   ...
>   if  signal BadCase2
>   ...
>end
>...
A lot of that I'd do with SELECT and CALL.  But partly I'm being compulsive 
about
avoiding SIGNAL.  And sometimes I force a terminal condition (such as NOVALUE)
to get the procedure call trace.

>* And way down below somewhere:
>BadCase1:
>say "The very bad case#1 happened!"
>exit 1
>
>BadCase2:
>say "The very bad case#2 happened!"
>exit 2
>(etc.)
>
>than:
>do 
>   ...
>   maybeError=1
>   if  leave
>   ...
>   maybeError=2
>   if  signal BadCase2
>   ...
>   maybeError=0
>end
>if maybeError <> 0 then ...
>
>or, perhaps more common:
>do 
>   ...
>   if  then do
>  
>   end
>   ...
>   if  then do
>  
>   end
>   ...
>end
>
>The point is that the second and third cases are much harder to read and 
>maintain. If you're disciplined about only using SIGNAL for this purpose, then 
>seeing "Ah, he SIGNALs somewhere, he's done, that's not the mainline path" is 
>quick and easy, allowing analysis of the mainline (and not incidentally 
>grouping the errors in one place).

-- gil

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

Re: "break" (was: Someone just too smart ...?)

[Smith III, Phil (HPE Data Security (Voltage))]

Paul Gilmartin wrote:
>Rexx has no GOTO.  "break" is LEAVE [control-variable] (and "continue is
>ITERATE [control-variable]).  I never use Rexx SIGNAL other than to force
>an error; its side effects are dreadful.

By "to force an error", do you mean "to say that something bad happened and end 
the program"? Because if so, I agree 100% (well, except for the slightly 
perverse "calculated goto" via "SIGNAL VALUE", which is useful in *very* 
specific, rare, heavily documented instances).

That is, I find this code much easier to read and maintain:

do 
   ...
   if  signal BadCase1
   ...
   if  signal BadCase2
   ...
end
...
* And way down below somewhere:
BadCase1:
say "The very bad case#1 happened!"
exit 1

BadCase2:
say "The very bad case#2 happened!"
exit 2
(etc.)

than:
do 
   ...
   maybeError=1
   if  leave
   ...
   maybeError=2
   if  signal BadCase2
   ...
   maybeError=0
end
if maybeError <> 0 then ...

or, perhaps more common:
do 
   ...
   if  then do
  
   end
   ...
   if  then do
  
   end
   ...
end

The point is that the second and third cases are much harder to read and 
maintain. If you're disciplined about only using SIGNAL for this purpose, then 
seeing "Ah, he SIGNALs somewhere, he's done, that's not the mainline path" is 
quick and easy, allowing analysis of the mainline (and not incidentally 
grouping the errors in one place).

I don't want to get into a theological argument on a Friday afternoon, but 
having grown up with PL/I, the "No GOTOs noway never nohow" has always seemed 
overly rigid. Plus I'm currently living with code that uses the second 
technique above, and it's hell to debug (ok, in this case, it's much worse 
because it tends to set the maybeError *once* and then test five things, so you 
have to try to figure out which of the five really caused the error...just lazy 
programming).

...phsiii

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

Re: PGSER FIX returns CC = 18A Reason=35000301

[Jim Mulder]

  That is correct - cross memory page faults are resolved as you would 
want,
so the PGSER FIX is not needed.

  Unfortunately, the system does not resolve ASTE-validity exception (PIC 
2B), 
which is why nonswappability is required. 

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

> From: John McKown 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/04/2017 04:00 PM
> Subject: Re: PGSER FIX returns CC = 18A Reason=35000301
> Sent by: IBM Mainframe Discussion List 
> 
> On Fri, Aug 4, 2017 at 2:18 PM, Joseph Reichman 
> wrote:
> 
> > I made it non swapable
> >
> > But that doesn't mean the virtual storage cann't get paged out
> >
> >
> ​Ah, I think that it is acceptable for a page fault to occur (on either
> "side") when doing an AR mode MVC or a DAS MVCS/MVCP instruction. Normal
> page fault resolution is done and the instruction is executed.​
> 
> 
> -- 
> Veni, Vidi, VISA: I came, I saw, I did a little shopping.
> 
> 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: PGSER FIX returns CC = 18A Reason=35000301

[John McKown]

On Fri, Aug 4, 2017 at 2:18 PM, Joseph Reichman 
wrote:

> I made it non swapable
>
> But that doesn't mean the virtual storage cann't get paged out
>
>
​Ah, I think that it is acceptable for a page fault to occur (on either
"side") when doing an AR mode MVC or a DAS MVCS/MVCP instruction. Normal
page fault resolution is done and the instruction is executed.​


-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

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: PGSER FIX returns CC = 18A Reason=35000301

[Joseph Reichman]

I made it non swapable

But that doesn't mean the virtual storage cann't get paged out



> On Aug 4, 2017, at 2:47 PM, John McKown  wrote:
> 
>> On Fri, Aug 4, 2017 at 1:42 PM, Jim Mulder  wrote:
>> 
>>  That does not require the storage to be fixed, unless you are disabled
>> or you are using a real address for the target of the copy.
>> 
>> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
>> Poughkeepsie NY
>> 
>> 
> ​I probably shouldn't say anything, being rather ignorant of this area, but
> if one wants to copy data directly from address space B (the target of the
> SRB in this case) to address space A (the originator of the SRB in this
> case), doesn't address space A need to be "non swappable"? I think this is
> true when using AR mode or DAS mode (MVCS instruction ?).​
> 
> --
> 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: PGSER FIX returns CC = 18A Reason=35000301

[Steve Beaver]

Why not us SP=245  that is a non-pageable subpool

Steve

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Friday, August 4, 2017 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PGSER FIX returns CC = 18A Reason=35000301

I thought the address space storage I was copying to could be paged out 

Ok l'll remove and see if I get any abends

> On Aug 4, 2017, at 2:42 PM, Jim Mulder  wrote:
> 
>  That does not require the storage to be fixed, unless you are 
> disabled or you are using a real address for the target of the copy.
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY
> 
>> From: Joseph Reichman 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date: 08/04/2017 02:40 PM
>> Subject: Re: PGSER FIX returns CC = 18A Reason=35000301 Sent by: IBM 
>> Mainframe Discussion List 
>> 
>> Copy storage from the address space in which SRB is running to the 
>> address space that scheduled it
>> 
>> Thanks
>> 
>> 
>> 
>>> On Aug 4, 2017, at 1:32 PM, Jim Mulder  wrote:
>>> 
>>> The answer is in the manual:
>>> 
>>> ,EA=end add 
>>> Specifies the last byte on the last page of the virtual area for
> R
>>> requests.
>>> 
>>> 
>>>  Your EA specifies the first byte on the next page, which is not 
>>> GETMAINed.
>>> 
>>>  What are you doing in the SRB that requires this storage to be 
>>> fixed
> 
>>> in 31-bit real storage?
>>> 
>>> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
>>> Poughkeepsie NY
>>> 
 I am getting an error for PGSER Fix that the storage has not been
>>> getmain'ed
 
 I have tried different subpool(s)  0 and 10 with same result AND 
 same address was returned
 
 Here is the storage macro whose storage I am trying to fix
 
USING VALSTOR,R3 
LAR0,4095 GET LENGTH 
AHR0,=H'1' 
STORAGE OBTAIN, X
  LENGTH=(R0), X
  ADDR=(R7), X
  BNDRY=PAGE, X
  SP=10, X
  LOC=(31,31)
 * 
 *   Page Fix Ws till SRB completes 
 * 
 LRR7,R13 Point to beg of WS 
 LAR8,4095(,R7)   4K 
 LAR8,1(,R8) 
 
 
 *
 
 PGSER R, X
   FIX, X
   A=(R7), X
   EA=(R8), X
   ECB=0
> 
> 
> 
> --
> 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: PGSER FIX returns CC = 18A Reason=35000301

[Joseph Reichman]

I thought the address space storage I was copying to could be paged out 

Ok l'll remove and see if I get any abends

> On Aug 4, 2017, at 2:42 PM, Jim Mulder  wrote:
> 
>  That does not require the storage to be fixed, unless you are disabled 
> or you are using a real address for the target of the copy. 
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY
> 
>> From: Joseph Reichman 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date: 08/04/2017 02:40 PM
>> Subject: Re: PGSER FIX returns CC = 18A Reason=35000301
>> Sent by: IBM Mainframe Discussion List 
>> 
>> Copy storage from the address space in which SRB is running to the 
>> address space that scheduled it
>> 
>> Thanks
>> 
>> 
>> 
>>> On Aug 4, 2017, at 1:32 PM, Jim Mulder  wrote:
>>> 
>>> The answer is in the manual:
>>> 
>>> ,EA=end add 
>>> Specifies the last byte on the last page of the virtual area for 
> R 
>>> requests.
>>> 
>>> 
>>>  Your EA specifies the first byte on the next page, which is not 
>>> GETMAINed. 
>>> 
>>>  What are you doing in the SRB that requires this storage to be fixed 
> 
>>> in 31-bit real storage?
>>> 
>>> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
>>> Poughkeepsie NY
>>> 
 I am getting an error for PGSER Fix that the storage has not been 
>>> getmain'ed
 
 I have tried different subpool(s)  0 and 10 with same result AND same
 address was returned
 
 Here is the storage macro whose storage I am trying to fix
 
USING VALSTOR,R3 
LAR0,4095 GET LENGTH 
AHR0,=H'1' 
STORAGE OBTAIN, X
  LENGTH=(R0), X
  ADDR=(R7), X
  BNDRY=PAGE, X
  SP=10, X
  LOC=(31,31) 
 * 
 *   Page Fix Ws till SRB completes 
 * 
 LRR7,R13 Point to beg of WS 
 LAR8,4095(,R7)   4K 
 LAR8,1(,R8) 
 
 
 * 
 
 PGSER R, X
   FIX, X
   A=(R7), X
   EA=(R8), X
   ECB=0 
> 
> 
> 
> --
> 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: PGSER FIX returns CC = 18A Reason=35000301

[John McKown]

On Fri, Aug 4, 2017 at 1:42 PM, Jim Mulder  wrote:

>   That does not require the storage to be fixed, unless you are disabled
> or you are using a real address for the target of the copy.
>
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> Poughkeepsie NY
>
>
​I probably shouldn't say anything, being rather ignorant of this area, but
if one wants to copy data directly from address space B (the target of the
SRB in this case) to address space A (the originator of the SRB in this
case), doesn't address space A need to be "non swappable"? I think this is
true when using AR mode or DAS mode (MVCS instruction ?).​

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

Re: PGSER FIX returns CC = 18A Reason=35000301

[Jim Mulder]

  That does not require the storage to be fixed, unless you are disabled 
or you are using a real address for the target of the copy. 

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

> From: Joseph Reichman 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/04/2017 02:40 PM
> Subject: Re: PGSER FIX returns CC = 18A Reason=35000301
> Sent by: IBM Mainframe Discussion List 
> 
> Copy storage from the address space in which SRB is running to the 
> address space that scheduled it
> 
> Thanks
> 
> 
> 
> > On Aug 4, 2017, at 1:32 PM, Jim Mulder  wrote:
> > 
> >  The answer is in the manual:
> > 
> > ,EA=end add 
> >  Specifies the last byte on the last page of the virtual area for 
R 
> > requests.
> > 
> > 
> >   Your EA specifies the first byte on the next page, which is not 
> > GETMAINed. 
> > 
> >   What are you doing in the SRB that requires this storage to be fixed 

> > in 31-bit real storage?
> > 
> > Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> > Poughkeepsie NY
> > 
> >> I am getting an error for PGSER Fix that the storage has not been 
> > getmain'ed
> >> 
> >> I have tried different subpool(s)  0 and 10 with same result AND same
> >> address was returned
> >> 
> >> Here is the storage macro whose storage I am trying to fix
> >> 
> >> USING VALSTOR,R3 
> >> LAR0,4095 GET LENGTH 
> >> AHR0,=H'1' 
> >> STORAGE OBTAIN, X
> >>   LENGTH=(R0), X
> >>   ADDR=(R7), X
> >>   BNDRY=PAGE, X
> >>   SP=10, X
> >>   LOC=(31,31) 
> >> * 
> >> *   Page Fix Ws till SRB completes 
> >> * 
> >>  LRR7,R13 Point to beg of WS 
> >>  LAR8,4095(,R7)   4K 
> >>  LAR8,1(,R8) 
> >> 
> >> 
> >> * 
> >> 
> >>  PGSER R, X
> >>FIX, X
> >>A=(R7), X
> >>EA=(R8), X
> >>ECB=0 



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

Re: PGSER FIX returns CC = 18A Reason=35000301

[Joseph Reichman]

Copy storage from the address space in which SRB is running to the address 
space that scheduled it

Thanks



> On Aug 4, 2017, at 1:32 PM, Jim Mulder  wrote:
> 
>  The answer is in the manual:
> 
> ,EA=end add 
>  Specifies the last byte on the last page of the virtual area for R 
> requests.
> 
> 
>   Your EA specifies the first byte on the next page, which is not 
> GETMAINed. 
> 
>   What are you doing in the SRB that requires this storage to be fixed 
> in 31-bit real storage?
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY
> 
>> I am getting an error for PGSER Fix that the storage has not been 
> getmain'ed
>> 
>> I have tried different subpool(s)  0 and 10 with same result AND same
>> address was returned
>> 
>> Here is the storage macro whose storage I am trying to fix
>> 
>> USING VALSTOR,R3 
>> LAR0,4095 GET LENGTH 
>> AHR0,=H'1' 
>> STORAGE OBTAIN,   X
>>   LENGTH=(R0),X
>>   ADDR=(R7),  X
>>   BNDRY=PAGE, X
>>   SP=10,  X
>>   LOC=(31,31) 
>> * 
>> *   Page Fix Ws till SRB completes 
>> * 
>>  LRR7,R13 Point to beg of WS 
>>  LAR8,4095(,R7)   4K 
>>  LAR8,1(,R8) 
>> 
>> 
>> * 
>> 
>>  PGSER R, X
>>FIX, X
>>A=(R7), X
>>EA=(R8), X
>>ECB=0 
> 
> 
> 
> --
> 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

"break" (was: Someone just too smart ...?)

[Paul Gilmartin]

On Fri, 4 Aug 2017 13:01:27 -0500, Steve Beaver wrote:

>Charles.   PL/1 and REXX are about the same   The break would be a goto 
>
Rexx has no GOTO.  "break" is LEAVE [control-variable] (and "continue is
ITERATE [control-variable]).  I never use Rexx SIGNAL other than to force
an error; its side effects are dreadful.

Rexx sorely lacks "longjump".

>> On Aug 4, 2017, at 12:45, Charles Mills wrote:
>> 
>>switch = 1;
>>break? /* what is the PL/I to exit from a loop? */ ;

-- gil

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

Re: Someone just too smart for his or her own good?

[Steve Beaver]

Charles.   PL/1 and REXX are about the same   The break would be a goto 

Sent from my iPhone

Sorry for any grammar problems 

> On Aug 4, 2017, at 12:45, Charles Mills  wrote:
> 
> Why do I keep devoting thought to this?
> 
> If you desperately needed to optimize every last cycle out of the loop, and 
> you wanted to do this in a supported way, the trick would be two loops. 
> Something like
> 
> for i = 1 to whatever;
>  if a(i) >= 0 then do
>sum = sum + a(i);
>switch = 1;
>break? /* what is the PL/I to exit from a loop? */ ;
>  end;
> end;
> 
> for i = i to whatever;
>  if a(i) > 0 then sum = sum + a(i);
> end;
> 
> I'm not a PL/I coder so not sure if you need a test for i already == whatever 
> when it gets to the second loop or whether it has already been incremented, 
> etc. 
> 
> Probably faster than the original because avoids most of the a(i) == 0 cases.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Robert Prins
> Sent: Friday, August 4, 2017 10:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Someone just too smart for his or her own good?
> 
>> On 2017-08-04 13:41, Charles Mills wrote:
>> OK, I get it. (Way too much time spent on this now.) The sum is also 
>> to be printed if there are any zero values in a[whatever].
>> 
>> Is this a real business problem or an exercise in whatever?
> 
> The original code actually fills a set of buckets with values (or nothing), I 
> just simplified the code to a loop over an array, changing the values in the 
> array to do some testing, after first figuring out what was going on.
> 
>> I don't know the PL/I compiler but on a modern processor Store on 
>> Condition potentially makes
>> 
>> if a(i) >= 0 then switch = 1;
> 
> It's more than likely that Enterprise PL/I V5.2 can already generate code 
> that utilizes new features of the z14 systems.
> 
> Robert
> --
> Robert AH Prins
> robert.ah.prins(a)gmail.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Someone just too smart for his or her own good?

[Charles Mills]

Why do I keep devoting thought to this?

If you desperately needed to optimize every last cycle out of the loop, and you 
wanted to do this in a supported way, the trick would be two loops. Something 
like

for i = 1 to whatever;
  if a(i) >= 0 then do
sum = sum + a(i);
switch = 1;
break? /* what is the PL/I to exit from a loop? */ ;
  end;
end;

for i = i to whatever;
  if a(i) > 0 then sum = sum + a(i);
end;

I'm not a PL/I coder so not sure if you need a test for i already == whatever 
when it gets to the second loop or whether it has already been incremented, 
etc. 

Probably faster than the original because avoids most of the a(i) == 0 cases.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert Prins
Sent: Friday, August 4, 2017 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Someone just too smart for his or her own good?

On 2017-08-04 13:41, Charles Mills wrote:
> OK, I get it. (Way too much time spent on this now.) The sum is also 
> to be printed if there are any zero values in a[whatever].
> 
> Is this a real business problem or an exercise in whatever?

The original code actually fills a set of buckets with values (or nothing), I 
just simplified the code to a loop over an array, changing the values in the 
array to do some testing, after first figuring out what was going on.

> I don't know the PL/I compiler but on a modern processor Store on 
> Condition potentially makes
> 
> if a(i) >= 0 then switch = 1;

It's more than likely that Enterprise PL/I V5.2 can already generate code that 
utilizes new features of the z14 systems.

Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com

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

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

Re: "-0" (was: Someone just too smart ...?)

[Charles Mills]

I tend to agree. If someone wants to make a "PL/I-checker" that detects general 
bad coding practices I would favor that.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Friday, August 4, 2017 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "-0" (was: Someone just too smart ...?)

OK, I think I may have finally "got" it... if PL/I actually causes that 
declaration to come out as x'000D', then I'd consider that a minor internal 
bug.  In any case it is an internal implementation detail, and anybody that 
depends on it gets what they deserve (horrible surprise) when IBM changes how 
it's implemented.

Still can't see an RFE... One of the things you give up in an HLL is control 
over the binary stuff that comes out of it.  Mind your own business, and let 
the compiler do its thing.

To radically generalize: the fact that something is bad, or is just stupid, is 
not sufficient reason to enact a law against it.

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

Re: z13s IOCP with FTP issue

[Rob Schramm]

Seems like no one has used ftp with server on zOS.

The lack of any sort of log is killing me.

Rob Schramm

On Fri, Aug 4, 2017, 1:25 PM Rob Schramm  wrote:

> HMC SE and the MF lpar are all in the same subnet.
>
> I was wondering if the HMC / SE was using ftp url support
>
> On Fri, Aug 4, 2017, 4:23 AM R.S.  wrote:
>
>> W dniu 2017-08-03 o 15:30, Rob Schramm pisze:
>> > Listers,
>> >
>> > I am having an issue attempting to use FTP to import the IOCP for a new
>> > z13s machine. I can ping the z/OS box that the FTP server is running
>> from
>> > the HMC and the SE.  But when I click " ", I get "File not found on
>> remote
>> > machine. Recheck the file name, and try again.
>> >
>> > My only real complaint, is that there is no log of errors to see what is
>> > happening.  My other question is has anyone actually retrieved the IOCP
>> > deck from a z/OS machine?
>>
>> (Maybe it was already answered, but it's not a crime to help again)
>>
>> You need very specific network connectivity to do that . Your Support
>> Element is connected to a HMC using "internal network", which is usually
>> isolated - only SE's and HMC are in this network. And you have to
>> connect this network to another network where your ftp server reside.
>> That also allows to "Load from DVD or ftp server" - of course in the
>> part of ftp.
>>
>> HTH
>>
>> --
>> 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.plsą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
>>
> --
>
> Rob Schramm
>
-- 

Rob Schramm

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

Re: Someone just too smart for his or her own good?

[Steve Smith]

It's not really a word where I live (OH, USA), but in the words of my
favorite /. sig: "Every now and then I like to masterbate a new word into
my vocabulary, even if I don't know what it means".  ;-)

sas

p.s. seems I don't even know how to spell that word.  Yay for me. :-)

On Fri, Aug 4, 2017 at 10:44 AM, David Crayford  wrote:

> On 4/08/2017 10:03 PM, Steve Smith wrote:
>
>> Using UNSPEC to test the sign is absolutely ridiculous.  Sure, that's "too
>> clever", but it really shows that the writer was a wanker.  Nevertheless,
>> you have no case for an RFE.  Any feature can be abused or misused.
>>
> I'm not sure what wanker means where you live but it probably has a
> different connotation where I do ;) Classic Friday quote.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: PGSER FIX returns CC = 18A Reason=35000301

[Jim Mulder]

  The answer is in the manual:

,EA=end add 
  Specifies the last byte on the last page of the virtual area for R 
requests.


   Your EA specifies the first byte on the next page, which is not 
GETMAINed. 

   What are you doing in the SRB that requires this storage to be fixed 
in 31-bit real storage?

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

> I am getting an error for PGSER Fix that the storage has not been 
getmain'ed
> 
> I have tried different subpool(s)  0 and 10 with same result AND same
> address was returned
> 
> Here is the storage macro whose storage I am trying to fix
> 
>  USING VALSTOR,R3 
>  LAR0,4095 GET LENGTH 
>  AHR0,=H'1' 
>  STORAGE OBTAIN,   X
>LENGTH=(R0),X
>ADDR=(R7),  X
>BNDRY=PAGE, X
>SP=10,  X
>LOC=(31,31) 
>  * 
>  *   Page Fix Ws till SRB completes 
>  * 
>   LRR7,R13 Point to beg of WS 
>   LAR8,4095(,R7)   4K 
>   LAR8,1(,R8) 
> 
> 
>  * 
> 
>   PGSER R, X
> FIX, X
> A=(R7), X
> EA=(R8), X
> ECB=0 



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

Re: z13s IOCP with FTP issue

[Rob Schramm]

HMC SE and the MF lpar are all in the same subnet.

I was wondering if the HMC / SE was using ftp url support

On Fri, Aug 4, 2017, 4:23 AM R.S.  wrote:

> W dniu 2017-08-03 o 15:30, Rob Schramm pisze:
> > Listers,
> >
> > I am having an issue attempting to use FTP to import the IOCP for a new
> > z13s machine. I can ping the z/OS box that the FTP server is running from
> > the HMC and the SE.  But when I click " ", I get "File not found on
> remote
> > machine. Recheck the file name, and try again.
> >
> > My only real complaint, is that there is no log of errors to see what is
> > happening.  My other question is has anyone actually retrieved the IOCP
> > deck from a z/OS machine?
>
> (Maybe it was already answered, but it's not a crime to help again)
>
> You need very specific network connectivity to do that . Your Support
> Element is connected to a HMC using "internal network", which is usually
> isolated - only SE's and HMC are in this network. And you have to
> connect this network to another network where your ftp server reside.
> That also allows to "Load from DVD or ftp server" - of course in the
> part of ftp.
>
> HTH
>
> --
> 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.plsą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
>
-- 

Rob Schramm

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

Re: "-0" (was: Someone just too smart ...?)

[Steve Smith]

OK, I think I may have finally "got" it... if PL/I actually causes that
declaration to come out as x'000D', then I'd consider that a minor
internal bug.  In any case it is an internal implementation detail, and
anybody that depends on it gets what they deserve (horrible surprise) when
IBM changes how it's implemented.

Still can't see an RFE... One of the things you give up in an HLL is
control over the binary stuff that comes out of it.  Mind your own
business, and let the compiler do its thing.

To radically generalize: the fact that something is bad, or is just stupid,
is not sufficient reason to enact a law against it.

sas

On Fri, Aug 4, 2017 at 11:53 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 4 Aug 2017 17:06:52 +0200, Bernd Oppolzer wrote:
> >
> >IMO, the case for the RFE could be
> >that programs that rely on the initialization of
> >
> >DCL SUM DEC FIXED (7) INIT (-0.1);
> >
> >with negative zero (X'000d')
> >should be flagged; this is bad practice, and I would like
> >such initializations to be flagged as ERROR (not only warning)
> >and to be told by the error message, that the initialization will be
> >POSITIVE zero from now on. (Losing decimal digits to the right of
> >the decimal point should only be a warning, IMO).
> >
> The designers of S/360 wisely avoided the "-0" silliness for fixed
> binary by choosing 2's complement ratner than the sign-magnitude
> used by the 7090.  This also avoids the need for a recomplement
> cycle dependent on the sign of the result.
>
> It would have been wiser to make the packed representation 10's
> complement rather than sign-magnitude for similar reasons:
> o No "-0".
> o Five times the range in the same storage.
> o Never a need for a recomplement cycle.
>
> I am not much swayed by the opposing arguments:
> o FORTRAN II relied on "-0" to indicate a blank input field.
> o Sign-magnitude is more legible than complement in a dump.
> o Some theorems in numerical analysis depend on symmetric range.
> o Possible overflow complementing a numbe is harmful.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: "-0" (was: Someone just too smart ...?)

[Charles Mills]

Hollerith card compatibility.

A negative number on a punch card is indicated with a "11-row" overpunch.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, August 4, 2017 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: "-0" (was: Someone just too smart ...?)

On Fri, 4 Aug 2017 17:06:52 +0200, Bernd Oppolzer wrote:
>
>IMO, the case for the RFE could be
>that programs that rely on the initialization of
>
>DCL SUM DEC FIXED (7) INIT (-0.1);
>
>with negative zero (X'000d')
>should be flagged; this is bad practice, and I would like such 
>initializations to be flagged as ERROR (not only warning) and to be 
>told by the error message, that the initialization will be POSITIVE 
>zero from now on. (Losing decimal digits to the right of the decimal 
>point should only be a warning, IMO).
> 
The designers of S/360 wisely avoided the "-0" silliness for fixed binary by 
choosing 2's complement ratner than the sign-magnitude used by the 7090.  This 
also avoids the need for a recomplement cycle dependent on the sign of the 
result.

It would have been wiser to make the packed representation 10's complement 
rather than sign-magnitude for similar reasons:
o No "-0".
o Five times the range in the same storage.
o Never a need for a recomplement cycle.

I am not much swayed by the opposing arguments:
o FORTRAN II relied on "-0" to indicate a blank input field.
o Sign-magnitude is more legible than complement in a dump.
o Some theorems in numerical analysis depend on symmetric range.
o Possible overflow complementing a numbe is harmful.

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

PGSER FIX returns CC = 18A Reason=35000301

[Joe Reichman]

Hi,

 

 

I am getting an error for PGSER Fix that the storage has not been getmain'ed

 

I have tried different subpool(s)  0 and 10 with same result AND same
address was returned

 

Here is the storage macro whose storage I am trying to fix

 

 

 USING VALSTOR,R3   

 LAR0,4095 GET LENGTH   

 AHR0,=H'1' 

 STORAGE OBTAIN,   X

   LENGTH=(R0),X

   ADDR=(R7),  X

   BNDRY=PAGE, X

   SP=10,  X

   LOC=(31,31)  

 

 

 *  

 *   Page Fix Ws till SRB completes 

 *  

  LRR7,R13 Point to beg of WS   

  LAR8,4095(,R7)   4K   

  LAR8,1(,R8)   

 

 

 

 *   

  PGSER R,  X

FIX,X

A=(R7), X

EA=(R8),X

ECB=0


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

Re: XTIOT info

[Lizette Koehler]

So this has been available for some time  

https://www-304.ibm.com/support/docview.wss?uid=isg1OA34634


  Before enabling non-VSAM access methods, BSAM, BPAM, and QSAM, for support of 
dynamic allocation options XTIOT, nocapture UCB, and DSAB above the line (z/OS 
1.12 DFSMSdfp LI957), please review the publication "z/OS V1R12.0 DFSMS Using 
the New Functions",  and determine the necessary steps to take before enabling 
this support system wide via setting the NON_VSAM_XTIOT=YES in the DEVSUPxx 
member of PARMLIB.  Additionally, APAR OA34634 was created as a documentation 
APAR to update some points in "z/OS V1R12.0 DFSMS Using the New Functions."


My understanding is when it is turned on, it makes things happen.  I do not see 
that you can "test" it other than to verify that the XTIOT is being used for 
Non Vsam.

You could probably do that through TSO TEST, XDC, or other tools that could 
look at active storage for the TIOT


Even IPCS may be able to see if your TIOTs are XTIOT

If you have IMS/CICS/DB2 you may want to search the internet for IBM XTIOT and 
see if there were any issues found for these products and XTIOT.  If there 
were, you may want to see if you have the maintenance applied before turning it 
on.  (I think you probably do, but never hurts to check the old stuff)



Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steely.Mark
> Sent: Friday, August 04, 2017 8:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: XTIOT info
> 
> We are z/OS v2.2 and I would like to add NON_VSAM_XTIOT=YES to DEVSUP. I have
> already done this on our sandbox system without any problems.
> 
> I would like to be able to test this out. Does anyone have a program or
> anything else that will allocated a dataset using  XTIOT.
> 
> Any help would be appreciated.
> 
> Thanks
> 

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

Re: Someone just too smart for his or her own good?

[Robert Prins]

On 2017-08-04 13:41, Charles Mills wrote:

OK, I get it. (Way too much time spent on this now.) The sum is also to be
printed if there are any zero values in a[whatever].

Is this a real business problem or an exercise in whatever?


The original code actually fills a set of buckets with values (or nothing), I 
just simplified the code to a loop over an array, changing the values in the 
array to do some testing, after first figuring out what was going on.



I don't know the PL/I compiler but on a modern processor Store on Condition
potentially makes

if a(i) >= 0 then switch = 1;


It's more than likely that Enterprise PL/I V5.2 can already generate code that 
utilizes new features of the z14 systems.


Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com

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

XTIOT info

[Steely.Mark]

We are z/OS v2.2 and I would like to add NON_VSAM_XTIOT=YES to DEVSUP. I have 
already done this on our sandbox system without any problems.

I would like to be able to test this out. Does anyone have a program or 
anything else that will allocated a dataset using  XTIOT. 

Any help would be appreciated. 

Thanks

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

Re: Someone just too smart for his or her own good?

[Bernd Oppolzer]

Am 04.08.2017 um 16:03 schrieb Steve Smith:

In PL/I "FIXED" means neither packed nor binary; it can be either.  The
relevant attribute is "DEC" or "BIN" (short forms), and the default is
"DEC".

Using UNSPEC to test the sign is absolutely ridiculous.  Sure, that's "too
clever", but it really shows that the writer was a wanker.  Nevertheless,
you have no case for an RFE.  Any feature can be abused or misused.


IMO, the case for the RFE could be
that programs that rely on the initialization of

DCL SUM DEC FIXED (7) INIT (-0.1);

with negative zero (X'000d')
should be flagged; this is bad practice, and I would like
such initializations to be flagged as ERROR (not only warning)
and to be told by the error message, that the initialization will be
POSITIVE zero from now on. (Losing decimal digits to the right of
the decimal point should only be a warning, IMO).

BTW, it's not the UNSPEC per se and not the content of the loop,
which is subject of the discussion, IMO. The UNSPEC is needed
if you want to test for negative zero, after all (the UNSPEC is ok,
but the usage in this case is questionable).

See more discussions on this topic on the PL/1 mailing list
(pl...@listserv.dartmouth.edu), if you are interested.

Kind regards

Bernd Oppolzer




Anyway, it's been really difficult to make out what this post is about.
What's with all the discussion about what's in the loop, "negative zero",
etc. if the UNSPEC is the issue?

sas




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

Re: Someone just too smart for his or her own good?

[David Crayford]

On 4/08/2017 10:03 PM, Steve Smith wrote:

Using UNSPEC to test the sign is absolutely ridiculous.  Sure, that's "too
clever", but it really shows that the writer was a wanker.  Nevertheless,
you have no case for an RFE.  Any feature can be abused or misused.
I'm not sure what wanker means where you live but it probably has a 
different connotation where I do ;) Classic Friday quote.


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

Re: Someone just too smart for his or her own good?

[Steve Smith]

In PL/I "FIXED" means neither packed nor binary; it can be either.  The
relevant attribute is "DEC" or "BIN" (short forms), and the default is
"DEC".

Using UNSPEC to test the sign is absolutely ridiculous.  Sure, that's "too
clever", but it really shows that the writer was a wanker.  Nevertheless,
you have no case for an RFE.  Any feature can be abused or misused.

Anyway, it's been really difficult to make out what this post is about.
What's with all the discussion about what's in the loop, "negative zero",
etc. if the UNSPEC is the issue?

sas

On Fri, Aug 4, 2017 at 9:42 AM, Charles Mills  wrote:

>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Friday, August 4, 2017 6:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Someone just too smart for his or her own good?
>
> Oh geez, well then I rest my case that this code is too clever to be
> maintainable. The next programmer might not be any smarter than I.
>
> (I'm not a PL/I expert -- I guess "fixed" means packed? I had guessed
> binary.)
>
> If i is fairly large and there are a good number of a(i) == 0 then my
> point is still valid -- this has to be an expensive way of doing this.
>
> What is the statement of the problem? What is the snippet supposed to
> accomplish? "For a table of packed values a[whatever], print the sum of all
> of the positive values, unless that sum is zero?" Do I have that right?
>
> I would be stunned if the code below performs better than -- and not worse
> than, assuming a fair number of zero values -- the most obvious logic
>
> for i = 1 to whatever;
> if a(i) > 0 then sum = sum + a(i);
> end;
> if sum > 0 then put data(sum);
>
> Charles

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

Re: Someone just too smart for his or her own good?

[Charles Mills]

OK, I get it. (Way too much time spent on this now.) The sum is also to be 
printed if there are any zero values in a[whatever].

Is this a real business problem or an exercise in whatever?

I don't know the PL/I compiler but on a modern processor Store on Condition 
potentially makes 

if a(i) >= 0 then switch = 1;

pretty fast.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, August 4, 2017 6:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Someone just too smart for his or her own good?

Oh geez, well then I rest my case that this code is too clever to be 
maintainable. The next programmer might not be any smarter than I.

(I'm not a PL/I expert -- I guess "fixed" means packed? I had guessed binary.)

If i is fairly large and there are a good number of a(i) == 0 then my point is 
still valid -- this has to be an expensive way of doing this.

What is the statement of the problem? What is the snippet supposed to 
accomplish? "For a table of packed values a[whatever], print the sum of all of 
the positive values, unless that sum is zero?" Do I have that right?

I would be stunned if the code below performs better than -- and not worse 
than, assuming a fair number of zero values -- the most obvious logic

for i = 1 to whatever;
if a(i) > 0 then sum = sum + a(i);
end;
if sum > 0 then put data(sum);

Charles

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

Re: Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog Post)

[Charles Mills]

No offense was intended.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Thursday, August 3, 2017 6:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog 
Post)

> On Aug 3, 2017, at 8:58 AM, Charles Mills  wrote:
> 
>>> The following Christmas party I got brave and went over to the CEO and got 
>>> into a conversation about the issue. 
> 
>> Wow! You're that brave!
> 
> Liquid courage
> 
> CM


Actually, no. I haven’t had a drink in over 30 years.

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

Re: Someone just too smart for his or her own good?

[Charles Mills]

Oh geez, well then I rest my case that this code is too clever to be 
maintainable. The next programmer might not be any smarter than I.

(I'm not a PL/I expert -- I guess "fixed" means packed? I had guessed binary.)

If i is fairly large and there are a good number of a(i) == 0 then my point is 
still valid -- this has to be an expensive way of doing this.

What is the statement of the problem? What is the snippet supposed to 
accomplish? "For a table of packed values a[whatever], print the sum of all of 
the positive values, unless that sum is zero?" Do I have that right?

I would be stunned if the code below performs better than -- and not worse 
than, assuming a fair number of zero values -- the most obvious logic

for i = 1 to whatever;
if a(i) > 0 then sum = sum + a(i);
end;
if sum > 0 then put data(sum);

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert Prins
Sent: Friday, August 4, 2017 2:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Someone just too smart for his or her own good?

On 2017-08-04 00:31, Charles Mills wrote:
> Certainly if one is looking to save a cycle or two then
> 
>if a(i) >= 0 then
>  sum = sum + a(i);
> 
> should be
> 
>if a(i) > 0 then
>  sum = sum + a(i);
> 
> because adding a(i) to sum when a(i) == 0 is a waste of a cycle or two.

Yes, but in this case it *IS* significant, because the initialization of a PL/I 
"FIXED (7)" with -1.0 < init-value < 0 will set it to MINUS zero (zero with a
D-sign) and by adding zero to this will normalize the value to have a C-sign.

As I already write in the title, the gal or guy who wrote this code is just a 
trifle too smart for her or his own good, I've been using PL/I for nearly 32 
years, and until I used UNSPEC() on "sum", the code didn't make any sense to me.

FWIW, my original post contained a type,

if substr(unspec(sum), 25, 8) ^= '0d'bx then

should have been

if substr(unspec(sum), 29, 4) ^= 'd'bx then

or, like in the original code,

if substr(unspec(sum), 8*stg(sum)-3, 4) ^= 'd'bx then

Mea culpa, too much Intel assembler where hex constants must start with a 
zero...

Robert
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Robert Prins
> Sent: Thursday, August 3, 2017 12:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Someone just too smart for his or her own good?
> 
> Just came across the following, and please don't come back with pedantic 
> remarks about undeclared variables, the code is just to show what's there:
> 
> dcl sum fixed (7) init (-0.1);
> 
> for i = 1 to whatever;
>if a(i) >= 0 then
>  sum = sum + a(i);
> end;
> 
> if substr(unspec(sum), 25, 8) ^= '0d'bx then
>put data(sum);
> 
> In other words if all a(i) are negative, nothing is printed. A comment in the 
> code suggests that this is faster code, on modern OoO z/OS systems, than the 
> more logical:
> 
> dcl sum fixed (7) init (-1);
> 
> for i = 1 to whatever;
>if a(i) >= 0 then
>  if sum ^= -1 then
>sum = sum + a(i);
>  else
>sum = a(i);
> end;
> 
> It probably is if the value of whatever is in the order of 42 gazillion, but 
> any other thoughts about this?
> 
> Robert
> --
> Robert AH Prins
> robert.ah.pr...@gmail.com
> Some programming  @ 
> 
> --
> 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
> 


--
Robert AH Prins
robert(a)prino(d)org

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

TSO Help - ISPF Dialog

[Lionel Dyck]

I have released a new ISPF Dialog called ZTSOHELP that presents a searchable
table of TSO Help entries with descriptions.

 

Sample (non graphic as IBM-Main does not allow graphics)

 

Command:  L cmd -Locate  RL - Repeat Locate  O str - Only R -
Refresh

  S cmd -Select  SE - Set Viewer SOrt col A/D - Sort

Line: S -Select

 

Sel  Command   Component  Description

_ACCOUNT TSO  Modify/add/delete user attributes in UADS

_ADDGROUPRACF Add group profile

_ADDSD   RACF Add data set profile

_ADDUSER RACF Add user profile

 

I received a compliment from one site that appears to really like it:

 

ZTSOHELP is the whipped cream on my Hagan Daaz!

 

You can find it at www.lbdsoftware.com   along
with other free, open source (yes there is z/OS open source) tools

 

LIonel


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

RFE submitted [WAS: Someone just too smart for his or her own good?]

[Robert Prins]

On 2017-08-04 07:56, Robert Prins wrote:

On 2017-08-04 00:31, Charles Mills wrote:

Certainly if one is looking to save a cycle or two then

   if a(i) >= 0 then
 sum = sum + a(i);

should be

   if a(i) > 0 then
 sum = sum + a(i);

because adding a(i) to sum when a(i) == 0 is a waste of a cycle or two.


Yes, but in this case it *IS* significant, because the initialization of a PL/I 
"FIXED (7)" with -1.0 < init-value < 0 will set it to MINUS zero (zero with a 
D-sign) and by adding zero to this will normalize the value to have a C-sign.


As I already write in the title, the gal or guy who wrote this code is just a 
trifle too smart for her or his own good, I've been using PL/I for nearly 32 
years, and until I used UNSPEC() on "sum", the code didn't make any sense to me.


FWIW, my original post contained a type,

if substr(unspec(sum), 25, 8) ^= '0d'bx then

should have been

if substr(unspec(sum), 29, 4) ^= 'd'bx then

or, like in the original code,

if substr(unspec(sum), 8*stg(sum)-3, 4) ^= 'd'bx then

Mea culpa, too much Intel assembler where hex constants must start with a 
zero...


Following myself, I've submitted this RFE requesting an I- or W-type message to 
flag this kind of (too) clever code, or a new RULES() option to outright ban it 
with an E-type message:


http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=108713

Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
Some programming  @ 

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

Re: z13s IOCP with FTP issue

[R.S.]

W dniu 2017-08-03 o 15:30, Rob Schramm pisze:

Listers,

I am having an issue attempting to use FTP to import the IOCP for a new
z13s machine. I can ping the z/OS box that the FTP server is running from
the HMC and the SE.  But when I click " ", I get "File not found on remote
machine. Recheck the file name, and try again.

My only real complaint, is that there is no log of errors to see what is
happening.  My other question is has anyone actually retrieved the IOCP
deck from a z/OS machine?


(Maybe it was already answered, but it's not a crime to help again)

You need very specific network connectivity to do that . Your Support 
Element is connected to a HMC using "internal network", which is usually 
isolated - only SE's and HMC are in this network. And you have to 
connect this network to another network where your ftp server reside.
That also allows to "Load from DVD or ftp server" - of course in the 
part of ftp.


HTH

--
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.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: Someone just too smart for his or her own good?

[Robert Prins]

On 2017-08-04 00:31, Charles Mills wrote:

Certainly if one is looking to save a cycle or two then

   if a(i) >= 0 then
 sum = sum + a(i);

should be

   if a(i) > 0 then
 sum = sum + a(i);

because adding a(i) to sum when a(i) == 0 is a waste of a cycle or two.


Yes, but in this case it *IS* significant, because the initialization of a PL/I 
"FIXED (7)" with -1.0 < init-value < 0 will set it to MINUS zero (zero with a 
D-sign) and by adding zero to this will normalize the value to have a C-sign.


As I already write in the title, the gal or guy who wrote this code is just a 
trifle too smart for her or his own good, I've been using PL/I for nearly 32 
years, and until I used UNSPEC() on "sum", the code didn't make any sense to me.


FWIW, my original post contained a type,

if substr(unspec(sum), 25, 8) ^= '0d'bx then

should have been

if substr(unspec(sum), 29, 4) ^= 'd'bx then

or, like in the original code,

if substr(unspec(sum), 8*stg(sum)-3, 4) ^= 'd'bx then

Mea culpa, too much Intel assembler where hex constants must start with a 
zero...

Robert


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert Prins
Sent: Thursday, August 3, 2017 12:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Someone just too smart for his or her own good?

Just came across the following, and please don't come back with pedantic 
remarks about undeclared variables, the code is just to show what's there:

dcl sum fixed (7) init (-0.1);

for i = 1 to whatever;
   if a(i) >= 0 then
 sum = sum + a(i);
end;

if substr(unspec(sum), 25, 8) ^= '0d'bx then
   put data(sum);

In other words if all a(i) are negative, nothing is printed. A comment in the 
code suggests that this is faster code, on modern OoO z/OS systems, than the 
more logical:

dcl sum fixed (7) init (-1);

for i = 1 to whatever;
   if a(i) >= 0 then
 if sum ^= -1 then
   sum = sum + a(i);
 else
   sum = a(i);
end;

It probably is if the value of whatever is in the order of 42 gazillion, but 
any other thoughts about this?

Robert
--
Robert AH Prins
robert.ah.pr...@gmail.com
Some programming  @ 

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




--
Robert AH Prins
robert(a)prino(d)org

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

Re: Someone just too smart for his or her own good?

[Kenneth J. Kripke]

>dcl sum fixed (7) init (-0.1);/* Packed Decimal? */

 

>for i = 1 to whatever;

>  if a(i) >= 0 then

>sum = sum + a(i);

> 

And there, at least I'd do:

>  if a(i) >  0 then

>sum = sum + a(i);

> 

as long as testing, why bother to add 0?

 

>if substr(unspec(sum), 25, 8) ^= '0d'bx then/* test the sign of the
number? */

>  put data(sum);

> 

Unspec function returns a binary representation 

 

Sincerely;  

 

Kenneth J. Kripke

 

kennethkri...@gmail.com 

 


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