Post #132,257
12/24/03 8:29:01 PM
|
MF Language choices
I'm full time MIS now. This means I deal with our internal
systems, accounting, inventory, project tracking, etc.
Most of the data I need to get to is on the mainframe,
in VSAM files, with multiple record types in a single
file, with variable record lengths, and MF specific
low level numeric encoding.
AKA, I'm screwed.
I've been at this company for about 8 years and I've
managed to learn as little as possible about that
environment. I no longer have that luxury.
So, I'll be learning the following:
A decent understanding of the initiator system,
file/tape IO, etc. IE: the environment as presented
by SDSF.
JCL
Wylbur (a HORRIBLE editor)
A bit of TSO.
A bit of CICS (application user perspective).
and ...
A language.
The language is the open issue.
The most commonly used languages on our MF are
COBOL and QuickJob, with a bit of assembler thrown
in.
QuickJob is kinda like the MF version of AWK. It takes
care of a lot of the record housekeeping, but the flow
control SUCKS. No loops. The "IF" statement do not have
an "END" or an "ELSE". You always have to pre-test the
undesired portion and "GOTO" past the undesired code.
The end of the "IF" is usually a "GOTO". Coding in it
is like simultaneously skipping multiple rocks on a pond.
Not attractive.
I'd prefer to stay away from COBOL. More personal preference
than anything else. I dislike it while realizing it has
redeeming values such as wonderful structured record handling.
I need to access these files to pull / reformat the
data. I will not be modifying any current systems,
so I am not restricted by what is already written, but
if I use anything other than COBOL or QuickJob I'm on
my own if I hit a snag.
My other alternatives are PL/I and REXX. At least I
think so. I haven't done enough research on REXX to
determine if the will handle the data I need. Most of
what I will be doing is reformatting then getting it off
the machine.
I've read about 100 pages of the PL/I manual and I am
impressed. This seems seriously well engineered. Feels
like a primitive BASIC visually, yet thought out. Has
the lovely MF records, multi-level structures, etc.
It also has dynamic memory, pointers, and the capability
to create things like linked lists. So the BASIC moves
into 'C' territory.
The fact it has a named argument when "LEAVE"ing a loop blew
me away. This is one of my favorite bits of Perl syntactic
sugar.
It will handle the variable length VSAM data without a problem
according to what I've read so far.
Am I done, or do I also review REXX?
Any suggestions / observations?
|
Post #132,261
12/24/03 8:54:48 PM
|
Re: MF Language choices
I'd do it in REXX, because there is a PC environment for it.
PL/1 was most likely the inspiration for C, as you noticed. But it is way, way archaic (mid 60s, right after - gasp - Algol 60). REXX is current and has OOPification in some versions. That said, I'd still learn some COBOL. It's not very hard if you're used to Perl and C. I haven't done any COBOL since 1991 and I think I could pick up where I left off.
Also, I'd be amazed if your MF didn't have XEDIT, which is an acceptable record-oriented editor with full screen display.
-drl
|
Post #132,264
12/24/03 9:28:14 PM
|
How would I check for XEDIT?
Not found on the TSO command line.
COBOL? Not a matter of "hard". I just dislike it. Jumping through hoops to accomplish the simplest stuff.
I'll look further into REXX.
|
Post #132,269
12/24/03 10:28:11 PM
|
tso %xedit dataset.name? no idea
XEDIT is more VM/CMS world it looks like, from browsing - try
[link|http://www-306.ibm.com/software/awdtools/ispf/|http://www-306.ibm.c...re/awdtools/ispf/]
I have an idea Mr MIS - hire me to implement Linux S/390 and I'll bring in Imric to do the REXX in the interim :)
-drl
|
Post #132,291
12/25/03 11:45:07 AM
|
No Xedit
But yes to ISPF.
The only reason to use Wylbur is for historical issues.
Old crappy editor that macro based systems have been created
against. I'm leaning towar ISPF right now.
|
Post #132,370
12/26/03 6:33:19 AM
|
ISPF can be very powerful.
Spend some time getting lost in the help pages. There are lots of tricks you can learn. I think you'll like Cursor page mode, for instance.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #133,202
1/2/04 1:59:55 AM
|
no XEDIT
TSO doesn't have XEDIT. That's only in the VM/CMS world. In the Unix and Windows worlds THE, [link|http://hessling-editor.sourceforge.net/|The Hessling Editor], emulates it pretty closely ("closeness" is configurable :-) In TSO, you have ISPF. It works from a similar paradigm, but lacks many of the the more programmable features. For instance, it's possible to use XEDIT as your display manager. ISPF is limited to editing files. :-)
Regarding REXX, I recommend checking out [link|http://www2.hursley.ibm.com/rexx/|IBM's Hursley site]. Lots of pointers to good information there. If you can find a used copy of [link|http://www.amazon.com/exec/obidos/tg/detail/-/0137806515/qid=1073026008/sr=1-1/ref=sr_1_1/002-1715200-4704868?v=glance&s=books|The REXX Language] pick it up. Amazon wants far too much for a new one. [link|http://www.amazon.com/exec/obidos/tg/detail/-/0070236828/qid%3D1073025787/002-1715200-4704868|The REXX Handbook] is well worth getting. It covers REXX in great breadth and detail. There are a couple of chapters dealing with TSO/MVS issues.
ps. the name of one of the authors of chapter 20 should look familiar. ;-)
Have fun,
Carl Forde
|
Post #132,265
12/24/03 9:36:42 PM
|
REXX issues
No mention of VSAM that I can find.
It seems very proud to implement stream IO.
Any ideas?
[link|http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/H1981605/CONTENTS?DT=20030825101721|http://publibz.bould...DT=20030825101721]
|
Post #132,270
12/24/03 10:34:07 PM
|
Re: REXX issues
I'm certain that REXX has an includable library to handle any supported dataset format for that platform. You just have to indentify the library.
Some looking reveals a way to use a tempfile and EXECIO for VSAM access without a library, and that the library needed is RXVSAM:
[link|http://mywebpages.comcast.net/gsf/tools/tsovsam.html|http://mywebpages.co...ools/tsovsam.html]
The advantages of REXX over COBOL, particularly for a Perler, make dealing with these headaches worth it, IMO.
-drl
|
Post #132,271
12/24/03 10:35:59 PM
|
Where to get RXVSAM
[link|http://www.cbttape.org/|http://www.cbttape.org/]
MVS freeware.
-drl
|
Post #132,292
12/25/03 11:55:11 AM
|
Thanks
Good links.
For immediate productivity I'm going to try to use SAS for it.
Then as I need a real language I'll move to either PL/I or
REXX.
|
Post #132,443
12/26/03 10:28:09 PM
|
Isn't there a modern version/update of QuickJob?
There is a Monica Lawinski joke in there somewhere.
________________
oop.ismad.com
|
Post #132,708
12/29/03 11:11:22 PM
|
I know less about mainframes than you do but...
what little that I have heard says that PL/I appeals to people who like Perl and vice versa. Since you seem to like Perl, I would naturally suggest that.
But you seem to have discovered that for yourself. :-)
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #132,771
12/30/03 11:04:31 AM
|
Yup.
I wish it had hashes, regular expressions, etc.
But the record layouts are very nice.
It also has some incredibly stupid stuff. If you name an "end" block you can are allowed not to end any of the inner blocks. How dangerous can you get?
Our original systems programmer, now semi-retired, is available to me as a personal tutor, over email and and has coded some great examples for me to go by.
|
Post #132,776
12/30/03 11:24:00 AM
|
Is it just me?
If you name an "end" block you can are allowed not to end any of the inner blocks. I can't parse that. And I'm not just being comma police here, I don't get what you're saying. ===
Implicitly condoning stupidity since 2001.
|
Post #132,794
12/30/03 1:48:50 PM
|
It is not just you
I'm guessing that an "end block" is a block that does final cleanup whenever you exit. I'm further guessing that it isn't named that in PL/I, and Barry is just calling it that because that is what it would be called in Perl.
But I'm kinda fishing here, and wouldn't be very confident in that guess...
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #132,843
12/30/03 4:12:27 PM
|
It's both of you
Blocks are like code between {} in Perl. Given the following code: \nBLOCK_A:\n BEGIN;\n some code\n BLOCK_B:\n BEGIN;\n some code within block b\n END; /* unnamed end block - end the last block defined, ie: B\n BLOCK_C:\n BEGIN;\n some code within block c\n END; /* unnamed end block - end the last block defined, ie: C\n Some more code\n END BLOCK_A; /* Named end block */\n See how the ends balance the begins? Now look at this: \n\nBLOCK_A:\n BEGIN;\n some code\n BLOCK_B:\n BEGIN;\n some code within block b\n\n BLOCK_C:\n BEGIN;\n some code within block c\n Some more code\n END BLOCK_A; /* Named end block */ \n When an END has a name, the compiler KNOWS which block you are ending. So it doesn't bother trying to balance opening and closing blocks. This code is perfectly legal. The BLOCKS can be part of inner procedures, flow control, part of "IF"s, etc. I'm leaving that out of the example to show the minimum amount of code. Feels dangerous to me.
|
Post #132,847
12/30/03 4:24:01 PM
|
Not what threw me
... you can are allowed not to ... After seeing your clarification, I assume you meant either "can" or "are allowed", but accidentally typed both things you were thinking. Either way, the named end block does look useful. ===
Implicitly condoning stupidity since 2001.
|
Post #132,852
12/30/03 4:42:13 PM
|
How does it know where the blocks end?
Does it use indentation? Does it nest them? (So that BLOCK_C would be in BLOCK_B.) Does it assume that they don't nest? (So BLOCK_C is not in BLOCK_B but "Some more code" accidentally is in BLOCK_C.) Does it depend on cues that depend on the kind of block? (So an IF might naturally terminate at an unexpected ELSE while a simple block remains open...)
It seems like a potentially confusing feature unless the rules are clear. If they are simple (eg it just assumes that when you close a named block then you close all other open blocks there) then it seems like a minor piece of syntactic sugar.
Anyways my limited understanding was that PL/I had exactly this kind of DWIMery built-in, which is why people who disliked Perl tended to likewise dislike PL/I.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #132,854
12/30/03 5:01:35 PM
|
It doesn't
Space does not matter, I just did that to show you.
Only on the final END does it matter.
This sugar is meant for when there are multiple ends,
one after the other, with no code in between being executed.
And like I said, there are many things I like about it.
But this threw me as a major danger.
|
Post #132,857
12/30/03 5:13:54 PM
|
There must be SOME rule
Obviously when it parses that code it inserts in the needed ENDs.
My question is where and why it decides to insert them.
If you don't (or can't) know that reliably, then this definitely is very dangerous since you will never be sure what that snippet will do.
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #132,870
12/30/03 6:23:38 PM
|
Yup
At the final named "END"
|
Post #132,874
12/30/03 6:38:27 PM
|
So it nests blocks
In your example, BLOCK_C is inside of BLOCK_B, and "some more code" is also in BLOCK_C (and hence in BLOCK_B).
Seems sane enough. I just wouldn't name any ENDs. :-)
(Logic that is nested deeply enough that removing the END statements seems like a big win has obvious problems - namely that it is nested too deeply for my sanity.)
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #132,886
12/30/03 8:27:04 PM
|
Breaks a coding practice of mine
I ALWAYS comment the ending brace of blocks.
So it would be natural for me to name the END statement.
Which means I am open to breakage if I ever miss a name.
|
Post #132,908
12/30/03 11:16:23 PM
|
Re: How does it know where the blocks end?
If the END is followed by a <statement-label> (before the semicolon), it closes that block and any unclosed interior blocks. If the END is not followed be a <statement-label>, it simply closes the preceding unclosed block. If a statement-label follows END, the END statement closes the unclosed group or block headed by the nearest preceding DO, SELECT, BEGIN, or PROCEDURE statement having that statement-label. It also closes any unclosed groups or blocks physically within that group or block; this is known as multiple closure.
If a statement-label does not follow END, the END statement closes the one group or block headed by the nearest preceding DO, SELECT, BEGIN, or PROCEDURE statement for which there is no other corresponding END statement. [link|http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ibm3l101/7.17?DT=19950506201638|IBM Link]. Alex
In every country and every age, the priest had been hostile to Liberty. -- Thomas Jefferson (1743-1826), US president
|
Post #132,841
12/30/03 4:10:33 PM
|
I took it:
If you name an ending "END" block... You absolutely *must* end inner blocks before the "END" block.
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
[insert witty saying here]
|
Post #132,844
12/30/03 4:13:40 PM
|
I wish
Not only do you not have to name them, you don't have to code them.
|
Post #132,936
12/31/03 7:44:28 AM
|
Feels very old-fashioned.
Not surprising, I guess, given the age of the language :-). I wouldn't be surprised if the parser has some horrible rules to deal with this nicety.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #132,937
12/31/03 8:04:05 AM
|
Hand code baby
No YACC or LEX here.
|
Post #132,938
12/31/03 8:09:05 AM
|
... and I thought of that, too.
Yet I didn't post it. Hmm.
You can get some truly funky language features when you hand-code a compiler. My current favourite is my web-scripting language, [link|http://yceran.org/qomposr.|Qompose]. Due to the way they're declared and scanned for, variables can have almost any character in their names. :-)
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
