HP3000-L Archives

August 2005, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Duane Percox <[log in to unmask]>
Reply To:
Duane Percox <[log in to unmask]>
Date:
Tue, 23 Aug 2005 17:09:16 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (39 lines)
Brian writes:

>Also, I was looking at your $control statements, two of which
>would appear to conflict with each other :
>
>>$CONTROL USLINIT, SUBPROGRAM, SOURCE
>
>USLINIT only applies to CM *MAINLINE* programs and subprogram
>is for subroutines (duh!)

USLINIT is ignored by the NM cobol compiler so there is no harm
in leaving it in...

Also, depending on your method of compiling cm code and library
management you might find a need to use uslinit for cm subprogram code.

This is because when you compile cm code into a usl file the compiler
marks the old version of the code as deleted and adds the new code.
Eventually you will fill up this file and get an error in the compile, but
with uslinit you always get a fresh file.

The big warning on uslinit is when you compile a subprogram and direct
the object code to be put into an existing library of code you will wipe
out that code and be left with only your subprogram code. However, if you
use segmenter with usl/auxusl and associated commands to manage separately
compiled subprograms as independent usl files then it makes sense to use
uslinit.

But, this is all moot unless you are still doing CM development...

In fact I bet there are developers on the 3000 who never did CM stuff and
don't
even know the SEGMENTER command (SEGDVR.PUB.SYS) :-)

duane

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2