On Thu, 23 Aug 2018 17:46:43 +0000, Jesse 1 Robinson wrote: >(OK, I know my question sounded dumb, but I was afraid I was grossly >misinterpreting the thread.) > I wondered, too. Your contributions to some recent threads have not shown the sophistication I had come to expect of you.
>If I were gifted with the luxury of building a new MVS environment from >scratch, I would make all REXX and CLIST libraries FB-80. For one thing, >that's how virtually all vendors deliver execs. Running with concatenated VB >libraries means converting delivered FB objects to VB. Not a huge burden but a >task that must be performed periodically to keep up with vendor maintenance. >In truth, that chore often gets overlooked--for years at a time! So what's >with VB? > Ouch! (But things were so simple wnen we could count on all input's coming from an 029.) >Erery 'mature' shop I've ever been in has used VB libraries. The custom--it's >no more than that--goes back decades (think 70s)--to the day when DASD was >extraordinarily slow and expensive. Execs are text files that contain lots of >trailing blanks. A VB data set can be edited to remove trailing blanks and >considerably reduce the space required to store execs and to perform I/O on >them. Long before MVS REXX, CLISTs were heavily used. VB reduced the overhead, >meaning that VB was more economical. > A while back, John Gilmore asserted (implausibly?) that a startling fraction of compiler cycles are spent skipping blanks. So it's not storage, nor even channel bandwidth, but CPU cycles that may now be the concern. I'd expect interpreters to suffer this more than compilers. Aren't there hardware instructions nowadays to skip blanks? (I don't count TRT; it's inefficient.) >That concern seems pretty trivial these days. But in order to convert existing >VB exec libraries to FB, *every single user* in the shop would have to convert >at the same moment because, for the all the whizzbang modernization in MVS, >data set concatenation still requires all FB or all VB in a single DD. There >would be no grace period in the cutover. Just chaos. > It's worse if the coder has used more than 80 colums. I find VB liberating. Never "Oops! I'm at the limit stop; need to figure out how to continue!" And carbon is more expensive than silicon nowadays. I thought there have long been protocols for handling concatenations with unlike attributes. But perhaps that works only for QSAM, not BPAM. >In the case of system REXX, our SYS1.PARMLIB(AXR00) names only one SYSREXX >library, so we could convert that guy to FB with minimal impact. But really, >why bother? In 2018 I still get problem calls with mysterious abends resulting >from invalid concatenation. > CMS does it right. Regardless of RECFM the programmer never sees RDWs. The data go in the programmer-supplied buffer; the length in a separate fullword. For FB80, that word is always loaded with 80. A programmer trusting the data to be FB80 may (imprudently) ignore the length word. Access methods do something similar for UNIX files: they pad records of files allocated FB with blanks unto LRECL. Excessively long records go to SYNAD. This ability ought to be extended to legacy data sets. >A practical suggestion. If your SOP exec libraries are VB, you can get around >some concatenation problems like this: > >ADDRESS ISPEXEC "SELECT CMD(EX 'SYS1.SBLSCLI0(BLSCLIBD)') MODE(FSCR)" > >This statement in a VB library invokes the real IBM-supplied FB IPCS. No >conversion or periodic updates required. Transparent to the user. > Will that user be delighted to make that code change? I'd rather put everything in UNIX directories and let the access method convert on-the-fly. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
