IBM Mainframe Forum

Hello,

I have a question regarding the DISK=SYSDA statement.

Where exactly is the temporary file stored at time of execution? Is it on disk or just in random access memory?

What I specifically want to know is, if the system reads and writes faster on "sysda" than on "disk".

Regards,

Oliver

Most sites use SYSDA (or SYSALLDA) as a generic name for a disk drive. As such, it is not possible for SYSDA to be read or written faster than reading or writing to a specific volume serial of disk. A file written to SYSDA will be stored on disk, not in memory.

Where did you find the DISK=SYSDA construct? Normal JCL would be UNIT=SYSDA and there's not a DISK= parameter for the DD statement.

Thank you for your reply, that is what I wanted to know.

You are right, the command was UNIT=SYSDA, I'm sorry for that.

Regards

Oliver

Just to be sure you know it, there is VIO (virtual I/O) that can be used if it is defined in your system. This is for small data sets that are not written to disk but stay in a storage area, it is only for temporary data sets.

Hello Morgan,

that would be interesting.
How can I access this VIO, if it is configured?
I thought of a solution like UNIT=VIO if this is possible...

I thought of a solution like UNIT=VIO if this is possible...

Instead of thinking - look. My first thought was to ask 'what does the JCL manual say' so I opened it up, entered a search for VIO and started hitting next there are lots of 'preVIOus'es! I eventually found an answer.

NicC wrote:... so I opened it up, entered a search for VIO and started hitting next there are lots of 'preVIOus'es! I eventually found an answer.

Great that you found an answer... You can feel proud and lucky about it now.

So what he found out, for constructive matters, is that the syntax is really



Just like I assumed.

Thanks.

Kind Regards

Oliver

Well, I already knew the answer - just had to check that YOU could find it easily.

Depending on how your SMS is set up this can be done automatically. Temp data sets are automatically assigned to VIO at our shop unless they are too large for it. This is a shop dependant set up, so you would have to ask your storage management.

VIO is all very well, but these days the cache controller on your disk subsystem will do most of what you want to achieve in VIO automatically. As an example:

About ten years back at a site with real 3390s, I ran a comparative test and discovered that with half track blocking, 60 buffers gave optimal performance for BSAM reads. Because it could slurp whole cylinders at a time into the buffers without moving the heads, it was a lot faster.

Nowadays the data are held differently, smeared across stripes on RAID with a huge cache buffer.

Last week I ran the same test, and discovered that once I'd got up to 10 buffers, adding any more didn't make an appreciable difference, and using 60 actually made it worse.

So I'd be interested to see what kind of data needs the speed of VIO these days, and whether it even makes a difference any more...