Error handling points while data is migrated from Cobol to SAS

[deleted_user]

Hi,

can any one please tell me what are the points need to consider in error handling while migrating the data from Cobol Source (Legacy Sysytem) to SAS Source system

thanks in advance
DVD.....

[Cynthia_sas]

Hi...I'm not sure what you mean by "migrating source" -- When I used to work with COBOL (a long, long time ago, in a galaxy far, far away), we kept our COBOL source code in SOURCE libraries and since COBOL programs could be split into 4 "divisions" we sometimes kept our DATA Divisions separate from our Identification Division, the Environment Division or our Procedure Division code.

COBOL does not itself have "data". COBOL is a programming language that can read many different data formats -- IMS, DB2, VSAM, ISAM, BDAM, sequential, etc. COBOL can also create data files but generally, the layout of the data file is outlined in a particular data description. I usually created report files or sequential (flat) files when I was coding in COBOL. However, it was always our practice to use Packed Data for numeric values like numbers and dates -- so the field took up less storage space (when storage space was more expensive then it is these days).

Once you write a COBOL program to read data or produce a report, the program has to be compiled into a LOAD module and then it is the compiled LOAD module that needs to be executed in order to read, process or report on data.

So, if you are asking how to convert a COBOL Data Division or Working Storage section into a SAS program with INFILE/INPUT statements, then you might want to look at and read the documentation on the COB2SAS routine, which helps you convert your COBOL Data descriptions to SAS form data descriptions:
http://support.sas.com/techsup/technote/ts536.html

But you also asked about Error handing points, which leads me to believe that you may have data that was stored with COBOL's method of storing signs and negative numbers or using packed numbers. So one "error" that frequently happens with COBOL-program-created-data is that someone used a signed decimal format or packed decimal format in COBOL to create a data file and thus when you go to read the file with "standard" SAS input, you might not see your numbers or dates appearing correctly. (If you look in the old COBOL program and see things like: PICTURE S99V99 COMP-5 or PIC 9999 PACKED-DECIMAL, then you need to do something "different" in order to read this kind of data.) The COB2SAS routine essentially translates COBOL data descriptions into SAS format. But, if you look in the SAS documentation on INFORMATs, particularly, this Tech Support Note, it lists which SAS INFORMAT corresponds to which COBOL data description.
http://support.sas.com/techsup/unotes/SN/003/003714.html

Your best bet for help might be to contact Tech Support and explain your conversion issues and find out the best way to proceed in EG.

cynthia

[deleted_user]

The server response across the Pacific has been a little poor, which may be an issue with a kink in the cable . I wonder whether this is why we are seeing the same question posted a number of times.

I note you had a couple of dupe postings you had to clean up Cynthia, and if you were working locally that tends to exclude kinky cables.

Kind regards

David

[deleted_user]

I have to agree that you seem to be asking too general of a question, and that it may be out of scope for EG.

What kind of error handling?
SAS has macro variables with return code values for various operations that can be used.
SAS also has some functions that are helpful, like sysmsg().

SAS even has a datastep debugger -- look under SAS Products, Base SAS, SAS Language Dictionary, Appendixes.

If the actual run code is batch SAS run outside of EG, then this question should be posted elsewhere, and SAS has return codes, that can be user programmatically set, which can be captured by batch management systems like Control-M, which can then send appropriate alerts via emails, or SNMP traps. Or the return codes could be used with JCL cond() "statements/clauses".

IF you are trying to "scrub" the input data within SAS, that is a different thing intirely and should be covered in SAS's ETL related documentation.