>We are in the process of moving 30 or so COBOL programs that use AFP from VSE
>to z/OS. While we have a handle on the changes required to use PSF we are
>having a somewhat difficult time compiling and 'LinkEditing' the programs.At
>link time we get a ton of what appear to be C C++ unresolved r
blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px
#715FFA solid !important; padding-left:1ex !important; background-color:white
!important; } Guys,Does anyone has an old copy of vmsp rel5 ou 6 running an old
VS COBOL II (PN 5668-958)? Thank youDan
Sent from Yahoo Mail
>In what z/OS release(s) will those statements be corrected?
Books from old releases, whether supported releases or unsupported
releases, are typically not updated.
It is possible the update will show up in the 2.2 release; I would think
that it is unlikely to be made in any release earlier tha
I'm with those who are surprised that a directory-full condition would result
in x37, which I associate with the management of data set extents. In any case
I would certainly expect the error to show up in the CAUSER report, which lists
all (well, mostly all) unresolved errors during sysmod APPL
The error in the CAUSER report was that the Linkage return was > 4 and it did
not point to the SISFLOAD. It did point to the SMPn report, which was quite
long in the first run.
Before 2.1, I believe I would have seen an also seen an error in the job log
which would have quickly told me to ex
Maybe my memory is of an IEC217I or other message.
My real whine (and that's all it really is :) ) is that I think the info I am
used to looking for was suppressed in favor of different (possibly more useful)
info in a different place.
> -Original Message-
> From: IBM Mainframe Discussi
Carl,
PSF/VSE has an API that allows access to AFP functions. PSF for z/OS no
longer provides the API. It has been replaced by AFP Toolbox (5655-A25) as
a separately licensed product.
Al Loeffler
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] O
Paul Gilmartin wrote:
On Fri, 23 Sep 2016 16:55:54 -0700, Tom Brennan wrote:
I don't get it. A PO directory size is fixed, so why would we ever get
into x37 extent processing from STOW? Maybe I just don't understand.
But the message said nothing about extent processing:
I know, I probab
I've been running on 2.1 for quite a while. Looked for a recent job that had
some kind of 'space error'. Found one with actual x37 abends (but not directory
block shortage.). The CAUSER report has a slightly different format according
to whether the failure was in IEBCOPY, data transform, or bin
On 2016-09-24, at 11:25, Gibney, Dave wrote:
> Maybe my memory is of an IEC217I or other message.
> My real whine (and that's all it really is :) ) is that I think the info I am
> used to looking for was suppressed in favor of different (possibly more
> useful) info in a different place.
>
Pe
Just curious. I'm looking at:
z/OS 2.2.0
z/OS DFSMS
z/OS DFSMS Using Data Sets
Non-VSAM Access to Data Sets and UNIX Files
Processing a Partitioned Data Set Extended (PDSE)
Creating a PDSE Member
Adding or Replacing Multiple PDSE Members Concurrently
... which makes it
Hi
I have UNIT=VIO
I just read where this can only be specified on a temporary dataset and as I
have been told I can't do that with SVC 99
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Friday, September 23,
Well, yeah, it has to be temporary -- you can't catalog a dataset in VIO!
SVC 99 will let you allocate a temporary dataset -- I think it was a
back-reference you were trying to do before? That won't work.
IIRC the basic SVC 99 temporary dataset strategy is to omit the DSN key.
What are you tryi
>From the FM:
Verb code 01 - Dsname allocation text units
Dsname specification - Key = '0002'
DALDSNAM specifies the name of the data set to be allocated. The data set name
can contain special characters, if the data set name is enclosed in
apostrophes. The system cannot catalog a data set nam
So If I code DALSTATS = 04 and DALNDISP = 04
Which is disp=(NEW,DELETE)
It should work I don't have a dataset name
Regardless S99ERROR is 21C
> On Sep 24, 2016, at 9:46 PM, Charles Mills wrote:
>
> Well, yeah, it has to be temporary -- you can't catalog a dataset in VIO!
>
> SVC 99 will le
FM says you can have a DSN :
Example: To specify the temporary dsname &LOAD, code: KEY # LEN PARM
0002 0001 0005 50 D3 D6 C1 C4
Have you tried UNIT=SYSALLDA?
Sent from my iPhone
> On Sep 24, 2016, at 22:05, Joseph Reichman wrote:
>
> So If I code DALSTATS = 04 a
I wonder if I can dummy SYSLIN as I just want the assembler listing
> On Sep 24, 2016, at 10:15 PM, J R wrote:
>
> FM says you can have a DSN :
>
> Example: To specify the temporary dsname &LOAD, code: KEY # LEN PARM
>
> 0002 0001 0005 50 D3 D6 C1 C4
>
> Have y
I hope the assembly
Works all I want is the assembler listing
> On Sep 24, 2016, at 10:15 PM, J R wrote:
>
> FM says you can have a DSN :
>
> Example: To specify the temporary dsname &LOAD, code: KEY # LEN PARM
>
> 0002 0001 0005 50 D3 D6 C1 C4
>
> Have you tr
If you specify NODECK you shouldn't need SYSLIN.
Sent from my iPhone
> On Sep 24, 2016, at 22:23, Joseph Reichman wrote:
>
> I wonder if I can dummy SYSLIN as I just want the assembler listing
>
>
>
>> On Sep 24, 2016, at 10:15 PM, J R wrote:
>>
>> FM says you can have a DSN :
>>
>> E
Thanks
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of J R
Sent: Saturday, September 24, 2016 10:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S99ERROR = 21C For &&OBJ UNIT=VIO
If you specify NODECK you shouldn't need SYSLIN.
Sent
On Sun, 25 Sep 2016 02:02:43 +, J R wrote:
>From the FM:
>
>Verb code 01 - Dsname allocation text units
>
>Dsname specification - Key = '0002'
>
>DALDSNAM specifies the name of the data set to be allocated. The data set name
>can contain special characters, if the data set name is enclosed in
21 matches
Mail list logo
