Re: Rexx and member statistics question

[Elardus Engelbrecht]

Ze'ev Atlas wrote:

>I have to take it back
>In one of the libraries, I consistently have an empty line as the first line 
>and I did do some of my tests on that library.

This is WAD. You read something empty, then REXX processes stops.

>Mystery resolved!

Good! One riddle solved in 2015! ;-)

Anyways, I don't believe member stats have any influence in reading and writing 
of members in PDS. In fact, I have several REXX programs in Batch Jobs 
reading/writing members as generated by IEBGENER for example (which caused no 
member stats to be written at all, since AFAIK, IEBGENER does not update member 
stats)

AFAIK, Member stats are ONLY used by ISPF and other products (if they are 
designed to do that stats).

PS: I don't have any access to my z/OS toy for now... so above is based on my 
faulty decaying memory... 

Groete / Greetings
Elardus Engelbrecht

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

So Long, and Thanks For All The Fish

[Shane Ginnane]

Shane ...

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

Re: So Long, and Thanks For All The Fish

[Andre Massena]

An this as well - 
http://www.theregister.co.uk/2015/12/30/ian_murdock_debian_founder/




 Message d'origine 
De : Shane Ginnane 
À : IBM-MAIN@LISTSERV.UA.EDU
Objet : So Long, and Thanks For All The Fish
Date : 31/12/2015 15:47:04 CET

Shane ...

--
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: IXGLOGR on RSM usage

[Andrew Metcalfe]

I'm not aware, but that doesn't mean there isn't!

I seem to remember the page fixing (RSM use) for logstream mode SMF being 
specific to SMF's use of dataspaces and not necessarily System Logger's real 
storage use itself. There may have been something in the SMF Logstream Redbook 
that made me think that.

Andrew


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nathan Astle
Sent: 30 December 2015 18:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IXGLOGR on RSM usage

Hi Andrew

Thank you for the pointer which helped me in tuning up the SMF logstream.

So when it comes to other logstream structures for DB2,CICS. Is there a way to 
limit their RSM usage as well ?

Nathan


On Wednesday 23 December 2015, Elardus Engelbrecht < 
elardus.engelbre...@sita.co.za> wrote:

> Andrew Metcalfe wrote:
>
> >Do you have SMF in Logstream mode?
>
> The OP said he has SMF in Logstream in thread 'Re: S00C Slip trap for 
> any Stc'.
>
> He wrote: "Our SMF logstream has been defined in IXGLOGR with dasdonly. "
>
>
> >If so how many logstreams are defined? Each logstream has its own
> dataspace/buffers. There are some parameters which govern 
> Logstream/SMF real storage requirements that you may need to tune.
>
> Good questions. Thanks for asking.
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>

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

This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.

Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.

Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). 
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. 

Barclays Bank PLC is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority (Financial Services Register No. 122702).

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

Re: Rexx and member statistics question

[Paul Gilmartin]

On Thu, 31 Dec 2015 09:05:20 +0200, Itschak Mugzach wrote:

>You might have blanks lines in input. Stem . It stops the writing of the stem 
>to dataset. Try changing null lines to blanks.
> 
No!  If the programmer's intent is to copy a file unchanged, the
programmer shouldn't change the content of any line.


On Thu, 31 Dec 2015 03:20:32 -0600, Elardus Engelbrecht wrote:
>
>This is WAD. You read something empty, then REXX processes stops.
> 
It does not; it faithfully creates a corresponding empty item in the input STEM.

>Anyways, I don't believe member stats have any influence in reading and 
>writing of members in PDS. In fact, I have several REXX programs in Batch Jobs 
>reading/writing members as generated by IEBGENER for example (which caused no 
>member stats to be written at all, since AFAIK, IEBGENER does not update 
>member stats)
>
For example, NFS, and perhaps FTP, update member stats.

Why do people have such cognitive dissonance with the concept of empty records?
Ever since the advent of Arabic numerals, zero has been recognized as a valid
number.  Or should be.

-- gil

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

Re: So Long, and Thanks For All The Fish

[Bigendian Smalls]

That is a devastating loss.  And sounds like bizarre circumstances-yet to get 
all the details. 

> On Dec 31, 2015, at 09:00, Andre Massena  wrote:
> 
> An this as well - 
> http://www.theregister.co.uk/2015/12/30/ian_murdock_debian_founder/
> 
> 
> 
> 
>  Message d'origine 
> De : Shane Ginnane 
> À : IBM-MAIN@LISTSERV.UA.EDU
> Objet : So Long, and Thanks For All The Fish
> Date : 31/12/2015 15:47:04 CET
> 
> Shane ...
> 
> --
> 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: So Long, and Thanks For All The Fish

[Aled Hughes]

Best of luck Shane - enjoy your time, and don't think twice about us lot still 
slaving over z/OS ;-)
 

 

 

-Original Message-
From: Shane Ginnane 
To: IBM-MAIN 
Sent: Thu, 31 Dec 2015 9:47
Subject: So Long, and Thanks For All The Fish

Shane ...

--
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: So Long, and Thanks For All The Fish

[Farley, Peter x23353]

Best of luck Shane, and enjoy life.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: Thursday, December 31, 2015 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: So Long, and Thanks For All The Fish

Shane ...
--


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


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

Sample Programs for WebSphere MQ for z/OS V8.0.0?

[Hansen, Dave L - Eagan, MN]

Hello,

   I am looking for a sample program for MQ.  I can find a lot of CICS COBOL 
samples for programs that prompt and get back text.  For MQ I found the 
examples in the Application Programming Guide, but it looks like they are batch 
jobs.  One will connect, but a different one disconnects.

  Q).  Is there a sample program for MQ that is a CICS online program instead 
of MQ batch?  I'd take Assembler if there is a good example (they don't even 
load the sample libraries for Assembler here).


  Thanks to everybody for all there help through the year, Dave

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

Re: So Long, and Thanks For All The Fish

[Tom Marchant]

Best wishes Shane. Your wit and your knowledge will be missed.

-- 
Tom Marchant

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

Re: So Long, and Thanks For All The Fish

[Bigendian Smalls]

Apologies to Shane I hadn't read beyond the first reply.  Best sir. 

> On Dec 31, 2015, at 09:58, Bigendian Smalls  
> wrote:
> 
> That is a devastating loss.  And sounds like bizarre circumstances-yet to get 
> all the details. 
> 
>> On Dec 31, 2015, at 09:00, Andre Massena  wrote:
>> 
>> An this as well - 
>> http://www.theregister.co.uk/2015/12/30/ian_murdock_debian_founder/
>> 
>> 
>> 
>> 
>>  Message d'origine 
>> De : Shane Ginnane 
>> À : IBM-MAIN@LISTSERV.UA.EDU
>> Objet : So Long, and Thanks For All The Fish
>> Date : 31/12/2015 15:47:04 CET
>> 
>> Shane ...
>> 
>> --
>> 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: So Long, and Thanks For All The Fish

[Longabaugh, Robert E]

Good Luck to you Shane


Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Thursday, December 31, 2015 3:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: So Long, and Thanks For All The Fish

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DN-5FdUmDBfp6k=CwIGaQ=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM=o2gVjNZ9TdK6lLWT_C1wblxP02_yu_2JweU5e56_KLo=ldI_LXEDIHmJJS1V-vNMiGV9tPTxaHL7aHIORSCXuvI=
 



Shane,



Good luck in all your endeavors! 



I leave you with the following response:  
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DSJUhlRoBL8M=CwIGaQ=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM=o2gVjNZ9TdK6lLWT_C1wblxP02_yu_2JweU5e56_KLo=MlaQgklrm1EvKcYockXbax4dC9Edh9WpUzqaYbl7F-Q=
 



Bob



 



-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane

Sent: Thursday, December 31, 2015 9:47 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: So Long, and Thanks For All The Fish



Shane ...





--

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

Acessing storage in a other address space

[michealbutz]

Hi

 

I am trying to access storage in a other address space

 

I am logged on to TSOA and am running the following code under TESTAUTH

 

  L R5,0(,R5) 

  USING ASCB,R5   

  L R6,ASCBASSB   

  USING ASSB,R6   

  MVC   STOKENC,ASSBSTKN   Get the job's STOKEN   

  MODESET KEY=ZERO,MODE=SUP   

  XR R1,R1

 

 

 

  ALESERV ADD,  X

STOKEN=STOKENC, X

CHKEAX=NO,  X

ACCESS=PUBLIC,  X

ALET=ALET,  X

 

 

 LA  R0,111 

 STORAGE OBTAIN,   X

   LENGTH=(R0),X

   ADDR=(R9),  X

   SP=0,   X

   BNDRY=DBLWD,X

   ALET=ALET

 

LATER ON I go to into access register mode 

SAC 512

 

And Move data to the storage area

after doing so I versify the move under TESTAUTH

 

Via 

 

L 9R? AR(9) L(111) XC

 

However in the target address space using TASID Storage View Option 

the data I see at the address is not there, I am still under TESTAUTH at
this

point (meaningthe task hasn't ended) in the first address space

 

both ALESERV and Storage have return code zeros

 

Thanks in Advance  

 

  


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

Re: So Long, and Thanks For All The Fish

[Richards, Robert B.]

https://www.youtube.com/watch?v=N_dUmDBfp6k

Shane,

Good luck in all your endeavors! 

I leave you with the following response:  
https://www.youtube.com/watch?v=SJUhlRoBL8M

Bob

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: Thursday, December 31, 2015 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: So Long, and Thanks For All The Fish

Shane ...


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

Re: So Long, and Thanks For All The Fish

[Pinnacle]

On 12/31/2015 9:47 AM, Shane Ginnane wrote:

Shane ...

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



Happy New Yeah, ya bugga!  All the best in your new endeavours.

Tom

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

Re: So Long, and Thanks For All The Fish

[Scott Fagen]

Enjoy and don't be a stranger!

Scott
--
Chief Architect - z Systems
CA Technologies

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

Re: So Long, and Thanks For All The Fish

[Paul Gillis]

Always enjoyed reading your posts, enjoy life away from us.

Regards,
Paul Gillis

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: Friday, 1 January 2016 1:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: So Long, and Thanks For All The Fish

Shane ...

--
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: COBOL Code Gened for MOVE COMP-3 S9(9) to S9(8)

[Dale R. Smith]

On Sun, 13 Dec 2015 14:53:27 -0600, David Speake  
wrote:

>A coworker posed the following question.
>
>Given a COBOL statement that moves a field defined as S9(9) comp-3 
>to a field defined S9(8) comp-3, the generated assembler code looks like this:
>   
>   01A598  D204 5E58 17B3  MVC   3672(5,5),1971(1)   
>   01A59E  940F 5E58   NI3672(5),X'0F'   
>   01A5A2  F844 5E58 5E58  ZAP   3672(5,5),3672(5,5)
>
>I know the following:
>1. The program was compiled with the TRUNC option
>2. The source and target field are the same length (5 bytes)
>3. the first line does the actual move
>4. the second line is generated because the TRUNC compile option
>
>So why is IBM generating the ZAP instruction?
>The only use to this is to abend with S0C7 if the data is garbage.
>Right?
>
>I too can see no good reason for ZAP.
>Not a pressing issue, just both puzzled.

I had meant to reply to this earlier, but unfortunately, work and the holidays 
intervened!  :-)>

The TRUNC option only applies to Binary (COMP) fields, not Packed (COMP-3) 
fields.  The generated code is the result of compiling the program with the 
NOOPTimize option.  If OPTimize(STD) or OPTimize(FULL) is used, then the 
generated code will only contain an MVC instruction.  We have our default set 
to OPT(STD) as this generates better code but still allows Debug and Fault 
Analyzer to work.

The ZAP instruction will also appear in instructions that add/subtract to/from 
Packed fields.  The reason is because COBOL II (and beyond) will sometimes use 
CLC to compare two Packed fields instead of a Compare Packed (CP) instruction.  
This introduces a potential problem if the result of the computations is 
negative zero!  For example, two S9(3) COMP-3 fields, (FLD1 = -999 and FLD2 = 
-1), are added together, the result is negative zero with the overflow flag 
set.  The ZAP will change -0 to +0, but leave other values unchanged.  Thus 
zero fields would always compare equal with CLC.  If ON SIZE ERROR is used on 
the ADD or SUBTRACT, then the ZAP instruction is not generated.  The 
performance gain of using CLC instead of CP is somewhat offset by having the 
extra ZAP instruction added.

IMNSHO, Packed fields should always be defined with an odd number of digits in 
COBOL programs.  Packed fields always contain an odd number of digits so why 
would you create extra work for the compiler and the programmer by defining a 
Packed field with an even number of digits?  If you want an even number of 
digits on report, then define the edited output field with even number of 
digits.  In COBOL V5.2 they have added a new RULES compiler option and one of 
the new rules that can be used is NOEVENPACK.  NOEVENPACK will issue Warning 
messages for Packed fields with an even number of digits!

-- 
Dale R. Smith

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