If you are simply migrating and don't want to worry about changes then I wouldn't bother making any changes on VSE. But you will have to do what we did, which is during your source migration change (most!) of your select statements and remove the AS- prefix. Here is what we did during our migration:
1) Determined which sequential files in batch programs were also used in CICS. This is because the CICS files, when defined in the FCT, must be VSAM. 2) We placed these files in an "exception list". 3) When converting our COBOL programs from VSE to z/OS we removed all instances of AS- from our COBOL select statements *UNLESS* they were in the above exception list. If they were in the list we left them as ESDS. 4) When migrating our data we again looked at the exception list. For ESDS files in the exception list we defined them on z/OS as ESDS. For all others we pre-defined them as QSAM. The other alternative we for better or worse decided against was simply keeping all ESDS files as ESDS, rather than converting most of them to QSAM. It seems to me this would have made our conversion much simpler, but in the end what we did worked out well so I can't really complain. One other thing you'll need to know is that, while ESDS and QSAM generally behave similarly when used by COBOL, there are occasions when they do not behave the same. Here are the differences that I can recall 1) Easy one: QSAM does not support the second, VSAM only, file-status field. This is easy to fix because the program will not compile if you attempt to use the second file-status field when specifying a QSAM file. 2) For better or worse you apparently can refer to the file buffer of a VSAM file prior to opening the file, and after closing it. When the file is QSAM you get some sort of error, though I can't recall exactly what. S0C4 perhaps. In any case this is really a programming logic mistake, so you will simply need to fix the program to not do it. Of course thorough testing is the only way you are going to determine if this logic error exists in any of your programs. 3) Well, there was another one, but I don't recall all of the details. I believe it had something to do with changing the size of a record in the buffer of a variable length file. Whatever it is, hopefully you'll not run in to it. :-) Hope this helps, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 2/18/2011 at 5:36 AM, in message <snt137-w23e937c464dbf875cea823ac...@phx.gbl>, Sergio Lima <sergio...@hotmail.com> wrote: > Frank, > > We will migrate from VSE to ZOS. > If I understand, We can first, change all program on VSE, removing the AS > prefix from SELECT, and then, use the SAM-ESDS (MSAM). > And, when migrate the source from VSE to Z/OS, no change is required correct > ? > If is this idea, is very good, but I think that the developer people have no > time to change this, unfortunatelly. > > Anyway, thanks very much from your help, and best regards. > > Sergio > >> Date: Thu, 17 Feb 2011 18:05:37 -0700 >> From: frank.swarbr...@efirstbank.com >> Subject: Re: Question about COBOL Program >> To: IBM-MAIN@bama.ua.edu >> >> What is your end goal? Is it to have the same source code work on both VSE > and z/OS? Or are you just migrating to z/OS from VSE? >> >> If the former, I would recommend coding the select as non-VSAM (no AS- > prefix). Then use a QSAM file on z/OS and a VSAM-managed SAM (MSAM; aka > SAM-ESDS) on VSE. We just moved from VSE to z/OS last year. We used MSAM > fairly extensively. No need for those awful EXTENT statements that are > required by SD files. >> >> Of course, alternatively you could use VSAM ESDS instead of sequential on > both VSE and z/OS. I know that z/OS shops prefer QSAM to ESDS in general (or > so I've been told), but ESDS certainly is an option. >> >> Frank >> -- >> >> Frank Swarbrick >> Applications Architect - Mainframe Applications Development >> FirstBank Data Corporation - Lakewood, CO USA >> P: 303-235-1403 >> >> >> On 2/17/2011 at 12:44 PM, in message >> <snt137-w60ae05a8bf42cb28124dd1ac...@phx.gbl>, Sergio Lima >> <sergio...@hotmail.com> wrote: >> > Hello List, >> > >> > We had installed in our installation ZOS1.12 system , and also Z/VSE 4.2. >> > Under Z/VSE, is not very easy, work, with sequential files, if you don't >> > have a specific product for manage the VTOC space, that is our case. >> > Under Z/OS, it is not true, because, is not necessary specify the START of > a >> > LOCATION from a file in to disk. >> > So, We thing change all of our JCL, when the file is VSAM under Z//VSE : >> > // > >> > DLBL MYFILE,'MYFILE.VSAM',,VSAM , to sequential files under Z/OS, >> > //MYFILE DD DSN=MYFILE.SEQ,DISP=SHR, without change the source of a COBOL >> > program. >> > >> > The test that We made here, show that this is not possible, so, We want > know >> > the opinions of this list, if this is really true. >> > >> > In a single COBOL, we wrote : >> > >> > SELECT ARQSEQ ASSIGN TO SYS010-AS-ARQSEQ >> > FILE STATUS IS FS-ARQSEQ. >> > >> > Then running ok for VSAM, but not for a sequential file, had Return code = >> > 37. >> > >> > When running with this : >> > >> > SELECT ARQSEQ ASSIGN TO SYS010-UT-ARQSEQ >> > >> > Here, run ok for sequential file, but for VSAM had : >> > >> > IGZ0200W A file attribute mismatch was detected. File ARQSEQ in program >> > LESEQ was defined as a physical sequential >> > file and the file specified in the ASSIGN clause was a VSAM data >> > set. >> > >> > and the program end with Return code = 39. >> > >> > Thanks very much >> > >> > Sergio Lima Costa >> > Sao Paulo - Brazil >> > >> > >> > ---------------------------------------------------------------------- >> > For IBM-MAIN subscribe / signoff / archive access instructions, >> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >> > Search the archives at http://bama.ua.edu/archives/ibm-main.html >> >> >>> >> >> The information contained in this electronic communication and any document > attached hereto or transmitted herewith is confidential and intended for the > exclusive use of the individual or entity named above. If the reader of this > message is not the intended recipient or the employee or agent responsible > for delivering it to the intended recipient, you are hereby notified that any > examination, use, dissemination, distribution or copying of this > communication or any part thereof is strictly prohibited. If you have > received this communication in error, please immediately notify the sender by > reply e-mail and destroy this communication. Thank you. >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >> Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
