Hello world program in mainframe Cobol - M124

Поділитися
Вставка
  • Опубліковано 16 січ 2025

КОМЕНТАРІ • 86

  • @michaelvasquez5768
    @michaelvasquez5768 4 роки тому +7

    Love your videos! I am also part of the "COBOL BANDWAGON" that just got interested recently because of all the buzz. Finally got my "hello world" running in the MVS Hecules setup after a couple late nights of messing around. Been programming for over a decade and I never learned anything about mainframes. They are a lot of fun! Thank you for your content

  • @immanuelzanyo2264
    @immanuelzanyo2264 4 роки тому +6

    I have started learning COBOL recently. I work with mainframes and I decided to take up this new challenge this year to learn COBOL. You videos are inspiring and love how things are been explained

  • @misterspock1
    @misterspock1 5 років тому +7

    Just a note: Admiral Hopper died in 1992, so it's been a while, but Grandma Cobol was an awesome woman.

    • @moshixmainframechannel
      @moshixmainframechannel  5 років тому +1

      In 1992? That’s too long. Damn

    • @RaymondHng
      @RaymondHng 4 роки тому

      @@moshixmainframechannel Here she is. ua-cam.com/video/1LR6NPpFxw4/v-deo.html

  • @udayprasad7762
    @udayprasad7762 4 роки тому +2

    Simply too good. Moshix I llove cobol............You make it look so simple.

  • @iltux90
    @iltux90 5 років тому +4

    COBOL RULES!

  • @udayprasad7762
    @udayprasad7762 4 роки тому +3

    COBOL can never be dead. In fact those who say so need to come to the real world of computing on mainframe using cobol

    • @kattihatt
      @kattihatt 4 роки тому +1

      Of course its dead. You would never choose this obsolete language when building a new system. Its only for maintaining legacy systems.

    • @moshixmainframechannel
      @moshixmainframechannel  4 роки тому +1

      Saying never can sometimes be treacherous or downright foolish...

    • @kattihatt
      @kattihatt 4 роки тому +1

      @@moshixmainframechannel the foolish thing would be to use this language when building a modern system.

    • @moshixmainframechannel
      @moshixmainframechannel  4 роки тому +1

      On the mainframe it wouldn’t be foolish

    • @kattihatt
      @kattihatt 4 роки тому +1

      @@moshixmainframechannel but why would you choose a mainframe when building a modern system?

  • @ruffyatutube
    @ruffyatutube 5 років тому +4

    I hope you'll do more and more of Cobol!

  • @SubTroppo
    @SubTroppo 3 роки тому +2

    I like COBOL because when I go the "hole in the wall " it gives me cash! Is the university churning out COBOL programmers? I heard a BBC 4 radio programme a few years back which informed that COBOL experts were in great demand because those who still knew "the guts" of the financial system were nearing retirement or the grave. There had been a systems failure during the UK Xmas shopping rush which had halted card transactions. This event had prompted the investigative broadcast. The whole thing turns out to be a big banking rabbit-hole with failures to merge technologies in better than a "quick and dirty" manner.

  • @alfonsoadalberto8472
    @alfonsoadalberto8472 4 роки тому +4

    I remember my first program for a HP Tándem. 16k lines 😁👌 works great 😎

  • @misterspock1
    @misterspock1 5 років тому

    Great as usual, I'm sure I'll come back to this if I take the plunge into playing with COBOL.

  • @seshasharma7989
    @seshasharma7989 5 років тому +1

    Thanks for the video....keep doing such videos ....it helps me a lot as I am new to this language

  • @Kolian1274
    @Kolian1274 4 роки тому +2

    Hi moshix thanks a lot excellent video some of us being away like to go back to Cobol. Programming i like all your video.

  • @flyingzeppo
    @flyingzeppo 5 років тому +1

    Thank you for making it full screen.

  • @stonent
    @stonent 5 років тому +1

    It would be interesting to see if the 31 bit programs compiled on z/OS work unmodified in MVS/XA. Something this small I don't see why not, but maybe something a little more complex that doesn't call anything z/OS specific. Can you still compile in 24 bit mode?

  • @massimo79mmm
    @massimo79mmm 5 років тому +2

    I just signed the petition.

  • @Konslufius
    @Konslufius 3 роки тому +1

    Not gonne lie, I would consider to learn it in order to be more valueable for the job market.

  • @catherined.398
    @catherined.398 5 років тому +1

    Grace Hopper invented the idea of a compiler, from what I remember too, if I remember correctly.
    en.wikipedia.org/wiki/A-0_System

  • @mjshaheed
    @mjshaheed 5 років тому

    Is there a way to add "HI COB" to Hercules?. "HI JCL" works but not "HI COB".

  • @JuanSebastianTL
    @JuanSebastianTL 4 роки тому +1

    I use hércules and download a different version of z/os, you have to use this //STEPLIB DD DSN=IGY410. SIGYCOMP, DISP=SHR

    • @volksusnik6280
      @volksusnik6280 4 роки тому

      Thanks for your help!
      This fixed the error "ENDED IN N1 - JCL ERROR CN (INTERNAL)"

    • @tsdmbbstsdmbbs9440
      @tsdmbbstsdmbbs9440 2 роки тому

      @@volksusnik6280 FIXED SAME ERROR HERE, THANK YOU BOTH !

  • @Texasman-i8i
    @Texasman-i8i 4 роки тому

    Hi Moshix
    As always another excellent video
    Can we have same set up you show in this video on Mainframe computer in MVS 3.8 TK4 environment.

  • @ThePetersterwe
    @ThePetersterwe 4 роки тому +1

    Why UPPER-case? The restriction was gone -85, the COBOL-compiler on your ADCD-system supports much more than the COBOL-85 standard.
    Why not highlighting in the editor? Just enter HI COBOL.
    Why not skip the first six columns? Just enter NUMBER ON COBOL.
    Without those simple changes, it looks more complicated than it ought to be!
    .

    • @moshixmainframechannel
      @moshixmainframechannel  4 роки тому +1

      Sorry for angering you. The highlighting of ISPF is well known. Upper case so it also runs on MVS 3.8. Same for the columns.

  • @jurgbader8647
    @jurgbader8647 5 років тому +1

    Thanks for the Video. Now i know how to run a "batch program". But how can i run a COBOL Dialog Programm (… with the commands display and accept), meaning user input online ? Can you make an example ? Sorry for my English.

    • @moshixmainframechannel
      @moshixmainframechannel  5 років тому

      You need KICKS. See my video on the topic of KICKS

    • @jurgbader8647
      @jurgbader8647 5 років тому

      sorry my error. I thougt with this Video i make a installation from scratch. I worked in the eighties with NCR I-Systems, it's quite different...

  • @haihurry
    @haihurry 5 років тому +1

    Can we have more short videos like this in between your regular videos.. ex Jes2 check point (mas) like you did before.. sysplex structure role. Dump reading .

    • @moshixmainframechannel
      @moshixmainframechannel  5 років тому +1

      Dump reading has been in the channel already for 2 years

    • @haihurry
      @haihurry 5 років тому

      @@moshixmainframechannel thanks I'll refer it

  • @sokham4523
    @sokham4523 5 років тому

    how to go the ISPF screen?

    • @stonent
      @stonent 4 роки тому +1

      From the "READY." prompt, type ISPF and hit enter.
      If you're running TK3 or TK4, it does not have ISPF.

  • @EdouardTavinor
    @EdouardTavinor 2 роки тому +2

    In my current job I'm a helm/kubernetes developer and the language i most use is go, which i really, really like.
    however, i'm starting a new job in a few months and there i'll be writing COBOL on a mainframe :) This is partly because of your channel @moshix!
    i'm just getting in to COBOL. I've started posted my attempts to solve some programming exercises in COBOL on my UA-cam channel.
    What I really like about COBOL is that there isn't the same temptation to be clever as in some modern languages. When i think of languages like Rust or Scala i see languages where good developers can write intricately perfect code, but normal developers can quickly lose their way. Whenever i write in one of those languages I spend a lot of time trying to think of an even cleverer way to solve the problem at hand. Here I find COBOL to be much like go: they are both languages which seem to resist attempts to do something clever. I have the feeling that i'm more productive in go or COBOL than in more complicated languages because i tend to directly solve the problem and then spend time trying to find the best names for the functions or paragraphs that i've written.

    • @robertboyer5926
      @robertboyer5926 2 роки тому +1

      Don't get me wrong. I like Go in many ways but unfortunately you may have to get "clever" because of the automagic GC stuff and the language's idiomatic way of doing things do not yet play very well with the memory management... meaning the idiomatic strait forward way of doing it (which I like and is promoted by the language and community) just do not work at scale.
      I was a fan of Rust for a bit but after head to head smaller projects where Rust is appropriate (similar to C and my particular use of C++) the flaws of Rust's real world use vs philosophy became abundantly clear. To do anything remotely useful you need to bypass many of it's compile time safety mechanisms which then devolve into far far less strait forward C or better yet disciplined use of C++'s more modern feature set that makes pretty much a modern type safe C if one wants. Rust is a mess in use and worse in that it's highly unstable implementation and features. It turns out the only thing that actually is REALLY great is rustup and cargo.
      C and C++ (two different things) both are in dire need of the community standardizing defacto or via the actual standard on package and dependency management which today are far far far to complicated (but very capable)

    • @EdouardTavinor
      @EdouardTavinor 2 роки тому +2

      @@robertboyer5926 do you have an example of the problems you mention with go? If I'm not careful about closing channels my code can leak goroutines, but i haven't found any other memory management issues.
      I think there is a way to write interesting stuff in rust that doesn't require leaving the safe zone that often, but i tend to find it to be difficult to do anything useful. Things like lifetime management to explicitly enforce good coding discipline seems to me to be micromanagement.
      Oh and i totally agree with your comments about dependency management, which i think is valid for almost all language ecosystems i know.
      In fact the only language i regularly use where dependency language doesn't scare me is awk :D

    • @robertboyer5926
      @robertboyer5926 2 роки тому

      @@EdouardTavinor There are plenty of examples and talks explaining scaling GC and techniques for optimization of typical idiomatic go to be "more GC and memory friendly" I don't know if I have much to add to what has developed into it's own discipline at this point.
      A fairly decent example in RL of working code that is highly optimized for scale (IE pretty much what many things devolve into = resume of a fixed pool of allocated resources) is fastHTTP if you want to take a look at core optimization techniques.
      I use that code as an example as it pretty much violates all of the precepts of what I like about Go in the first place. It bypasses the standard library and does NOT use the simplest and most directly stated way of doing things via Go's idiomatic use. You'll find all sorts of dissertations that promote similar more targeted optimizations as common use in systems at scale.
      Having said all of that, I still like Go and it's tenants and promotion by the community to use the standard library and the most strait forward way of expressing what you are doing. I think it is the most practical modern language with high utility when you don't need things such as C for extreme scale or embedded small environments on bare metal.

    • @robertboyer5926
      @robertboyer5926 2 роки тому +1

      @@EdouardTavinor If you've not looked at C++17 and forward you'll find the memory management idioms far more modern and just as "safe" as Rust. Rust seems to try way way way too hard while removing NOTHING in terms of what you have to be aware of and think through and adding additional cognitive overhead while trying to solve the actual problem you are trying to solve.
      I typically use "modern" C for very small systems/memory and "extended" modern C (my definition of CPP17 with a very very useful subset of enhanced C features) for larger memory systems and things that have a comprehensive OS runtime when I am close to the metal and Go for everything else (IE things that I would have used NodeJS or Python (yuk for both) for in the absence of Go). Like web services of varying types etc...

    • @robertboyer5926
      @robertboyer5926 2 роки тому

      @@EdouardTavinor A good example of more idiomatic but reasonably optimized code might be something like litestream (if you are a fan of how wonderful SQLite can be as a substitute for MySQL/Oracle/SQLserver/Postgres etc for way bigger read heavy systems than you may think)

  • @VennThuria
    @VennThuria 4 роки тому +2

    Should COBOL source code files be FB, LRECL=80?

  • @VennThuria
    @VennThuria 5 років тому +1

    The JCL doesn't run on my system. Is the IGYWCLG not a common thing?
    STMT NO. MESSAGE
    2 IEFC612I PROCEDURE IGYWCLG WAS NOT FOUND
    2 IEFC611I OVERRIDDEN STEP NOT FOUND IN PROCEDURE

    • @moshixmainframechannel
      @moshixmainframechannel  5 років тому

      Depends on how they called your compiler procedure. It is usually but doesn't have to be

    • @JuanSebastianTL
      @JuanSebastianTL 4 роки тому

      Use this //STEPLIB DD DSN=IGY410. SIGYCOMP, DISP=SHR

    • @VennThuria
      @VennThuria 4 роки тому +1

      @@JuanSebastianTL Thanks for your help! Unfortuantely I cannot test this because I no longer have access to the system. But I got access to a much better system now where everything works anyways :)