At our shop we have a $VERSION line in each subroutine. We have a in-house
checkin process that updates the number. RL routines show up to. It helps
us to find differences in client code. Not real fancy. Anyway just some
ideas for you to ponder.
:VERSION PSSD08.XEQXL
VERSION C.60.00 Copyright (C) Hewlett-Packard 1987. All Rights Reserved.
PSSD08.XEQXL
SOM #1
@(#) HP30315 A.05.10 95/02/08 NRT0 Startup routine
PSSD08 VERSION: V95-00.11 LIST PART NUMBER INFO
PSSD08A VERSION: V95-00.11 REPORT PART INFO REQUESTED
PSSD08B VERSION: V95-00.11 DISPLAY PART DETAIL INFO
PSSD08B1 VERSION: V95-00.11 CURRENT PART QUANTITY ORDER
PSSD08C VERSION: V95-00.11 CONTROLS ASSEMBLY BOM LISTING
PSSD08D VERSION: V95-00.11 LIST BOM ASSEMBLY HEADER INFO
PSSD08E VERSION: V95-00.11 LIST ENG. AND MFG. ENG. NOTES
PSSD08F VERSION: V95-00.11 LIST DRAWING DOC NOTE RECORDS
PSSD08G VERSION: V95-00.11 DISPLAY ASSEMBLY REVISION LEVEL
PSSD08H VERSION: V95-00.11 LIST PRODUCT STRUCTURE RECORDS
PSSD08H1 VERSION: V95-00.11 DISPLAY DATA FOR LISTTYPE VALUE
PSSD08I VERSION: V95-00.11 LIST PSUEDO AND PARTS REPLACED
PSSD08J VERSION: V95-00.11 LIST PSUEDO AND PARTS REPLACED
PSSD08K VERSION: V95-00.11 DISPLAY A SINGLE LEVEL BOM
RL modules (this does not show up in the version MPE command)
BOMGET VERSION: V95-00.02 EBOM - DBGET FROM DATASET
BOMVALID VERSION: V95-00.02 FUNCTION TO VALIDATE EBOM TYPE
CFSSORT VERSION: V95-00.01 SORT A TEMPORARY FILE
GETTBL VERSION: V95-00.04 GET TABLE SWITCH VALUE
PARTLOOK VERSION: V95-00.04 SORTED PART LOOKUP (PNDSORT)
PSCHECK VERSION: V95-00.03 CHECK FOR PSEUDO OR REPLACE PART
RDMFG1 VERSION: V95-00.03 READ MFG FILE OR MFG1 DATASET
RDOPO1 VERSION: V95-00.09 READ OPO-DB1 AND CONVERT
RDOSO1 VERSION: V95-00.02 READ OSO-DB1
RDPND98 VERSION: V95-00.07 READ PND TO CURRENT BUFFER
RDPOM1 VERSION: V95-00.05 READ POM-DB1 BY PR-NUMBER
RDTCM1 VERSION: V95-00.01 READ TCM-DB1 BY INTERNAL TCN
REVLEVEL VERSION: V95-00.03 SCAN BEF FOR MAKE PART REV LEVEL
GETMSG VERSION: V95-00.06 GET MESSAGE TEXT FROM FILE
RDPSF1 VERSION: V95-00.02 READ PSF-DB1
MAX STACK SIZE: 393216
MAX HEAP SIZE: 81920000
CAPABILITIES: BA,IA,MR,DS,PH
UNSAT PROC NAME:
ENTRY NAME:
LIBRARY SEARCH LIST:
"Tom Emerson" <[log in to unmask]> wrote in message
news:abh2pe01an8@enews3.newsguy.com...
> A couple of thoughts come to mind, but they may be "fragile" workarounds
at
> best...
>
> > -----Original Message-----
> > From: Tad Bochan
> >
> > FYI, I have appended the HP documentation for $VERSION.
> > We have no issue with $version/migration since the $VERSION command
> > is currently dynamically created and doesnt appear in any source code.
> [snipped example]
> > ---------------------------------------------------
> > The above gives details of the source file and of some of the
> > include files which the program uses. (ie for each file, there is
> > Eof,CRC16,and ModDateTime. But alas, 255 bytes is not enough
> > space for all the include files and copy members.
> > The main purpose of the info is to make sure that we can find
> > the correct source code for a given piece of object code.
> >
> > $VERSION Command
> >
> [...]
> > $VERSION places the specified strings into the object file when the
> > program is compiled and linked. If you have more than one $VERSION
> > command in your program, only the last one is used.
>
> **important point**
> > If multiple source files make up a program file and there is a
> > $VERSION command for each, one $VERSION for each source file is used.
> /** important point**
>
> One suggestion this leads to is to create externally-compiled/linked files
> with no actual code, (or just a stub so it compiles) and just a series of
> "$version" statements built up to the 255 char limit per "file".
>
> [I'm thinking that what HP means by "multiple source files" are files that
> are seperately compiled & linked, however there was a recent discourse on
> the differences of $INCLUDE vs. COPY -- are "$included" files considered
> "multiple sources" so far as the compiler is concerned? Does the current
> version of COBOL allow for the concept of multiple 'files' contained
within
> one physical 'source file'? <a.k.a. cobol-2000 specs>]
>
> You also mentioned that this 255-character limit doesn't seem to apply to
> other compilers (C, for instance...) -- again, the same "idea" could be
> used, but instead of multiple COBOL sources, an external "C" module
compiled
> as "part of the program" that contains the full $VERSION information.
> (perhaps the "C" module would contain one function, such as
> "getprogversion", which returns a displayable string of the primary
version
> info you are interested in -- that should satisfy the compiler AND provide
a
> useful API to your programs...)
>
> Perhaps this idea is less fragile than I initially thought, because you
> indicate this is "dynamically created", so I take it this is built as part
> of the compilation job -- having the job "build" a foreign module (in
either
> C or COBOL) and compile/link it into the program is only one extra step
(as
> opposed to building it for $include purposes...)
>
> Tom
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
