Re: Storage Obtain .....

[Charles Mills]

> That clear more storage than they requested?

No, I meant, that GETMAIN zero bytes.

Don't want to get into a hissing contest. How many angels can dance on zero
bytes of dynamic storage? Less than one nano-cherub.

Any program that GETMAINs zero bytes and then "uses" the storage deserves
what it gets.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tony Harminc
Sent: Wednesday, February 12, 2014 6:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

On 12 February 2014 20:07, Charles Mills  wrote:
>> Sure - it could assign one. It wouldn't have to be unique; just
> access-exception correct.
>
> And then the OP would have cleared that "dummy" storage area passed 
> back from OBTAIN and wondered how _that_ happened.

If you clear only your requested 0 bytes of the area, all should be well.
MVCL and friends would work fine for that.

> I don't see how IBM solves it without creating a nightmare for some number
of programs that do this.

That clear more storage than they requested?

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

Re: Getting style sheets to work under IBM HTTP Server

[Scott Ford]

Dana:

By doing some googles on FSUM7332 REXX ..there were several hits all talk about 
syntax errors, that's the first place I would start.

Scott ford
www.identityforge.com
from my IPAD




> On Feb 12, 2014, at 4:03 PM, Dana Mitchell  wrote:
> 
> I'm working on creating some web pages in a REXX CGI served up with IBM HTTP 
> Server V5R3M0  but I can't get it to work. (the REXX and the html was working 
> by itself, before I started trying to move the formatting to a css file).
> 
> In my REXX CGI I have coded:
> say ''   
> say ''
> say ''  
> 
> sample.css contains:
> body {font-family: arial;  }  
>  
> h1 {background-color:#CCC;border: 1px solid;color:#39F;
> text-align: center; }
> table {  background-color: #F60;border: 1px solid #39F;width: 100%;   
>  }
> td {border: 0px;text-align: center;}  
>   
> p {color:#09F;text-indent: 20px;} 
>   
> 
> When I call the REXX,  in cgi-error.Feb122014 gets this message:
> /usr/lpp/internet/server_root/cgi-bin/sample.css 1: FSUM7332 syntax error: 
> got }, expecting Newline   
> 
> Has anybody done this and gotten it to work?  whats the trick I'm missing?
> 
> thanks
> Dana
> 
> --
> 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: Storage Obtain .....

[Tony Harminc]

On 12 February 2014 20:07, Charles Mills  wrote:
>> Sure - it could assign one. It wouldn't have to be unique; just
> access-exception correct.
>
> And then the OP would have cleared that "dummy" storage area passed back
> from OBTAIN and wondered how _that_ happened.

If you clear only your requested 0 bytes of the area, all should be
well. MVCL and friends would work fine for that.

> I don't see how IBM solves it without creating a nightmare for some number of 
> programs that do this.

That clear more storage than they requested?

Tony H.

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

Re: Users of CSP and its successor migrating to COBOL 5.1

[Clark Morris]

On 12 Feb 2014 13:59:28 -0800, in bit.listserv.ibm-main you wrote:

>>If your shop uses an IBM z series computer and it is looking to
>>upgrade to version 5.1 of Enterprise COBOL and it is using Cross
>>System Product (CSP) or its Visual Gen successor, migration may be a
>>problem.  CSP and possibly its successor forced an F zone on all
>>signed fields with positive values leaving the D zone for negative
>>fields.  The elimination of NUMPROC(MIG) means this behavior if still
>>existing can cause problems.
>
>In fact, there is nothing to worry  about, please check before
>raising unnecessary worries.
>
>Enterprise COBOL V5 has exactly the same sign behavior as COBOL V4
>for CSP, VA Gen and EGL COBOL programs.
>In particular, CSP (and EGL COBOL) require NUMPROC(NOPFD), from the
>EGL COBOL help at:
>http://pic.dhe.ibm.com/infocenter/rbdhelp/v8r5m0/index.jsp?topic=%2Fcom
>.ibm.egl.gg.doc%2Ftopics%2Fgegl_cobol_modifybuildscriptszos.html

If other programs that handle files created by CSP (and maybe its
successors) were using NUMPROC(MIG) because it was more efficient than
NUMPROC(NOPFD), then those programs may have to be recompiled with
NUMPROC(NOPFD) because there can be problems.  I ran into that with a
program that for whatever reason did an IF NUMERIC test of a field
that had be affected by CSP and using NUMPROC(PFD) with that program
caused the field to test not numeric.  Recompiling the program in
question with NUMPROC(MIG) solved the problem.  The problem is not the
compiler options used for the COBOL generation of CSP programs, the
problem is the compiler options of the programs that use the output
from CSP programs.

Why was NUMPROC(MIG) eliminated?

Clark Morris


>
>Required options for COBOL compiler for z/OS
>The following options are required for the z/OS COBOL compiler
>and are included in the FDABCL, FDABPTCL, FDABTCL, FDACL, FDAPCL,
>FDAPTCL, and FDATCL build scripts:
>
>LIB
>NODYNAM (as further described later)
>NUMPROC(NOPFD)
>NOSEQ
>QUOTE
>RENT
>TRUNC(BIN)  (requirement removed in later fixpacks)
>
>Cheers,
>TomR  >> COBOL is the Language of the Future! <<
>
>--
>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: Storage Obtain .....

[Paul Gilmartin]

On Wed, 12 Feb 2014 18:39:14 -0500, Tony Harminc wrote:
>
>> ..., freeing zero length is an instant disaster.
>
That ought to be a no-op.

>You can't free 0 bytes at address 0? Now that is an inconsistency. Ah
>- the subpool thing on FREEMAIN. Is that also true for STORAGE
>RELEASE?
>
The "subpool thing" oughtn't be checked unless one or more bytes are
to be freed.

>>> So to be consistent, a non-zero address with appropriate access setup
>>> (primarily key) should probably be returned.
>
>> Consistent with what? It can't return an address because one wasn't assigned.
>
>Sure - it could assign one. It wouldn't have to be unique; just
>access-exception correct.
>
This is somewhat reminiscent of allocating a data set with VOL=SER=xx,
SPACE=(CYL,0), when no space exists on volume xx, which I am told
succeeds.  I hope, likewise,  that such a data set can be freed without a
check of the validity of the primary extent.

-- gil

>Tony H.
>
>--
>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: Storage Obtain .....

[Charles Mills]

> Sure - it could assign one. It wouldn't have to be unique; just
access-exception correct.

And then the OP would have cleared that "dummy" storage area passed back
from OBTAIN and wondered how _that_ happened. 

I don't see how IBM solves it without creating a nightmare for some number
of programs that do this.

Here's a solution for all those who want it to ABEND: follow every GETMAIN
or OBTAIN in your code with MVI 0(R1),0 and you will S0C4 if you asked for
zero bytes.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tony Harminc
Sent: Wednesday, February 12, 2014 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

On 12 February 2014 18:22, Gerhard Postpischil  wrote:
> On 2/12/2014 6:06 PM, Tony Harminc wrote:
>>
>> I object far more to returning an address of 0 than to accepting a 
>> length of 0 on the request. To be sure, you are allowed to store no 
>> more than 0 bytes in your obtained area, so the 0 address sounds 
>> reasonable, but some instructions are allowed by the architecture to 
>> recognize access exceptions in the case where no data is stored, e.g.
>> STCM with a zero mask.

> The way I get and free storage, I'd be happier with an abend (R form) 
> or non-zero return code.

Sure, but as said, that's not going to happen for reasons of compatibility.

> I generally save the length, and then do a FREEMAIN (or STORAGE 
> RELEASE) using the saved length. If the GETMAIN/OBTAIN was accepted, 
> freeing zero length is an instant disaster.

You can't free 0 bytes at address 0? Now that is an inconsistency. Ah
- the subpool thing on FREEMAIN. Is that also true for STORAGE RELEASE?

>> So to be consistent, a non-zero address with appropriate access setup 
>> (primarily key) should probably be returned.

> Consistent with what? It can't return an address because one wasn't
assigned.

Sure - it could assign one. It wouldn't have to be unique; just
access-exception correct.

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

Re: Storage Obtain .....

[Paul Gilmartin]

On Wed, 12 Feb 2014 18:06:56 -0500, Tony Harminc  wrote:
>
>..., but some instructions are allowed by the architecture to
>recognize access exceptions in the case where no data is stored, e.g.
>STCM with a zero mask.
>
Ouch!  How does this work when the 4 bytes that might be accessed
span a page boundary so that some might be accessible and others
not?  If no bytes selected by the mask are inaccessible, there should
be no access exception *except* that for recognizing access exceptions
the behavior is may be as if one (only?) byte were selected, even if the
mask is zero?  Ouch!  Or may recognizing access exceptions be
performed as if the mask were B''?  Ouch!

Is recognizing an access exception performed according to rules different
from recognizing a protection exception when a page might be accessible
but not writable?

-- gil

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

Re: Storage Obtain .....

[Tony Harminc]

On 12 February 2014 18:22, Gerhard Postpischil  wrote:
> On 2/12/2014 6:06 PM, Tony Harminc wrote:
>>
>> I object far more to returning an address of 0 than to accepting a
>> length of 0 on the request. To be sure, you are allowed to store no
>> more than 0 bytes in your obtained area, so the 0 address sounds
>> reasonable, but some instructions are allowed by the architecture to
>> recognize access exceptions in the case where no data is stored, e.g.
>> STCM with a zero mask.

> The way I get and free storage, I'd be happier with an abend (R form) or
> non-zero return code.

Sure, but as said, that's not going to happen for reasons of compatibility.

> I generally save the length, and then do a FREEMAIN
> (or STORAGE RELEASE) using the saved length. If the GETMAIN/OBTAIN was
> accepted, freeing zero length is an instant disaster.

You can't free 0 bytes at address 0? Now that is an inconsistency. Ah
- the subpool thing on FREEMAIN. Is that also true for STORAGE
RELEASE?

>> So to be consistent, a non-zero address with appropriate access setup
>> (primarily key) should probably be returned.

> Consistent with what? It can't return an address because one wasn't assigned.

Sure - it could assign one. It wouldn't have to be unique; just
access-exception correct.

Tony H.

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

Re: Storage Obtain .....

[Gerhard Postpischil]

On 2/12/2014 6:06 PM, Tony Harminc wrote:

I object far more to returning an address of 0 than to accepting a
length of 0 on the request. To be sure, you are allowed to store no
more than 0 bytes in your obtained area, so the 0 address sounds
reasonable, but some instructions are allowed by the architecture to
recognize access exceptions in the case where no data is stored, e.g.
STCM with a zero mask.


The way I get and free storage, I'd be happier with an abend (R form) or 
non-zero return code. I generally save the length, and then do a 
FREEMAIN (or STORAGE RELEASE) using the saved length. If the 
GETMAIN/OBTAIN was accepted, freeing zero length is an instant disaster.



So to be consistent, a non-zero address with appropriate access setup
(primarily key) should probably be returned.


Consistent with what? It can't return an address because one wasn't 
assigned.



Now if you ask me how I would prioritize this requirement...


I'd like it fixed immediately, but honestly couldn't justify this as 
more important than a level 3, just above a DOC.



Gerhard Postpischil
Bradford, Vermont

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

Re: Storage Obtain .....

[Tony Harminc]

On 12 February 2014 14:21, Jim Mulder  wrote:
> When a length of 0 is requested on GETMAIN or STORAGE OBTAIN,
> VSM treats this as a successful request, and returns an address of 0.
> In my opinion, this was a poor design choice, made long before my time,
> and I have seen it lead to diagnosis confusion like this several times
> over the years. I would have preferred to abend when a length of 0
> is requested. But it has worked this way since at least MVS/370,
> and maybe even long before that, so for compatibility reasons,
> we do not change it.

I object far more to returning an address of 0 than to accepting a
length of 0 on the request. To be sure, you are allowed to store no
more than 0 bytes in your obtained area, so the 0 address sounds
reasonable, but some instructions are allowed by the architecture to
recognize access exceptions in the case where no data is stored, e.g.
STCM with a zero mask.

So to be consistent, a non-zero address with appropriate access setup
(primarily key) should probably be returned.

Now if you ask me how I would prioritize this requirement...

Tony H.

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

Re: Was: Implicit VVDS creation now: FDR & VVDS's

[DASDBILL2]

FDR used to be only one product, now it is a family of products.  The name of 
the company, however, is Innovation Data Processing in Little Falls, New 
Jersey. 
Bill Fairchild 

- Original Message -

From: "Shmuel Metz (Seymour J.)"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 12, 2014 7:05:53 AM 
Subject: Re: Was: Implicit VVDS creation now: FDR & VVDS's 

In <476fd1b4-cd31-49e7-bba2-d719c96b7...@comcast.net>, on 02/11/2014 
   at 01:40 PM, Ed Gould  said: 

>I am trying to remember if FDR consolidates the SYS1.VVDS extents   

FDR is a company that sells several products; which are you licensed 
for? 
  
-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT 
     ISO position; see  
We don't care. We don't have to care, we're Congress. 
(S877: The Shut up and Eat Your spam act of 2003) 

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

Users of CSP and its successor migrating to COBOL 5.1

[Tom Ross]

>If your shop uses an IBM z series computer and it is looking to
>upgrade to version 5.1 of Enterprise COBOL and it is using Cross
>System Product (CSP) or its Visual Gen successor, migration may be a
>problem.  CSP and possibly its successor forced an F zone on all
>signed fields with positive values leaving the D zone for negative
>fields.  The elimination of NUMPROC(MIG) means this behavior if still
>existing can cause problems.

In fact, there is nothing to worry  about, please check before
raising unnecessary worries.

Enterprise COBOL V5 has exactly the same sign behavior as COBOL V4
for CSP, VA Gen and EGL COBOL programs.
In particular, CSP (and EGL COBOL) require NUMPROC(NOPFD), from the
EGL COBOL help at:
http://pic.dhe.ibm.com/infocenter/rbdhelp/v8r5m0/index.jsp?topic=%2Fcom
.ibm.egl.gg.doc%2Ftopics%2Fgegl_cobol_modifybuildscriptszos.html

Required options for COBOL compiler for z/OS
The following options are required for the z/OS COBOL compiler
and are included in the FDABCL, FDABPTCL, FDABTCL, FDACL, FDAPCL,
FDAPTCL, and FDATCL build scripts:

LIB
NODYNAM (as further described later)
NUMPROC(NOPFD)
NOSEQ
QUOTE
RENT
TRUNC(BIN)  (requirement removed in later fixpacks)

Cheers,
TomR  >> COBOL is the Language of the Future! <<

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

Re: Getting style sheets to work under IBM HTTP Server

[Dana Mitchell]

Kirk,

Yes, that was it.  Moved it to the /pub directory and it works perfect.  Thanks!

Dana

On Wed, 12 Feb 2014 15:33:39 -0600, Kirk Wolf  wrote:

>The FSUM7332 message is from the z/OS Shell.
>So, it appears to me that the .css file is being treated as a shell script.
>You don't say which version of HTTP server you are using, but I think that
>the problem is that your directives are set up so that this .css file is
>being treated as an executable (CGI) - probably because it is in the
>cgi-bin directory.
>
>Kirk Wolf
>Dovetailed Technologies
>http://dovetail.com
>
>
>On Wed, Feb 12, 2014 at 3:29 PM, Dana Mitchell  wrote:
>
>> I think it's finding it because the message refers to the real location:
>>
>> /usr/lpp/internet/server_root/cgi-bin/sample.css
>>
>>
>> but I tried it that way and it does the same thing
>>
>> Dana
>>
>> --
>> 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: Getting style sheets to work under IBM HTTP Server

[Kirk Wolf]

The FSUM7332 message is from the z/OS Shell.
So, it appears to me that the .css file is being treated as a shell script.
You don't say which version of HTTP server you are using, but I think that
the problem is that your directives are set up so that this .css file is
being treated as an executable (CGI) - probably because it is in the
cgi-bin directory.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com


On Wed, Feb 12, 2014 at 3:29 PM, Dana Mitchell  wrote:

> I think it's finding it because the message refers to the real location:
>
> /usr/lpp/internet/server_root/cgi-bin/sample.css
>
>
> but I tried it that way and it does the same thing
>
> Dana
>
> --
> 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: Getting style sheets to work under IBM HTTP Server

[Dana Mitchell]

I think it's finding it because the message refers to the real location:

/usr/lpp/internet/server_root/cgi-bin/sample.css 


but I tried it that way and it does the same thing

Dana

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

Re: Getting style sheets to work under IBM HTTP Server

[Grinsell, Don]

Where does the css file actually reside?  What happens if you fully qualify the 
href?

say 'http://server/path/sample.css"; />'


--
 
Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov

"I love deadlines.  I love the whooshing sound they make as they fly by."  
~ Douglas Adams

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Wednesday, February 12, 2014 2:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Getting style sheets to work under IBM HTTP Server

I'm working on creating some web pages in a REXX CGI served up with IBM HTTP 
Server V5R3M0  but I can't get it to work. (the REXX and the html was working 
by itself, before I started trying to move the formatting to a css file).

In my REXX CGI I have coded:
say ''   
say ''  

sample.css contains:
body {font-family: arial;  }
   
h1 {background-color:#CCC;border: 1px solid;color:#39F;
text-align: center; }
table {  background-color: #F60;border: 1px solid #39F;width: 100%;
}
td {border: 0px;text-align: center;}

p {color:#09F;text-indent: 20px;}   


When I call the REXX,  in cgi-error.Feb122014 gets this message:
/usr/lpp/internet/server_root/cgi-bin/sample.css 1: FSUM7332 syntax error: got 
}, expecting Newline   

Has anybody done this and gotten it to work?  whats the trick I'm missing?

thanks
Dana

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

Getting style sheets to work under IBM HTTP Server

[Dana Mitchell]

I'm working on creating some web pages in a REXX CGI served up with IBM HTTP 
Server V5R3M0  but I can't get it to work. (the REXX and the html was working 
by itself, before I started trying to move the formatting to a css file).

In my REXX CGI I have coded:
say ''   
say ''
say ''  

sample.css contains:
body {font-family: arial;  }
   
h1 {background-color:#CCC;border: 1px solid;color:#39F;
text-align: center; }
table {  background-color: #F60;border: 1px solid #39F;width: 100%;
}
td {border: 0px;text-align: center;}

p {color:#09F;text-indent: 20px;}   


When I call the REXX,  in cgi-error.Feb122014 gets this message:
/usr/lpp/internet/server_root/cgi-bin/sample.css 1: FSUM7332 syntax error: got 
}, expecting Newline   

Has anybody done this and gotten it to work?  whats the trick I'm missing?

thanks
Dana

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

Re: Error overriding concatenated DD in PROC where one is instream data

[Ray Mullins]

Hello everyone,

An update: I've opened a PMR. Our sysprog has a 2.1 system lurking in a back 
corner and confirmed it fails there as well.


I also just got a call from IBM support. There is a 1.13 APAR for something 
similar but it was fixed in 2.1. The JES2 and allocation teams are looking 
into it. It does look like I found something.


Cheers,
Ray

On 2014-02-11 08:45, Ray Mullins wrote:

Hi everyone,

I played a bit with this over the past couple of days, with several 
combinations of DDs, and it all points to the DD that's used to tell 
allocation to leave the second DD as-is. It's incorrectly being processed 
with a generated temporary data set name instead of letting the instream be.


I'm going to APAR this. I would appreciate it, though, if someone who has 
access to a 2.1 system could run my example JCL (it's just using IEBGENER 
and an instream PROC) to see if it's fixed there.


Cheers,
Ray

On 2014-02-07 06:25, Pommier, Rex wrote:

Ray,

Just out of curiosity, would it work if you added a third DD card to the 
original SYSLPARM DD concatenation?  The JCL ref manual doesn't 
explicitly state the override needs something to override, but it might 
be worth a try.


Can you try something like:

//SYSLPARM DD DSN=&&tempds,DISP=(OLD,DELETE)
// DD *
some more binder parms overriding the first one
/*
// DD *
A comment line or do-nothing line (or possibly nothing at all)
/*

And then your override would have the second DD * to be overridden.

Or maybe the third DD could be DD DUMMY?

Rex


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Ray Mullins

Sent: Thursday, February 06, 2014 4:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Error overriding concatenated DD in PROC where one is instream data

Hello, long time absent.

In z/OS 1.13, I'm playing with instream data in a PROC for the first time to
try to simplify some bind JCL and I've run into an error. It's an atypical
situation, I realize.

In the PROC I have

//* Following is a data set created with ISRSCAN from a concatenation
//SYSLPARM DD DSN=&&tempds,DISP=(OLD,DELETE)
// DD *
some more binder parms overriding the first one
//*

Because one of the program objects needs different stuff, I've coded

//DRVASTRT EXEC MMB,symbolics
//B.SYSLPARM DD
// DD
// DD *
different parms to override a couple in the first two DDs
//*

The job hits this step and gives me

IEF344I MMDB B DRVASTRT SYSLPARM+001 - ALLOCATION FAILED DUE TO DATA
FACILITY SYSTEM ERROR
IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET
SYS14037.T114830.RA000.MMDB.R0484370

It seems like conversion/interpretation has skipped the fact that I'm not
overriding the second DD in the concatenation and is generating a data set
name, instead of noting that it's a blank DD and just leaving the original
DD alone.

  From a logic standpoint, this makes sense, but I'm wondering if this is 
WAD

(thou shalt not override instream data) or maybe DD concatenation needs some
extra checks if the underlying DD is instream (or does not have a DSN). I am
curious as how this would be handled if the DD was a SUBSYS.

Yes, I could put the instream data in a PDS member, but for various reasons
that would complicate the underlying binder proc; let's just say we'd rather
not go there.

So, what's the consensus? WAD? APARable?

Cheers,
Ray







--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/

German is essentially a form of assembly language consisting entirely of far 
calls heavily accented with throaty guttural sounds. ---ilvi
French is essentially German with messed-up pronunciation and spelling.  
--Robert B Wilson
English is essentially French converted to 7-bit ASCII.  ---Christophe Pierret 
[for Alain LaBonté]

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

Re: DELETE CLUSTER fails (IKJ56882I / IEF195I)

[Guy Eshel]

How can I move the index on it's own? DSS only works on the cluster level.
I can probably REPRO the index to a different one, but that still wouldn't 
delete the original.

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

Re: DELETE CLUSTER fails (IKJ56882I / IEF195I)

[Guy Eshel]

z/OS level is V1R13. 

Some of the IDCAMS control cards attempted:

DELETE 'VSAM.DATA.SET' CLUSTER SCRATCH

EXPORT 'VSAM.DATA.SET' OUTFILE(EXPORT) PERM

DELETE FILE(DD) CLUSTER

Haven't contacted MainStar or IBM yet, that's probably the next step. Although 
I'm starting to get the feeling that they'll direct me to one of the "ZAP/DEL 
NOSCR and cleanup" solutions.

INDEX:
HI-A-RBA---319488000
HI-U-RBA---313516032

DATA: 
HI-A-RBA-56328192000
HI-U-RBA-56328192000
This is why I wanted to delete it in the first place, all 59 volumes filled up, 
and I wanted to delete-define it on bigger volumes.

EXTADDR might let it use more of each volume - but eventually, down the road, 
I'll need to delete this data set either way.

Thanks for the help!

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

Re: Storage Obtain .....

[John Gilmore]

It worked that way, when it worked, under OS/360 MVT.

The design issue is not perhaps so clearcut as Jim makes it out to be.
 There are circumstances in which a calculated sometime size of zero
is very convenient.

Perhaps an electable option, one that required explicit coding to
permit storage sizes/lengths of zero, would have met everyone's needs.
 It is, however, decades too late to change this behavior.  It could
have been changed for STORAGE obtain, but another such opportunity
will not come along any time soon.

John Gilmore, Ashland, MA 01721 - USA

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

Re: DELETE CLUSTER fails (IKJ56882I / IEF195I)

[Guy Eshel]

No issues with keeping the file - I tried using COPY-DELETE in dfDSS. The COPY 
part worked just fine, the DELETE though... :)

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

Re: DELETE CLUSTER fails (IKJ56882I / IEF195I)

[Alan Field]

Could you move the index so that is is on one or more of the same volumes 
as the data, thereby getting below the 59 volume limit?

Alan Field
Technical Engineer Principal
BCBS Minnesota

Phone: 651.662.3546  Mobile:  651.428.8826





From:   "Guy Eshel" 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   02/12/2014 14:24
Subject:Re: DELETE CLUSTER fails (IKJ56882I / IEF195I)
Sent by:IBM Mainframe Discussion List 



I've tried using IEFBR14 before, and it failed with the IEF195I code.

Using NOSCRATCH and then manually cleaning the leftovers is my last 
resort, I just find it mind boggling how there's no proper way for doing 
this, considering this situation wasn't a result of some 
user/catalog/system error.

I'll probably end up using that though, thank you for the suggestions.

--
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: DELETE CLUSTER fails (IKJ56882I / IEF195I)

[Guy Eshel]

I've tried using IEFBR14 before, and it failed with the IEF195I code.

Using NOSCRATCH and then manually cleaning the leftovers is my last resort, I 
just find it mind boggling how there's no proper way for doing this, 
considering this situation wasn't a result of some user/catalog/system error.

I'll probably end up using that though, thank you for the suggestions.

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

Re: DELETE CLUSTER fails (IKJ56882I / IEF195I)

[Bill Ashton]

You might be able to REPRO the DATA component separately to another file
with fewer volumes, and then use that to rebuild the INDEX if you want to
keep the file.


On Wed, Feb 12, 2014 at 2:56 PM, John McKown
wrote:

> You might try:
>
> //IEFBR14 EXEC PGM=IEFBR14
> //DELETE DD DISP=(OLD,DELETE,DELETE),DSN=VSAM.DATA.SET
> //*
>
> The initiator can now create and delete VSAM data sets. Another possibility
> is to do an IDCAMS delete with the NOSCRATCH option. Then you will need to
> do a
>
> DELETE component.name VVR FILE(ddname)
>
> with one DELETE for each component.name on each volume upon which it
> resides being listed separately. With said volumes being allocated to a
> unique DD name. Like:
>
> //Vvolser DD DISP=OLD,UNIT=SYSDA,VOL=SER=volser
>
>
>
>
> On Wed, Feb 12, 2014 at 1:45 PM, Guy Eshel  wrote:
>
> > Here's an interesting puzzle...
> >
> > We have a VSAM data set, which currently occupies more than 59 volumes:
> > - The data component spans on 59.
> > - The index component spans on 2, but one of them is not among the data's
> > 59.
> > Which sums up to 60 volumes.
> >
> > The actual data is accessable just fine - no issues reported from the
> > batch process using it.
> >
> > But now we want to get rid of the file, yet every attempt at manipulating
> > the data set itself (moving / deleting / reorganizing / migrating) fails
> > with errors such as:
> > IKJ56882I DATA SET VSAM.DATA.SET NOT ALLOCATED, TOO MANY VOLUMES
> > IKJ56882I NUMBER OF VOLUMES SPECIFIED EXCEEDS LIMIT
> > or
> > IEF195I DELJOB IDCAMS VSAMDD - MAXIMUM NUMBER OF DEVICES FOR DD EXCEEDED
> >
> > Haven't had any luck using IDCAMS / dfDSS / dfHSM / CA-Disk.
> > We have Catalog RecoveryPlus, but it doesn't offer a complete deletion
> > solution. Using it will probably require various ZAPs and cleanup.
> >
> > Is there a proper way to deal with this? Any suggestions would be
> > appreciated...
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> Wasn't there something about a PASCAL programmer knowing the value of
> everything and the Wirth of nothing?
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Thank you and best regards,
*Billy Ashton*

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

Re: DELETE CLUSTER fails (IKJ56882I / IEF195I)

[John McKown]

You might try:

//IEFBR14 EXEC PGM=IEFBR14
//DELETE DD DISP=(OLD,DELETE,DELETE),DSN=VSAM.DATA.SET
//*

The initiator can now create and delete VSAM data sets. Another possibility
is to do an IDCAMS delete with the NOSCRATCH option. Then you will need to
do a

DELETE component.name VVR FILE(ddname)

with one DELETE for each component.name on each volume upon which it
resides being listed separately. With said volumes being allocated to a
unique DD name. Like:

//Vvolser DD DISP=OLD,UNIT=SYSDA,VOL=SER=volser




On Wed, Feb 12, 2014 at 1:45 PM, Guy Eshel  wrote:

> Here's an interesting puzzle...
>
> We have a VSAM data set, which currently occupies more than 59 volumes:
> - The data component spans on 59.
> - The index component spans on 2, but one of them is not among the data's
> 59.
> Which sums up to 60 volumes.
>
> The actual data is accessable just fine - no issues reported from the
> batch process using it.
>
> But now we want to get rid of the file, yet every attempt at manipulating
> the data set itself (moving / deleting / reorganizing / migrating) fails
> with errors such as:
> IKJ56882I DATA SET VSAM.DATA.SET NOT ALLOCATED, TOO MANY VOLUMES
> IKJ56882I NUMBER OF VOLUMES SPECIFIED EXCEEDS LIMIT
> or
> IEF195I DELJOB IDCAMS VSAMDD - MAXIMUM NUMBER OF DEVICES FOR DD EXCEEDED
>
> Haven't had any luck using IDCAMS / dfDSS / dfHSM / CA-Disk.
> We have Catalog RecoveryPlus, but it doesn't offer a complete deletion
> solution. Using it will probably require various ZAPs and cleanup.
>
> Is there a proper way to deal with this? Any suggestions would be
> appreciated...
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wasn't there something about a PASCAL programmer knowing the value of
everything and the Wirth of nothing?

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: DELETE CLUSTER fails (IKJ56882I / IEF195I)

[Lizette Koehler]

One other question, what is the HURBA at now?

Maybe you could do an ALTER to EXTADDR and see if that helps.  This is a WAG.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Wednesday, February 12, 2014 12:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DELETE CLUSTER fails (IKJ56882I / IEF195I)
> 
> If you could state your z/OS Level and post your IDCAMS control cards that 
> could
> help.
> 
> Have you called Mainstar support?  Sometimes they know tricks that are not
> obvious.
> 
> Have you contacted IBM Support for assistance?/  They also maybe helpful.
> 
> Thanks
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Guy Eshel
> > Sent: Wednesday, February 12, 2014 12:46 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: DELETE CLUSTER fails (IKJ56882I / IEF195I)
> >
> > Here's an interesting puzzle...
> >
> > We have a VSAM data set, which currently occupies more than 59 volumes:
> > - The data component spans on 59.
> > - The index component spans on 2, but one of them is not among the data's 
> > 59.
> > Which sums up to 60 volumes.
> >
> > The actual data is accessable just fine - no issues reported from the
> > batch process using it.
> >
> > But now we want to get rid of the file, yet every attempt at
> > manipulating the data set itself (moving / deleting / reorganizing / 
> > migrating) fails
> with errors such as:
> > IKJ56882I DATA SET VSAM.DATA.SET NOT ALLOCATED, TOO MANY
> VOLUMES
> > IKJ56882I NUMBER OF VOLUMES SPECIFIED EXCEEDS LIMIT or IEF195I
> DELJOB
> > IDCAMS VSAMDD - MAXIMUM NUMBER OF DEVICES FOR DD EXCEEDED
> >
> > Haven't had any luck using IDCAMS / dfDSS / dfHSM / CA-Disk.
> > We have Catalog RecoveryPlus, but it doesn't offer a complete deletion 
> > solution.
> > Using it will probably require various ZAPs and cleanup.
> >
> > Is there a proper way to deal with this? Any suggestions would be 
> > appreciated...
> >

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

Re: DELETE CLUSTER fails (IKJ56882I / IEF195I)

[Lizette Koehler]

If you could state your z/OS Level and post your IDCAMS control cards that 
could help.

Have you called Mainstar support?  Sometimes they know tricks that are not 
obvious.

Have you contacted IBM Support for assistance?/  They also maybe helpful.

Thanks

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Guy Eshel
> Sent: Wednesday, February 12, 2014 12:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DELETE CLUSTER fails (IKJ56882I / IEF195I)
> 
> Here's an interesting puzzle...
> 
> We have a VSAM data set, which currently occupies more than 59 volumes:
> - The data component spans on 59.
> - The index component spans on 2, but one of them is not among the data's 59.
> Which sums up to 60 volumes.
> 
> The actual data is accessable just fine - no issues reported from the batch 
> process
> using it.
> 
> But now we want to get rid of the file, yet every attempt at manipulating the 
> data set
> itself (moving / deleting / reorganizing / migrating) fails with errors such 
> as:
> IKJ56882I DATA SET VSAM.DATA.SET NOT ALLOCATED, TOO MANY
> VOLUMES
> IKJ56882I NUMBER OF VOLUMES SPECIFIED EXCEEDS LIMIT
> or
> IEF195I DELJOB IDCAMS VSAMDD - MAXIMUM NUMBER OF DEVICES FOR
> DD EXCEEDED
> 
> Haven't had any luck using IDCAMS / dfDSS / dfHSM / CA-Disk.
> We have Catalog RecoveryPlus, but it doesn't offer a complete deletion 
> solution.
> Using it will probably require various ZAPs and cleanup.
> 
> Is there a proper way to deal with this? Any suggestions would be 
> appreciated...
> 

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

DELETE CLUSTER fails (IKJ56882I / IEF195I)

[Guy Eshel]

Here's an interesting puzzle...

We have a VSAM data set, which currently occupies more than 59 volumes: 
- The data component spans on 59.
- The index component spans on 2, but one of them is not among the data's 59.
Which sums up to 60 volumes.

The actual data is accessable just fine - no issues reported from the batch 
process using it.

But now we want to get rid of the file, yet every attempt at manipulating the 
data set itself (moving / deleting / reorganizing / migrating) fails with 
errors such as:
IKJ56882I DATA SET VSAM.DATA.SET NOT ALLOCATED, TOO MANY VOLUMES
   
IKJ56882I NUMBER OF VOLUMES SPECIFIED EXCEEDS LIMIT 
or
IEF195I DELJOB IDCAMS VSAMDD - MAXIMUM NUMBER OF DEVICES FOR DD EXCEEDED 

Haven't had any luck using IDCAMS / dfDSS / dfHSM / CA-Disk.
We have Catalog RecoveryPlus, but it doesn't offer a complete deletion 
solution. Using it will probably require various ZAPs and cleanup.

Is there a proper way to deal with this? Any suggestions would be appreciated...

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

Re: Storage Obtain .....

[Jim Mulder]

> It's the workarea length ... 004C0 105 LCLDSCTL EQU   *-LCLDSECT
> LENGTH OF LOCAL WORK AREA  0041

>  SSRV78  9F00130A      Getmain
> CCB45F68C0337D48   05
>003D
> 
>  PGM004 _1F001320  00040004    0001 

> 003D 003D CCB45F68C034FF2C   05
> 0704 8000      
> 
> *RCVY  PROG940C4000 0004   0001 

> 003D 003D CCB45F68C06843A6   05


  The SSRV  78 entry shows that the requested length was 0.
When a length of 0 is requested on GETMAIN or STORAGE OBTAIN,
VSM treats this as a successful request, and returns an address of 0.
In my opinion, this was a poor design choice, made long before my time,
and I have seen it lead to diagnosis confusion like this several times
over the years. I would have preferred to abend when a length of 0
is requested. But it has worked this way since at least MVS/370,
and maybe even long before that, so for compatibility reasons, 
we do not change it. 

 Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

Re: Users of CSP and its successor migrating to COBOL 5.1

[John Gilmore]

Paul Gilmartin's point has merit; but, as usual, the details matter.
Mike Cowlishaw's design of the [now IEEE-standard] z/Architecture
decimal floating-point (DFP) format

1) distinguishes -0.0e+000 from +0.0e+000, and

2) ensures that they compare equal architecturally.

The distinction is useful in coding and studying many
limiting/convergence processes for which the direction from which zero
is approached is important.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Storage Obtain .....

[Lloyd Fuller]

Actually in some products quite a lot.  A product that I worked on in the past 
is used by several banks including people who regularly post here and on the VM 
list.  Many of those banks used the product for various things including escrow 
accounts which are VERY long lived.  In several cases that I know about the 
escrow accounts were set up before 1900 so when they were computerized, the 
date algorithms had to handle a non-leap year 00 year.  Worked fine.  Some of 
the escrow accounts go past 2100 and those are working fine also.
 
For that same product the only Y2K issues were making sure that computer forms 
that only allowed two digits for years would be able to work.  Hence a century 
windor for input only was implemented.  Internal dates went from 1/1/1600 to a 
time VERY long in the future (year 1 something).  In fact, after discussion 
we even implemented the leap year calendar in the past by using negative dates. 
 In most of the cases that users wanted that, only year matter, not necessarily 
month and day so things worked fine.
 
Lloyd
 

>
> From: "Vernooij, CP (SPLXM) - KLM" 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Wednesday, February 12, 2014 9:40 AM
>Subject: Re: Storage Obtain .
>  
>
>A similar one: 
>How to determine a leap year:
>Q1:Is year a multiple of 4?
>If yes: Q2: is year a multiple of 100?
>If yes: Q3: is year a multiple of 400?
>If yes: it is a leapyear.
>(skipping the 'If No' branches).
>
>Q2 and Q3 will start making sense for the first time in the history of
>computer programming in the year 2100. Until then Q1 would have been
>sufficient.
>How much power has been put into executing instructions to answer Q2 and
>Q3? 
>If I only had a Euro for each program that has this code and will not
>live until 2100...
>
>Kees.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of Gerhard Postpischil
>Sent: Wednesday, February 12, 2014 15:08
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Storage Obtain .
>
>On 2/12/2014 8:50 AM, Jim Thomas wrote:
>
>>>           XR    R14,R14
>>>           XR    R15,R15
>>>           L     R1,=AL4(WORKAREA)
>>>           MVCL  R0,R14
>
>Minor quibble - when the from length is zero, the from register is never
>referenced nor inspected, so the XR R14,R14 is extraneous. (If I had a
>dollar for every time I've seen this, I could retire ).
>
>Gerhard Postpischil
>Bradford, Vermont
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>For information, services and offers, please visit our web site: 
>http://www.klm.com/. This e-mail and any attachment may contain confidential 
>and privileged material intended for the addressee only. If you are not the 
>addressee, you are notified that no part of the e-mail or any attachment may 
>be disclosed, copied or distributed, and that any other action related to this 
>e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
>received this e-mail by error, please notify the sender immediately by return 
>e-mail, and delete this message. 
>
>Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
>employees shall not be liable for the incorrect or incomplete transmission of 
>this e-mail or any attachments, nor responsible for any delay in receipt. 
>Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
>Airlines) is registered in Amstelveen, The Netherlands, with registered number 
>33014286
>
>            
>
>--
>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: IBMLINK SR problems?

[Jousma, David]

Here was the response from SR support.  Of course I am not able to use another 
browser on my workstation:

Hello,

We apologize for any inconvenience. 

We are investigating the issue. Meanwhile, please try using another browser 
like Firefox or Chrome. 

Thanks,
IBM SR Support Team


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David G. Yeager
Sent: Wednesday, February 12, 2014 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBMLINK SR problems?

Also glad to know not alone,  I'm using chrome as a work around. 

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: IBMLINK SR problems?

[David G. Yeager]

Also glad to know not alone,  I'm using chrome as a work around.

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

Re: Storage Obtain .....

[Jim Thomas]

Peter,

My apologies ... I was pasting snippets and accidently left our parts ... 

None the less, I was missing a REGS= on the SETLOCK. I added REGS=USE and it
now works. 

Thank you and to everybody else that tried to assist.

Kind Regards.

Jim Thomas

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Wednesday, February 12, 2014 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

You didn't show the code involved with where you said it. You wrote that it
was "trying to chain backward / forward save area's".

>LENGTH=LCLDSCTL,
what is this value?

You wrote about an "LTR after the STORAGE OBTAIN". You showed no such LTR.

>  LRR11,R1 
>  LRR0,R1 
>  XRR14,R14 
>  XRR15,R15 
>  L R1,=AL4(WORKAREA) 
>  MVCL  R0,R14 

what is "WORKAREA"? Usualy one would clear the amount of storage that was 
obtained (as identified by LCLDSCTL). If WORKAREA is actually an "area", 
it's unlikely that the address of that area would work well as a length of 
the target of the MVCL.

Maybe it blew up on the MVCL because the length you were attempting to did 
not match what you had obtained.
If you are seeing R11 = 0 it could only be because the length you 
requested was 0. It is valid (but not what you likely want) to request 0 
bytes.

Other things: 
- You do not need to set R14 for an MVCL that zeroes an area.
- You should use TYPE=LOCAL not TYPE=CML on your SETLOCK OBTAIN if you 
want the local lock of home (and you appear to, since you are specifying 
the home ASCB address that is in PSAAOLD).
- You might consider CHECKZERO=YES on STORAGE OBTAIN so that you can avoid 
clearing the obtained area, based on the return code (which the system 
sets to indicate whether it has already made sure that the area will be 
zeroes when first referenced).

Peter Relson
z/OS Core Technology Design

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

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

Re: Storage Obtain .....

[Jim Thomas]

Binyamin,

Right you are .. I added the second one y'day when I had the S0C4's ... it's
been removed now.. and yes, 
you were correct... I added REGS=USE and it works now ... 

thank you for your assistance.

Kind Regards.

Jim Thomas

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Wednesday, February 12, 2014 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

On Wed, 12 Feb 2014 07:58:13 -0600 Jim Thomas 
wrote:

:>Twice because the first is for R0,R1 and the second is for R12,R13.

As there is only one state area, the second one overwrites the first.

If you need to get a pre-BAKR register, you can use EREG(G).

:>When my ASCB = home, then it is a local lock. 
:>
:>Ohh.. good one Binyamin ... duhh ... I didn't even think of that ... I'll
:>preserve the :>registers, especially R13, retry and repost. 
:>
:>Thank you kind Sir,
:>
:>Kind Regards,
:>
:>Jim Thomas
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>Behalf Of Binyamin Dissen
:>Sent: Wednesday, February 12, 2014 3:55 AM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: Storage Obtain .
:>
:>On Tue, 11 Feb 2014 17:50:53 -0600 Jim Thomas 
:>wrote:
:>
:>:>Given the below ... 
:>
:>:> BAKR  R0,R0
:>:> MSTA  R0  
:>:> MSTA  R12 
:>
:>Why twice?
:>
:>:> MODESET MODE=SUP,
:>:>   KEY=ZERO   
:>:> L R11,PSAAOLD-PSA 
:>:> SETLOCK OBTAIN,   
:>:>   ASCB=(11),  
:>:>   TYPE=CML,   
:>:>   MODE=UNCOND
:>
:>Why not directly take the local lock rather than this convoluted form?
:>
:>Also, without REGS=, R11-R13 are changed.
:> 
:>:> XRR4,R4 
:>:> L R7,PSAAOLD-PSA
:>:> STORAGE OBTAIN, 
:>:>   LENGTH=LCLDSCTL,  
:>:>   SP=244,   
:>:>   LOC=(31,31),  
:>:>   CAUB=CURRENT, 
:>:>   OWNER=HOME,   
:>:>   LINKAGE=BRANCH
:>:> LRR11,R1
:>:> LRR0,R1 
:>:> XRR14,R14   
:>:> XRR15,R15   
:>:> L R1,=AL4(WORKAREA) 
:>
:>Is workarea the same length (or shorter) than LCLDSCTL?
:>
:>:> MVCL  R0,R14
:>
:>:>Everything up to the STORAGE OBTAIN seems to work but w/trying to chain
:>:>backward / forward save area's (no I not really using the linkage
stack), :>:>I get a S0C4-4 ??... I understand the S0C4 because R1 is zeroes
... but :>...
:>:>why ??. My LTR after the STORAGE OBTAIN does not catch a failure. 
:>
:>SETLOCK has altered your R13.
:>
:>:>The only reason I'm trying to use the linkage stack is because this is
at :>:>the very start of my program.
:>
:>:>The trace table shows the SSRV for the OBTAIN .. but it's obviously
:>:>failing... 
:>
:>:>Could anybody give me some direction / suggestions ??. 
:>
:>Which instruction is causing the 0C4? What is your base register?

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

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

Re: Storage Obtain .....

[Jim Thomas]

Gerhard,

Thank you for pointing that out.. 

Kind Regards.

Jim Thomas

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gerhard Postpischil
Sent: Wednesday, February 12, 2014 8:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

On 2/12/2014 8:50 AM, Jim Thomas wrote:

>>   XRR14,R14
>>   XRR15,R15
>>   L R1,=AL4(WORKAREA)
>>   MVCL  R0,R14

Minor quibble - when the from length is zero, the from register is never
referenced nor inspected, so the XR R14,R14 is extraneous. (If I had a
dollar for every time I've seen this, I could retire ).

Gerhard Postpischil
Bradford, Vermont

--
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: SYSLOG messages Frozen

[Ed Gould]

Try: "W START" ?

Ed

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

Re: Was: Implicit VVDS creation now: FDR & VVDS's

[Ed Gould]

FDR,compaktor
On Feb 12, 2014, at 7:05 AM, Shmuel Metz (Seymour J.) wrote:


In <476fd1b4-cd31-49e7-bba2-d719c96b7...@comcast.net>, on 02/11/2014
   at 01:40 PM, Ed Gould  said:


I am trying to remember if FDR consolidates the SYS1.VVDS extents


FDR is a company that sells several products; which are you licensed
for?

--
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: Users of CSP and its successor migrating to COBOL 5.1

[Paul Gilmartin]

On Tue, 11 Feb 2014 22:47:42 -0400, Clark F Morris wrote:

> ...  CSP and possibly its successor forced an F zone on all
>signed fields with positive values leaving the D zone for negative
>fields.  The elimination of NUMPROC(MIG) means this behavior if still
>existing can cause problems.
> ...
Demonstrating that in the long term a hardware design that allows
multiple representations of any mathematical value is a colossal
blunder.  +0 and -0 are a case in point.

-- gil

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

I need a Q/A resource z/OS cobol

[chris lindenhauer]

Hi Gang:

I have a Q/A contract position in Charleston SC, (on site not remote)
Anyone interested shoot me a resume or email me for more info...

Thanks
Chris

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

Re: Storage Obtain .....

[Peter Relson]

You didn't show the code involved with where you said it. You wrote that 
it was "trying to chain
backward / forward save area's".

>LENGTH=LCLDSCTL, 
what is this value?

You wrote about an "LTR after the STORAGE OBTAIN". You showed no such LTR.

>  LRR11,R1 
>  LRR0,R1 
>  XRR14,R14 
>  XRR15,R15 
>  L R1,=AL4(WORKAREA) 
>  MVCL  R0,R14 

what is "WORKAREA"? Usualy one would clear the amount of storage that was 
obtained (as identified by LCLDSCTL). If WORKAREA is actually an "area", 
it's unlikely that the address of that area would work well as a length of 
the target of the MVCL.

Maybe it blew up on the MVCL because the length you were attempting to did 
not match what you had obtained.
If you are seeing R11 = 0 it could only be because the length you 
requested was 0. It is valid (but not what you likely want) to request 0 
bytes.

Other things: 
- You do not need to set R14 for an MVCL that zeroes an area.
- You should use TYPE=LOCAL not TYPE=CML on your SETLOCK OBTAIN if you 
want the local lock of home (and you appear to, since you are specifying 
the home ASCB address that is in PSAAOLD).
- You might consider CHECKZERO=YES on STORAGE OBTAIN so that you can avoid 
clearing the obtained area, based on the return code (which the system 
sets to indicate whether it has already made sure that the area will be 
zeroes when first referenced).

Peter Relson
z/OS Core Technology Design

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

OT: enlightenment (humor?)

[John McKown]

I just realized that CA-Endevor was designed to prove that there is
something more confusing than GNU make.

-- 
Wasn't there something about a PASCAL programmer knowing the value of
everything and the Wirth of nothing?

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: Debug Tool: EQA1872E An error occurred while opening file...

[Thomas Berg]

That was it!  Thanks!!
(It was a "leftover" from our standard parm.  And I thought it just tell DT 
where to find eventual command members, not that it tried to execute the exact 
target.)


Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of George Young
> Sent: Wednesday, February 12, 2014 3:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Debug Tool: EQA1872E An error occurred while opening
> file...
> 
> Is there any chance you have DT.COMMANDS as the 2nd parm in your TEST
> runtime string?  That could cause a problem like this (because it will
> get an error because you don't have a member name specified).  If you
> specify something there, the debugger will try to run commands out of
> that data set after processing the preferences file.
> 
> George
> 
> 
> 
> On 2/12/2014 4:35 AM, Thomas Berg wrote:
> > Hi,
> >
> > I'm having a problem with running Debug Tool.
> > I'm getting a "EQA1872E An error occurred while opening file" but I
> have no idea of WHY it tries that.
> > The end of the log:
> > ...
> >SET KEYS ON 12 ;
> >SET MONITOR COLUMN ON ;
> >USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
> >   /*USE 'S000TBE.DT.COMMANDS(ALLPROCS)' ;
> */
> >   /*  ALLSESS : PROCEDURE ;
> */
> >   /*USE 'S000TBE.DT.COMMANDS(ALLSESS)' ;
> */
> >   /*  END ;
> */
> >   /*  ALLENTRY : PROCEDURE ;
> */
> >   /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> */
> >   /*  END ;
> */
> >   /*  INITCU : PROCEDURE ;
> */
> >   /*USE 'S000TBE.DT.COMMANDS(INITCU)' ;
> */
> >   /*  END ;
> */
> >   /*  USE 'S000TBE.DT.COMMANDS(ALLPGMS)' ;
> */
> >   /*KVAMKNR : PROCEDURE ;
> */
> >   /*  USE 'S000TBE.DT.COMMANDS(KVAMKNR)' ;
> */
> >   /*END ;
> */
> >   /*GKVAMKNR : PROCEDURE ;
> */
> >   /*  USE 'S000TBE.DT.COMMANDS.GENCMD(KVAMKNR)' ;
> */
> >   /*END ;
> */
> >   /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> */
> >   /*  %IF %CU = 'KVAMKNR' THEN
> */
> >   /*CALL KVAMKNR ;
> */
> >   /*CALL ALLSESS ;
> */
> >   /*  NAMES EXCLUDE CU "BPS*" ;
> */
> >   /*  NAMES EXCLUDE CU "SPA*" ;
> */
> >   /*  SET ECHO OFF ;
> */
> >   /*  CLEAR AT ;
> */
> >   /* There are no breakpoints set.
> */
> >   /*  CLEAR MONITOR ;
> */
> >   /* *** User preferences file commands end ***
> */
> >   /* EQA1872E An error occurred while opening file:
> S000TBE.DT.COMMANDS */
> >   /*  . The file may not exist, or is not accessible.
> */
> >
> > Note the "User preferences file commands end".
> > Why is DT trying to open "S000TBE.DT.COMMANDS" ?  I'm not referencing
> that (exact) file(name) (without a membername) in any command member.
> And the file DOES exist as you can see above.  I also copied
> S000TBE.DT.COMMANDS to S000TBE.S000TBE.DT.COMMANDS in case it had
> anything to do with a qualification problem.
> >
> > BTW, does anyone know of a list/forum that may have more DT users than
> IBM-MAIN ?
> >
> >
> >
> > Best Regards
> > Thomas Berg
> > ___
> > Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> >
> >
> >
> >
> > --
> > 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: Storage Obtain .....

[Vernooij, CP (SPLXM) - KLM]

A similar one: 
How to determine a leap year:
Q1:Is year a multiple of 4?
If yes: Q2: is year a multiple of 100?
If yes: Q3: is year a multiple of 400?
If yes: it is a leapyear.
(skipping the 'If No' branches).

Q2 and Q3 will start making sense for the first time in the history of
computer programming in the year 2100. Until then Q1 would have been
sufficient.
How much power has been put into executing instructions to answer Q2 and
Q3? 
If I only had a Euro for each program that has this code and will not
live until 2100...

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gerhard Postpischil
Sent: Wednesday, February 12, 2014 15:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

On 2/12/2014 8:50 AM, Jim Thomas wrote:

>>   XRR14,R14
>>   XRR15,R15
>>   L R1,=AL4(WORKAREA)
>>   MVCL  R0,R14

Minor quibble - when the from length is zero, the from register is never
referenced nor inspected, so the XR R14,R14 is extraneous. (If I had a
dollar for every time I've seen this, I could retire ).

Gerhard Postpischil
Bradford, Vermont

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: Debug Tool: EQA1872E An error occurred while opening file...

[George Young]

Is there any chance you have DT.COMMANDS as the 2nd parm in your TEST 
runtime string?  That could cause a problem like this (because it will 
get an error because you don't have a member name specified).  If you 
specify something there, the debugger will try to run commands out of 
that data set after processing the preferences file.


George



On 2/12/2014 4:35 AM, Thomas Berg wrote:

Hi,

I'm having a problem with running Debug Tool.
I'm getting a "EQA1872E An error occurred while opening file" but I have no 
idea of WHY it tries that.
The end of the log:
...
   SET KEYS ON 12 ;
   SET MONITOR COLUMN ON ;
   USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
  /*USE 'S000TBE.DT.COMMANDS(ALLPROCS)' ;   */
  /*  ALLSESS : PROCEDURE ; */
  /*USE 'S000TBE.DT.COMMANDS(ALLSESS)' ;*/
  /*  END ; */
  /*  ALLENTRY : PROCEDURE ;*/
  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;   */
  /*  END ; */
  /*  INITCU : PROCEDURE ;  */
  /*USE 'S000TBE.DT.COMMANDS(INITCU)' ; */
  /*  END ; */
  /*  USE 'S000TBE.DT.COMMANDS(ALLPGMS)' ;  */
  /*KVAMKNR : PROCEDURE ;   */
  /*  USE 'S000TBE.DT.COMMANDS(KVAMKNR)' ;  */
  /*END ;   */
  /*GKVAMKNR : PROCEDURE ;  */
  /*  USE 'S000TBE.DT.COMMANDS.GENCMD(KVAMKNR)' ;   */
  /*END ;   */
  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;   */
  /*  %IF %CU = 'KVAMKNR' THEN  */
  /*CALL KVAMKNR ;  */
  /*CALL ALLSESS ;  */
  /*  NAMES EXCLUDE CU "BPS*" ; */
  /*  NAMES EXCLUDE CU "SPA*" ; */
  /*  SET ECHO OFF ;*/
  /*  CLEAR AT ;*/
  /* There are no breakpoints set.  */
  /*  CLEAR MONITOR ;   */
  /* *** User preferences file commands end *** */
  /* EQA1872E An error occurred while opening file: S000TBE.DT.COMMANDS */
  /*  . The file may not exist, or is not accessible.   */

Note the "User preferences file commands end".
Why is DT trying to open "S000TBE.DT.COMMANDS" ?  I'm not referencing that 
(exact) file(name) (without a membername) in any command member. And the file DOES exist 
as you can see above.  I also copied S000TBE.DT.COMMANDS to S000TBE.S000TBE.DT.COMMANDS 
in case it had anything to do with a qualification problem.

BTW, does anyone know of a list/forum that may have more DT users than IBM-MAIN 
?



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)




--
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: Storage Obtain .....

[Binyamin Dissen]

On Wed, 12 Feb 2014 07:58:13 -0600 Jim Thomas 
wrote:

:>Twice because the first is for R0,R1 and the second is for R12,R13.

As there is only one state area, the second one overwrites the first.

If you need to get a pre-BAKR register, you can use EREG(G).

:>When my ASCB = home, then it is a local lock. 
:>
:>Ohh.. good one Binyamin ... duhh ... I didn't even think of that ... I'll
:>preserve the 
:>registers, especially R13, retry and repost. 
:>
:>Thank you kind Sir,
:>
:>Kind Regards,
:>
:>Jim Thomas
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>Behalf Of Binyamin Dissen
:>Sent: Wednesday, February 12, 2014 3:55 AM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: Storage Obtain .
:>
:>On Tue, 11 Feb 2014 17:50:53 -0600 Jim Thomas 
:>wrote:
:>
:>:>Given the below ... 
:>
:>:> BAKR  R0,R0
:>:> MSTA  R0  
:>:> MSTA  R12 
:>
:>Why twice?
:>
:>:> MODESET MODE=SUP,
:>:>   KEY=ZERO   
:>:> L R11,PSAAOLD-PSA 
:>:> SETLOCK OBTAIN,   
:>:>   ASCB=(11),  
:>:>   TYPE=CML,   
:>:>   MODE=UNCOND
:>
:>Why not directly take the local lock rather than this convoluted form?
:>
:>Also, without REGS=, R11-R13 are changed.
:> 
:>:> XRR4,R4 
:>:> L R7,PSAAOLD-PSA
:>:> STORAGE OBTAIN, 
:>:>   LENGTH=LCLDSCTL,  
:>:>   SP=244,   
:>:>   LOC=(31,31),  
:>:>   CAUB=CURRENT, 
:>:>   OWNER=HOME,   
:>:>   LINKAGE=BRANCH
:>:> LRR11,R1
:>:> LRR0,R1 
:>:> XRR14,R14   
:>:> XRR15,R15   
:>:> L R1,=AL4(WORKAREA) 
:>
:>Is workarea the same length (or shorter) than LCLDSCTL?
:>
:>:> MVCL  R0,R14
:>
:>:>Everything up to the STORAGE OBTAIN seems to work but w/trying to chain
:>:>backward / forward save area's (no I not really using the linkage stack),
:>:>I get a S0C4-4 ??... I understand the S0C4 because R1 is zeroes ... but
:>...
:>:>why ??. My LTR after the STORAGE OBTAIN does not catch a failure. 
:>
:>SETLOCK has altered your R13.
:>
:>:>The only reason I'm trying to use the linkage stack is because this is at
:>:>the very start of my program.
:>
:>:>The trace table shows the SSRV for the OBTAIN .. but it's obviously
:>:>failing... 
:>
:>:>Could anybody give me some direction / suggestions ??. 
:>
:>Which instruction is causing the 0C4? What is your base register?

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: Storage Obtain .....

[Gerhard Postpischil]

On 2/12/2014 8:50 AM, Jim Thomas wrote:


  XRR14,R14
  XRR15,R15
  L R1,=AL4(WORKAREA)
  MVCL  R0,R14


Minor quibble - when the from length is zero, the from register is never 
referenced nor inspected, so the XR R14,R14 is extraneous. (If I had a 
dollar for every time I've seen this, I could retire ).


Gerhard Postpischil
Bradford, Vermont

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

Re: Storage Obtain .....

[Jim Thomas]

Bill,

My apologies ... I was pasting snippets... 

Kind Regards.

Jim Thomas

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of DASDBILL2
Sent: Wednesday, February 12, 2014 6:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

>My LTR after the STORAGE OBTAIN does not catch a failure. 
Your LTR after the STORAGE OBTAIN is not in the code you posted. 
  
Bill Fairchild 

- Original Message -

From: "Jim Thomas" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 11, 2014 5:50:53 PM
Subject: Re: Storage Obtain . 

Hello ... 

Given the below ... 

 BAKR  R0,R0
 MSTA  R0
 MSTA  R12
 MODESET MODE=SUP,
   KEY=ZERO
 L R11,PSAAOLD-PSA
 SETLOCK OBTAIN,
   ASCB=(11),
   TYPE=CML,
   MODE=UNCOND
 XRR4,R4
 L R7,PSAAOLD-PSA
 STORAGE OBTAIN,
   LENGTH=LCLDSCTL,
   SP=244,
   LOC=(31,31),
   CAUB=CURRENT,
   OWNER=HOME,
   LINKAGE=BRANCH
 LRR11,R1
 LRR0,R1
 XRR14,R14
 XRR15,R15
 L R1,=AL4(WORKAREA)
 MVCL  R0,R14 

Everything up to the STORAGE OBTAIN seems to work but w/trying to chain 
backward / forward save area's (no I not really using the linkage stack), I get 
a S0C4-4 ??... I understand the S0C4 because R1 is zeroes ... but ... 
why ??. My LTR after the STORAGE OBTAIN does not catch a failure. 

The only reason I'm trying to use the linkage stack is because this is at the 
very start of my program. 

The trace table shows the SSRV for the OBTAIN .. but it's obviously failing... 

Could anybody give me some direction / suggestions ??. 

Kind Regards. 

Jim Thomas 

--
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: Storage Obtain .....

[Jim Thomas]

Binyamin,

Twice because the first is for R0,R1 and the second is for R12,R13.

When my ASCB = home, then it is a local lock. 

Ohh.. good one Binyamin ... duhh ... I didn't even think of that ... I'll
preserve the 
registers, especially R13, retry and repost. 

Thank you kind Sir,

Kind Regards,

Jim Thomas

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Wednesday, February 12, 2014 3:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

On Tue, 11 Feb 2014 17:50:53 -0600 Jim Thomas 
wrote:

:>Given the below ... 

:> BAKR  R0,R0
:> MSTA  R0  
:> MSTA  R12 

Why twice?

:> MODESET MODE=SUP,
:>   KEY=ZERO   
:> L R11,PSAAOLD-PSA 
:> SETLOCK OBTAIN,   
:>   ASCB=(11),  
:>   TYPE=CML,   
:>   MODE=UNCOND

Why not directly take the local lock rather than this convoluted form?

Also, without REGS=, R11-R13 are changed.
 
:> XRR4,R4 
:> L R7,PSAAOLD-PSA
:> STORAGE OBTAIN, 
:>   LENGTH=LCLDSCTL,  
:>   SP=244,   
:>   LOC=(31,31),  
:>   CAUB=CURRENT, 
:>   OWNER=HOME,   
:>   LINKAGE=BRANCH
:> LRR11,R1
:> LRR0,R1 
:> XRR14,R14   
:> XRR15,R15   
:> L R1,=AL4(WORKAREA) 

Is workarea the same length (or shorter) than LCLDSCTL?

:> MVCL  R0,R14

:>Everything up to the STORAGE OBTAIN seems to work but w/trying to chain
:>backward / forward save area's (no I not really using the linkage stack),
:>I get a S0C4-4 ??... I understand the S0C4 because R1 is zeroes ... but
...
:>why ??. My LTR after the STORAGE OBTAIN does not catch a failure. 

SETLOCK has altered your R13.

:>The only reason I'm trying to use the linkage stack is because this is at
:>the very start of my program.

:>The trace table shows the SSRV for the OBTAIN .. but it's obviously
:>failing... 

:>Could anybody give me some direction / suggestions ??. 

Which instruction is causing the 0C4? What is your base register?

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

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

Re: IBMLINK SR problems?

[Dennis Trojak]

Same here, fails on IE9 or IE10 even with work-around. Works just fine on 
Firefox.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, February 12, 2014 6:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBMLINK SR problems?

FYI, I have opened a PMR with IBM on this.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 11, 2014 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBMLINK SR problems?

Whew.  Glad I am not alone.   There is a statement on their webpage to IE10 
users, with a work around, which I tried to no avail.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Harold Zbiegien
Sent: Tuesday, February 11, 2014 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBMLINK SR problems?

tried to update a PMR, got the same problem, IE9, I deleted cache, retried, 
same problem

 


 From: "Wissink, Brad [ITSYS]" 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, February 11, 2014 3:41 PM
Subject: Re: IBMLINK SR problems?
  

Just entered a new SR ticket at 2:00 pm and everything was fine.   I use 
Firefox.

Brad Wissink 
Information Technology Services 
Iowa State University 
515-294-3088 
"If it ain't broke, you ain't trying" - Red Green

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 11, 2014 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBMLINK SR problems?

Anyone try to open a new ticket today on Service Request?   IE9 here on WIN7, 
and it fails.  Both for me, and a team mate after you fill out the ticket, and 
click on open, comes back with the form emptied out, and error messages saying 
to fill in subject, problem text, etc.  Form is messed up too, SEV1 is gone, 
etc.  I find it hard to believe it is a global thing since no one else has said 
anything, however just as hard to believe it is a local thing either.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

Re: Storage Obtain .....

[Jim Thomas]

Charles,

They are the same ... I'd typed 'workarea' (in the email) while trying to
describe what the field was and never changed it.

Kind Regards.

Jim Thomas

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, February 11, 2014 8:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

What is the MVCL trying to accomplish? Clear a number of bytes equal to the
address of WORKAREA? Might you want the length of the OBTAIN and the length
of the MVCL to be the same?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Thomas
Sent: Tuesday, February 11, 2014 3:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

Hello ... 

Given the below ... 

 BAKR  R0,R0
 MSTA  R0  
 MSTA  R12 
 MODESET MODE=SUP,
   KEY=ZERO   
 L R11,PSAAOLD-PSA 
 SETLOCK OBTAIN,   
   ASCB=(11),  
   TYPE=CML,   
   MODE=UNCOND 
 XRR4,R4 
 L R7,PSAAOLD-PSA
 STORAGE OBTAIN, 
   LENGTH=LCLDSCTL,  
   SP=244,   
   LOC=(31,31),  
   CAUB=CURRENT, 
   OWNER=HOME,   
   LINKAGE=BRANCH
 LRR11,R1
 LRR0,R1 
 XRR14,R14   
 XRR15,R15   
 L R1,=AL4(WORKAREA) 
 MVCL  R0,R14

Everything up to the STORAGE OBTAIN seems to work but w/trying to chain
backward / forward save area's (no I not really using the linkage stack), I
get a S0C4-4 ??... I understand the S0C4 because R1 is zeroes ... but ...
why ??. My LTR after the STORAGE OBTAIN does not catch a failure. 

The only reason I'm trying to use the linkage stack is because this is at
the very start of my program.

The trace table shows the SSRV for the OBTAIN .. but it's obviously
failing... 

Could anybody give me some direction / suggestions ??. 

--
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: Storage Obtain .....

[Jim Thomas]

Jim

It's the workarea length ... 004C0 105 LCLDSCTL EQU   *-LCLDSECT
LENGTH OF LOCAL WORK AREA  0041

SVC 6B _1F0012E2  9F001298 9F001298 003C  ModeSet
CCB45F68C0317E5E   05
07851000 8000

 SVCR6B _1F0012E2   9F001298 003C
CCB45F68C0327E4E   05
07041000 8000

 SSRV78  9F00130A      Getmain
CCB45F68C0337D48   05
   003D

 PGM004 _1F001320  00040004    0001 
003D 003D CCB45F68C034FF2C   05
0704 8000      

*RCVY  PROG940C4000 0004   0001 
003D 003D CCB45F68C06843A6   05
   

 SSRV78  8132BBC2  4000EF50 0A28 00FCA5D8  Getmain
CCB45F68C07A83B0   05
   0001


Kind Regards.,

Jim Thomas 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Tuesday, February 11, 2014 8:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

>  BAKR  R0,R0
>  MSTA  R0 
>  MSTA  R12 
>  MODESET MODE=SUP,
>KEY=ZERO 
>  L R11,PSAAOLD-PSA 
>  SETLOCK OBTAIN, 
>ASCB=(11), 
>TYPE=CML, 
>MODE=UNCOND 
>  XRR4,R4 
>  L R7,PSAAOLD-PSA
>  STORAGE OBTAIN, 
>LENGTH=LCLDSCTL, 
>SP=244, 
>LOC=(31,31), 
>CAUB=CURRENT, 
>OWNER=HOME, 
>LINKAGE=BRANCH 
>  LRR11,R1 
>  LRR0,R1 
>  XRR14,R14 
>  XRR15,R15 
>  L R1,=AL4(WORKAREA) 
>  MVCL  R0,R14
> 
> Everything up to the STORAGE OBTAIN seems to work but w/trying to 
> chain backward / forward save area's (no I not really using the 
> linkage
stack),
> I get a S0C4-4 ??... I understand the S0C4 because R1 is zeroes ... 
> but
...
> why ??. My LTR after the STORAGE OBTAIN does not catch a failure. 
> 
> The only reason I'm trying to use the linkage stack is because this is
at
> the very start of my program.
> 
> The trace table shows the SSRV for the OBTAIN .. but it's obviously 
> failing...

  It's not failing.  If it was failing, with the default of COND=NO, 
you would have gotten an ABEND.  What is in the SSRV   78   trace entry?
What is LCLDSCTL, which you used as a length specification? 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
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: Was: Implicit VVDS creation now: FDR & VVDS's

[John McKown]

I thought FDR was the product (Fast Dump Restore) and IDP (Innovation Data
Processing) was the company. Ref: http://www.fdr.com



On Wed, Feb 12, 2014 at 7:05 AM, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:

> In <476fd1b4-cd31-49e7-bba2-d719c96b7...@comcast.net>, on 02/11/2014
>at 01:40 PM, Ed Gould  said:
>
> >I am trying to remember if FDR consolidates the SYS1.VVDS extents
>
> FDR is a company that sells several products; which are you licensed
> for?
>
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wasn't there something about a PASCAL programmer knowing the value of
everything and the Wirth of nothing?

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: Debug Tool: EQA1872E An error occurred while opening file...

[Thomas Berg]

11.1.  I tried google also, but most of them have a specific reference to a 
dataset (which showed up in the log).
But not in this case.


Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: Wednesday, February 12, 2014 2:15 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Debug Tool: EQA1872E An error occurred while opening
> file...
> 
> What version of DEBUG is this?  I just did a google search on EQA1872E
> and came up with a few hits.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Thomas Berg
> Sent: Wednesday, February 12, 2014 7:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Debug Tool: EQA1872E An error occurred while opening
> file...
> 
> They may look like they are commented in the log but they are active
> commands.  (The "/*" doesn't exist in the source.)
> 
> I want to avoid the PMR way as I suspect it's me doing something wrong
> (and it cost money if it is so).
> 
> 
> 
> Best Regards
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jousma, David
> > Sent: Wednesday, February 12, 2014 1:31 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Debug Tool: EQA1872E An error occurred while opening
> > file...
> >
> > Sorry Tom, I didn't know that those commented lines came from that
> > member.   I guess a PMR with them might be in order.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Thomas Berg
> > Sent: Wednesday, February 12, 2014 7:27 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Debug Tool: EQA1872E An error occurred while opening
> > file...
> >
> > As you see below it seems to work ok.  (The content of
> > 'S000TBE.DT.COMMANDS(ALLINIT)' is displayed in the log.)
> >
> >
> >
> > Best Regards
> > Thomas Berg
> > ___
> > Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> >
> >
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David
> > > Sent: Wednesday, February 12, 2014 1:20 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Debug Tool: EQA1872E An error occurred while opening
> > > file...
> > >
> > > I'm not an expert, but it is because of this statement?
> > >
> > > USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg
> > > Sent: Wednesday, February 12, 2014 4:34 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Debug Tool: EQA1872E An error occurred while opening
> file...
> > >
> > > Hi,
> > >
> > > I'm having a problem with running Debug Tool.
> > > I'm getting a "EQA1872E An error occurred while opening file" but I
> > > have no idea of WHY it tries that.
> > > The end of the log:
> > > ...
> > >   SET KEYS ON 12 ;
> > >   SET MONITOR COLUMN ON ;
> > >   USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
> > >  /*USE 'S000TBE.DT.COMMANDS(ALLPROCS)' ;
> > > */
> > >  /*  ALLSESS : PROCEDURE ;
> > > */
> > >  /*USE 'S000TBE.DT.COMMANDS(ALLSESS)' ;
> > > */
> > >  /*  END ;
> > > */
> > >  /*  ALLENTRY : PROCEDURE ;
> > > */
> > >  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> > > */
> > >  /*  END ;
> > > */
> > >  /*  INITCU : PROCEDURE ;
> > > */
> > >  /*USE 'S000TBE.DT.COMMANDS(INITCU)' ;
> > > */
> > >  /*  END ;
> > > */
> > >  /*  USE 'S000TBE.DT.COMMANDS(ALLPGMS)' ;
> > > */
> > >  /*KVAMKNR : PROCEDURE ;
> > > */
> > >  /*  USE 'S000TBE.DT.COMMANDS(KVAMKNR)' ;
> > > */
> > >  /*END ;
> > > */
> > >  /*GKVAMKNR : PROCEDURE ;
> > > */
> > >  /*  USE 'S000TBE.DT.COMMANDS.GENCMD(KVAMKNR)' ;
> > > */
> > >  /*END ;
> > > */
> > >  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> > > */
> > >  /*  %IF %CU = 'KVAMKNR' THEN
> > > */
> > >  /*CALL KVAMKNR ;
> > > */
> > >  /*CALL ALLSESS ;
> > > */
> > >  /*  NAMES EXCLUDE CU "BPS*" ;
> > > */
> > >  /*  NAMES EXCLUDE CU "SPA*" ;
> > > */
> > >  /*  SET ECHO OFF ;
> > > */
> > >  /*  CLEAR AT ;
> > > */
> > >  /* There are no breakpoints set.
> > > */
> > >  /*  CLEAR MONITOR ;
> > > */
> > >  /* *** User preferences file commands end *** */
> > >  /* EQA1872E An error occurred while opening file:
> > > S000TBE.DT.COMMANDS */
> > >  /*  . The file may no

Re: SMP/E SYSMOD SOURCEID(s)?

[Kathryn A. Pinto]

Hi Gil,

Yes, this is characteristic of all repeatable subentries and there is no limit 
to the number of SOURCEIDs that may exist for a SYSMOD.

I will let you be the judge as to whether the existing documentation is unclear 
or you just missed the information.

The 'UCLIN and ENDUCL Syntax' section of the UCLIN command chapter of the SMP/E 
Commands manual:


http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp?topic=%2Fcom.ibm.zos.v2r1.gim1000%2Fgim1217.htm

states the following:

Three types of statements are needed for UCLIN processing:

1. The UCLIN command indicates the start of UCL processing.

2. UCL statements follow the UCLIN command and describe the changes for a 
specific entry. There are three types of UCL statements:
ADD, DEL, and REP. These statements can add, delete, or replace entries 
or subentries in the entries.

   - ADD is used to add the following entries:
   - A new entry
   - A new subentry to an existing entry
   - A new subentry list to an existing entry
   - A new subentry list value to an existing subentry list in an 
existing entry
   - A new subentry indicator to an existing entry

  - DEL is used to delete the following entries:
   - An entire entry
   - A subentry
   - A complete subentry list
   - A value from a subentry list
   - A subentry indicator

  - REP is used to replace the following entries:
   - A subentry in an existing entry
   - A subentry list in an existing entry
   - A subentry indicator in an existing entry

   Note: Do not use the REP statement to replace an individual value in 
a subentry list. If the entry already contains the specified
subentry list—for example, FMID(ABC1234,DEF5678)—SMP/E 
replaces all the current values with the new value specified 
on the REP statement.

Many UCL statements can follow a single UCLIN command. UCL statement 
syntax describes the syntax of specific UCL statements 
for each entry type.

3. The ENDUCL command indicates the end of the UCL statements and the end 
of UCLIN processing.

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

Re: Debug Tool: EQA1872E An error occurred while opening file...

[Jousma, David]

What version of DEBUG is this?  I just did a google search on EQA1872E and came 
up with a few hits.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Thomas Berg
Sent: Wednesday, February 12, 2014 7:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Debug Tool: EQA1872E An error occurred while opening file...

They may look like they are commented in the log but they are active commands.  
(The "/*" doesn't exist in the source.) 

I want to avoid the PMR way as I suspect it's me doing something wrong (and it 
cost money if it is so).  



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jousma, David
> Sent: Wednesday, February 12, 2014 1:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Debug Tool: EQA1872E An error occurred while opening 
> file...
> 
> Sorry Tom, I didn't know that those commented lines came from that
> member.   I guess a PMR with them might be in order.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Thomas Berg
> Sent: Wednesday, February 12, 2014 7:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Debug Tool: EQA1872E An error occurred while opening 
> file...
> 
> As you see below it seems to work ok.  (The content of 
> 'S000TBE.DT.COMMANDS(ALLINIT)' is displayed in the log.)
> 
> 
> 
> Best Regards
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> 
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David
> > Sent: Wednesday, February 12, 2014 1:20 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Debug Tool: EQA1872E An error occurred while opening 
> > file...
> >
> > I'm not an expert, but it is because of this statement?
> >
> > USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg
> > Sent: Wednesday, February 12, 2014 4:34 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Debug Tool: EQA1872E An error occurred while opening file...
> >
> > Hi,
> >
> > I'm having a problem with running Debug Tool.
> > I'm getting a "EQA1872E An error occurred while opening file" but I 
> > have no idea of WHY it tries that.
> > The end of the log:
> > ...
> >   SET KEYS ON 12 ;
> >   SET MONITOR COLUMN ON ;
> >   USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
> >  /*USE 'S000TBE.DT.COMMANDS(ALLPROCS)' ;
> > */
> >  /*  ALLSESS : PROCEDURE ;
> > */
> >  /*USE 'S000TBE.DT.COMMANDS(ALLSESS)' ;
> > */
> >  /*  END ;
> > */
> >  /*  ALLENTRY : PROCEDURE ;
> > */
> >  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> > */
> >  /*  END ;
> > */
> >  /*  INITCU : PROCEDURE ;
> > */
> >  /*USE 'S000TBE.DT.COMMANDS(INITCU)' ;
> > */
> >  /*  END ;
> > */
> >  /*  USE 'S000TBE.DT.COMMANDS(ALLPGMS)' ;
> > */
> >  /*KVAMKNR : PROCEDURE ;
> > */
> >  /*  USE 'S000TBE.DT.COMMANDS(KVAMKNR)' ;
> > */
> >  /*END ;
> > */
> >  /*GKVAMKNR : PROCEDURE ;
> > */
> >  /*  USE 'S000TBE.DT.COMMANDS.GENCMD(KVAMKNR)' ;
> > */
> >  /*END ;
> > */
> >  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> > */
> >  /*  %IF %CU = 'KVAMKNR' THEN
> > */
> >  /*CALL KVAMKNR ;
> > */
> >  /*CALL ALLSESS ;
> > */
> >  /*  NAMES EXCLUDE CU "BPS*" ;
> > */
> >  /*  NAMES EXCLUDE CU "SPA*" ;
> > */
> >  /*  SET ECHO OFF ;
> > */
> >  /*  CLEAR AT ;
> > */
> >  /* There are no breakpoints set.
> > */
> >  /*  CLEAR MONITOR ;
> > */
> >  /* *** User preferences file commands end *** */
> >  /* EQA1872E An error occurred while opening file: 
> > S000TBE.DT.COMMANDS */
> >  /*  . The file may not exist, or is not accessible.
> > */
> >
> > Note the "User preferences file commands end".
> > Why is DT trying to open "S000TBE.DT.COMMANDS" ?  I'm not 
> > referencing that (exact) file(name) (without a membername) in any command 
> > member.
> > And the file DOES exist as you can see above.  I also copied 
> > S000TBE.DT.COMMANDS to S000TBE.S000TBE.DT.COMMANDS in case it had 
> > anything to do with a qualification problem.
> >
> > BTW, does anyone know of a list/forum that may have more DT users 
> > than IBM-MAIN ?
> >
> >
> >
> > Best Regards
> > Thomas Berg
> > ___
> > Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> >
> >
> >
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / arch

Re: Was: Implicit VVDS creation now: FDR & VVDS's

[Shmuel Metz (Seymour J.)]

In <476fd1b4-cd31-49e7-bba2-d719c96b7...@comcast.net>, on 02/11/2014
   at 01:40 PM, Ed Gould  said:

>I am trying to remember if FDR consolidates the SYS1.VVDS extents  

FDR is a company that sells several products; which are you licensed
for?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Debug Tool: EQA1872E An error occurred while opening file...

[Thomas Berg]

They may look like they are commented in the log but they are active commands.  
(The "/*" doesn't exist in the source.) 

I want to avoid the PMR way as I suspect it's me doing something wrong (and it 
cost money if it is so).  



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: Wednesday, February 12, 2014 1:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Debug Tool: EQA1872E An error occurred while opening
> file...
> 
> Sorry Tom, I didn't know that those commented lines came from that
> member.   I guess a PMR with them might be in order.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Thomas Berg
> Sent: Wednesday, February 12, 2014 7:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Debug Tool: EQA1872E An error occurred while opening
> file...
> 
> As you see below it seems to work ok.  (The content of
> 'S000TBE.DT.COMMANDS(ALLINIT)' is displayed in the log.)
> 
> 
> 
> Best Regards
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> 
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jousma, David
> > Sent: Wednesday, February 12, 2014 1:20 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Debug Tool: EQA1872E An error occurred while opening
> > file...
> >
> > I'm not an expert, but it is because of this statement?
> >
> > USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Thomas Berg
> > Sent: Wednesday, February 12, 2014 4:34 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Debug Tool: EQA1872E An error occurred while opening file...
> >
> > Hi,
> >
> > I'm having a problem with running Debug Tool.
> > I'm getting a "EQA1872E An error occurred while opening file" but I
> > have no idea of WHY it tries that.
> > The end of the log:
> > ...
> >   SET KEYS ON 12 ;
> >   SET MONITOR COLUMN ON ;
> >   USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
> >  /*USE 'S000TBE.DT.COMMANDS(ALLPROCS)' ;
> > */
> >  /*  ALLSESS : PROCEDURE ;
> > */
> >  /*USE 'S000TBE.DT.COMMANDS(ALLSESS)' ;
> > */
> >  /*  END ;
> > */
> >  /*  ALLENTRY : PROCEDURE ;
> > */
> >  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> > */
> >  /*  END ;
> > */
> >  /*  INITCU : PROCEDURE ;
> > */
> >  /*USE 'S000TBE.DT.COMMANDS(INITCU)' ;
> > */
> >  /*  END ;
> > */
> >  /*  USE 'S000TBE.DT.COMMANDS(ALLPGMS)' ;
> > */
> >  /*KVAMKNR : PROCEDURE ;
> > */
> >  /*  USE 'S000TBE.DT.COMMANDS(KVAMKNR)' ;
> > */
> >  /*END ;
> > */
> >  /*GKVAMKNR : PROCEDURE ;
> > */
> >  /*  USE 'S000TBE.DT.COMMANDS.GENCMD(KVAMKNR)' ;
> > */
> >  /*END ;
> > */
> >  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> > */
> >  /*  %IF %CU = 'KVAMKNR' THEN
> > */
> >  /*CALL KVAMKNR ;
> > */
> >  /*CALL ALLSESS ;
> > */
> >  /*  NAMES EXCLUDE CU "BPS*" ;
> > */
> >  /*  NAMES EXCLUDE CU "SPA*" ;
> > */
> >  /*  SET ECHO OFF ;
> > */
> >  /*  CLEAR AT ;
> > */
> >  /* There are no breakpoints set.
> > */
> >  /*  CLEAR MONITOR ;
> > */
> >  /* *** User preferences file commands end *** */
> >  /* EQA1872E An error occurred while opening file: S000TBE.DT.COMMANDS
> > */
> >  /*  . The file may not exist, or is not accessible.
> > */
> >
> > Note the "User preferences file commands end".
> > Why is DT trying to open "S000TBE.DT.COMMANDS" ?  I'm not referencing
> > that (exact) file(name) (without a membername) in any command member.
> > And the file DOES exist as you can see above.  I also copied
> > S000TBE.DT.COMMANDS to S000TBE.S000TBE.DT.COMMANDS in case it had
> > anything to do with a qualification problem.
> >
> > BTW, does anyone know of a list/forum that may have more DT users than
> > IBM-MAIN ?
> >
> >
> >
> > Best Regards
> > Thomas Berg
> > ___
> > Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> >
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > This e-mail transmission contains information that is confidential and
> > may be privileged.   It is intended only for the addressee(s) named
> > above. If you receive this e-mail in error, please do not read, copy
> > or disseminate it in any manner. If you are not the intended
> >

Re: IBMLINK SR problems?

[Jousma, David]

FYI, I have opened a PMR with IBM on this.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 11, 2014 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBMLINK SR problems?

Whew.  Glad I am not alone.   There is a statement on their webpage to IE10 
users, with a work around, which I tried to no avail.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Harold Zbiegien
Sent: Tuesday, February 11, 2014 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBMLINK SR problems?

tried to update a PMR, got the same problem, IE9, I deleted cache, retried, 
same problem

 


 From: "Wissink, Brad [ITSYS]" 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, February 11, 2014 3:41 PM
Subject: Re: IBMLINK SR problems?
  

Just entered a new SR ticket at 2:00 pm and everything was fine.   I use 
Firefox.

Brad Wissink 
Information Technology Services 
Iowa State University 
515-294-3088 
"If it ain't broke, you ain't trying" - Red Green

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 11, 2014 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBMLINK SR problems?

Anyone try to open a new ticket today on Service Request?   IE9 here on WIN7, 
and it fails.  Both for me, and a team mate after you fill out the ticket, and 
click on open, comes back with the form emptied out, and error messages saying 
to fill in subject, problem text, etc.  Form is messed up too, SEV1 is gone, 
etc.  I find it hard to believe it is a global thing since no one else has said 
anything, however just as hard to believe it is a local thing either.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Debug Tool: EQA1872E An error occurred while opening file...

[Jousma, David]

Sorry Tom, I didn't know that those commented lines came from that member.   I 
guess a PMR with them might be in order.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Thomas Berg
Sent: Wednesday, February 12, 2014 7:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Debug Tool: EQA1872E An error occurred while opening file...

As you see below it seems to work ok.  (The content of 
'S000TBE.DT.COMMANDS(ALLINIT)' is displayed in the log.)



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jousma, David
> Sent: Wednesday, February 12, 2014 1:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Debug Tool: EQA1872E An error occurred while opening 
> file...
> 
> I'm not an expert, but it is because of this statement?
> 
> USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Thomas Berg
> Sent: Wednesday, February 12, 2014 4:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Debug Tool: EQA1872E An error occurred while opening file...
> 
> Hi,
> 
> I'm having a problem with running Debug Tool.
> I'm getting a "EQA1872E An error occurred while opening file" but I 
> have no idea of WHY it tries that.
> The end of the log:
> ...
>   SET KEYS ON 12 ;
>   SET MONITOR COLUMN ON ;
>   USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
>  /*USE 'S000TBE.DT.COMMANDS(ALLPROCS)' ;
> */
>  /*  ALLSESS : PROCEDURE ;
> */
>  /*USE 'S000TBE.DT.COMMANDS(ALLSESS)' ;
> */
>  /*  END ;
> */
>  /*  ALLENTRY : PROCEDURE ;
> */
>  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> */
>  /*  END ;
> */
>  /*  INITCU : PROCEDURE ;
> */
>  /*USE 'S000TBE.DT.COMMANDS(INITCU)' ;
> */
>  /*  END ;
> */
>  /*  USE 'S000TBE.DT.COMMANDS(ALLPGMS)' ;
> */
>  /*KVAMKNR : PROCEDURE ;
> */
>  /*  USE 'S000TBE.DT.COMMANDS(KVAMKNR)' ;
> */
>  /*END ;
> */
>  /*GKVAMKNR : PROCEDURE ;
> */
>  /*  USE 'S000TBE.DT.COMMANDS.GENCMD(KVAMKNR)' ;
> */
>  /*END ;
> */
>  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> */
>  /*  %IF %CU = 'KVAMKNR' THEN
> */
>  /*CALL KVAMKNR ;
> */
>  /*CALL ALLSESS ;
> */
>  /*  NAMES EXCLUDE CU "BPS*" ;
> */
>  /*  NAMES EXCLUDE CU "SPA*" ;
> */
>  /*  SET ECHO OFF ;
> */
>  /*  CLEAR AT ;
> */
>  /* There are no breakpoints set.
> */
>  /*  CLEAR MONITOR ;
> */
>  /* *** User preferences file commands end *** */
>  /* EQA1872E An error occurred while opening file: S000TBE.DT.COMMANDS 
> */
>  /*  . The file may not exist, or is not accessible.
> */
> 
> Note the "User preferences file commands end".
> Why is DT trying to open "S000TBE.DT.COMMANDS" ?  I'm not referencing 
> that (exact) file(name) (without a membername) in any command member.
> And the file DOES exist as you can see above.  I also copied 
> S000TBE.DT.COMMANDS to S000TBE.S000TBE.DT.COMMANDS in case it had 
> anything to do with a qualification problem.
> 
> BTW, does anyone know of a list/forum that may have more DT users than 
> IBM-MAIN ?
> 
> 
> 
> Best Regards
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> This e-mail transmission contains information that is confidential and
> may be privileged.   It is intended only for the addressee(s) named
> above. If you receive this e-mail in error, please do not read, copy 
> or disseminate it in any manner. If you are not the intended 
> recipient, any disclosure, copying, distribution or use of the 
> contents of this information is prohibited. Please reply to the 
> message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer 
> system. Your assistance in correcting this error is appreciated.
> 
> --
> 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 transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in 

Re: Debug Tool: EQA1872E An error occurred while opening file...

[Thomas Berg]

As you see below it seems to work ok.  (The content of 
'S000TBE.DT.COMMANDS(ALLINIT)' is displayed in the log.)



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: Wednesday, February 12, 2014 1:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Debug Tool: EQA1872E An error occurred while opening
> file...
> 
> I'm not an expert, but it is because of this statement?
> 
> USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Thomas Berg
> Sent: Wednesday, February 12, 2014 4:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Debug Tool: EQA1872E An error occurred while opening file...
> 
> Hi,
> 
> I'm having a problem with running Debug Tool.
> I'm getting a "EQA1872E An error occurred while opening file" but I have
> no idea of WHY it tries that.
> The end of the log:
> ...
>   SET KEYS ON 12 ;
>   SET MONITOR COLUMN ON ;
>   USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
>  /*USE 'S000TBE.DT.COMMANDS(ALLPROCS)' ;
> */
>  /*  ALLSESS : PROCEDURE ;
> */
>  /*USE 'S000TBE.DT.COMMANDS(ALLSESS)' ;
> */
>  /*  END ;
> */
>  /*  ALLENTRY : PROCEDURE ;
> */
>  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> */
>  /*  END ;
> */
>  /*  INITCU : PROCEDURE ;
> */
>  /*USE 'S000TBE.DT.COMMANDS(INITCU)' ;
> */
>  /*  END ;
> */
>  /*  USE 'S000TBE.DT.COMMANDS(ALLPGMS)' ;
> */
>  /*KVAMKNR : PROCEDURE ;
> */
>  /*  USE 'S000TBE.DT.COMMANDS(KVAMKNR)' ;
> */
>  /*END ;
> */
>  /*GKVAMKNR : PROCEDURE ;
> */
>  /*  USE 'S000TBE.DT.COMMANDS.GENCMD(KVAMKNR)' ;
> */
>  /*END ;
> */
>  /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;
> */
>  /*  %IF %CU = 'KVAMKNR' THEN
> */
>  /*CALL KVAMKNR ;
> */
>  /*CALL ALLSESS ;
> */
>  /*  NAMES EXCLUDE CU "BPS*" ;
> */
>  /*  NAMES EXCLUDE CU "SPA*" ;
> */
>  /*  SET ECHO OFF ;
> */
>  /*  CLEAR AT ;
> */
>  /* There are no breakpoints set.
> */
>  /*  CLEAR MONITOR ;
> */
>  /* *** User preferences file commands end ***
> */
>  /* EQA1872E An error occurred while opening file: S000TBE.DT.COMMANDS
> */
>  /*  . The file may not exist, or is not accessible.
> */
> 
> Note the "User preferences file commands end".
> Why is DT trying to open "S000TBE.DT.COMMANDS" ?  I'm not referencing
> that (exact) file(name) (without a membername) in any command member.
> And the file DOES exist as you can see above.  I also copied
> S000TBE.DT.COMMANDS to S000TBE.S000TBE.DT.COMMANDS in case it had
> anything to do with a qualification problem.
> 
> BTW, does anyone know of a list/forum that may have more DT users than
> IBM-MAIN ?
> 
> 
> 
> Best Regards
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> This e-mail transmission contains information that is confidential and
> may be privileged.   It is intended only for the addressee(s) named
> above. If you receive this e-mail in error, please do not read, copy or
> disseminate it in any manner. If you are not the intended recipient, any
> disclosure, copying, distribution or use of the contents of this
> information is prohibited. Please reply to the message immediately by
> informing the sender that the message was misdirected. After replying,
> please erase it from your computer system. Your assistance in correcting
> this error is appreciated.
> 
> --
> 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: Debug Tool: EQA1872E An error occurred while opening file...

[Jousma, David]

I'm not an expert, but it is because of this statement?

USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Thomas Berg
Sent: Wednesday, February 12, 2014 4:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Debug Tool: EQA1872E An error occurred while opening file...

Hi,

I'm having a problem with running Debug Tool.
I'm getting a "EQA1872E An error occurred while opening file" but I have no 
idea of WHY it tries that.
The end of the log:
...
  SET KEYS ON 12 ;
  SET MONITOR COLUMN ON ;
  USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
 /*USE 'S000TBE.DT.COMMANDS(ALLPROCS)' ;   */
 /*  ALLSESS : PROCEDURE ; */
 /*USE 'S000TBE.DT.COMMANDS(ALLSESS)' ;*/
 /*  END ; */
 /*  ALLENTRY : PROCEDURE ;*/
 /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;   */
 /*  END ; */
 /*  INITCU : PROCEDURE ;  */
 /*USE 'S000TBE.DT.COMMANDS(INITCU)' ; */
 /*  END ; */
 /*  USE 'S000TBE.DT.COMMANDS(ALLPGMS)' ;  */
 /*KVAMKNR : PROCEDURE ;   */
 /*  USE 'S000TBE.DT.COMMANDS(KVAMKNR)' ;  */
 /*END ;   */
 /*GKVAMKNR : PROCEDURE ;  */
 /*  USE 'S000TBE.DT.COMMANDS.GENCMD(KVAMKNR)' ;   */
 /*END ;   */
 /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;   */
 /*  %IF %CU = 'KVAMKNR' THEN  */
 /*CALL KVAMKNR ;  */
 /*CALL ALLSESS ;  */
 /*  NAMES EXCLUDE CU "BPS*" ; */
 /*  NAMES EXCLUDE CU "SPA*" ; */
 /*  SET ECHO OFF ;*/
 /*  CLEAR AT ;*/
 /* There are no breakpoints set.  */
 /*  CLEAR MONITOR ;   */
 /* *** User preferences file commands end *** */
 /* EQA1872E An error occurred while opening file: S000TBE.DT.COMMANDS */
 /*  . The file may not exist, or is not accessible.   */

Note the "User preferences file commands end".
Why is DT trying to open "S000TBE.DT.COMMANDS" ?  I'm not referencing that 
(exact) file(name) (without a membername) in any command member. And the file 
DOES exist as you can see above.  I also copied S000TBE.DT.COMMANDS to 
S000TBE.S000TBE.DT.COMMANDS in case it had anything to do with a qualification 
problem.

BTW, does anyone know of a list/forum that may have more DT users than IBM-MAIN 
?



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)




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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Storage Obtain .....

[DASDBILL2]

>My LTR after the STORAGE OBTAIN does not catch a failure. 
Your LTR after the STORAGE OBTAIN is not in the code you posted. 
  
Bill Fairchild 

- Original Message -

From: "Jim Thomas"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, February 11, 2014 5:50:53 PM 
Subject: Re: Storage Obtain . 

Hello ... 

Given the below ... 

         BAKR  R0,R0 
         MSTA  R0       
         MSTA  R12     
         MODESET MODE=SUP, 
               KEY=ZERO   
         L     R11,PSAAOLD-PSA 
         SETLOCK OBTAIN,       
               ASCB=(11),       
               TYPE=CML,       
               MODE=UNCOND     
         XR    R4,R4         
         L     R7,PSAAOLD-PSA 
         STORAGE OBTAIN,         
               LENGTH=LCLDSCTL,   
               SP=244,           
               LOC=(31,31),       
               CAUB=CURRENT,     
               OWNER=HOME,       
               LINKAGE=BRANCH     
         LR    R11,R1             
         LR    R0,R1             
         XR    R14,R14           
         XR    R15,R15           
         L     R1,=AL4(WORKAREA) 
         MVCL  R0,R14             

Everything up to the STORAGE OBTAIN seems to work but w/trying to chain 
backward / forward save area's (no I not really using the linkage stack), 
I get a S0C4-4 ??... I understand the S0C4 because R1 is zeroes ... but ... 
why ??. My LTR after the STORAGE OBTAIN does not catch a failure. 

The only reason I'm trying to use the linkage stack is because this is at 
the very start of my program. 

The trace table shows the SSRV for the OBTAIN .. but it's obviously 
failing... 

Could anybody give me some direction / suggestions ??. 

Kind Regards. 

Jim Thomas 

-- 
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: SYSLOG messages Frozen

[Vernooij, CP (SPLXM) - KLM]

I checked Google:
Was a WRITELOG CLOSE command given before? Issue WRITELOG START to
reverse.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Wednesday, February 12, 2014 12:30
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYSLOG messages Frozen

IEE026I SYSLOG   NOT SUPPORTED - After V SYSLOG,HARDCPY


CONSOLES MATCHING COMMAND: D C,HC
MSG:CURR=1LIM= RPLY:CURR=20   LIM=200   SYS=CA11 PFK=00
HARDCOPY  LOG=(OPERLOG) CMDLEVEL=CMDS
  ROUT=(ALL)





On Wed, Feb 12, 2014 at 4:56 PM, Vernooij, CP (SPLXM) - KLM <
kees.verno...@klm.com> wrote:

> Are you sure of the syntax? No problem here:
>
> V SYSLOG,HARDCPY
> D C,HC,L=Z
> CNZ4100I 12.24.51 CONSOLE DISPLAY 529
> CONSOLES MATCHING COMMAND: D C,HC
> MSG:CURR=0LIM=5000 RPLY:CURR=0LIM=99SYS=MVSM PFK=00
> HARDCOPY  LOG=(SYSLOG,OPERLOG)  CMDLEVEL=CMDS
>   ROUT=(ALL)
> LOG BUFFERS IN USE: 0   LOG BUFFER LIMIT: 5000
>
> Kees
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of mf db
> Sent: Wednesday, February 12, 2014 12:17
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSLOG messages Frozen
>
> Hi,
>
> OPERLOG is working, but SYSLOG is not working.. I tried giving V 
> SYSLOG,HARDCPY but it says invalid syntax
>
>
> On Wed, Feb 12, 2014 at 4:42 PM, Vernooij, CP (SPLXM) - KLM < 
> kees.verno...@klm.com> wrote:
>
> > Is your SYSLOG or your OPERLOG not functioning?
> > You can use V SYSLOG,HARDCPY (or OPERLOG) The V command accepts some

> > parameters from the HARDCOPY statement, like ROUTCDE and CMDLEVEL, 
> > check the manual.
> >
> > Kees
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db
> > Sent: Wednesday, February 12, 2014 11:58
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SYSLOG messages Frozen
> >
> > Hi,
> >
> > I tried giving : V OPERLOG,HARDCPY,HARDCOPY
> > DEVNUM(SYSLOG,OPERLOG),ROUTCODE(ALL),CMDLEVEL(CMDS)
> >
> > but it says its a invalid keyword
> >
> >
> > On Wed, Feb 12, 2014 at 4:17 PM, Vernooij, CP (SPLXM) - KLM < 
> > kees.verno...@klm.com> wrote:
> >
> > > Yes:
> > > V SYSLOG,HARDCPY,followed by the parameter in CONSOLxx for the 
> > > HARDCOPY device.
> > > Similarly:
> > > V OPERLOG,HARDCPY
> > >
> > > Kees.
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List 
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db
> > > Sent: Wednesday, February 12, 2014 11:20
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: SYSLOG messages Frozen
> > >
> > > Hello Group,
> > >
> > > One of our LPAR's SYSLOG messages are not being updated. I see 
> > > there
>
> > > are no contentions in Console. I checked in /etc/rc to see if the 
> > > SYSLOG is started as BPX, but thats commented.
> > >
> > > Is there a way to restart the SYSLOG address space
> > >
> > > Peter
> > >
> > > --
> > > --
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,

> > > send email to lists...@listserv.ua.edu with the message: INFO 
> > > IBM-MAIN
> > > 
> > > For information, services and offers, please visit our web site:
> > > http://www.klm.com. This e-mail and any attachment may contain 
> > > confidential and privileged material intended for the addressee
> only.
> > > If you are not the addressee, you are notified that no part of the

> > > e-mail or any attachment may be disclosed, copied or distributed, 
> > > and that any other action related to this e-mail or attachment is 
> > > strictly
> >
> > > prohibited, and may be unlawful. If you have received this e-mail 
> > > by
>
> > > error, please notify the sender immediately by return e-mail, and
> > delete this message.
> > >
> > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries 
> > > and/or its employees shall not be liable for the incorrect or 
> > > incomplete transmission of this e-mail or any attachments, nor 
> > > responsible for
> > any delay in receipt.
> > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> > > Dutch
> > > Airlines) is registered in Amstelveen, The Netherlands, with 
> > > registered number 33014286
> > > 
> > >
> > >
> > > --
> > > --
> > > -- 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 information, s

Re: SYSLOG messages Frozen

[mf db]

IEE026I SYSLOG   NOT SUPPORTED - After V SYSLOG,HARDCPY


CONSOLES MATCHING COMMAND: D C,HC
MSG:CURR=1LIM= RPLY:CURR=20   LIM=200   SYS=CA11 PFK=00
HARDCOPY  LOG=(OPERLOG) CMDLEVEL=CMDS
  ROUT=(ALL)





On Wed, Feb 12, 2014 at 4:56 PM, Vernooij, CP (SPLXM) - KLM <
kees.verno...@klm.com> wrote:

> Are you sure of the syntax? No problem here:
>
> V SYSLOG,HARDCPY
> D C,HC,L=Z
> CNZ4100I 12.24.51 CONSOLE DISPLAY 529
> CONSOLES MATCHING COMMAND: D C,HC
> MSG:CURR=0LIM=5000 RPLY:CURR=0LIM=99SYS=MVSM PFK=00
> HARDCOPY  LOG=(SYSLOG,OPERLOG)  CMDLEVEL=CMDS
>   ROUT=(ALL)
> LOG BUFFERS IN USE: 0   LOG BUFFER LIMIT: 5000
>
> Kees
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of mf db
> Sent: Wednesday, February 12, 2014 12:17
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSLOG messages Frozen
>
> Hi,
>
> OPERLOG is working, but SYSLOG is not working.. I tried giving V
> SYSLOG,HARDCPY but it says invalid syntax
>
>
> On Wed, Feb 12, 2014 at 4:42 PM, Vernooij, CP (SPLXM) - KLM <
> kees.verno...@klm.com> wrote:
>
> > Is your SYSLOG or your OPERLOG not functioning?
> > You can use V SYSLOG,HARDCPY (or OPERLOG) The V command accepts some
> > parameters from the HARDCOPY statement, like ROUTCDE and CMDLEVEL,
> > check the manual.
> >
> > Kees
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of mf db
> > Sent: Wednesday, February 12, 2014 11:58
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SYSLOG messages Frozen
> >
> > Hi,
> >
> > I tried giving : V OPERLOG,HARDCPY,HARDCOPY
> > DEVNUM(SYSLOG,OPERLOG),ROUTCODE(ALL),CMDLEVEL(CMDS)
> >
> > but it says its a invalid keyword
> >
> >
> > On Wed, Feb 12, 2014 at 4:17 PM, Vernooij, CP (SPLXM) - KLM <
> > kees.verno...@klm.com> wrote:
> >
> > > Yes:
> > > V SYSLOG,HARDCPY,followed by the parameter in CONSOLxx for the
> > > HARDCOPY device.
> > > Similarly:
> > > V OPERLOG,HARDCPY
> > >
> > > Kees.
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db
> > > Sent: Wednesday, February 12, 2014 11:20
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: SYSLOG messages Frozen
> > >
> > > Hello Group,
> > >
> > > One of our LPAR's SYSLOG messages are not being updated. I see there
>
> > > are no contentions in Console. I checked in /etc/rc to see if the
> > > SYSLOG is started as BPX, but thats commented.
> > >
> > > Is there a way to restart the SYSLOG address space
> > >
> > > Peter
> > >
> > > 
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO
> > > IBM-MAIN
> > > 
> > > For information, services and offers, please visit our web site:
> > > http://www.klm.com. This e-mail and any attachment may contain
> > > confidential and privileged material intended for the addressee
> only.
> > > If you are not the addressee, you are notified that no part of the
> > > e-mail or any attachment may be disclosed, copied or distributed,
> > > and that any other action related to this e-mail or attachment is
> > > strictly
> >
> > > prohibited, and may be unlawful. If you have received this e-mail by
>
> > > error, please notify the sender immediately by return e-mail, and
> > delete this message.
> > >
> > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
> > > and/or its employees shall not be liable for the incorrect or
> > > incomplete transmission of this e-mail or any attachments, nor
> > > responsible for
> > any delay in receipt.
> > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > > Dutch
> > > Airlines) is registered in Amstelveen, The Netherlands, with
> > > registered number 33014286
> > > 
> > >
> > >
> > > 
> > > -- 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 information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only.
> > If you are not the addressee, you are notified that no part of the
> > e-mail or any attachment may be disclosed, copied or distributed, and
> > that any other action related to this e-mail o

Re: SYSLOG messages Frozen

[Vernooij, CP (SPLXM) - KLM]

Are you sure of the syntax? No problem here:

V SYSLOG,HARDCPY   
D C,HC,L=Z 
CNZ4100I 12.24.51 CONSOLE DISPLAY 529  
CONSOLES MATCHING COMMAND: D C,HC  
MSG:CURR=0LIM=5000 RPLY:CURR=0LIM=99SYS=MVSM PFK=00
HARDCOPY  LOG=(SYSLOG,OPERLOG)  CMDLEVEL=CMDS  
  ROUT=(ALL)   
LOG BUFFERS IN USE: 0   LOG BUFFER LIMIT: 5000 

Kees

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Wednesday, February 12, 2014 12:17
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYSLOG messages Frozen

Hi,

OPERLOG is working, but SYSLOG is not working.. I tried giving V
SYSLOG,HARDCPY but it says invalid syntax


On Wed, Feb 12, 2014 at 4:42 PM, Vernooij, CP (SPLXM) - KLM <
kees.verno...@klm.com> wrote:

> Is your SYSLOG or your OPERLOG not functioning?
> You can use V SYSLOG,HARDCPY (or OPERLOG) The V command accepts some 
> parameters from the HARDCOPY statement, like ROUTCDE and CMDLEVEL, 
> check the manual.
>
> Kees
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of mf db
> Sent: Wednesday, February 12, 2014 11:58
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSLOG messages Frozen
>
> Hi,
>
> I tried giving : V OPERLOG,HARDCPY,HARDCOPY
> DEVNUM(SYSLOG,OPERLOG),ROUTCODE(ALL),CMDLEVEL(CMDS)
>
> but it says its a invalid keyword
>
>
> On Wed, Feb 12, 2014 at 4:17 PM, Vernooij, CP (SPLXM) - KLM < 
> kees.verno...@klm.com> wrote:
>
> > Yes:
> > V SYSLOG,HARDCPY,followed by the parameter in CONSOLxx for the 
> > HARDCOPY device.
> > Similarly:
> > V OPERLOG,HARDCPY
> >
> > Kees.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db
> > Sent: Wednesday, February 12, 2014 11:20
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: SYSLOG messages Frozen
> >
> > Hello Group,
> >
> > One of our LPAR's SYSLOG messages are not being updated. I see there

> > are no contentions in Console. I checked in /etc/rc to see if the 
> > SYSLOG is started as BPX, but thats commented.
> >
> > Is there a way to restart the SYSLOG address space
> >
> > Peter
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> > 
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain 
> > confidential and privileged material intended for the addressee
only.
> > If you are not the addressee, you are notified that no part of the 
> > e-mail or any attachment may be disclosed, copied or distributed, 
> > and that any other action related to this e-mail or attachment is 
> > strictly
>
> > prohibited, and may be unlawful. If you have received this e-mail by

> > error, please notify the sender immediately by return e-mail, and
> delete this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries 
> > and/or its employees shall not be liable for the incorrect or 
> > incomplete transmission of this e-mail or any attachments, nor 
> > responsible for
> any delay in receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> > Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with 
> > registered number 33014286
> > 
> >
> >
> > 
> > -- 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 information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain 
> confidential and privileged material intended for the addressee only. 
> If you are not the addressee, you are notified that no part of the 
> e-mail or any attachment may be disclosed, copied or distributed, and 
> that any other action related to this e-mail or attachment is strictly

> prohibited, and may be unlawful. If you have received this e-mail by 
> error, please notify the sender immediately by return e-mail, and
delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsi

Re: SYSLOG messages Frozen

[mf db]

Hi,

OPERLOG is working, but SYSLOG is not working.. I tried giving V
SYSLOG,HARDCPY but it says invalid syntax


On Wed, Feb 12, 2014 at 4:42 PM, Vernooij, CP (SPLXM) - KLM <
kees.verno...@klm.com> wrote:

> Is your SYSLOG or your OPERLOG not functioning?
> You can use V SYSLOG,HARDCPY (or OPERLOG)
> The V command accepts some parameters from the HARDCOPY statement, like
> ROUTCDE and CMDLEVEL, check the manual.
>
> Kees
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of mf db
> Sent: Wednesday, February 12, 2014 11:58
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSLOG messages Frozen
>
> Hi,
>
> I tried giving : V OPERLOG,HARDCPY,HARDCOPY
> DEVNUM(SYSLOG,OPERLOG),ROUTCODE(ALL),CMDLEVEL(CMDS)
>
> but it says its a invalid keyword
>
>
> On Wed, Feb 12, 2014 at 4:17 PM, Vernooij, CP (SPLXM) - KLM <
> kees.verno...@klm.com> wrote:
>
> > Yes:
> > V SYSLOG,HARDCPY,followed by the parameter in CONSOLxx for the
> > HARDCOPY device.
> > Similarly:
> > V OPERLOG,HARDCPY
> >
> > Kees.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of mf db
> > Sent: Wednesday, February 12, 2014 11:20
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: SYSLOG messages Frozen
> >
> > Hello Group,
> >
> > One of our LPAR's SYSLOG messages are not being updated. I see there
> > are no contentions in Console. I checked in /etc/rc to see if the
> > SYSLOG is started as BPX, but thats commented.
> >
> > Is there a way to restart the SYSLOG address space
> >
> > Peter
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > 
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only.
> > If you are not the addressee, you are notified that no part of the
> > e-mail or any attachment may be disclosed, copied or distributed, and
> > that any other action related to this e-mail or attachment is strictly
>
> > prohibited, and may be unlawful. If you have received this e-mail by
> > error, please notify the sender immediately by return e-mail, and
> delete this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> > its employees shall not be liable for the incorrect or incomplete
> > transmission of this e-mail or any attachments, nor responsible for
> any delay in receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with
> > registered number 33014286
> > 
> >
> >
> > --
> > 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 information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
>
> --
> 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: SYSLOG messages Frozen

[Vernooij, CP (SPLXM) - KLM]

Is your SYSLOG or your OPERLOG not functioning?
You can use V SYSLOG,HARDCPY (or OPERLOG)
The V command accepts some parameters from the HARDCOPY statement, like
ROUTCDE and CMDLEVEL, check the manual.

Kees

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Wednesday, February 12, 2014 11:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYSLOG messages Frozen

Hi,

I tried giving : V OPERLOG,HARDCPY,HARDCOPY
DEVNUM(SYSLOG,OPERLOG),ROUTCODE(ALL),CMDLEVEL(CMDS)

but it says its a invalid keyword


On Wed, Feb 12, 2014 at 4:17 PM, Vernooij, CP (SPLXM) - KLM <
kees.verno...@klm.com> wrote:

> Yes:
> V SYSLOG,HARDCPY,followed by the parameter in CONSOLxx for the 
> HARDCOPY device.
> Similarly:
> V OPERLOG,HARDCPY
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of mf db
> Sent: Wednesday, February 12, 2014 11:20
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SYSLOG messages Frozen
>
> Hello Group,
>
> One of our LPAR's SYSLOG messages are not being updated. I see there 
> are no contentions in Console. I checked in /etc/rc to see if the 
> SYSLOG is started as BPX, but thats commented.
>
> Is there a way to restart the SYSLOG address space
>
> Peter
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain 
> confidential and privileged material intended for the addressee only. 
> If you are not the addressee, you are notified that no part of the 
> e-mail or any attachment may be disclosed, copied or distributed, and 
> that any other action related to this e-mail or attachment is strictly

> prohibited, and may be unlawful. If you have received this e-mail by 
> error, please notify the sender immediately by return e-mail, and
delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or 
> its employees shall not be liable for the incorrect or incomplete 
> transmission of this e-mail or any attachments, nor responsible for
any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with 
> registered number 33014286
> 
>
>
> --
> 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 information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: SYSLOG messages Frozen

[mf db]

Hi,

I tried giving : V OPERLOG,HARDCPY,HARDCOPY
DEVNUM(SYSLOG,OPERLOG),ROUTCODE(ALL),CMDLEVEL(CMDS)

but it says its a invalid keyword


On Wed, Feb 12, 2014 at 4:17 PM, Vernooij, CP (SPLXM) - KLM <
kees.verno...@klm.com> wrote:

> Yes:
> V SYSLOG,HARDCPY,followed by the parameter in CONSOLxx for the HARDCOPY
> device.
> Similarly:
> V OPERLOG,HARDCPY
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of mf db
> Sent: Wednesday, February 12, 2014 11:20
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SYSLOG messages Frozen
>
> Hello Group,
>
> One of our LPAR's SYSLOG messages are not being updated. I see there are
> no contentions in Console. I checked in /etc/rc to see if the SYSLOG is
> started as BPX, but thats commented.
>
> Is there a way to restart the SYSLOG address space
>
> Peter
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
>
> --
> 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: SYSLOG messages Frozen

[Vernooij, CP (SPLXM) - KLM]

Yes:
V SYSLOG,HARDCPY,followed by the parameter in CONSOLxx for the HARDCOPY
device.
Similarly:
V OPERLOG,HARDCPY

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Wednesday, February 12, 2014 11:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SYSLOG messages Frozen

Hello Group,

One of our LPAR's SYSLOG messages are not being updated. I see there are
no contentions in Console. I checked in /etc/rc to see if the SYSLOG is
started as BPX, but thats commented.

Is there a way to restart the SYSLOG address space

Peter

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

SYSLOG messages Frozen

[mf db]

Hello Group,

One of our LPAR's SYSLOG messages are not being updated. I see there are no
contentions in Console. I checked in /etc/rc to see if the SYSLOG is
started as BPX, but thats commented.

Is there a way to restart the SYSLOG address space

Peter

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

Re: Storage Obtain .....

[Binyamin Dissen]

On Tue, 11 Feb 2014 17:50:53 -0600 Jim Thomas 
wrote:

:>Given the below ... 

:> BAKR  R0,R0
:> MSTA  R0  
:> MSTA  R12 

Why twice?

:> MODESET MODE=SUP,
:>   KEY=ZERO   
:> L R11,PSAAOLD-PSA 
:> SETLOCK OBTAIN,   
:>   ASCB=(11),  
:>   TYPE=CML,   
:>   MODE=UNCOND

Why not directly take the local lock rather than this convoluted form?

Also, without REGS=, R11-R13 are changed.
 
:> XRR4,R4 
:> L R7,PSAAOLD-PSA
:> STORAGE OBTAIN, 
:>   LENGTH=LCLDSCTL,  
:>   SP=244,   
:>   LOC=(31,31),  
:>   CAUB=CURRENT, 
:>   OWNER=HOME,   
:>   LINKAGE=BRANCH
:> LRR11,R1
:> LRR0,R1 
:> XRR14,R14   
:> XRR15,R15   
:> L R1,=AL4(WORKAREA) 

Is workarea the same length (or shorter) than LCLDSCTL?

:> MVCL  R0,R14

:>Everything up to the STORAGE OBTAIN seems to work but w/trying to chain
:>backward / forward save area's (no I not really using the linkage stack),
:>I get a S0C4-4 ??... I understand the S0C4 because R1 is zeroes ... but ...
:>why ??. My LTR after the STORAGE OBTAIN does not catch a failure. 

SETLOCK has altered your R13.

:>The only reason I'm trying to use the linkage stack is because this is at
:>the very start of my program.

:>The trace table shows the SSRV for the OBTAIN .. but it's obviously
:>failing... 

:>Could anybody give me some direction / suggestions ??. 

Which instruction is causing the 0C4? What is your base register?

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Debug Tool: EQA1872E An error occurred while opening file...

[Thomas Berg]

Hi,

I'm having a problem with running Debug Tool.
I'm getting a "EQA1872E An error occurred while opening file" but I have no 
idea of WHY it tries that.
The end of the log:
...
  SET KEYS ON 12 ;
  SET MONITOR COLUMN ON ;
  USE 'S000TBE.DT.COMMANDS(ALLINIT)' ;
 /*USE 'S000TBE.DT.COMMANDS(ALLPROCS)' ;   */
 /*  ALLSESS : PROCEDURE ; */
 /*USE 'S000TBE.DT.COMMANDS(ALLSESS)' ;*/
 /*  END ; */
 /*  ALLENTRY : PROCEDURE ;*/
 /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;   */
 /*  END ; */
 /*  INITCU : PROCEDURE ;  */
 /*USE 'S000TBE.DT.COMMANDS(INITCU)' ; */
 /*  END ; */
 /*  USE 'S000TBE.DT.COMMANDS(ALLPGMS)' ;  */
 /*KVAMKNR : PROCEDURE ;   */
 /*  USE 'S000TBE.DT.COMMANDS(KVAMKNR)' ;  */
 /*END ;   */
 /*GKVAMKNR : PROCEDURE ;  */
 /*  USE 'S000TBE.DT.COMMANDS.GENCMD(KVAMKNR)' ;   */
 /*END ;   */
 /*USE 'S000TBE.DT.COMMANDS(ALLENTRY)' ;   */
 /*  %IF %CU = 'KVAMKNR' THEN  */
 /*CALL KVAMKNR ;  */
 /*CALL ALLSESS ;  */
 /*  NAMES EXCLUDE CU "BPS*" ; */
 /*  NAMES EXCLUDE CU "SPA*" ; */
 /*  SET ECHO OFF ;*/
 /*  CLEAR AT ;*/
 /* There are no breakpoints set.  */
 /*  CLEAR MONITOR ;   */
 /* *** User preferences file commands end *** */
 /* EQA1872E An error occurred while opening file: S000TBE.DT.COMMANDS */
 /*  . The file may not exist, or is not accessible.   */

Note the "User preferences file commands end".
Why is DT trying to open "S000TBE.DT.COMMANDS" ?  I'm not referencing that 
(exact) file(name) (without a membername) in any command member. And the file 
DOES exist as you can see above.  I also copied S000TBE.DT.COMMANDS to 
S000TBE.S000TBE.DT.COMMANDS in case it had anything to do with a qualification 
problem.

BTW, does anyone know of a list/forum that may have more DT users than IBM-MAIN 
?



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)




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