There is a 64-bit ODBC driver so Db2 does provide a 64 bit API today, just
not for embedded SQL :)

On Tue, Jan 7, 2020 at 7:10 AM Don Poitras <
[email protected]> wrote:

> In article <
> bn7pr10mb2546b7200578531cb1734e24f3...@bn7pr10mb2546.namprd10.prod.outlook.com>
> you wrote:
> > >So what can you do *today* if you have an immediate requirement for an
> AMODE 64 COBOL program per Tom Savor's comment, a program that must run
> both in CICS >Transaction Server for z/OS and in non-CICS batch mode? Tom
> Marchant provides one answer that works today and is fully IBM supported:
> > >compile both AMODE 31 and AMODE 64 versions of the same COBOL program
> from the same source code. Invoke the former within CICS TS, and invoke the
> latter in (non->CICS) batch, assuming the program can otherwise run both
> inside and outside CICS TS. Before you dismiss this idea out of hand, let's
> recognize that many software vendors >already do this and have for many
> years, for example when they compile and distribute "performance tuned" and
> "compatible" releases of their software products, each using >different
> compiler parameters (ARCH, TUNE, etc., as applicable). Also, "debug" and
> "non-debug" versions, and "ABO'ed" and "non-ABO'ed." Importantly, it's not
> two versions >of source code; it's only two versions post-compilation.
>
> > For us, the programs that run in Batch and Online are DB2 i/o programs.
> So your solution wont work for us as SQL and LP(64) are in-compatible.
> >
>
> > Thanks,
>
> > Tom Savor
>
> There is a painful work-around. Use an assembler stub to call the DB2
> API in amode 31. Allocate all storage that will be written to or read
> from DB2 in storage allocated below the bar. I've done this in C, so
> I have to think it's possible to do in COBOL. I see there is an
> ALLOCATE statement that can be used to get dynamic storage below the
> bar. In C, we use __malloc31().
>
> Of course, it would be much better if DB2 would provide a 64-bit API.
> Now that C, COBOL and PL1 are able to run amode=64, I think there's
> a good argument to be made that this should be a priority.
>
> --
> Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
> [email protected]           (919) 531-5637                Cary, NC 27513
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to