Welcome Guest [Log In] [Register]
Bookmark and Share
Welcome to LawsonTalk. We hope you enjoy your visit.


You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free. After registration, please check your e-mail within 24 hours for an message from us, read it, and reply to it.


Join our community!


If you're already a member please log in to your account to access all of our features:

Username:   Password:
Add Reply
Cobol Programs
Topic Started: May 3 2006, 07:02 AM (3,892 Views)
John Polito
Member Avatar
Newbie
[ * ]
Sorry to ask this question, but can someone tell me if there is a command in Lawson that will tell me all of the modules that a program needs to compile.
I need to find out where some of the FD's and SD's are stored. But it would come in handy for other things i have to research.
You see I have coded cobol programs for 24 years but it has all been on a mainframe, and let me tell you its alot easier to figure out where copybooks are located.

Thanks for anybodys help.

John
Offline Profile Quote Post Goto Top
 
schroncd
Member Avatar
Lawson Technorati
[ *  *  *  *  *  *  *  * ]
There's a script on my website (how many mesages have I started that way?) called cmp_lib.sh that will list or compile all the programs and modules associated to a particular library - it may help you out.
[
Offline Profile Quote Post Goto Top
 
John Polito
Member Avatar
Newbie
[ * ]
Thanks schroncd, that is a great tool, and i will be able to use it, but what i'm looking for is all the pieces that it takes to create the obj module when i compile a program. Lets take PR140. I know it has the pr140pd, pr140ws, prdedcalc and so on, it's the so on i need. When i look at a compile listing i can see alot to working storage and procedure stuff but i don't know where that information is located, Such as FD's and SD's ect....
Offline Profile Quote Post Goto Top
 
wsb2624
Newbie
[ * ]
run a bldsh on the compile - this will create a program shell that you can view
Offline Profile Quote Post Goto Top
 
ranjitd
Newbie
[ * ]
There is a utility called info3 that comes along with the UNIX version of lawson, which will help you find the copybooks,

here is the command
$>info3 <productline>
eg info3 patch810

this will bring a few search options, for your purpose it will be option 24 (finds all the modules used in a program)

give 24 at the prompt and it will ask you for the program name, give the program name and press enter and it will give you the list of all the modules used in the program.

once you have the name of the module you can do a search within the corresponding productline lib to get the location.

eg patch810$> find . -name MODULE1

the first two letters of the module, gives a fair idea to which system/module the copybook belongs , for
ex MA90XXXPD , will be within the 'ma'pdlib of 'ma'src.

B)
Offline Profile Quote Post Goto Top
 
Phil Feller
Advanced Member
[ *  *  * ]
Are you sure that info3 isn't a function and collection of shell scripts that your admin created (typing functions, or typeset -f, at the command line will list all shell functions that are defined for you)? We don't have it on our system, the Lawson KB makes no mention of it, and it doesn't sound like anything that I ever encountered (going back to Universe 2.1).

You could easily write a shell script that would do what Johhn wants. The guts of it would be something like:

rngdbdump -nt gen pgmlib -f libname \
-v productline=PROD systemcode=HR programcode=HR11 \
| while read lib
do
find $LAWDIR/prod -name $lib
done

I may try fleshing this out (in which case I will both report back here and send the script to Dave for his web site). This obviously only looks for pdlibs, and not any corresponding wslibs in gen/libraryws.
Offline Profile Quote Post Goto Top
 
trezaei
Member Avatar
LawsonTalk Addict!
[ *  *  *  *  *  *  * ]
I don't know if this will give you what you're looking for but the lstinvk utility shows you all the programs that are invoked by a particular program.

lstinvk

Usage: Print Compile Script For Programs Which Use 4GL INVOKE
Syntax: lstinvk [-qDT] ProductLine Invoked/Invoking ProgramCode
q - submit list to qcompile
D - compile for debug
T - compile for trace

And you can send a compile command to all of them as well.

But your question, "... all of the modules that a program needs to compile" is maybe a little confusing. I am not sure what you mean by modules. A typical online program basically only needs a PD, WS, and .scr. Batch programs have all the above and a .rpt file in addition. Other than that ( and the program definition in pgmdef) you really don't need anything else to create a compiled object using qcompile or loccmp.

Oh and this is a perfect place to ask your question so I am sure you'll get it answered.

One thing to keep in mind is that the Lawson 4GL is actually a lot simpler than it looks. You don't need to be all that concerned about the COBOL behind the scenes, and as useful as your 24 years is, its probably working against you somewhat right now.

Best way to learn is by example. Tell us what you're trying to accomplish and we can tell you how we went about getting it done.

Good luck :console:
Offline Profile Quote Post Goto Top
 
Phil Feller
Advanced Member
[ *  *  * ]
Because John mentioned copybooks, and specifically cited prdedcalc as an example of what he wanted to find for pr140, I assume that he means the pd and ws libs.

I wrote a Korn shell script that seems to do this for both 8.0.3 and 8,1 applications:

typeset -u pl pgm
pl=$1
pgm=$2

# Find the system code for the program; no need to have to remember it
sys=$(rngdbdump -ipgmset2 -nt gen program -f systemcode \
-v productline=${pl} programcode=${pgm})

# Find all pdlibs used by the program
rngdbdump -nt gen pgmlib -f libname \
-v productline=${pl} systemcode=${sys} programcode=${pgm} \
| while read ws
do
echo ${ws}

# Find all wslibs used by the pdlib
rngdbdump -nt gen libraryws -f wslibname \
-v productline=${pl} libname=${lib}
done | sort -u | while read lib
do
typeset -l pl

# Could use 'find ${LAWDIR} -name ${lib}', except that work and print
# directories with a lot of files would make the find very slow

# Location of 8.1 application libs
if [ -f ${LAWDIR}/${pl}/??src/????lib/${lib} ]; then
ls ${LAWDIR}/${pl}/??src/????lib/${lib}
fi
# Location of 8.0 application libs
if [ -f ${LAWDIR}/${pl}/??lib/${lib} ]; then
ls ${LAWDIR}/${pl}/??lib/${lib}
fi
# Location of common libs
if [ -f ${LAWDIR}/??lib/${lib} ]; then
ls ${LAWDIR}/??lib/${lib}
fi
done
Offline Profile Quote Post Goto Top
 
Phil Feller
Advanced Member
[ *  *  * ]
Oops, wouldn't you know that there was one mistake that kept ws libs from being reported. The real script is:

typeset -u pl pgm
pl=$1
pgm=$2

# Find the system code for the program; no need to have to remember it
sys=$(rngdbdump -ipgmset2 -nt gen program -f systemcode \
-v productline=${pl} programcode=${pgm})

# Find all pdlibs used by the program
rngdbdump -nt gen pgmlib -f libname \
-v productline=${pl} systemcode=${sys} programcode=${pgm} \
| while read pd
do
echo ${pd}

# Find all wslibs used by the pdlib
rngdbdump -nt gen libraryws -f wslibname \
-v productline=${pl} libname=${pd}
done | sort -u | while read lib
do
typeset -l pl

# Could use 'find ${LAWDIR} -name ${lib}', except that work and print
# directories with a lot of files would make the find very slow

# Location of 8.1 application libs
if [ -f ${LAWDIR}/${pl}/??src/????lib/${lib} ]; then
ls ${LAWDIR}/${pl}/??src/????lib/${lib}
fi
# Location of 8.0 application libs
if [ -f ${LAWDIR}/${pl}/??lib/${lib} ]; then
ls ${LAWDIR}/${pl}/??lib/${lib}
fi
# Location of common libs
if [ -f ${LAWDIR}/??lib/${lib} ]; then
ls ${LAWDIR}/??lib/${lib}
fi
done
Offline Profile Quote Post Goto Top
 
Milo
Member Avatar
Rebmem Member
[ *  *  *  *  *  *  * ]
John, here's my 2-cents'-worth:

You asked:
> what i'm looking for is all the pieces that it takes to create the
> obj module when i compile a program

That isn't really possible automatically, and I'll explain why. When I want to see "All The Cobol", I use Qcompile command's "-l" flag to create a listing. This shows all of the COBOL which will be compiled to create the program.

Going back to the PD module: I manually trace through to find where subroutines are referenced. If I don't find the subroutine in the PD itself, I usually 'grep' for the subroutine through the entire source directory's PD files. When I don't find the subroutine there, I go to the ..\pdlib directory, and look for the subroutine there. That gets me the file that the subroutine is in.

If I don't find any reference to that subroutine at all, then it is something that the system will add automatically. That requires checking the API (Application Program Interface) manual. For instance, if a file is referenced by including a search: PERFORM 850-FIND-NLT-CDFSET1, that single statement will tell the pre-compiler to include all statements and modules necessary to create the lookup, add, and delete subroutines in the Procedure Division, along with the necessary data structures in the Data Division, for the appropriate data file (in this case, CDF = CUSTDEFLTS file). I find them all there when I check the final COBOL listing!

But wait, there's more!

If you create a "User Exit Program", it is automatically invoked by the program, but must be compiled separately. Look for more information in the ADW Standards Guide. The program will kick in if it's there, but won't if it isn't there.

Now, to make it worse:

Some of the programs that I've investigated are object-oriented. I don't remember which ones, but I do remember finding a PD in a ~src subdirectory, which linked via a subprogram to a PD in ..\pdlib, which then invoked another program which ran back in the original ~src subdirectory, which in turn linked via a subprogram to another PD in the ..\pdlib subdirectory ... yes, that's four (4) different PD's that I had to look at to figure out what the code was doing!

And now, for the crowning piece of information that will blow your mind: :bonk:

When you run your program, the information coded into the screens, such as access to Screen Rules and Object Rules (via the Key Number system), and select lists coded directly into the screen, are not invoked by the COBOL at all. They operate on a layer that rides above the COBOL. They are invoked either by Portal / Information Office routines, or by the LID session, but have nothing to do directly with the COBOL. They are used for lookup, data validation, and for controlling input. So no matter what the COBOL says or does, that won't tell you everything that's going on, you have to check the screen layer also.

That's just the condensed version of what I've been learning for the last 5+ years. If you know COBOL, you still will have a lot to learn about the Lawson system.

And btw, you can't do a CASE statement (in COBOL it's the SWITCH construct) because Lawson won't allow it. For some reason it's too advanced for Lawson, even though they use sophisticated object-oriented techniques. Every time I've tried it, the compiler blows up. :banghead:

I hope that this gives you something to think about! :)
Offline Profile Quote Post Goto Top
 
« Previous Topic · Coding, Program Errors and Bugs · Next Topic »
Add Reply