Here is a shoutout to Ravi Cheepa for suggesting I needed to add some VSAM material to the site. I’ll start with this video that contains some basic information about VSAM and its macros: ACB, RPL, EXLST, PUT, GET, MODCB, …
I’ve always thought that looking at code is the best way for programmers to learn, so I’ll follow this up with a series of demo programs that do something interesting and efficiently. I’ll also add some video to explain the programs and why the techniques they use are efficient. More soon …
You might also consider adding VTAM coding as the VSAM macros are derived from VTAM. That is to say that you have more than 75% of the basics, e.g., control block hierarchy to hand.
Wow, VTAM! Not much call for it, but could be very interesting as another topic for another day.
http://ibm.com/docs/en/zos/2.1.0?topic=language-summary-description-vtam-macroinstructions
VSAM is hard enough already for those who’ve never used it. What made VSAM easier for me was to take as many defaults as possible. Then you learn what “comes naturally” to VSAM. It also makes the code much easier to read and understand. When it comes to code (not comments!) my rule if thumb is: If you CAN leave it out, DO leave it out. ๐
I think you’ll find that VSAM preceded VTAM by several years
The control block structure of VTAM hasn’t any relationship to VSAM at all
It is unfortunate that VTAM decided to acquire the use of the ACB and RPL for its own use
If you leave stuff out, you won’t get what you’ve asked for…best watch the video and read the Manuals
Melvyn Maltz
@Melvyn “๐๐ ๐ฒ๐จ๐ฎ ๐ฅ๐๐๐ฏ๐ ๐ฌ๐ญ๐ฎ๐๐ ๐จ๐ฎ๐ญ, ๐ฒ๐จ๐ฎ ๐ฐ๐จ๐ง’๐ญ ๐ ๐๐ญ ๐ฐ๐ก๐๐ญ ๐ฒ๐จ๐ฎ’๐ฏ๐ ๐๐ฌ๐ค๐๐ ๐๐จ๐ซ…”. But if you “leave stuff out” then you haven’t actually “asked for” anything, right? What you get is what the system *gives you* automatically. That’s the key! Knowing what the system *gives you* without having to *ask for it*. There’s a lot of stuff like that, and defaults don’t get to be defaults for no reason. Where they exist, you can be sure the designers already put a lot of thought into what the best values should be. So if you choose to *override* their judgment, not only do you risk getting it wrong, but also discover your very best effort is usually what the system gives you automatically.
A couple of non-VSAM examples (off-topic, I know, but just to illustrate the principle).
Someone I know once added a field to a Print file where AFTER ADVANCING was used with the ADV Compile option. He got called in after hours on a COBOL abend because the LRECL in the JCL didn’t match the expected value. While the system waited, he spent a couple of very frustrating hours trying various Compile options and LRECL values to come up with something that worked, which he finally did. But if he’d just *left out* the LRECL, COBOL would have supplied the correct value automatically! The very best value he could come up with (the one that worked) was the exact same value the system would have given him automatically. In fact, with COBOL, if you specify anything *other than* what COBOL calculates, you’ll get an abend. So, just leave it out.
We also have a bunch of code in which the author (now retired) had a penchant for using explicit lengths with things like COMMAREA, KEYLENGTH, SEND MAP, BIF DEEDIT, etc. But these are things the Translator and Compiler will calculate for you! And again, the very best value you can specify happens to be the exact same value you get if you let the system do it for you. So, I am now removing all these explicit lengths, with the result that they are now “future proof”. If they ever change, instead of having to track them all down and change them all (there are hundreds scattered all over) I can trust the system to make the changes for me. ๐
Aha! I see a pattern forming here. By letting go a bit and trusting the system to supply the correct values, you can save yourself a lot of trouble, have applications that are robust, not fragile, and have code that’s simpler, easier to understand and maintain.
So, let the default be your first choice. And *only* if the default doesn’t give you what you need, *then* try to find something better.
“If the default fits, take it!”
>>>Knowing what the system *gives you* without having to *ask for it*
This is the crux of the matter, some products like COBOL and CICS may have defaults which you can rely on, but it’s important that you “know” what the system gives you…as you said
>>>defaults donโt get to be defaults for no reason
>>>If the default fits, take it!
With products like VSAM and CICS, defaults have no real purpose
It is always better to specify all relevant parms whether defaulted or not, just for clarity
An example…
I want to read a KSDS by generic key…all of these work
RPL…OPTCD=(GEN,ARD,FWD,NWAITX )
RPL…OPTCD=GEN
RPL…OPTCD=(KEY,GEN)
But I know the one I’d like to read in code that wasn’t mine ๐