ISAM is supported by a couple / three different open source vendors.
It is not VSAM in the traditional IBM sense of SHR LEVEL or with the IBM notion of control intervals. However from a GnuCOBOL perspective the VSAM access methods are one and the same as ISAM.
EBCDIC is only supported on certain hardware (none are Windows).
There is no IDCAMS utility available.
No commit / rollback.
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2022-06-23
Hello I want to give you more details:
1. I have a JCL runing a cobol program XXPD0894 in a mainframe it reads several VSAM ( I did not copy all the JCL step) and create a sequential file:
I want to make a proof of concept and try to run this step that consumes a lot of CPU in the mainframe in a Docker with OPEN COBOL trying to make the minimiun changes to XXPD0894 PGM, I was thinking to load this VSAM in a POSTGRESS DB but it will take so much effort to map all this fields
So I want to try to download this files maybe run a sort and create de sequential file can I build a Vsam file on PC or maybe would be another strategy to run this PGM y PC and after copy it using for example FTP to load the result file to my mainframe?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With either of those tools, they would show the number of I/O's on each file & index...
I'm guessing that if the cpu time for the step is not huge, that the issue is related to I/O on one or more of the VSAM files.
If that is the case, I recommend that you talk to your System Programmer about using BLSR (Batch Local Shared Resources) to make better use of buffers and buffering techniques.
There is an IBM Redbook, search for VSAM Demystified or something close to that...
Also do some searches on using BLSR in JCL, some of this may be dependent on how your System Programmers have configured BLSR at your site.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2022-06-24
You are right this pgm while it is proccessing a sequential file search in several vsam data and it uses so much I/O and CPU, to change it could need testing and migrating this step could avoid testing, this app has a big number of jcl like this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello guys I want to know if you can process vsam file with this Cobol?
It all depends what "your vsam file" is and if you have the necessary COBOL code to process the file. Also depends on what you mean with "process".
ISAM is supported by a couple / three different open source vendors.
It is not VSAM in the traditional IBM sense of SHR LEVEL or with the IBM notion of control intervals. However from a GnuCOBOL perspective the VSAM access methods are one and the same as ISAM.
EBCDIC is only supported on certain hardware (none are Windows).
There is no IDCAMS utility available.
No commit / rollback.
Ralph
Hello I want to give you more details:
1. I have a JCL runing a cobol program XXPD0894 in a mainframe it reads several VSAM ( I did not copy all the JCL step) and create a sequential file:
//FD31C050 EXEC PGM=XXPD0894,COND=(0,LT)
//SYSOUT DD SYSOUT=*
//AMBSSCON DD DISP=SHR,DSN=S&HLQ..XX.NA.BA.XXXXXXX.GMR.SCRON.V
//FILPARML DD DISP=SHR,DSN=S&HLQ..SS.NA.LY.XXXXXXXX(FD001050)
//FACTULAN DD DSN=S&HLQ..XX.NA.BA.XXXXXXX.L30.S,
// DCB=(MODEL,
// RECFM=FB,LRECL=300,BLKSIZE=0),
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(1000,100),RLSE)
//SYS001 DD SYSOUT=(V,,SIMP)
Do you have access to Compuware's Strobe product on the mainframe or IBM's Application Performance Analyzer for Z/OS ?
if so they would be much better tools to analyze the performance bottlenecks...
With either of those tools, they would show the number of I/O's on each file & index...
I'm guessing that if the cpu time for the step is not huge, that the issue is related to I/O on one or more of the VSAM files.
If that is the case, I recommend that you talk to your System Programmer about using BLSR (Batch Local Shared Resources) to make better use of buffers and buffering techniques.
There is an IBM Redbook, search for VSAM Demystified or something close to that...
https://www.redbooks.ibm.com/abstracts/sg246105.html
Also do some searches on using BLSR in JCL, some of this may be dependent on how your System Programmers have configured BLSR at your site.
You are right this pgm while it is proccessing a sequential file search in several vsam data and it uses so much I/O and CPU, to change it could need testing and migrating this step could avoid testing, this app has a big number of jcl like this.