How to output arp datastream

[Tommy Tsui]

Hi all,
Is there any way I can output the afp data stream to a qsam file format？and 
transmit the dataset to other platform!

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

Re: How to output afp datastream (was How to output arp datastream)

[Chris Hoelscher]

Unfortunately, many of us are intently interested in the aarp datastream ... oh 
wait

Chris hoelscher
Technology Architect 
Database Infrastructure Services
Technology Solution Services

123 East Main Street
Louisville, KY 40202
choelsc...@humana.com
Humana.com
(502) 714-8615
(502) 476-2538
 with the message: INFO IBM-MAIN

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

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

Re: How to output afp datastream (was How to output arp datastream)

[Lizette Koehler]

Where is it coming from? Batch job, server, etc...
Where do you think you can trap it from? At JES, at a printer, etc...

What problem are you trying to solve?
What is the other platform?  *IX, Windows, etc...
What will you do with it on the other platform?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tommy Tsui
> Sent: Friday, September 04, 2015 3:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How to output arp datastream
>
> Hi all,
> Is there any way I can output the afp data stream to a qsam file format？and
> transmit the dataset to other platform!
>

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

Re: IPCS Magicians (was: Smaller Private Area in DR)

[John McKown]

On Fri, Sep 4, 2015 at 9:10 AM, David Griffiths1 <
david_griffit...@uk.ibm.com> wrote:

> Which is why you have a need for IPCS Magicians! Much more intuitive to
> just click a link in a web browser, use the forward and backward buttons,
> open in a new tab, save a bookmark, share the URL with a colleague etc.
> Plus when you're displaying register contents or stack traces, the
> addresses are displayed as links. Quickly navigate round a dump using an
> iPad even.
>
> But I can't talk really - I'm practically the only person left here who
> still edits using vi :)
>

​Evil. You need to convert to emacs immediately. Lest the wrath of Stallman
fall upon thee!

I read of a professional author who uses UNIX "ed" to write all of his
first drafts. No editing, just pure type it fast, fix it later.​



>
> Cheers,
>
> Dave Griffiths
>

-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: IPCS Magicians (was: Smaller Private Area in DR)

[David Griffiths1]

Which is why you have a need for IPCS Magicians! Much more intuitive to 
just click a link in a web browser, use the forward and backward buttons, 
open in a new tab, save a bookmark, share the URL with a colleague etc. 
Plus when you're displaying register contents or stack traces, the 
addresses are displayed as links. Quickly navigate round a dump using an 
iPad even.

But I can't talk really - I'm practically the only person left here who 
still edits using vi :)

Cheers,

Dave Griffiths
IBM Operational Decision Manager
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
Tel: +44 1962 816478 Mobile: 07590 195531
dgr...@uk.ibm.com
 



From:   "Shmuel Metz (Seymour J.)" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   03/09/2015 23:10
Subject:Re: IPCS Magicians (was: Smaller Private Area in DR)
Sent by:IBM Mainframe Discussion List 



In
,
on 09/03/2015
   at 01:36 PM, David Griffiths1  said:

>where you could 
>just click on an address and it would take you there.

You don't need an RYO for that; IPCS has had it for lo these many
years. I'd considser IPCS macros a better use of my time than
reinventing the wheel.
 
-- 
 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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

AW: Re: How to output afp datastream (was How to output arp datastream)

[Peter Hunkeler]

> Is there any way I can output the afp data stream to a qsam file format？and 
> transmit the dataset to other platform! 


Not sure what your problem is, and what you consider a "QSAM file format". An 
AFP datastream, when created on z/OS is nothing more than a sequence of 
variable length records. Rendering software, such as ISIS Papyrus, write the 
records using plain normal z/OS, i.e. QSAM. 


When is comes to send the data to some other platform, just use FTP in *binary* 
mode. When you receive AFP datastreams generated on non-z/OS platforms, you 
must "reblock" the data. This "AFP" speak and a bit misleading. What it does is 
to split the byte stream received into variable length records.


I may be of more help, if you can be more specific about what your problem is.


--
Peter Hunkeler


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

Re: Submit job without messages

[Bob Rutledge]

I believe RDINUM left us at the same time that internal reader processing left 
the JES2 address space and moved to the address space of the requester.


Bob

On 8/29/2015 7:48 PM, J O Skip Robinson wrote:

Indeed this is not an unlimited resource, but it's controllable. The limit is 
specified in JES2 parmlib INTRDR RDINUM=. I've never seen TSO SUBMIT cause an 
internal reader shortage, but we have had problems in the past with CICS 
applications, which would allocate internal readers in order to submit jobs. 
This occurred in so many regions that we would hit the defined limit. Solution: 
increase the limit.

I'm pretty sure that SUBMIT allocates and releases an internal reader for each 
execution. If a lot of tasks--TSO users, batch jobs, regions, whatever--are 
bogarting internal readers, then either increase the limit or have a chat with 
the hogsters.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Gould
Sent: Saturday, August 29, 2015 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Submit job without messages

On Aug 29, 2015, at 1:12 AM, Tim Hare wrote:


Did not see this caveat, and I  had some big troubles from this, so I
have to mention this:

IF you allocate an INTRDR under TSO, you need to find a way to limit
how many concurrent users use it.  Unless things have changed since I
retired, internal readers are _not_ an unlimited resource, there are
only so many defined in the system.  If you have a lot of concurrent
users of your submit process and they use up _all_ of the internal
readers, then regular SUBMIT commands can start failing .


Try using free+close on the allocate.

Ed

--
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: IPCS Magicians (was: Smaller Private Area in DR)

[Paul Gilmartin]

On Fri, 4 Sep 2015 15:10:09 +0100, David Griffiths1 wrote:
>
>But I can't talk really - I'm practically the only person left here who
>still edits using vi :)
> 
Vim, however, has a lot of nice features.  Imagine using ISPF to
edit a file such as this containing Roman, Español, français,
Ελληνική, and кириллический.

-- gil

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

Re: IPCS Magicians (was: Smaller Private Area in DR)

[Shmuel Metz (Seymour J.)]

In <2335242147549170.wa.ibmmaintpg.com...@listserv.ua.edu>, on
09/03/2015
   at 06:37 PM, Shane Ginnane  said:

>Jerry Ng

If he's still giving Systems Diagnostic Approach, it's a must session.
 
-- 
 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: How to output afp datastream (was How to output arp datastream)

[Ed Finnell]

To output to DSN just specify it on SYSOUT DD. It will be VB with large  
LRECL BLKSIZE. Then transfer
as binary. XMITIP at _www.ldsoftware.com_ (http://www.ldsoftware.com)  is 
useful for these type  endeavors. 'bout the only problem is
DOS/VSE where you have to reblock to get card images. AFPREBLOCK on IBM  
printers page is just the ticket.. 
 
 
In a message dated 9/4/2015 8:22:13 A.M. Central Daylight Time,  
stars...@mindspring.com writes:

What  problem are you trying to solve?
What is the other platform?  *IX,  Windows, etc...
What will you do with it on the other  platform?


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

Re: IPCS Magicians (was: Smaller Private Area in DR)

[Tom Marchant]

On Thu, 3 Sep 2015 16:13:24 -0400, Shmuel Metz wrote:

>In
>,
>on 09/03/2015
>   at 01:36 PM, David Griffiths1  said:
>
>>where you could
>>just click on an address and it would take you there.
>
>You don't need an RYO for that; IPCS has had it for lo these many
>years. I'd considser IPCS macros a better use of my time than
>reinventing the wheel.

Shmuel,
How would you do that?

-- 
Tom Marchant

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

Re: Submit job without messages

[Paul Gilmartin]

On Fri, 4 Sep 2015 15:43:20 +, J O Skip Robinson wrote:

>Wow. I was bowled over by the 'left us' comment. We still specify it even in 
>z/OS 2.1, but it seems indeed to have disappeared from the doc. Was that in 
>1.7 with the JES2 redesign? If there is no longer a defined limit, why would 
>anyone still have a system-wide problem?
>
Apparently:

ftp://public.dhe.ibm.com/s390%2Fbrazil%2Fdownloads%2Finfo%2Fitso_2005/zOS_V1R7_Paul_Rogers/jes2.pdf
JES2 Enhancements Version 1 Release 7 SDSF for V1R7 JES3 V1R7
International Technical Support Organization
© Copyright IBM Corp. 2005. All rights reserved.

Internal Readers
Support for RDINUM= on the INTRDR statement has been discontinued
Internal readers are allocated as they are needed and there is no limit

I guess they retained the syntax for compatibility.  "No limit" is never true;
all resources have some limit.

-- gil

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

Re: Submit job without messages

[J O Skip Robinson]

Wow. I was bowled over by the 'left us' comment. We still specify it even in 
z/OS 2.1, but it seems indeed to have disappeared from the doc. Was that in 1.7 
with the JES2 redesign? If there is no longer a defined limit, why would anyone 
still have a system-wide problem?

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Rutledge
Sent: Friday, September 04, 2015 7:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Submit job without messages

I believe RDINUM left us at the same time that internal reader processing left 
the JES2 address space and moved to the address space of the requester.

Bob

On 8/29/2015 7:48 PM, J O Skip Robinson wrote:
> Indeed this is not an unlimited resource, but it's controllable. The limit is 
> specified in JES2 parmlib INTRDR RDINUM=. I've never seen TSO SUBMIT cause an 
> internal reader shortage, but we have had problems in the past with CICS 
> applications, which would allocate internal readers in order to submit jobs. 
> This occurred in so many regions that we would hit the defined limit. 
> Solution: increase the limit.
>
> I'm pretty sure that SUBMIT allocates and releases an internal reader for 
> each execution. If a lot of tasks--TSO users, batch jobs, regions, 
> whatever--are bogarting internal readers, then either increase the limit or 
> have a chat with the hogsters.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Ed Gould
> Sent: Saturday, August 29, 2015 8:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Submit job without messages
>
> On Aug 29, 2015, at 1:12 AM, Tim Hare wrote:
>
>> Did not see this caveat, and I  had some big troubles from this, so I 
>> have to mention this:
>>
>> IF you allocate an INTRDR under TSO, you need to find a way to limit 
>> how many concurrent users use it.  Unless things have changed since I 
>> retired, internal readers are _not_ an unlimited resource, there are 
>> only so many defined in the system.  If you have a lot of concurrent 
>> users of your submit process and they use up _all_ of the internal 
>> readers, then regular SUBMIT commands can start failing .
>
> Try using free+close on the allocate.
>
> Ed

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

Re: IPCS Magicians (was: Smaller Private Area in DR)

[David Griffiths1]

IBM Mainframe Discussion List  wrote on 
04/09/2015 15:50:48:

> From: John McKown 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 04/09/2015 15:50
> Subject: Re: IPCS Magicians (was: Smaller Private Area in DR)
> Sent by: IBM Mainframe Discussion List 
> 
> On Fri, Sep 4, 2015 at 9:10 AM, David Griffiths1 <
> david_griffit...@uk.ibm.com> wrote:
> 
> > Which is why you have a need for IPCS Magicians! Much more intuitive 
to
> > just click a link in a web browser, use the forward and backward 
buttons,
> > open in a new tab, save a bookmark, share the URL with a colleague 
etc.
> > Plus when you're displaying register contents or stack traces, the
> > addresses are displayed as links. Quickly navigate round a dump using 
an
> > iPad even.
> >
> > But I can't talk really - I'm practically the only person left here 
who
> > still edits using vi :)
> >
> 
> ​Evil. You need to convert to emacs immediately. Lest the wrath of 
Stallman
> fall upon thee!
> 
> I read of a professional author who uses UNIX "ed" to write all of his
> first drafts. No editing, just pure type it fast, fix it later.​

That's interesting, I was chatting to someone the other day who had been 
on a creative writing course and she was recommended to use pen and paper 
to help with the thought flow process - when you use a word processor 
you're forever getting distracted by the need to edit what you've just 
written. I shall recommend ed to her!

I thought vi/vim had won the editor wars? Haven't come across anyone using 
emacs for years. You only need to learn vi once and then it's the only 
editor you ever need :)

Cheers,

Dave Griffiths
IBM Operational Decision Manager
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
Tel: +44 1962 816478 Mobile: 07590 195531
dgr...@uk.ibm.com
 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: cobol sequential write problem

[Sri h Kolusu]

LE runtime parm CBLQDA is the answer. If you have CBLQDA(ON), the output 
file is dynamically allocated. You can check the run options like this

//STEP0100 EXEC PGM=COBPGM,PARM='/RPTOPTS(ON),MSGFILE(CEEDOPT)' 
//CEEDOPT  DD SYSOUT=* 

Thanks,
Kolusu

IBM Mainframe Discussion List  wrote on 
09/04/2015 11:42:35 AM:

> From: Rick Stetser <001012027c5e-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 09/04/2015 11:42 AM
> Subject: Re: cobol sequential write problem
> Sent by: IBM Mainframe Discussion List 
> 
> Now that the problem has been fixed it brings up another question 
> however.   If the external name didn't match the DD statement in the
> jobs JCL why wouldn't I get an open error? 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 



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

Re: cobol sequential write problem

[Vince Coen]

Noticed two thing but not sure how important:

1.  You are opening two file but only one is present in the program but 
should have produced an error!.
2.  Moving spaces to 01 record and depending on your settings JCL wise 
it "might" be treated as blank / non-record and not write out.


Try it with say ALL 'A' or '1' and see what happens.

Vince


On 04/09/15 19:06, Rick Stetser wrote:

I haven't found a COBOL listserv so I'm posting this here.
I have Enterprise COBOL for z/OS 4.2.0.  I wrote a simple program to open a 
sequential output file, write a record to it, and then close the file.  The 
program compiles cleanly and when I run it I allocate the output dataset in the 
step the program runs in.  When the job completes the file is present but there 
aren't any records in it.

Here's my code:
SELECT DPGM-FILE  ASSIGN TO DMGPFILE
  FILE STATUS IS DPGM-STATUS.


FD  DPGM-FILE
 BLOCK CONTAINS 0
 RECORDING MODE F
 LABEL RECORDS STANDARD.
01  DPGM-RECORDPIC X(80).

OPEN OUTPUT DPGM-FILE, EPGM-FILE.
IF DPGM-STATUS EQUAL '00'
NEXT SENTENCE
ELSE
DISPLAY 'DPGM-STATUS=' DPGM-STATUS
STOP RUN
END-IF.
MOVE SPACES TO DPGM-RECORD.
WRITE DPGM-RECORD.
  IF DPGM-STATUS EQUAL '00'
 NEXT SENTENCE
  ELSE
 DISPLAY 'DPGM-STATUS=' DPGM-STATUS
 STOP RUN
  END-IF.
  CLOSE DPGM-FILE.
GOBACK.

It's so simple I'm sure I'm missing something but I can't figure out what.  Any 
suggestions?

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




--
- IMPORTANT –

This email and the information in it may be confidential, legally privileged
and/or protected by law.
It is intended solely for the use of the person to whom it is addressed. If you
are not the intended recipient, please notify the sender immediately and do not
disclose the contents to any other person, use it for any purpose, or store or
copy the information in any medium.
Please also delete all copies of this email & any attachments from your system.

If this is an encrypted email it is your responsibility to maintain the
1024 byte key system even for one-use keys. Once mail has been sent the sending
key is not kept and therefore a replacement mail cannot be resent.

We cannot guarantee the security or confidentiality of non encrypted email
communications. We do not accept any liability for losses or damages that you
may suffer as a result of your receipt of this email including but not limited
to computer service or system failure, access delays or interruption, data
non-delivery or mis-delivery, computer viruses or other harmful components.

Copyright in this email and any attachments belongs to Applewood Computers.
Should you communicate with anyone at Applewood Computers by email, you consent
to us monitoring and reading any such correspondence.

Nothing in this email shall be taken or read as suggesting, proposing or
relating to any agreement concerted practice or other practice that could
infringe UK or EC competition legislation (unless it is against Security
requirements).

This Email and its attachments (if any) are scanned for virii using Clamd and
ClamAV 0.98.8 or later (Linux x64).

Dykegrove Limited T/A Applewood Computers is a company registered in England
(no. 01681349) whose registered office is at Applewood House, Epping Road,
Roydon, Essex, CM19 5DA

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

cobol sequential write problem

[Rick Stetser]

I haven't found a COBOL listserv so I'm posting this here.  
I have Enterprise COBOL for z/OS 4.2.0.  I wrote a simple program to open a 
sequential output file, write a record to it, and then close the file.  The 
program compiles cleanly and when I run it I allocate the output dataset in the 
step the program runs in.  When the job completes the file is present but there 
aren't any records in it.  

Here's my code:
SELECT DPGM-FILE  ASSIGN TO DMGPFILE  
 FILE STATUS IS DPGM-STATUS.  


FD  DPGM-FILE   
BLOCK CONTAINS 0
RECORDING MODE F
LABEL RECORDS STANDARD. 
01  DPGM-RECORDPIC X(80).   

OPEN OUTPUT DPGM-FILE, EPGM-FILE.   
IF DPGM-STATUS EQUAL '00'   
   NEXT SENTENCE
ELSE
   DISPLAY 'DPGM-STATUS=' DPGM-STATUS   
   STOP RUN 
END-IF. 
MOVE SPACES TO DPGM-RECORD.
WRITE DPGM-RECORD.  
 IF DPGM-STATUS EQUAL '00'  
NEXT SENTENCE   
 ELSE   
DISPLAY 'DPGM-STATUS=' DPGM-STATUS  
STOP RUN
 END-IF.
 CLOSE DPGM-FILE.
GOBACK.

It's so simple I'm sure I'm missing something but I can't figure out what.  Any 
suggestions?

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

Re: cobol sequential write problem

[Bill Ashton]

I don't know if this was intentional, but your SELECT statement uses
DDname DMGPFILE,
not DPGMFILE as I would expect from all the other DPGM references.

Billy

On Fri, Sep 4, 2015 at 2:06 PM, Rick Stetser <
001012027c5e-dmarc-requ...@listserv.ua.edu> wrote:

> I haven't found a COBOL listserv so I'm posting this here.
> I have Enterprise COBOL for z/OS 4.2.0.  I wrote a simple program to open
> a sequential output file, write a record to it, and then close the file.
> The program compiles cleanly and when I run it I allocate the output
> dataset in the step the program runs in.  When the job completes the file
> is present but there aren't any records in it.
>
> Here's my code:
> SELECT DPGM-FILE  ASSIGN TO DMGPFILE
>  FILE STATUS IS DPGM-STATUS.
>
>
> FD  DPGM-FILE
> BLOCK CONTAINS 0
> RECORDING MODE F
> LABEL RECORDS STANDARD.
> 01  DPGM-RECORDPIC X(80).
>
> OPEN OUTPUT DPGM-FILE, EPGM-FILE.
> IF DPGM-STATUS EQUAL '00'
>NEXT SENTENCE
> ELSE
>DISPLAY 'DPGM-STATUS=' DPGM-STATUS
>STOP RUN
> END-IF.
> MOVE SPACES TO DPGM-RECORD.
> WRITE DPGM-RECORD.
>  IF DPGM-STATUS EQUAL '00'
> NEXT SENTENCE
>  ELSE
> DISPLAY 'DPGM-STATUS=' DPGM-STATUS
> STOP RUN
>  END-IF.
>  CLOSE DPGM-FILE.
> GOBACK.
>
> It's so simple I'm sure I'm missing something but I can't figure out
> what.  Any suggestions?
>
> --
> 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: cobol sequential write problem

[John McKown]

OK, just for fun I also did the following:

1) copy the object file from UNIX to LI.OBJ(TEST2)

In TSO, ran the program by doing (ISPF option 6)

alloc ddn(dmgpfile) dsn('fb80.junk) new catalog lrecl(80) recfm(f) space(1)
tracks
loadgo li.obj(test2) lib('cee.sceelked')

output:

IEW2278I B352 INVOCATION PARAMETERS - CALL,NOMAP,NOPRINT,RES,TERM
IEW2010I 0F06 LOADED PROGRAM RETURN CODE =  0.
IEW2008I 0F03 PROCESSING COMPLETED.  RETURN CODE =  0.
***

And there was a single blank link in FB80.JUNK



On Fri, Sep 4, 2015 at 1:58 PM, John McKown 
wrote:

> FWIW, on z/OS 1.12, using COBOL 3.4.1, your program compiles and runs just
> fine.
>
> OK, I do things strangely. What I really did was use "vi" to create your
> program (cut from the email) in a UNIX shell. I then edited it in ISPF to
> put in all the extra junk the compiler wants. I did a "cob2 -o test2
> test2.cbl"command in my UNIX shell to compile the program. Lastly, I set
> the UNIX environment variable DMGPFILE to point to a UNIX file and ran the
> program. Yes, I ran it in UNIX. But I ended up with a file containing 80
> blanks. Just what I expected.
>
> On Fri, Sep 4, 2015 at 1:06 PM, Rick Stetser <
> 001012027c5e-dmarc-requ...@listserv.ua.edu> wrote:
>
>> I haven't found a COBOL listserv so I'm posting this here.
>> I have Enterprise COBOL for z/OS 4.2.0.  I wrote a simple program to open
>> a sequential output file, write a record to it, and then close the file.
>> The program compiles cleanly and when I run it I allocate the output
>> dataset in the step the program runs in.  When the job completes the file
>> is present but there aren't any records in it.
>>
>> Here's my code:
>> SELECT DPGM-FILE  ASSIGN TO DMGPFILE
>>  FILE STATUS IS DPGM-STATUS.
>>
>>
>> FD  DPGM-FILE
>> BLOCK CONTAINS 0
>> RECORDING MODE F
>> LABEL RECORDS STANDARD.
>> 01  DPGM-RECORDPIC X(80).
>>
>> OPEN OUTPUT DPGM-FILE, EPGM-FILE.
>> IF DPGM-STATUS EQUAL '00'
>>NEXT SENTENCE
>> ELSE
>>DISPLAY 'DPGM-STATUS=' DPGM-STATUS
>>STOP RUN
>> END-IF.
>> MOVE SPACES TO DPGM-RECORD.
>> WRITE DPGM-RECORD.
>>  IF DPGM-STATUS EQUAL '00'
>> NEXT SENTENCE
>>  ELSE
>> DISPLAY 'DPGM-STATUS=' DPGM-STATUS
>> STOP RUN
>>  END-IF.
>>  CLOSE DPGM-FILE.
>> GOBACK.
>>
>> It's so simple I'm sure I'm missing something but I can't figure out
>> what.  Any suggestions?
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
>
> --
>
> Schrodinger's backup: The condition of any backup is unknown until a
> restore is attempted.
>
> Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
>
> He's about as useful as a wax frying pan.
>
> 10 to the 12th power microphones = 1 Megaphone
>
> Maranatha! <><
> John McKown
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: cobol sequential write problem

[Rick Stetser]

Now that the problem has been fixed it brings up another question however.   If 
the external name didn't match the DD statement in the jobs JCL why wouldn't I 
get an open error?

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

Re: cobol sequential write problem

[Rick Stetser]

AARRRGGHHH!  See I knew it was something simple.  Billy had the answer!  
Thank you very much!

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

Re: Submit job without messages

[Bob Rutledge]

Yes, 1.7, the same one that caused me to redo several JES2 exits.  I think we 
both heard about that at the same Share session.


I can't imagine a system-wide limitation; I'd think address space limitations 
would be either DYNAMNBR or TIOT size.


Bob

On 9/4/2015 11:43 AM, J O Skip Robinson wrote:

Wow. I was bowled over by the 'left us' comment. We still specify it even in 
z/OS 2.1, but it seems indeed to have disappeared from the doc. Was that in 1.7 
with the JES2 redesign? If there is no longer a defined limit, why would anyone 
still have a system-wide problem?

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Rutledge
Sent: Friday, September 04, 2015 7:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Submit job without messages

I believe RDINUM left us at the same time that internal reader processing left 
the JES2 address space and moved to the address space of the requester.

Bob

On 8/29/2015 7:48 PM, J O Skip Robinson wrote:

Indeed this is not an unlimited resource, but it's controllable. The limit is 
specified in JES2 parmlib INTRDR RDINUM=. I've never seen TSO SUBMIT cause an 
internal reader shortage, but we have had problems in the past with CICS 
applications, which would allocate internal readers in order to submit jobs. 
This occurred in so many regions that we would hit the defined limit. Solution: 
increase the limit.

I'm pretty sure that SUBMIT allocates and releases an internal reader for each 
execution. If a lot of tasks--TSO users, batch jobs, regions, whatever--are 
bogarting internal readers, then either increase the limit or have a chat with 
the hogsters.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Ed Gould
Sent: Saturday, August 29, 2015 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Submit job without messages

On Aug 29, 2015, at 1:12 AM, Tim Hare wrote:


Did not see this caveat, and I  had some big troubles from this, so I
have to mention this:

IF you allocate an INTRDR under TSO, you need to find a way to limit
how many concurrent users use it.  Unless things have changed since I
retired, internal readers are _not_ an unlimited resource, there are
only so many defined in the system.  If you have a lot of concurrent
users of your submit process and they use up _all_ of the internal
readers, then regular SUBMIT commands can start failing .


Try using free+close on the allocate.

Ed


--
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: Submit job without messages

[J O Skip Robinson]

The point of my question is that I understood OP to have had a problem that 
affected other users. Which is I why chased the wild goose into INTRDR 
specification. But it seems that this should no longer be a problem.  

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Rutledge
Sent: Friday, September 04, 2015 2:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Submit job without messages

Yes, 1.7, the same one that caused me to redo several JES2 exits.  I think we 
both heard about that at the same Share session.

I can't imagine a system-wide limitation; I'd think address space limitations 
would be either DYNAMNBR or TIOT size.

Bob

On 9/4/2015 11:43 AM, J O Skip Robinson wrote:
> Wow. I was bowled over by the 'left us' comment. We still specify it even in 
> z/OS 2.1, but it seems indeed to have disappeared from the doc. Was that in 
> 1.7 with the JES2 redesign? If there is no longer a defined limit, why would 
> anyone still have a system-wide problem?
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Bob Rutledge
> Sent: Friday, September 04, 2015 7:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Submit job without messages
>
> I believe RDINUM left us at the same time that internal reader processing 
> left the JES2 address space and moved to the address space of the requester.
>
> Bob
>
> On 8/29/2015 7:48 PM, J O Skip Robinson wrote:
>> Indeed this is not an unlimited resource, but it's controllable. The limit 
>> is specified in JES2 parmlib INTRDR RDINUM=. I've never seen TSO SUBMIT 
>> cause an internal reader shortage, but we have had problems in the past with 
>> CICS applications, which would allocate internal readers in order to submit 
>> jobs. This occurred in so many regions that we would hit the defined limit. 
>> Solution: increase the limit.
>>
>> I'm pretty sure that SUBMIT allocates and releases an internal reader for 
>> each execution. If a lot of tasks--TSO users, batch jobs, regions, 
>> whatever--are bogarting internal readers, then either increase the limit or 
>> have a chat with the hogsters.
>>
>> .
>> .
>> .
>> J.O.Skip Robinson
>> Southern California Edison Company
>> Electric Dragon Team Paddler
>> SHARE MVS Program Co-Manager
>> 626-302-7535 Office
>> 323-715-0595 Mobile
>> jo.skip.robin...@sce.com
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Ed Gould
>> Sent: Saturday, August 29, 2015 8:02 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Submit job without messages
>>
>> On Aug 29, 2015, at 1:12 AM, Tim Hare wrote:
>>
>>> Did not see this caveat, and I  had some big troubles from this, so 
>>> I have to mention this:
>>>
>>> IF you allocate an INTRDR under TSO, you need to find a way to limit 
>>> how many concurrent users use it.  Unless things have changed since 
>>> I retired, internal readers are _not_ an unlimited resource, there 
>>> are only so many defined in the system.  If you have a lot of 
>>> concurrent users of your submit process and they use up _all_ of the 
>>> internal readers, then regular SUBMIT commands can start failing .
>>
>> Try using free+close on the allocate.
>>
>> Ed
>
> --
> 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: cobol sequential write problem

[Jim Ladouceur]

Check your CBLQDA setting in LE. If it is set to on, LE will create a temp file 
and delete it at end of step. The current 2.1 default is OFF, but I believe the 
default used to be ON.

Jim LaDouceur | Principal Systems Engineer || office: 508-598-4066 | 
jim.ladouc...@infor.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rick Stetser
Sent: Friday, September 04, 2015 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: cobol sequential write problem

Now that the problem has been fixed it brings up another question however.   If 
the external name didn't match the DD statement in the jobs JCL why wouldn't I 
get an open error?  

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

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

Re: cobol sequential write problem

[John McKown]

FWIW, on z/OS 1.12, using COBOL 3.4.1, your program compiles and runs just
fine.

OK, I do things strangely. What I really did was use "vi" to create your
program (cut from the email) in a UNIX shell. I then edited it in ISPF to
put in all the extra junk the compiler wants. I did a "cob2 -o test2
test2.cbl"command in my UNIX shell to compile the program. Lastly, I set
the UNIX environment variable DMGPFILE to point to a UNIX file and ran the
program. Yes, I ran it in UNIX. But I ended up with a file containing 80
blanks. Just what I expected.

On Fri, Sep 4, 2015 at 1:06 PM, Rick Stetser <
001012027c5e-dmarc-requ...@listserv.ua.edu> wrote:

> I haven't found a COBOL listserv so I'm posting this here.
> I have Enterprise COBOL for z/OS 4.2.0.  I wrote a simple program to open
> a sequential output file, write a record to it, and then close the file.
> The program compiles cleanly and when I run it I allocate the output
> dataset in the step the program runs in.  When the job completes the file
> is present but there aren't any records in it.
>
> Here's my code:
> SELECT DPGM-FILE  ASSIGN TO DMGPFILE
>  FILE STATUS IS DPGM-STATUS.
>
>
> FD  DPGM-FILE
> BLOCK CONTAINS 0
> RECORDING MODE F
> LABEL RECORDS STANDARD.
> 01  DPGM-RECORDPIC X(80).
>
> OPEN OUTPUT DPGM-FILE, EPGM-FILE.
> IF DPGM-STATUS EQUAL '00'
>NEXT SENTENCE
> ELSE
>DISPLAY 'DPGM-STATUS=' DPGM-STATUS
>STOP RUN
> END-IF.
> MOVE SPACES TO DPGM-RECORD.
> WRITE DPGM-RECORD.
>  IF DPGM-STATUS EQUAL '00'
> NEXT SENTENCE
>  ELSE
> DISPLAY 'DPGM-STATUS=' DPGM-STATUS
> STOP RUN
>  END-IF.
>  CLOSE DPGM-FILE.
> GOBACK.
>
> It's so simple I'm sure I'm missing something but I can't figure out
> what.  Any suggestions?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: How to output afp datastream (was How to output arp datastream)

[Ed Finnell]

Rudimentary JCL. Not very secure.
 

Examples  of the OUTPUT parameter

z/OS MVS JCL  Reference
SA23-1385-00 


 
Example 2
//J6 JOB,'SUE THACKER'
 //OUTA   OUTPUT DEST=HQ
 //STEP1  EXEC   PGM=RDR
 //OUTB   OUTPUT CONTROL=DOUBLE
 //DS1DD SYSOUT=A,OUTPUT=(*.OUTA,*.OUTB)
 //STEP2  EXEC   PGM=WRT
 //OUTC   OUTPUT DEST=ID2742
 //DS2DD SYSOUT=A,OUTPUT=(*.OUTC,*.STEP1.OUTB)

The OUTPUT parameter on DS1 references:  
*   The job-level OUTPUT JCL statement OUTA to send the sysout  data 
set to HQ. 
*   The step-level OUTPUT JCL statement OUTB to print the  sysout data 
set double-spaced on the local 3800 Printing Subsystem used  for output 
class A.



 
 
In a message dated 9/4/2015 6:12:36 P.M. Central Daylight Time,  
tommyt...@gmail.com writes:

Actually, we want outsource the printing jobs to other vendor and  they
require only arp format that why we want keep a AFP copy from our  batch job


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

Re: How to output afp datastream (was How to output arp datastream)

[Lizette Koehler]

Could you setup an NJE connection to the vendor and just directly transmit the 
output to their printing system?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tommy Tsui
> Sent: Friday, September 04, 2015 4:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How to output afp datastream (was How to output arp datastream)
> 
> Actually, we want outsource the printing jobs to other vendor and they 
> require only
> arp format that why we want keep a AFP copy from our batch job
> 
> 
> Lizette Koehler  於 2015年9月4日星期五 寫道：
> 
> > Where is it coming from? Batch job, server, etc...
> > Where do you think you can trap it from? At JES, at a printer, etc...
> >
> > What problem are you trying to solve?
> > What is the other platform?  *IX, Windows, etc...
> > What will you do with it on the other platform?
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> > ] On
> > > Behalf Of Tommy Tsui
> > > Sent: Friday, September 04, 2015 3:57 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU 
> > > Subject: How to output arp datastream
> > >
> > > Hi all,
> > > Is there any way I can output the afp data stream to a qsam file
> > format？and
> > > transmit the dataset to other platform!

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

Re: Submit job without messages

[Paul Gilmartin]

On Fri, 4 Sep 2015 00:15:07 -0500, Tim Hare wrote:

>Yes - exactly - we had a talk with the hogsters,  but that after-the-fact 
>action really doesn't calm down managers who are freaking out because work 
>can't be submitted while it's happening.  We ended up, I think, ensuring that 
>the maximum number of internal readers was greater than the maximum number of 
>TSO users plus some amount for other use.
> 
Better add the maximum number of processes UNIX users can start.  After
a half century, IBM has finally arrived in the world of multiprocessing.

>The suggestion of FREE=CLOSE is a good one, the person who wrote the CLIST 
>that did this really didn't research anything much, I don't even know where 
>they got the idea to do ALLOC of an INTRDR rather than using SUBMIT.
>
Perhaps they read the manual?  People are often telling each other to do that.

If you want users to restrict themselves to the SUBMIT command, you should
submit RFEs to:

o Relax the fixed-80 restriction imposed by SUBMIT but not by INTRDR.

o SUBMIT from DDNAMES, UNIX files, and POSIX pipes, all of which are
  supported by INTRDR but not by SUBMIT.

-- gil

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