On Sun, Dec 1, 2013 at 4:20 PM, esst...@juno.com <esst...@juno.com> wrote:
> I initiallydid notfind this topic particularly interesting as it was > basicaly responded too in the first few responses. > (SVC/PC). > > I recently had a dispute with Management reagrding the uses of sceduling > COBOL BATCH under an SRB. > Thats Right a Batch COBOL Prpogram runing Under an SRB, moreover under > CICS Transaction Server. A Software Vendor > believes they can solve a program sharing issue by using SRBS > to execute a Batch Cobol Progam. > > In a nut shell the user enters a basic CICS transaction code and a PC call > is issued to a Server Address Spaces whose only responsibility is to > SCHEDULE an SRB Back to the specific CICS Region. The SRB then executes a > Batch COBOL program. > Oh my. I guess you can't mention the vendor. I'd like to __avoid__ them. I won't say "that is impossible!". But how they can make a standard batch COBOL program, with all the LE routines, and especially the READ and WRITE verbs work in an SRB is totally beyond my comprehension. Well, I guess they might have some way to replace some of the LE routines with their own which would "do something". Also, by definition, everything which runs in SRB mode is running authorized. Being the "dirty rat fink" that I am, I'd report this to the IT auditors as a sever security and reliability breach. As a sysprog, I would _refuse_ to acknowledge any responsibility for system integrity if this were implemented. > > I dont want to bore everyone with all the politics; such as we dont want > to pay for Transactional VSAM, and we dont want to maintain 2 Versions of > this program (Batch & CICS). > Mu collogue and I lost all the battles. > Your management is composed of FOOLS. Ignorant, brain impaired idiots. We do this, concurrent VSAM, using the relatively inexpensive SYSB-II product from H & W Computing (http://www.hwcs.com). We have had a few minor problems, but they were self inflicted. We have _no_ problems at all with the product now. > > I raise this issue to encourage some additional discussion. > Again this is a VENDOR who has developing this facility. > > Paul D'ANgelo > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
