Hi Skip, You said: "... Vendor distribution is usually FB--SMPE pretty much requires that ...". Can you prove that "SMPE pretty much requires that"? I think that this assertion is false.
Regards. David On 2019-05-13 12:04, Jesse 1 Robinson wrote: > 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 > https://nam02.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7C29293da556de462861d808d6d7bcae92%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636933602772274132&sdata=O%2F4Dn1wVo%2BMCxCA%2FRRIyQnf5gVVhfF%2Bn1cggQdKM%2Bu0%3D&reserved=0 > > ________________________________________ > 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
