× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




You can split the 800 in half to get the display VS update programs.  We have a
display & update program that is supported by one map.  So we have 400 display,
400 updates and 400 maps.  We are getting Progen and will use it to replace a
language called General (SGT).  The problem that we are looking at with all the
code is that our online system has 27 years of business rule edits and
functions.  If we had to get into trying to decide what each of those edits are
really about, we would never be able to convert.  We need a way to keep in place
the basis of the cobol edits and just change the CICS transactions to the
equivalent native transactions.

We will take a better look at Progen to help us out.  I am excited about Progen,
so maybe we can get even more use out of it than what we had originally
intended.

Thanks!
Dusty





"Stone, Joel" <StoneJ@GourmetAward.com> on 12/31/2001 11:12:38 AM

Please respond to cobol400-l@midrange.com

To:   "'cobol400-l@midrange.com'" <cobol400-l@midrange.com>
cc:    (bcc: Dusty Hansen/UT/FBFS)

Subject:  mainframe cobol to AS/400 cobol



This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
We converted from a cobol mainframe environment (not IBM) to the AS/400
several years ago.

Of the 800 interactive pgms, how many are simple maintenance or display
programs (Read a customer record, display on screen, allow
add/change/delete)?

We used a code generator to quickly develop these types of pgms.  We
purchased Progen, which generates RPG code (we rarely had to look at the RPG
code, although it helped us to learn RPG).

Only a handful of pgms required complete re-writes.  Most were replaced with
Progen or migrated easily.



-----Original Message-----
From: dkhansen@fbwc.com [mailto:dkhansen@fbwc.com]
Sent: Friday, December 21, 2001 2:28 PM
To: cobol400-l@midrange.com
Subject: (no subject)




My name is Dusty Hansen.  I am a programming manager of 17 programmers.  We
are
going to try and go from our current COBOL CICS main frame platform to
COBOL/400
on the 400.  We are currently running our batch processing on the 400 but we
need to migrate all of our 800 COBOL programs and 400 BMS maps to the 400.
We
will then have our interactive portion on the 400 and we can get ride of the
bigger main frame.   I have read some very good mail posted in the archives.
This has been very valuable.

I am looking to see if we there is a way that a called program can kill the
calling program and run on it's own?  If you have a stack and the main
calling
program calls a sub program which calls others, do we have to keep the
relationship of the main program or can we kill it at some point?  With what
we
are doing we do not need the initial calling program once we have
transferred
control to one of the sub programs.

In our CICS world we have a display program that reads a record and then
sends a
map to the screen.  The display program then goes away.  If there has been
any
thing coded on the screen the update program is invoked and reads the map,
updates the record and then send out the output map (screen).  the update
program then goes away.  This is handled by using the CICS XCTL command.
This
will transfer control to another program and then go away.  Is there an
equivalent situation for COBOL/400?


_______________________________________________
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/cobol400-l
or email: COBOL400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.
_______________________________________________
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/cobol400-l
or email: COBOL400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.









As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.