SMPE has supported RECFM=VB elements since Old Man Noach cornered the market in Gopher Wood.
While access methods don't support PO concatenation of FB and VB, a bit of REXX coding using, e.g., LIBDEF, can greatly alleviate the problem. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Jesse 1 Robinson <jesse1.robin...@sce.com> Sent: Monday, May 13, 2019 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Concatenating VB and FB ? I've worked for several large, mature shops. Large means many users who need TLC; some will be quite influential within the organization. Mature means lots of processes deeply embedded in the infrastructure; some will be considered Tier 1 production. The problem with FB vs. VB--mostly in script management involving CLIST or REXX--is as old as MVS. For most of affected shops, the conundrum is the reverse of OP's. Vendor distribution is usually FB--SMPE pretty much requires that--while older shops chose *many decades* ago to standardize on VB in order to economize on SLED space and I/O overhead. I have never heard of a generic mechanism to allow FB and VB SYSPROC or SYSEXEC concatenations to coexist transparently. So it usually falls on the sysprog team to convert supplied data sets to the user-expected format. The biggest problem with format conversion is that you have to keep up with vendor updates. That's way more trouble than the original conversion. So if pressure on the vendor gains you nothing, you need to live with the hassle. One technique to simplify life works if you can isolate a product to a particular set of users. For example, SMPE and IPCS are used by sysprogs. You can write an 'INIT' REXX that allocates vendor-supplied data sets--including e.g. REXX of the opposite format--and instruct users to run *your* application. The INIT REXX almost never needs updating; vendor updates everything else. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Seymour J Metz Sent: Monday, May 13, 2019 8:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Concatenating VB and FB ? Concatenation of FB and VB isn't going to work. I prefer VB, but changing it after the fact is a user hostile move. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Tim Hare <haresystemssupp...@comcast.net> Sent: Sunday, May 12, 2019 10:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Concatenating VB and FB ? I seem to be finding different answers on this. A vendor used to ship some files as PDSes with RECFM=FB and LRECL=80 (BLKSIZE 23440). User-customized members at this shop were put in a different PDS, with the same attributes, and concatenated in cataloged procedures, ahead of the vendor's libraries. Pretty standard practice I'm sure most are familiar with. Suddenly, because (I'm told) of a merging of code bases at the vendor, their PDSes are now RECFM=VB and LRECL=2044 (BLKSIZE 27998) ! My instincts tell me this isn't going to work well, but with changes in concatenation of libraries over the course of my career I'm not sure. Here's what I think: because of the "new" rule where the largest BLKSIZE sets the buffer size, we'll be OK for reading the blocks (23440 fits into 27998) but when we try to read a member from the VB library, the RDWs are going to mess things up. I have tried searching for the answer, but haven't, apparently, found the right source yet. What say you all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
