• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 961
  • Last Modified:

S/36 Migration to AS/400

All I am currently in the process of migrating to from a virtual S36
machine to a S36 Environment.  I have found that the software appears
to be using external Assembler subroutines or I assume that is what it
is doing.  The OPT Code is EXIT and when I did the RSTS36LIBM it
created a QS36SBR source file.  Most of the members have a type DFU36
but some have ASM36.  If I view the source file it look all garbled

Does anyone know how to create the subroutine object from this source
or can point me in the direction I need to go?

3 Solutions
Gary PattersonVP Technology / Senior Consultant Commented:
The RPG II EXIT opcode is used to execute an external subroutine.  

The QS36SBR file is created to hold compiled external subroutine members, and is not converted to anything usable in the AS/400 S/36 environment.  It is not source code.  It is object code - that's why it looks garbled.

Are you using the Migration Assistant?  The Migration Assistant will move these compiled assembler routines, but these are not supported in the S/36 Environment of OS/400.  It will also produce reports that will help you identify unsupported items like this that need to be dealt with prior to conversion.


How many different subroutines are called, and what are they?

Anyway, bottom line is these subroutines will need to be rewritten in order to convert from the SSP environment to OS/400 S/36 Environment.

- Gary Patterson
DCS12Author Commented:
So then there should be a source for these objects and if I can find the source then I could just copy it into the program as an internal subroutine.  Correct?
Gary PattersonVP Technology / Senior Consultant Commented:

First of all, there is no guarantee that you have source code - it may be part of a package, for example, that only shipped compiled subroutines.  

If you just follow the Migration Assistant and related documentation, it explains all of this, and the reports it generates will document all of your migration problems like this one.  It will also help you identify any other numerous troublesome migration items that you may encounter.

Depending on your environment, SSP to OS/400 S/36 Environment migration is not trivial: it is not as simple as just saving it on SSP and restoring it in the S/36 environment.  Please take an hour or two and give the Migration Assistant book I sent you a link to a good read before you do anything else.

If there is source for these objects, it is written in S/36 assembler,  which does you no good in the S/36 Environment under OS/400 (i5/OS, iOS,  whatever), since you can't

System 36 compiled objects (like these external subroutines) are not executable under OS/400.  This means that you need to recompile your programs.  The AS/400 S/36 environment includes an RPG II compiler that will compule most S/36 RPG code that runs under SSP.  It also includes an OCL interpreter, and a few other tools that enable you to make use of S/36 objects and source code.  

Unfortunately, there is no corresponding compiler (at least not any that I know of) for S/36 Assembler.  These routines you need to rewrite in some language that you can compile on an AS/400.

S/36 Compatible RPG Guide: http://publib.boulder.ibm.com/iseries/v5r1/ic2924/books/c0918180.pdf
System/36 Environment Programming: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/books/sc414730.pdf

- Gary Patterson
Building an Effective Phishing Protection Program

Join Director of Product Management Todd OBoyle on April 26th as he covers the key elements of a phishing protection program. Whether you’re an old hat at phishing education or considering starting a program -- we'll discuss critical components that should be in any program.

Gary is 100% correct.  That assembler has got to go.

The only thing the source will be good for is to help you figure out what it is doing.   Then you can replace that code with a supported language.

What are the names of the routines?  Who knows it might be something we have heard of.  They may have been supplied by IBM.

Gary PattersonVP Technology / Senior Consultant Commented:
Steve brings up a good point:

The IBM-supplied routines are numeric (SUBRnn), and are supported internally by the S/36 Environment RPG compiler, so they need no conversion.  These probably aren't what is giving you trouble, though.

IBM used to publish a guide that assisted in S/36 Assembler conversion: GC21-8160.  I  can't find it online, but you may be able to obtain a copy from IBM or somewhere.

- Gary
AFAIK, the SUBRxx subroutines can be implemented as normal i5/OS *PGM objects. The primary requirements are (a) getting the parameter interface correct, and then (b) getting the functioning correct. Many things that were difficult to do on a S/36 may be trivial on a reasonably current AS/400.

At least some commercial assembler SUBRxx subroutines were never brought over to OS/400 simply because they could be replaced by trivial programs by almost any average developer.

DCS12Author Commented:
Thanks for the help and clarification.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now