info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Cobol/VS to Cobol/VSE and CICS/VS to CICS/TS compatibility
40 views
Skip to first unread message
Tony Thigpen
Oct 8, 2015, 7:41:22 PM10/8/15
to
A customer has asked me to post this set of questions.
I am working with a customer that uses a so-called '4th Gen Language'
called XBOL. The 4GL language actually converts the source to real Cobol
which is then compiled normally. XBOL would only produce FCOBOL code and
since the author died several years ago, this customer was stuck using
FCOBOL.
This customer (who is running z/VSE 4.2 and CICS/2.3) has decided that
it's time to move forward. They got me involved and I have updated XBOL
to produce Cobol/VSE code. (They had the source).
Now, they are in the process of recompiling all their online XBOL code
(about 1400 programs) using Cobol/VSE, 31bit and RENT for use by CICS
with the goal to identify any programs with link or compile errors. This
compile pass will be used for some initial testing, but is not intended
to be the final compile pass. (They are doing it outside of their SOX
procedures.)
Now, they are looking at how to roll this into their production
environment.
Some background:
They currently run 4 CICSs. Although they do not have a real TOR/AOR
environment, they do share many (100+) files between the CICSs in a
AOR/DOR type environment. (It's really 4 AORs, but some AORs act as a
DOR for other CICS regions.)
While they have been linking their programs with LE for about 10 years,
a good portion of their CICS phases have not been compiled since then.
Option 1:
Recompile everything using Cobol/VSE, translating with the CICS/2.3
translator and migrate everything piecemeal and continue to run under
CICS/2.3 until everything is in production. Then, in the near future,
mass recompile and translate using the CICS/TS translator and moving in
one big move all their CICSs to CICS/TS.'
Option 2:
Recompile everything that is used by an individual CICS to CICS/TS and
then roll that CICS/TS into production as one big migration for each
CICS region. This would mean that there could be CICS/2.3 to CICS/TS DOR
issues.
Option 3:
Recompile everything for CICS/TS and convert all CICSs to CICS/TS in one
move.
They know that any way they do it, there is risk. Even just recompiling
everything can bring in the wrong version of the program, but they know
that is unavoidable. (It will also satisfy their SOX audit concerns as
source will match phases.)
The consider Option 1 the least risky, but more work on their part. They
consider Option 3 the most risky, but it may be acceptable as it reduced
the time to completion and the man-hours involved.
They know there is no 'perfect' solution. And, they plan on a lot of
testing before rolling it into production.
Also, while they don't mind running both Cobol/VS and Cobol/VSE programs
in the same CICS during the migration, they want to be totally Cobol/VSE
at the end of the project.
They want to know how others have approached this process. They are open
to suggestions and caveats.
--
Tony Thigpen
_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu
https://lists.lehigh.edu/mailman/listinfo/vse-l
I am working with a customer that uses a so-called '4th Gen Language'
called XBOL. The 4GL language actually converts the source to real Cobol
which is then compiled normally. XBOL would only produce FCOBOL code and
since the author died several years ago, this customer was stuck using
FCOBOL.
This customer (who is running z/VSE 4.2 and CICS/2.3) has decided that
it's time to move forward. They got me involved and I have updated XBOL
to produce Cobol/VSE code. (They had the source).
Now, they are in the process of recompiling all their online XBOL code
(about 1400 programs) using Cobol/VSE, 31bit and RENT for use by CICS
with the goal to identify any programs with link or compile errors. This
compile pass will be used for some initial testing, but is not intended
to be the final compile pass. (They are doing it outside of their SOX
procedures.)
Now, they are looking at how to roll this into their production
environment.
Some background:
They currently run 4 CICSs. Although they do not have a real TOR/AOR
environment, they do share many (100+) files between the CICSs in a
AOR/DOR type environment. (It's really 4 AORs, but some AORs act as a
DOR for other CICS regions.)
While they have been linking their programs with LE for about 10 years,
a good portion of their CICS phases have not been compiled since then.
Option 1:
Recompile everything using Cobol/VSE, translating with the CICS/2.3
translator and migrate everything piecemeal and continue to run under
CICS/2.3 until everything is in production. Then, in the near future,
mass recompile and translate using the CICS/TS translator and moving in
one big move all their CICSs to CICS/TS.'
Option 2:
Recompile everything that is used by an individual CICS to CICS/TS and
then roll that CICS/TS into production as one big migration for each
CICS region. This would mean that there could be CICS/2.3 to CICS/TS DOR
issues.
Option 3:
Recompile everything for CICS/TS and convert all CICSs to CICS/TS in one
move.
They know that any way they do it, there is risk. Even just recompiling
everything can bring in the wrong version of the program, but they know
that is unavoidable. (It will also satisfy their SOX audit concerns as
source will match phases.)
The consider Option 1 the least risky, but more work on their part. They
consider Option 3 the most risky, but it may be acceptable as it reduced
the time to completion and the man-hours involved.
They know there is no 'perfect' solution. And, they plan on a lot of
testing before rolling it into production.
Also, while they don't mind running both Cobol/VS and Cobol/VSE programs
in the same CICS during the migration, they want to be totally Cobol/VSE
at the end of the project.
They want to know how others have approached this process. They are open
to suggestions and caveats.
--
Tony Thigpen
_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu
https://lists.lehigh.edu/mailman/listinfo/vse-l
Martin Truebner
Oct 9, 2015, 3:15:42 AM10/9/15
to
Tony,
here is my opinion (althru I'd rather be directly involved (hint hint
hint) )
>> Option 1:
Recompile everything using Cobol/VSE, translating with the CICS/2.3
translator and migrate everything piecemeal and continue to run under
CICS/2.3 until everything is in production.
CICS 2.3 has everything you need (*1). So this would be the way to go.
>> Then, in the near future, mass recompile and translate using the
>> CICS/TS translator and moving in one big move all their CICSs to CICS/TS.
Why on earth would you do that? There is absolutely no need to do that.
Once you are in 2.3 (+macro level only) you should be able to go
seamless to CICS/TS. I did that more than once. The point is really
that macro-level must be removed. 2.3 has everything to run on
CICS/TS. Remember IBM is the company that has a record of being
compatible to antediluvian code (as opposed to most others).
Any while I am writing-
>> Even just recompiling everything can bring in the wrong version of
>> the program,
Give me a date - and I write you an exit that makes sure that no
program compiled before that date (or without one) is executed as
application-code in CICS 2.3 (and later in CICS/TS).
What does DOR stand for? database owning? dataowing (including TS and
TD).
While i do not think it makes any difference,i would want to avoid any
possible hassles and have everything ready to go (on 2.3) and then do
the switch (*2).
You haven't said a word about the VSE system. Something before 4.3 to
something beyond 4.4 --- but this could be VSE 2.1 to 5.2 so could you
say something .... there could be way more booby-traps.
Notes:
(*1) and If you find anything that is not there, needed to go CICS/TS
you can blame me. I was more than active involved in identifying all
needs that are in CICS pre macro-only (on MVS) and phrase requirements.
These requirements are all in CICS-VSE 2.3. There should not be any
problem to convert whatever you have in whatever language you want to
CICS 2.3.
(*2) 2.3 is not supported anymore. So whatever goes wrong, you are on
your own. If you have everything on 2.3 you are at least safe from
release-difference-issues. Then on to TS.
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
here is my opinion (althru I'd rather be directly involved (hint hint
hint) )
>> Option 1:
Recompile everything using Cobol/VSE, translating with the CICS/2.3
translator and migrate everything piecemeal and continue to run under
CICS/2.3 until everything is in production.
>> Then, in the near future, mass recompile and translate using the
>> CICS/TS translator and moving in one big move all their CICSs to CICS/TS.
Once you are in 2.3 (+macro level only) you should be able to go
seamless to CICS/TS. I did that more than once. The point is really
that macro-level must be removed. 2.3 has everything to run on
CICS/TS. Remember IBM is the company that has a record of being
compatible to antediluvian code (as opposed to most others).
Any while I am writing-
>> Even just recompiling everything can bring in the wrong version of
>> the program,
program compiled before that date (or without one) is executed as
application-code in CICS 2.3 (and later in CICS/TS).
What does DOR stand for? database owning? dataowing (including TS and
TD).
While i do not think it makes any difference,i would want to avoid any
possible hassles and have everything ready to go (on 2.3) and then do
the switch (*2).
You haven't said a word about the VSE system. Something before 4.3 to
something beyond 4.4 --- but this could be VSE 2.1 to 5.2 so could you
say something .... there could be way more booby-traps.
Notes:
(*1) and If you find anything that is not there, needed to go CICS/TS
you can blame me. I was more than active involved in identifying all
needs that are in CICS pre macro-only (on MVS) and phrase requirements.
These requirements are all in CICS-VSE 2.3. There should not be any
problem to convert whatever you have in whatever language you want to
CICS 2.3.
(*2) 2.3 is not supported anymore. So whatever goes wrong, you are on
your own. If you have everything on 2.3 you are at least safe from
release-difference-issues. Then on to TS.
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
Kevin Corkery
Oct 9, 2015, 7:38:31 AM10/9/15
to
We converted all our CICS code on VSE 2.3 to COBOL for VSE on CICS/VSE.
When we went to VSE 2.4 we went directly onto CICS/TS. The code had been
well exercised on CICS/VSE so we knew there wasn't anything particular to
the application code. One thing that does come to mind is that the file
status of DISABLED was not available in CICS/VSE so anything explicitly
checking for CLOSED must also check for DISABLED (or at least I think that
was what it was, this happened a long time ago). Also, and this I can't
remember and can't find in old documentation (oh, Mike or maybe Garry)
there's a SIT parameter, I think it's LESTG, that allocates storage
manageable directly by LE under CICS/VSE; this needs to be expanded from the
default or the COBOL for VSE code runs like crap under CICS/VSE.
When we went to VSE 2.4 we went directly onto CICS/TS. The code had been
well exercised on CICS/VSE so we knew there wasn't anything particular to
the application code. One thing that does come to mind is that the file
status of DISABLED was not available in CICS/VSE so anything explicitly
checking for CLOSED must also check for DISABLED (or at least I think that
was what it was, this happened a long time ago). Also, and this I can't
remember and can't find in old documentation (oh, Mike or maybe Garry)
there's a SIT parameter, I think it's LESTG, that allocates storage
manageable directly by LE under CICS/VSE; this needs to be expanded from the
default or the COBOL for VSE code runs like crap under CICS/VSE.
Mike Moore
Oct 9, 2015, 7:56:37 AM10/9/15
to
Tony,
I'm trying to remember when we went to TS and I think option 3 would end up being the least amount of trouble and the fastest way to convert. Once they get the general sense of what changes have to be made, they can move pretty fast through their list of programs to compile. Send the compiles to a test library so they can make sure the programs still play well with each other.
Mike Moore
IT Manager
Alabama Judicial Datacenter
300 Dexter Avenue
Montgomery, Alabama 36104
334-954-5025
"This is the final test of a gentleman: his respect for those who can be of no possible service to him." - William Lyon Phelps
I'm trying to remember when we went to TS and I think option 3 would end up being the least amount of trouble and the fastest way to convert. Once they get the general sense of what changes have to be made, they can move pretty fast through their list of programs to compile. Send the compiles to a test library so they can make sure the programs still play well with each other.
Mike Moore
IT Manager
Alabama Judicial Datacenter
300 Dexter Avenue
Montgomery, Alabama 36104
334-954-5025
"This is the final test of a gentleman: his respect for those who can be of no possible service to him." - William Lyon Phelps
Tony Thigpen
Oct 9, 2015, 8:40:06 AM10/9/15
to
Martin,
The following was included in the original post:
Tony Thigpen
The following was included in the original post:
> This customer (who is running z/VSE 4.2 and CICS/2.3
Additionally, the customer wants to move quickly to 5.x.
Tony Thigpen
Tony Thigpen
Oct 9, 2015, 9:00:28 AM10/9/15
to
In addition to the on-list replies, I have received some off-list
suggestions. So, a follow-up question related to the translator:
1) What issues are related to the level of the CICS Translator? Since
the code originally generated CICS/VSE code, they need to spot any
incompatibilities with the newer CICS/TS translator. So, can the CICS/TS
translator be used to pre-process a CICS/VSE phase. Or, is this just
something that has to be checked with the "research" compile project phase?
Additional information in response to replies:
As far as known, there is no macro level code.
There are very few (<10) small assembler subroutines. As these are
found, I have been reviewing them for compatibility with CICS Storage
Protection. So far, no issues have been found. [While not turned on
initially, part of the testing will have Storage Protection turned on.
It is the preferred mode going forward.]
In the original post, the reference to DOR was "Data Owning Region". All
files are VSAM with no Database involved. While they don't have a true
DOR-only region, they do have about 100 VSAM files that are cross-shared
using REMOTE in the FCT.
Tony Thigpen
suggestions. So, a follow-up question related to the translator:
1) What issues are related to the level of the CICS Translator? Since
the code originally generated CICS/VSE code, they need to spot any
incompatibilities with the newer CICS/TS translator. So, can the CICS/TS
translator be used to pre-process a CICS/VSE phase. Or, is this just
something that has to be checked with the "research" compile project phase?
Additional information in response to replies:
As far as known, there is no macro level code.
There are very few (<10) small assembler subroutines. As these are
found, I have been reviewing them for compatibility with CICS Storage
Protection. So far, no issues have been found. [While not turned on
initially, part of the testing will have Storage Protection turned on.
It is the preferred mode going forward.]
In the original post, the reference to DOR was "Data Owning Region". All
files are VSAM with no Database involved. While they don't have a true
DOR-only region, they do have about 100 VSAM files that are cross-shared
using REMOTE in the FCT.
Tony Thigpen
Garry Hasler
Oct 9, 2015, 9:21:33 AM10/9/15
to
On 09/10/15 19:37, Kevin Corkery wrote:
> was what it was, this happened a long time ago). Also, and this I can't
> remember and can't find in old documentation (oh, Mike or maybe Garry)
> there's a SIT parameter, I think it's LESTG, that allocates storage
> manageable directly by LE under CICS/VSE; this needs to be expanded from the
> default or the COBOL for VSE code runs like crap under CICS/VSE.
specified - or set too small - could have a negative
impact on LE application performance under CICS.
The "equivalent" for CICS/TS is RUWA - but while it is recommended to be
used (especially if you have some AMODE24
applications still running) it will not have quite the same performance
"improvement" as was noticed between LESTG
and not setting LESTG in CICS/VSE 2.3.
Regards,
Garry Hasler
Australian Development Lab for System/z.
Perth, Australia
linkedin : http://au.linkedin.com/pub/garry-hasler/68/a9b/557
LE z/VSE Blog : LE z/VSE Blog : https://www.ibm.com/developerworks/community/blogs/lezvse/?lang=en
Ken and Mary Meyer
Oct 9, 2015, 10:19:01 AM10/9/15
to
Since the customer does not have any macro code, there are very few differences
between CICS/VSE and CICS/TS that were not related to access to CSA, use of
various terminal or transaction elements that were not using the proper access
methods, order of execution of transactions, etc. If the customer is
just running
applications that did not look for specific CICS internal information,
the only issues
should be related to COBOL release and if they are using LE properly.
They should
also consult the migration guides.
For a comparison, they could build individual source using both translators and
compare the two without actually compiling the source. Years ago I used to
do that a lot. :)
Ken
snip..
between CICS/VSE and CICS/TS that were not related to access to CSA, use of
various terminal or transaction elements that were not using the proper access
methods, order of execution of transactions, etc. If the customer is
just running
applications that did not look for specific CICS internal information,
the only issues
should be related to COBOL release and if they are using LE properly.
They should
also consult the migration guides.
For a comparison, they could build individual source using both translators and
compare the two without actually compiling the source. Years ago I used to
do that a lot. :)
Ken
snip..
0 new messages