Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

FW: [HP3000-L] HP3000 TO HP9000 Migration

0 views
Skip to first unread message

Bundy, Mike

unread,
Aug 4, 2005, 11:49:15 AM8/4/05
to HP30...@raven.utc.edu
-----Original Message-----
From: Bundy, Mike
Sent: Thursday, August 04, 2005 11:45 AM
To: 'Shahan, Ray'
Subject: RE: [HP3000-L] HP3000 TO HP9000 Migration


Ray,

here is what we have encountered so far. Again we are just getting started.


1. Accept statement in AcuCobol does not terminate when the receiving
field is filled.
On the HP3000 when you accept input into a field, once that field is
filled there
is an automatic termination of the accept. When we compile on the
HP9000
using AcuCobol (with HP Compatibility and Ansii Compatibility for
Display & Accept
options enabled), the data input will not terminate until the user
presses Enter.
Once that is done, the value returned in the accepted field will
only be the length
of that field. According to AcuCorp, the only way to have an auto
terminate on an
Accept is to use the following: ACCEPT <FIELD> FROM CRT however
CRT
is not a valid option when using the HP Compatibility option. Any
attempt to
compile the program not using that option will result in a clean
compile but will
subsequently abort with a Memory Access Violation when running the
program
in the nlsh shell from Speedware.

2. READX intrinsic is not functioning in the nlsh shell the same way as
it does on the
HP3000. On the HP3000, when calling readx, if you pass the number
of characters
expected as one of the parameters, the intrinsic will accept that
number of characters
then auto terminate. When calling this intrinsic using the NLREADX
intrinsic from
Speedware, the requested number of characters will be all that is
returned, however,
the user can input any number of characters until a carriage return
is entered to stop
the input process.

Both of the above issues create problems if you're in an environment where
people responsible
for data entry are accustom to having the program auto return thru fields as
they are being
entered.

3. The DELETE record function returns status 23 (record not found) when
attempting to
delete a record from a KSAMXL file when the program is running in
the nlsh shell
from Speedware. The test program works perfectly when run on the
HP3000, but
when migrated and compiled on the HP9000, the Add function will
correctly add
a record into the file. The Inquiry (readbykey) will correctly
retrieve a record.
When attempting to delete a record, the record is found (readbykey)
and displayed
to validate that the correct record is there, then the following
instruction is to delete
that record and we're getting the status 23 and no delete is done.

I hope this is not the beginning of a long difficult trail.

Mike.


-----Original Message-----
From: Shahan, Ray [mailto:rsh...@schoolspecialty.com]
Sent: Thursday, August 04, 2005 10:48 AM
To: HP30...@RAVEN.UTC.EDU
Subject: Re: [HP3000-L] HP3000 TO HP9000 Migration


Kike,

Can you share what the 'GOTHCA'S" you've run into are? Not only
will this help (hopefully) get your specific questions/concerns
answered, it will also add those answers to the archive for those that
are looking at migrating to the 9K from the 3K.

Thanks (and best of luck!!),

Ray Shahan

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:HP30...@RAVEN.UTC.EDU] On
Behalf Of Bundy, Mike
Sent: Thursday, August 04, 2005 9:39 AM
To: HP30...@RAVEN.UTC.EDU
Subject: [HP3000-L] HP3000 TO HP9000 Migration

I know we are not the only shop going through this migration process.
With
the tools and options that are available, my company decided to go with
ACUCOBOL for our Cobol3000 migration and AMXW for our Image migration. I
am
curious, did anyone out there choose this path and what has been your
experience. We have just begun and we are running into a few somewhat
disappointing "GOTCHA'S".

Mike Bundy
Senior Analyst
The Thompson Group

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

========================================================================
This e-mail message has been scanned for Viruses and Content and cleared

by School Specialty's email filtering solution.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

Craig Lalley

unread,
Aug 4, 2005, 12:18:33 PM8/4/05
to HP30...@raven.utc.edu
Mike,

What I have found when converting to AcuCobol from HP-Cobol II is that the HP is much more forgiving.

An example I ran into yesterday.

A date field was not being filled in correctly i.e. "20050720" became "2005 720" the 3000 would read this and see no problem.

AcuCobol would burp. Thankfully is was only 23 records out of 23,000.

Another problem was the was AcuCobol treats sub-program and values passed.

-Craig

"Bundy, Mike" <MBu...@ThompsonGroup.com> wrote:
-----Original Message-----
From: Bundy, Mike
Sent: Thursday, August 04, 2005 11:45 AM
To: 'Shahan, Ray'
Subject: RE: [HP3000-L] HP3000 TO HP9000 Migration


Ray,

here is what we have encountered so far. Again we are just getting started.


1. Accept statement in AcuCobol does not terminate when the receiving
field is filled.
On the HP3000 when you accept input into a field, once that field is
filled there
is an automatic termination of the accept. When we compile on the
HP9000
using AcuCobol (with HP Compatibility and Ansii Compatibility for
Display & Accept
options enabled), the data input will not terminate until the user
presses Enter.
Once that is done, the value returned in the accepted field will
only be the length
of that field. According to AcuCorp, the only way to have an auto
terminate on an

Accept is to use the following: ACCEPT FROM CRT however

Mike.


Kike,

Ray Shahan

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Walter Murray

unread,
Aug 5, 2005, 3:14:12 PM8/5/05
to
"Craig Lalley" <mr_l...@yahoo.com> wrote:
[snip]

> Another problem was the was AcuCobol treats sub-program and values passed.

Craig,

Could you be more specific about this one?

Walter

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

0 new messages