View previous topic :: View next topic
|
Author |
Message |
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
The following could be of interest/help :
Batch Modernization on z/OS SG24-7779-01
Chapter 16 : Increasing concurrency by exploiting BatchPipes |
|
Back to top |
|
|
vshchukin
New User
Joined: 13 Mar 2014 Posts: 11 Location: Czech Republic
|
|
|
|
Thank you guys for all the proposed suggestions,
@Dick
I think the solution that could fix all the issues could be an address space creation since address spaces shouldn't affect each other. But I don't sure if there will be any pitfalls on this way.
@Steve
I would love to use a different DD name, but actually I'm working on the application that wasn't exclusively written by me, and for some reason they are using SYSPRINT as primary log DD. They could be understood since SYSPRINT should be considered like "standard output stream", and maybe it would be used as an API for some external apps. As for IEBPTPCH utility, that's a funny story
@Peter
Thanks for the BatchPipes hint, I will research if it could workaround the problem. One important moment in this story is that normally output retrieval should work like "in-memory" communication between programs, avoiding use of any external memory, particularly HDD's. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
I believe you had the solution you wanted to use and have been looking for some way(s) to make this the proper choice . . .
Quote: |
One important moment in this story is that normally output retrieval should work like "in-memory" communication between programs, avoiding use of any external memory, particularly HDD's. |
I do not recall seeing this in the industry . . . Where (which publication(s)) did you find this guidance? |
|
Back to top |
|
|
vshchukin
New User
Joined: 13 Mar 2014 Posts: 11 Location: Czech Republic
|
|
|
|
Dick,
Quote: |
Where (which publication(s)) did you find this guidance? |
I don't think IBM have a publication with DASD versus main storage access speed comparison. Generally, random access is 100k faster when main storage is used instead of DASD. Whether it is a requirement, depends on the application. But I would prefer to avoid using datasets, I believe datasets are for long term data storage. |
|
Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
|
|
|
|
For 50 years (and one day) the IBM 360, and later machines, have used datasets for passing data between programs in a job and between jobs. That is the way they work unlike the younger technologies such as Unix and DOS which pipe data (but that is probably stored in a temporary file that you do not see). |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Yup - keep in mind that in Unix "everything is a file". . .
And on most machines there is not enough memory on the system to accommodate very large files - so they Must be written and re-read. . . |
|
Back to top |
|
|
|