TomLiotta Aug 18, 2010   1:42 AM GMT

Perhaps if you tell us what you need to accomplish, we can suggest an alternative. Why do you need to replace it? Did it get lost? Is there some kind of licensing problem? What problem are you trying to solve? If it's a "non-IBM subroutine", it might be unfamiliar to everyone here. An example of how it is used might be helpful. Tom

125,585 pointsBadges:

Scyla6060 Aug 18, 2010   2:35 AM GMT

Let me see if I can fill in some of the blanks. "SUBRCP" is a S/36 machine language subroutine. I do not have the source, so I cannot recompile it on AS/400. The function of the subroutine is quite straight forward. When called, the subroutine returns cursor position on the screen, row number and column number. Note that we will be running System/36 environment on AS/400, not native mode.

100 pointsBadges:

TomLiotta Aug 18, 2010   5:57 AM GMT

Most was already understood. Only a couple things need comments. I do not have the source, so I cannot recompile it on AS/400. AFAIK, SUBRCP was a commercial subroutine. I don't think it is supported by the vendor anymore and I don't know that it was ever made available for the S/36 environment on AS/400s. Note that we will be running System/36 environment on AS/400, not native mode. This isn't totally clear. That is, are you now attempting to install an application from an actual S/36 onto a newly obtained AS/400 in order to run in the S/36 environment? Which "S/36 environment"? What model AS/400? What OS version/release? Depending on exactly what is going on, you might be interested in this quote:

• 7)If you aren't already on a AS/400, replace any assembler routines you may have (like SUBRCP to determine cursor position) with native implementations using the same name and your EXIT/RLABL will work without modification, You can then later change the calls to native CALL/PARM.

That comes from Re: RPG II to RPG/400 conversion, thread from back in 1997 on a closely related topic. If you can show an example usage (source code showing how SUBRCP is called/referenced), it might be fairly easy to get past your problem. Maybe. We can sure find out. Tom

125,585 pointsBadges:

Scyla6060 Aug 18, 2010   5:41 PM GMT

sspi, the company which supplied the original software, no longer distributes the SUBRCP subroutine. It only ran on SSP based S/36 machines. It was never designed to run under OS/400 in the System/36 environment. The new system will be an ISeries - 9406 - 800 and OS/400 V5R2M0. What I need is a function or subroutine (hopefully part of OS/400) that I can call from my System/36 programs running under System/36 environment.

100 pointsBadges:

Scyla6060 Aug 19, 2010   1:45 AM GMT

Here are the statements I am dealing with: 0877 * --- GETCSP- Determine Cursor Position ------------- 0878 CSR GETCSP BEGSR GETCSP 0879 CSR EXIT SUBRCP 0880 CSR RLABL ROW 40 0881 CSR RLABL COL 40 0882 CSR ENDCP ENDSR ENDCP 0883 C* Executing GETCSP will put the row and column location of the cursor into the fields ROW and COL..

100 pointsBadges:

TomLiotta Aug 19, 2010   6:42 AM GMT

If you can compile some source and test on an AS/400 in S/36 mode, I'll try to post code to return row/column -- subject to available time in the immediate future. I've never needed to link into a S/36 program before, but I can work around most error messages that you might run across. And one or two others here might be interested in jumping in. I did S/3, S/32/34/38 and many others; but somehow managed to miss S/36. Tom

125,585 pointsBadges:

Scyla6060 Aug 19, 2010   5:31 PM GMT

Your help would be greatly appreciated. I have compile the program under System/36 environment successfully. However, when I execute the program, I receive a message . "Call to program SUBRCP ended in error". There is no additional message saying what the nature of the error is. The job log says "Cannot resolve to object SUBRCP. Type and Subtype X'0201' Authority X'0000'." Thank you again for any help you can provide. Ron

100 pointsBadges:

TomLiotta Aug 20, 2010   0:41 AM GMT

Seeing your current error message was already helpful. Here is an absolute bare-bones test that is intended to determine basic requirements:

pgm    ( +
         &pRow        +
         &pColumn     +
       )

   dcl   &pRow        *dec  (  4 0 )
   dcl   &pColumn     *dec  (  4 0 )


   dcl   &Row         *char    4
   dcl   &Column      *char    4
   dcl   &hLoLvlEnv   *char    4
   dcl   &ErrCod      *char    8
   dcl   &RtnVal      *char    4


   callprc 'QsnGetCsrAdr'   ( +
                              &Row         +
                              &Column      +
                              x'00000000'  +
                              x'00000000'  +
                            ) +
                      rtnval( +
                              %bin( &RtnVal ) +
                            )

   chgvar         &pRow          %bin( &Row )
   chgvar         &pColumn       %bin( &Column )

   return

endpgm

It is ILE CL that should compile and run successfully on V5R2 (though I don't have anything that old available.) When called with an 5250 device session, it should return two values -- &pRow and &pColumn. Both values will be 4-digit packed-decimal. It should compile with a straight CRTBNDCL command. Ideally, it will be in a source member with an attribute of CLLE, but that shouldn't be required. It must be compiled as ILE CL. It can't be a CLP. Name the program SUBRCP. As far as what library to put the compiled *PGM into, I suppose the //LOAD library will be fine for testing.

CRTBNDCL PGM( loadlib/SUBRCP )
         SRCFILE( mylib/QCLSRC )
         SRCMBR( SUBRCP )

One likely error will that the parms should be defined as something other than *DEC ( 4 0 ). That will be evident either by a very incorrect row/column value or an actual decimal-data error. Until an error comes up, I can't tell what happens between the program and the "subroutine". Another likely error will be a 'hidden' parameter. That might take a few tries to track down. Not much I can add for now. Ask questions if needed. Tom

125,585 pointsBadges:

TomLiotta Aug 26, 2010   0:57 AM GMT

Any news? Questions? Clarification needed? Tom

125,585 pointsBadges:

Scyla6060 Aug 26, 2010   4:19 PM GMT

Good morning I have to say that I am a little lost. My experience is in S/36 not AS/400. My AS/400 activities have been limited system activities and converting to System/36 environment. I have been trying to get started on your solution and have been reading on-line manuals to try to get some knowledge. I will try to describe some of my problems (unknowns?). - I tried to key in the solution you sent to me but I do not have QCLSRC file in my libraries because they originated from S/36. When I tried to create the file, I was asked to give another library/file to give the characteristic and I did not have the information. - My programs are run from OCL procedures, not CL. Do you know if I can embed CL in OCL?

100 pointsBadges:

TomLiotta Aug 26, 2010   9:44 PM GMT

The source code is merely "source code". It can be placed into any normal source file in any standard library. The 'trick' will be when it is compiled, that's at the end of this. You might have a QCLSRC source file in the QGPL (General Purpose Library) that should exist on every AS/400. If you have the SEU Source Edit Utility, you should be able to run this command from any command line:

STRSEU SRCFILE(QGPL/QCLSRC) SRCMBR(SUBRCP) TYPE(CLLE) OPTION(2)

You might be able to copy/paste the command and press <Enter>. If you create a different source file in a different library, just remember the source file name and library for later. Once an edit session opens, you should be able to copy/paste blocks of the new source code into the edit screen. There will likely be two complications. First, the source is longer than a single edit screen page. That will require an extra step to get the second block of lines to open up in the edit session. If you are familiar with SEU, you can position the last line of code at the top of the window and then request a dozen additional lines to be 'I'nserted. That should open enough edit space to paste the next block of lines. (You can, of course, simply type lines one at a time.) But second, there are a few single-quote characters in the source. Those have a very good chance of not converting correctly from the character codes used by this web site to the codes used on your system. There are six single-quote marks that you might need to type over after you paste those lines. You might choose to paste into Notepad first and type "real" single-quotes over those six characters before pasting into SEU. Once the source is entered, you can use <F3> to exit the edit session. Press <Enter> to leave the Exit display that should appear. The Exit display might force you to go back into the edit session and make corrections, so don't be surprised if it happens. If you've made all the corrections that you can figure out, you can tell the Exit display not to put you back into edit mode by tabbing down to the "Return to editing" field and making it a 'N'. Once the source is entered, you can run the CRTBNDCL command from the earlier note. It might look this way now:

CRTBNDCL PGM( loadlib/SUBRCP )
         SRCFILE( QGPL/QCLSRC )
         SRCMBR( SUBRCP )

The source library would be QGPL in this case. I don't know what your S/36 "load library" is, but it should be whatever library has the program that calls this subroutine. That's the library that will contain the compiled version of this little program. Part of the whole deal is that CL is a compiled language on AS/400s. It's a very different kind of thing from OCL. You can create actual compiled programs that can be called by RPG programs or by any other language. Your RPG program (and your OCL) won't have any indication that "CL" is running. It's actually more than that because this is "ILE CL" which is quite a bit advanced beyond even the original AS/400 CL. But you don't need to know details of that yet. We're not even sure if we're on the right track yet. Once compiled into the load-library, it should get called as if it was object code in any other language. The results will tell us what direction to go next. Don't hesitate to ask for additional info or help. Tom

125,585 pointsBadges:

TomLiotta Aug 26, 2010   11:41 PM GMT

When I tried to create the file,... This part just caught my attention. The work can't reasonably be done from inside of the S/36 environment. That is, I think it's possible to get it done; but it would be awkward and likely to throw unanticipated error messages that might be tricky to track down. Do you have easy access to standard AS/400 command lines? Tom

125,585 pointsBadges:

Scyla6060 Aug 29, 2010   0:23 AM GMT

I have access to an AS/400 command line. The S/36 environment doesn't interfer with AS/400 commands. Ron

100 pointsBadges:

Scyla6060 Aug 31, 2010   1:34 AM GMT

I have compiled and tested the subroutine which you provided and have some results. So far I have only focused on the row value which is really the only one I need. The subroutine returns a value to my program. For cursor in row 8, the value returned to the ROW field is X'00008FF0'. I did a test bit operation on byte 3 which seemed to have a value that related to the row number and the returned values were the row number with an 'F' following (x'1F' for row 1, x'2F' for row 2, etc.). The problem comes at row 10 when I receive an "x-prog error". Any thoughts on this problem would be appreciated.

100 pointsBadges:

TomLiotta Aug 31, 2010   9:47 PM GMT

For cursor in row 8, the value returned to the ROW field is X’00008FF0′. Because of the 4th byte containing x'F0', it seems possible that the value needs to be returned as zoned-decimal instead of packed-decimal. So, try making these changes -- The parameter variables need to be changed to 4-byte character fields, and an intermediate variable needs to be defined as a temporary work variable:

   dcl   &pRow        *char    4
   dcl   &pColumn     *char    4

   dcl   &DecVal      *dec  (  4 0 )

Then at the end of the program, the two statements that place values into the parameter variables need to be replaced with these four statements:

   chgvar         &DecVal        %bin( &Row )
   chgvar         &pRow                &DecVal
   chgvar         &DecVal        %bin( &Column )
   chgvar         &pColumn             &DecVal

We could do it with less, but V5R2 has limits. And, again, this is intended to give back useful data. Comparison of these results against the previous results should point us directly at a solution. If these changes don't make sense, I can repost the entire routine. In short, two of the first variable declarations are replaced with three declarations; and two of the final instructions are replaced with four instructions. Tom

125,585 pointsBadges:

TomLiotta Sep 1, 2010   0:02 AM GMT

Although the improvement of skipping the &DecVar variable is perfectly okay, it could be useful to separate the %bin() function from any change to the parameter variable itself. In practice, the result should be the same. But during development/debugging, I like to touch parms only with elementary operations. Glad it worked! I'll see if I can supply a "real" solution now that we know the method itself can work. ILE CL at V5R2 doesn't quite cover some finer details. It sure is handy for prototyping most solutions. Tom

125,585 pointsBadges: