Joined: 14 Oct 2006 Posts: 14 Location: Appleton Wi USA
I have ONE user that is having issues with a REXX program when it issues the command "EXECIO "QUEUED()" DISKW SYSIN (FINIS" to write records that have been queued up. He gets the following message on his screen:
Code:
The input or output file SYSIN is not allocated. It cannot be opened for I/O.
EXECIO error while trying to GET or PUT a record.
I have TRACEd the REXX and can see that he is getting a RC=20 on the EXECIO command. However, other users (myself included) have no issues with this code. I have searched this forum (and others) but have not found anything that has helped me resolve this issue.
Here is a snippet of the actual code causing the issue:
Code:
IF XINQ ¬= '' & TESTDATE ¬= '' THEN DO
QUEUE "$$DD01 COPYBACK IF=(0001,EQ,C'"XINQ"'),"
QUEUE " AND=(51,EQ,C'"TESTDATE"'),"
END
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
Well, writing to a file named SYSIN is pretty darned confusing.
More to the point, however the file needs to be allocated somewhere. That's not happening for your cow-orker; it may well be happening for you in another exec or program, and SYSIN is never freed.
Assume for the sake of argument that you wish the records to be written to HLQ.FOO(BAR). Clone the exec and add
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I agree with Akatsukami. 99% of people looking at your code will think "what the heck is that"?
Are you using SYSIN because some other program is reading SYSIN? Or are you/whoever wrote it trying to avoid having to deal with datasetnames?
Maybe most of your ids get SYSIN allocated by default, and one doesn't, or as Akatsukami, all the other have previously used something which fails to deallocate SYSIN, except the user with the "problem".
Actually, it is the user with the "problem" who is working "correctly", everyone else is working "by accident", ie, not by relying on code in the program.
Use another filename. Allocate it. Write to it. Deallocate it. It'll work for everybody, and not rely on some "state" that most, but not all, users have when the program starts.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
Writing to SYSIN may be unusual, but if what you're writing out is used in the same code by utility that expects SYSIN as its input dataset, it does make sense...
I have a front-end for the ISPF EDIT COMPARE command that dynamically builds the required SYSIN and it would be utterly silly to actually allocate a permanent dataset with a DDNAME SYSOUT, free it and reallocate it with a DDNAME SYSIN...
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I don't know, Prino.
As SYSIN would have emerged from a card-reader originally, I'd get the "output" side would be the card punch, SYSPCH or SYSPNCH (I think the first, can't remember clearly, not going to check). Of course "device independence" means it doesn't matter, does it? Not to the computer, just to us humans. OK, actually SYSIN does get some special processing. In JCL, if you have some "cards" lying around, the system will generate a //SYSIN DD * for you. If, in batch, you happened to be writing to SYSIN as well, you'd get some confusion.
I don't know what TSO would make of it all, but it looks like for TS he is suffering/benefitting from a default assignment somewhere along the way - except for one user, who probably has a different "profile" in that he's a different type of user, or by default does something which frees it.
So, I think writing to SYSIN looks confusing. It is, after all, only a DD isn't it? So no requirement to be the same as anything subsequent?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Maybe it is only Akatsukami and I who find it unusual to write to SYSin.
Would we read, for instance, SORTOUT. Ooops. I see we have an answer there as well.
I suppose this comes down to the difference between TSO and JCL. In JCL, the DDs do not exist beyond the step in which they are used. So, with no "convenience" in JCL of just having some DD lying around which you could pre-use or re-use, we don't do it, we give it a different DD name. We could write to SYSIN as a PS/PDS member in one step and in the next step use SYSIN with the same DSN. Same with the SORTOUT. We just don't, by convention I suppose.
Because it can be done in TSO in itself doesn't mean it should, or shouldn't.
Joined: 14 Oct 2006 Posts: 14 Location: Appleton Wi USA
Thank You all for your suggestions..... I finally determined what the issue was...... Akatsukami was on the right track.
Even though there was code in the CLIST to ALLOCATE and FREE the dataset in the SYSIN DD, it was not happening successfully. This was due to the fact that the user had an issue months ago and a dataset named Userid.SYSIN was left hanging on the system and eventually got migrated off to tape. So now when this CLIST tried to ALLOCATE the dataset, it was unsuccessful. For some reason the TRACE did not show a bad return code on the ALLOCATE but it showed a RC=20 on the EXECIO when trying to write to the SYSIN DD.
Once we recalled and deleted Userid.SYSIN the issues went away.
By the way... this code was written by someone else long ago.... who knows why they decided to name the DD "SYSIN".... But the DD name had no bearing on the issue.
.jpg)
