When I am confused by this sort of thing, I ask the compiler to show me the generated assembler code that it is using. Perhaps C++ is inserting some other data in the parameter list. Also, is the HLASM routine defined with a prototype with an extern "C" ? Something like:
extern "C" type0 myassem(int, type1, type2, type3, type4, type5, type6, type7); Where the "type?" names are replaced by the proper type declaration. Just some thought. I am not a C++ programmer. On Wed, May 29, 2019 at 9:52 AM Pierre Fichaud <[email protected]> wrote: > I have an assembler routine that gets called by 64-bit C++. The assembler > routine uses CELQPRLG and CELQEPLG and calls DSNALI. The C++ function > prototype has a variable number of arguments, the first being the number of > parameters that follow in the argument list. The C++ program passes the > count of 7 followed by 7 31-bit pointers. These were dumped prior to the > call. I forced an S0C3 at entry to the assembler routine. R01 contains a > valid 64-bit address. It points to a doubleword containing 7. But the 7 > 31-bit addresses do NOT follow the value of 7. They are at +A8 from r01. I > want to move the pointers into 31-bit memory and call DSNALI to do a > CONNECT (Hence a prior post about DB2 manuals). I can't figure out what > I've done wrong. There is precious little doc on this and it's in the LE > bookshelf, LE Programming Guide for 64-bit Virtual Addressing Mode. Is > there other doc somewhere else ? I've looked but can't find anything. > > R01 points has 50_082FEBF8 and the 7 addresses are at 82FECA0. > > _82FEBF8 00000000 00000007 ! ........ > ! > _82FEC00 00000000 2B0DBB88 00000050 29E54920 ! .......h...&.V.. > ! > _82FEC10 00000050 082FED20 00000000 00000000 ! ...&............ > ! > _82FEC20 00000000 297ED1C6 00000050 29E55330 ! .....=JF...&.V.. > ! > _82FEC30 00000000 2B1D1B60 00000000 2B0DB74A ! .......-.......Ä > ! > _82FEC40 00000000 2B0DBB88 00000000 281B72A0 ! .......h........ > ! > _82FEC50 00000000 2B0DCD88 00000050 29D29640 ! .......h...&.Ko > ! > _82FEC60 00000050 29E2EB60 00000000 25218CF0 ! ...&.S.-.......0 > ! > _82FEC70 00000000 2B14D808 00000000 2B1D152A ! ......Q......... > ! > _82FEC80 00000000 2B0DBB88 00000000 281B72A0 ! .......h........ > ! > _82FEC90 00000000 2B0DCD88 00000050 29D29640 ! .......h...&.Ko > ! > _82FECA0 00000000 297ED0A2 00000000 297ED198 ! .....=üs.....=Jq > ! > _82FECB0 00000000 297ED180 00000000 297ED184 ! .....=J......=Jd > ! > _82FECC0 00000000 297ED188 00000000 297ED190 ! .....=Jh.....=J. > ! > _82FECD0 00000000 297ED194 00000000 00000000 ! .....=Jm........ > ! > > Registers at abend are : > > General purpose register values > 0-1 00000000_297ED194 00000050_082FEBF8 > 2-3 00000000_297ED0A2 00000000_297ED198 > 4-5 00000050_082FD940 00000000_00000000 > 6-7 00000000_2B14B778 00000000_2B1D9088 > 8-9 00000000_2B1D971E 00000000_281B72A0 > 10-11 00000000_2B1D9B58 00000050_29E55330 > 12-13 00000000_297ED188 00000000_297ED184 > 14-15 00000000_297ED180 00000000_24D50010 > > > > > Thanks in advance, Pierre. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
