IBM Mainframe Forum

Thank you, Enrico. Then I'll go on to check what exactly my programme writes to the internal reader.

Two things.

First, what are you "protecting" with the ENQ? For all intents and purposes, the internal reader allocation itself protects the submission. You don't really need anything else! We have a tendency to think there is one internal reader, but there are really, in most shops, several internal readers in addition to the dedicated internal readers used for the START command and TSO LOGONs. You don't have to worry about someone else messing up your submission.

Second. The ACB/RPL you use to write to the internal reader should be the same as used to write a VSAM ESDS. Write to an ESDS that as a proof of concept. Well, back in the 1980s (or was in the 1970s?) I didn't bother, though by then I was already much more experienced than you.

To Steve and Enrico,

Thank you for following up and your suggestion. I'm definitely not experienced. I had been a *NIX programmer before got hired by that Mainframe software company 1+ years ago.

I really can't find anything wrong in my test programme.

I don't know how to write ESDS so I modified the OPEN/PUT statements as well as the DCB block and the DD statement so that the test programme writes to a simple PS dataset. Then I opened the PS dataset (looked fine) and 'sub'-ed it. The job worked find!

I even used IEBGENER to directly 'copy' the PS dataset mentioned above to 'SYSOUT=(A,INTRDR)', and the job in the PS was submitted too!

I only failed to submit the job from my stupid test programme! Really frustrating.

THANK YOU GUYS AGAIN for your time and help. I have to wait for my senior colleagues to be back after the Christmas week and see if they could find anything.

Thank you and wish you a merry Christmas!

This is about as simple and bare bones as you can get. Yes, it did work in very limited testing.

To Steve:

Really ?? Cool !!

I must try it after dinner, and will let you know the result. A BIG THANK you in advance!

To Steve:

Thank you very much for your sample programme. It really worked in my environment and it showed me a simple but clear skeleton code for using the internal reader. After I got a better understanding to all these stuff, I reviewed my code and finally managed to sort out the mistake. Now my programme can also submit jobs through internal reader. Very happy.

Thank you again!

In my very first post, I pointed out two rather obvious mistakes:

1. Your RPL did not point to its corresponding ACB.
2. The RPL did not specify an area address.

Really, all I did was correct those problems and surrounded the GET/PUT RPL loop with as simple a shell as I could arrange.

No pun intended, but....

You are scratching your ear with your foot.

I do not see any reason to use ACB/RPL for something so simple, unless You want just to "practice" your HLASM skills, it can be done but not as quickly as You may want to.

If You, on the other hand, want this to work fast, a very quick way to do it, is getting rid of the ACB/RPL, and as Enrico has already pointed out, treat your "internal reader" dataset as a PS file, use an DCB instead, which points to... again.. to your a sequential "internal reader" dataset, just open it up, write n it, and close it. You will have nothing to do with your JCL, it is OK as it is.

The "internal reader" quotes are just to tease a little bit, since you can indeed, write to any other PS dataset with it, just by changing your JCL DDNAME statement accordingly.

I said this in my very first post in this thread. I wonder if gcastillo read it.

steve-myers wrote:... Why are you using this interface? What do you hope to gain? The only potential advantage I know of other than a tiny advantage of using less CPU time is to obtain the job id of the submitted job, which you are not doing.

The topic starter did not pick up on this, but the ACB/RPL code we have been discussing in this thread can be used to create VSAM entry sequenced data sets.