|
Hi
apologies for the probably stupid newbie question.? I get an error while trying to execute the attached job, which is a pretty standard (AFAIU) COBOL Hello World job. The problem appears to be an error dealing with SYSOUT.? I am running on an unmodified (except for the new user) TK4-. 19.38.14 JOB 26 IEC130I SYSOUT DD STATEMENT MISSING 19.38.14 JOB 26 +IKF999I UNSUCCESSFUL OPEN FOR SYSOUT Any help is appreciated, as I obviously do not quite understand what is going on. Of course, you all can expect more questions like this in the future :) Thank you All the best Marco -- Marco Antoniotti Somewhere over the rainbow |
¿ªÔÆÌåÓý"If in doubt, give it what it wants" :-)
In this case, it wants a //SYSOUT DD statement. I nothing of COBOL, but how about //SYSOUT DD SYSOUT=* Roops On 19/11/2020 19:12, marcoxa@...
wrote:
Hi |
|
You need to add? ??GO.SYSOUT DD SYSOUT=* regards; Rahim? ??? ??
On Thursday, November 19, 2020, 01:21:32 PM CST, Rupert Reynolds <rupertreynolds@...> wrote:
"If in doubt, give it what it wants" :-)
In this case, it wants a //SYSOUT DD statement. I nothing of COBOL, but how about //SYSOUT DD SYSOUT=* Roops On 19/11/2020 19:12, marcoxa@...
wrote:
Hi apologies for the probably stupid newbie question.? I get an error while trying to execute the attached job, which is a pretty standard (AFAIU) COBOL Hello World job. The problem appears to be an error dealing with SYSOUT.? I am running on an unmodified (except for the new user) TK4-. 19.38.14 JOB 26 IEC130I SYSOUT DD STATEMENT MISSING 19.38.14 JOB 26 +IKF999I UNSUCCESSFUL OPEN FOR SYSOUT Any help is appreciated, as I obviously do not quite understand what is going on. Of course, you all can expect more questions like this in the future :) Thank you All the best Marco -- Marco Antoniotti Somewhere over the rainbow |
|
Marco,
Hopefully to add to what others have advised: If you DISPLAY "TEST". then you need a GO.SYSOUT DD SYSOUT=* If you have 0065 SPECIAL-NAMES. 0066 CONSOLE IS CNSL and DISPLAY "TEST" UPON CNSL. then your current JCL will work, with a //GO.SYSPRINT DD SYSOUT=A Chris -- <cjar1950@...> ---------------------------------------------------------------------------------------------------------------------------------- On Thu, 19 Nov 2020 11:12:48 -0800 marcoxa@... wrote: Hi |
|
Marco,
In TK4-, look in SYS2.JCLLIB, at TESTCOB, and PRIMCOB1 etc Chris. -- <cjar1950@...> ---------------------------------------------------------------------------------------------------------------------------------- On Thu, 19 Nov 2020 11:57:23 -0800 marcoxa@... wrote: Thanks. |
|
Thank you Chris
I did notice that the examples were referencing CONSOLE, but I did not imagine that that would make a difference between SYSOUT and SYSPRINT. Would you have any pointer to manuals that explained this use of the different DDNAMES?? I assume that for Fortran and PL/1 you would have to deal with similar issues. All the best -- Marco Antoniotti Somewhere over the rainbow |
|
Marco,
Our Cobol is lacking in any documentation. I suggest you look at page 62-3 in which is a bit older (for OS360/MFT & MVT), but as far as I recall still stood in later Cobol versions. Our Cobol is a MVT Cobol, which has been ported to MVS. Chris -- <cjar1950@...> ---------------------------------------------------------------------------------------------------------------------------------- On Thu, 19 Nov 2020 14:13:06 -0800 marcoxa@... wrote: Thank you Chris |
|
On 11/19/20 4:13 PM, marcoxa@... wrote:
Thank you ChrisHere is some information that I added to my site several years ago for COBOL that applies to the MVT era COBOL: There is also a pdf that contains some expansion on what I have summarized. It came from a textbook from that era so it matches the compiler. |
|
An interesting thread.
I have only ever used DISPLAY which outputs to the SYSOUT DD card, or DISPLAY UPON CONSOLE which outputs to the operator console. I understand that there is also DISPLAY UPON SYSPUNCH which outputs to the SYSPUNCH DD card. Displaying on SYSPRINT is a new one for me, but I'm certainly not going to contradict the experts in this group. By the way, DISPLAY in PL/1 (F) outputs to the operator console. JJ |
|
On 2020-11-20 9:13 AM, marcoxa@... wrote:
I assume that for Fortran and PL/1 you would have to deal with similar issues.Real FORTRAN types will know the unit number assignments better than I do, but unit 5 was traditionally the card reader and unit 6 was traditionally the line printer.? (Unit numbers for paper tape reader and card punch, anyone?) This means that most OS FORTRAN programs require a DD of FT06F001 to be allocated - to the terminal in TSO is usually good, while to SYSOUT in batch is usually good. For TSO, FT05F001 would also be allocated to the terminal in the usual case. IIRC, SUPRTREK will not run unless FT06F001 is allocated. For PL/I, SYSPRINT is the default print/report DD name, although for "modern" levels other DD names may be used for the underlying Language Environment input (default options etc.) and output (abends. etc.).? Even so, the default "print" output from the application goes to SYSPRINT unless another DD is specifically requested. If a PL/I programmer gets thirsty, does he/she drink a SYSPINT of their favourite beverage? (A reference to PL/I's habit of first 4 plus last 3 characters of an external reference making up the 7-character-linited name used by PL/I internally.? I suppose I'm the only one who thinks that's funny... :(? ) Cheers, Greg |
|
After the question/discussion yesterday regarding COBOL DD Names, I have added links to the IBM COBOL manual and User's Guide and the Linkage Editor User's Guide. I also cobbled together a table summarizing the DD Names for the COBOL compiler, Link Editor, Loader, and user program execution:
Link to the two new paragraphs: |
|
So I had a ittle play with DISPLAY UPON SYSPUNCH, and it's quite interesting (at least for anyone with as brain as picky as mine).
It turns out that what is output is 80-column records, with the program-id in cols 73-80 (and the output message in 1-72). If you output a message longer than 72 bytes then the trailing bytes flow over into the next output record, with padding consisting of blank space characters where necesssary, JJ |
|
in FORTRAN the card punch is unit 7 I wouldn't have a clue about the paper tape reader Tim
On Saturday, 21 November 2020, 3:23:44 am AEDT, Greg Price <procegrog@...> wrote:
On 2020-11-20 9:13 AM, marcoxa@... wrote: > I assume that for Fortran and PL/1 you would have to deal with similar > issues. Real FORTRAN types will know the unit number assignments better than I do, but unit 5 was traditionally the card reader and unit 6 was traditionally the line printer.? (Unit numbers for paper tape reader and card punch, anyone?) This means that most OS FORTRAN programs require a DD of FT06F001 to be allocated - to the terminal in TSO is usually good, while to SYSOUT in batch is usually good. For TSO, FT05F001 would also be allocated to the terminal in the usual case. IIRC, SUPRTREK will not run unless FT06F001 is allocated. For PL/I, SYSPRINT is the default print/report DD name, although for "modern" levels other DD names may be used for the underlying Language Environment input (default options etc.) and output (abends. etc.).? Even so, the default "print" output from the application goes to SYSPRINT unless another DD is specifically requested. If a PL/I programmer gets thirsty, does he/she drink a SYSPINT of their favourite beverage? (A reference to PL/I's habit of first 4 plus last 3 characters of an external reference making up the 7-character-linited name used by PL/I internally.? I suppose I'm the only one who thinks that's funny... :(? ) Cheers, Greg |
|
Hello Jay,
Am 20.11.2020 um 18:50 schrieb Jay Moseley <JayMoseley@...>: After the question/discussion yesterday regarding COBOL DD Names, I have added links to the IBM COBOL manual and User's Guide and the Linkage Editor User's Guide. I also cobbled together a table summarizing the DD Names for the COBOL compiler, Link Editor, Loader, and user program executionThanks a lot! Your site is very helpful, I very much appreciate your work! :wq! PoC |
|
On 2020-11-21 6:57 AM, Tim via groups.io wrote:
in FORTRAN the card punch is unit 7Ah yes - that sounds familiar - thanks Tim! I was thinking it might be 2 if there is such a convention - memories are hazy... I think all of those low numbers initially had a conventional assignment. I think VS FORTRAN has or had a customisable upper unit number limit.? Applications would crash off if they tried to use a unit number higher than was configured.? We just used to make it 99, IIRC. Cheers, Greg |
|
On Saturday, 21 November 2020, 3:14:06 pm AEDT, Greg Price <procegrog@...> wrote:
On 2020-11-21 6:57 AM, Tim via groups.io wrote: >> in FORTRAN the card punch is unit 7 >Ah yes - that sounds familiar - thanks Tim! >> >> I wouldn't have a clue about the paper tape reader >I was thinking it might be 2 if there is such a convention - memories >are hazy... >I think all of those low numbers initially had a conventional assignment. Did the S360 have a paper tape reader? I had never heard of one, but then I was an applications programmer/analyst - never a systems programmer, and I never knew much about mainframe hardware >I think VS FORTRAN has or had a customisable upper unit number limit.? >Applications would crash off if they tried to use a unit number higher >than was configured.? We just used to make it 99, IIRC. Yes VS Fortran did have a customisable upper unit number. I found that out when the systems guys put in a new version of VS Fortran, and one of our programs promptly aborted with an invalid unit number message, or something like that. I just looked at some of my old JCL members (which I copied to a CD before the mainframe was decommissioned where I used to work) and in one of the FORTRAN ones I made a comment that you needed to specify UNTABLE=99 in the VSFORTL macro (not that I really know what that means..). Ever since that occasion, the first thing I did when they put in a new version of VS Fortran was to run a small test program that used unit number 80! (I can't remember why I didn't use 99 - perhaps 80 was the highest unit number we used). >Cheers, >Greg Tim |
Marco Antoniotti