|
View previous topic :: View next topic
|
| Author |
Message |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
has anybody noticed that the TS has disappeared,
it was clear to me that he/she was supposed to post the failing code..
but for some obscure reason he/she preferred to drop the issue.
if it was for me I would save lots of resources by banning such posters and deleting all their posts
but probably somebody might remark that I am overreacting 
I like the other forum where there is a section titled "Stupid Questions"
but probably over here it would be overcrowded |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Yes, it would likely be such a trivial thing that TS would find it once they got over the idea that it must be something "funny" going on.
However, not a total loss, the thread. As long as someone stuffs in a bit of code somewhere along the way, we're quite happy to comment and improve.
Anuj has suffered on this one - don't use compiler option AWO (my personal command), instad use APPLY WRITE ONLY for each QSAM VB output file.
Yes, I know what IBM says in the performance document :-) |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
and the soc4 was is relation to input file.
why all this discussion of output file? |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
OK, if you have the AWO compile option and if you have at least one VB QSAM output file, then you'll never get the S0C4. Never. Never. Not even at 3am on New Year's Day.
|
Hmmmm? accessing the Record within the FD
before opening or after closing?? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Yep :-)
OK, I'm talking specifically about after EOF, Anuj's example in question.
Compiler option AWO is nuts (if you search, you'll see some discussion from last year). AWO is nuts because it affects input QSAM VB files as well as output. So, instead of the FD addressing the buffer, with the possibility of being outside of your allowed storage at the end of the final buffer, it instead is a "record-area", with the data from the buffer MOVEd to it. Same for the WRITE. So, since it is a record-area, within the Cobol run-time.
Before the file is OPEN and after the file is CLOSED I don't know, not tried. But in Anuj's example it will never get a S0C4.
Without the compile option AWO, the code would behave in the "usual" way and occasionally blow up. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
| But in Anuj's example it will never get a S0C4. |
even though Anuj's example is one (1) Fixed-Byte QSAM INPUT file? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
At the time I mentioned the AWO the file's properties were still unknown.
No, it will not (according to the documentation) affect a QSAM FB, or anything except a QSAM VB.
I do not know whether a program only containing input QSAM VB (rather than containing at least one output QSAM VB) would do the same thing, ie use a record-area rather than addressing the buffer.
Some things to play with :-)
Plus, I am not suggesting that this is at all a "good thing". I'd advise anyone to specifically code APPLY WRITE ONLY for each QSAM VB output file and just have done with it. I think the compiler option AWO is a bad thing to use. It is for the lazy, and it is implemented sloppily. |
|
| Back to top |
|
|
|
|
