Passing parameters to an MVS Cobol program - M210

[@Stosszahlansatz]

I could not resist looking at how to pass a parameter to a PL/I program. To paraphrase Screen Rant, it is super easy, barely an inconvenience! The parameter is a varying string of length at most 100 which you can map to a structure or, even better, decode with GET STRING DATA, LIST or EDIT. Damn I love PL/I !!

[@educate9946]

It's fascinating to see you watch this. It's so much different to the Linux-style development I do everyday. Keep up the great work!

[@moshixmainframechannel]

Thanks !

[@grappydingus]

If you want a more traditional way to develop on the mainframe check this video out: kzbin.info/www/bejne/fYeQlYp3aqufm8U

[@MacBaerFFM]

As always, very useful and fun to watch. Thank you, Moshix!

[@moshixmainframechannel]

Thank you Sir

[@higiniofuentes2551]

Thank you for this very useful video!

[@lavaq9593]

Thanks Moshix! Linkage works fine; however, it would be nice to make a video on getting the Rob Prins updated DASDs to work. It appears more complicated than simply substituting the DASDs as JES2 won't startup and the shell freezes.

[@moshixmainframechannel]

Did you make make the conf change for the new JES2 dasd as suggested in the instructions on his website ?

[@lavaq9593]

Thanks again! Yeah, I'm getting really old! LOL! I just missed it!

[@Johan-ez5wo]

@@lavaq9593 Euh, it needs a /r 00,y I believe. After that it will ipl ok again.

[@lavaq9593]

Thanks@@Johan-ez5wo Moshix reply about what I missed on the config spool param fixed my oversight.

[@cact25]

You are not really passing the linkage section to the compiler. You are telling the compiler to generate the instructions for a pgm to be able to send/receive data via the linkage section. Jim K

[@furzkram]

I never saw someone working like this, mixing JCL and the program source in the same member. Why don't you keep your jobs and your program sources in separate libraries, so that COBOL sources would have proper automatic line numbering on? They way you do it is really weird, especially when you have an ISPF like editor at hand.

[@moshixmainframechannel]

Because I don’t run production

[@furzkram]

@@moshixmainframechannel neither do I - but I'd do things the same way for my personal use, because it's way more elegant, less prone to errors, and simply makes more sense to me. The same way as I won't drive on the wrong side of the road just because I'm driving my private car and not the company truck. But that's only me ;-)

[@moshixmainframechannel]

You’re right

[@SINC0MENTARI0S]

I find moshix's approach more didactic and self-contained than what you suggest. Since usually (but not always, as this video reflects with PARM.GO) names in JCL and the embedded code must match, switching between members in order to make sense of what's going on would be a hassle.

[@robertlaw8510]

On my TK4- COBOL I don't have to put line numbers on the code. Do you have to do that if you are passing parms?

[@Johan-ez5wo]

You see them i think scrolling right. Auto added.

[@EdouardTavinor]

Strangely it looks like gnucobol doesn't have a method for reading command line parameters :/ in any case the method you use in this video doesn't seem to work.

[@moshixmainframechannel]

Linkage for gnucobol is completely different. That would certainly not work for gnucobol

[@DeanHorak]

To get command line arguments in gnucobol, use the ACCEPT verb. ACCEPT command-line-string FROM COMMAND-LINE. There are quite a few differences between IBM COBOL and ANSI COBOL, which gnuCobol implements.