Execute ECL in COBOL program
Frank Ney
execute ECL inside an ACOB program, but I can't remember it and I
can't seem to find it in my CD-ROM.
Someone jog my memory, please? Thanks.
George Ewins
On 7/15/03 5:07 PM, in article
ee24c354.03071...@posting.google.com, "Frank Ney"
sro
in acob, eracsf$
in ucob, eracsf
elauria
For facilities-type ECL you can use ERACSF$ as others have pointed
out. For the other ECL types, look up the executive request, QECL$.
Andrew Williams
Without having a copy of the ACOB manual in front of me, I think that it
is in Chapter 16 (System Interfaces).
I saw a posting earlier which now seems to have disappeared, where
someone indicated you could use ER QECL$ for non-CSF stuff (Look at the
Exec ER Manual to see what ER ACSF$ can do).
QECL$ - which you would have to write a Cobol interface for anyway - can
not be used like this. It allows you to queue calls to external
processors (like @ssg or whatever) but the calls do not take place until
your program terminates. This is not what you want.
PCFP offers an interface to the Furpur commands (Furpur itself uses it)
but that only works from UCOB (+ UFTN, UC and the rest), not ACOB.
--
opinions personal, facts suspect.
http://home.arcor.de/36bit/samba.html
noname
<andrew....@t-online.de> wrote:
>I saw a posting earlier which now seems to have disappeared, where
>someone indicated you could use ER QECL$ for non-CSF stuff (Look at the
>Exec ER Manual to see what ER ACSF$ can do).
>
>QECL$ - which you would have to write a Cobol interface for anyway - can
>not be used like this. It allows you to queue calls to external
>processors (like @ssg or whatever) but the calls do not take place until
>your program terminates. This is not what you want.
Yes, it's true, the calling program needs to terminate first
before the ECL statements could be executed. "This is not what
you want", but how did you arrive at this conclusion? Going by
the original post, I can't discern this requirement.
>PCFP offers an interface to the Furpur commands (Furpur itself uses it)
>but that only works from UCOB (+ UFTN, UC and the rest), not ACOB.
The OP's site might not have the pcfp package installed. And using
pcfp limits you to the FURPUR-type statements only. For other ECL
statements, pcfp won't help.
Andrew Williams
Stuff I see in Google does not get here).
This is cut-and pasted from Google.
> On Thu, 17 Jul 2003 18:23:17 +0200, Andrew Williams
> <andrew....@t-online.de> wrote:
>
>>I saw a posting earlier which now seems to have disappeared, where
>>someone indicated you could use ER QECL$ for non-CSF stuff (Look at the
>>Exec ER Manual to see what ER ACSF$ can do).
>>
>>QECL$ - which you would have to write a Cobol interface for anyway - can
>>not be used like this. It allows you to queue calls to external
>>processors (like @ssg or whatever) but the calls do not take place until
>>your program terminates. This is not what you want.
>
> Yes, it's true, the calling program needs to terminate first
> before the ECL statements could be executed. "This is not what
> you want", but how did you arrive at this conclusion? Going by
> the original post, I can't discern this requirement.
>
Wanting to execute ECL inside an ACOB program is an indication that the
command should be executed immediately, not later.
Apart from that, ER QECL$ has very few and very specific uses. If you
really want to schedule a program or 3 for subsequent execution from
within an ACOB program, you would normally write the whole lot to some
SDF file and then do an @ADD.
I have used QECL$, it's uses are really limited.
>>PCFP offers an interface to the Furpur commands (Furpur itself uses it)
>>but that only works from UCOB (+ UFTN, UC and the rest), not ACOB.
>
> The OP's site might not have the pcfp package installed. And using
> pcfp limits you to the FURPUR-type statements only. For other ECL
> statements, pcfp won't help.
1 - I said that PCFP covers FURPUR. Thank you for repeating that.
2 - I said that 'Furpur itself uses it' (PCFP). This means that if you
do not have PCFP installed then Furpur will normally not work. I say
'normally' because there is a way around this but no-one in their right
mind would take it. Take it as read that the OP has PCFP installed, or
an Exec-level predating (at a guess) 1997 which is when Furpur was
rewritten.
Finally, It will be possible to write a BM interface to PCFP. I am
pretty sure I could knock one together in a couple of weeks. FURPUR
itself is mostly BM.
No idea why postings are not getting through to T-Online's servers, but
I am cancelling this account from Monday on anyway.
Richard Steiner
Andrew Williams <andrew....@t-online.de> spake unto us, saying:
>I have used QECL$, it's uses are really limited.
It's more useful when used within an interactive program.
The CALL macro language's BREAKPOINT RELOAD statement used ER QECL$,
I believe, and that statement was quite useful when used in programs
such as UEDIT because it let the UEDIT user effectively "shell out" to
external processors (such as IACULL) and flip back to UEDIT when the
external processor was exited.
The CSHELL interface I added to UEDIT used the same mechanism, and
allowed a UEDIT user to execute most CSHELL aliases from inside the
editor. I found it useful, anyway...
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + BeOS + Linux + Win95 + DOS + PC/GEOS = PC Hobbyist Heaven! :-)
Now running in text mode on a PPro/200. Eat my dust, GUI freaks!
The Theorem Theorem: If If, Then Then.
andrew williams
data-structures to some disc (or fmem) file so that you can then
reload them on reentry.
You also have to have a way of checkpointing all open files.
This will have made excellent sense with your UEDIT (don't know it,
@FSED is my 1st choice) but this is not the sort of technique which is
going to be found in applications written by someone who cannot
remember the ERACFS$ call (which is his right, his skills will be
elsewhere). Actually, you could probably have used the SDF-File +
@add technique instead, but QECL$ is safer and more fun ;-)
One thing I used it for was an @udsmon redirector. The user said
@udsmon appoct,e
and the redirector (in sys$lib$*lib$) would generate
@uds$$oct*util$.udsmon appoct,e (util$ may be wrong)
The default for the application was appsvn.
It sounds like UEDIT is somewhere in the POSIX area, would it make
sense to use it in the 2200 world? Where is it to be found or
documented? (I am at home, my manuals are at work and I can't
remember an editor of that name).
InfoConnect gives me 4 screens so I just use another screen in
emergencies.
rste...@visi.com (Richard Steiner) wrote in message news:<38CG/oHpvWV...@visi.com>...
Keith Stone
> Finally, It will be possible to write a BM interface to PCFP. I am
> pretty sure I could knock one together in a couple of weeks. FURPUR
> itself is mostly BM.
Yes, there's a BM interface to PCFP. I don't know if Teamquest ever
looked at the code they sold as part of SA Utilities but there is an
amazing array of interfaces in there for the industrious person that
wants to read through all the definition files that are installed. Not
everything was documented because we didn't want to support it
officially, but since it formed the underpinnings of LA, MSAR, MS
Manager (and countless other tools for other vendors living and dead)
they work pretty good. Very good stuff for UPLS coding there that
works good with other Uxxx languages (or did at the time). If you look
close, you'll find some high speed EM block transfer routines that we
used developing a server based backup client for the 2200 that never
hit the market.
I have no idea if SA Utilities is still marketed. Joe can maybe fill
me in there.
andrew williams
maintained (the LA read-interface changed below the surface with CP IX
7.1). Joe would have to say if new features are being added.
kst...@crewstone.com (Keith Stone) wrote in message news:<6bbad151.0307...@posting.google.com>...
Richard Steiner
andrew....@t-online.de (andrew williams) spake unto us, saying:
>In order to use it that way, you have to 'checkpoint' all of your
>data-structures to some disc (or fmem) file so that you can then
>reload them on reentry.
Yes -- the CALL macro language does this transparently (at least to
the programmer using it).
Because of this, all of UEDIT's active editing windows, current L/F
strings, and all other portions of the "current" editing environment
are automagically saved on exit and restored upon re-entry.
Some snippets of code in UEDIT which illustrate how it does this are as
follows (this also illustrates a bit of CALL syntax):
[Much code removed for brevity...]
CASE line[1] = '#':
ecl := UPPER (line [2, *]) ;
clen := VERIFY (ecl, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ') ;
IF clen THEN
ecl := ecl [1, clen-1] ;
ENDIF ;
LOCATE ecl IN csf_type ;
IF ecl = csf_type (ELEMENTINDEX) AND (line [clen + 1] =
',' OR line [clen + 1] = ' ') THEN
res := EXEC ('@' || line [2, *]) ;
CASEENTRY res OF
CASE = 'SYNTAX ERROR':
CALL error ('Syntax error in @' || ecl || ' image.') ;
CASE = '000000000000000000000000000000000000':
CALL message ('Done.') ;
CASE *:
octal := '' ;
LOOP FOR i := 1 TO 36 BY 3 DO
octal ||= res[i]*4 + res[i+1]*2 + res[i+2] ;
ENDLOOP ;
CALL message ('@' || ecl || ' result status = ' ||
octal || '.') ;
ENDCASE ;
ELSE
line [1] := '@' ;
WRITE line ;
shell_message :=
'Leaving UEDIT -- Exit processor normally to return' ;
CALL auto_save (FALSE, TRUE) ;
shell_message := '' ;
ENDIF ;
CASE line[1] = '=':
WRITE '@CSHELL' ;
ecl := UPPER(line[2,*]) ;
WRITE ecl ;
shell_message :=
'Leaving UEDIT -- Type EXIT from CSHELL to return' ;
CALL auto_save (FALSE, TRUE) ;
shell_message := '' ;
CASE line[1] = '!':
WRITE '@CSHELL' ;
ecl := UPPER(line[2,*]) || ';EXIT' ;
WRITE ecl ;
shell_message :=
'Performing CSHELL command (control returns to UEDIT ' ||
'automagically when done)' ;
CALL auto_save (FALSE, TRUE) ;
shell_message := '' ;
[Much code removed for brevity...]
PROCEDURE auto_save (noexit, reload)
IF auto_limit THEN
auto_count := 0 ;
ENDIF ;
OPEN auto_file WRITE 'EDIT$AUTO.' ;
IF noexit THEN
BREAKPOINT INTO auto_file NOEXIT ;
ELSE
IF reload THEN
SET FULLSCREEN OFF ;
PRINT CONTROL 'D,@@END' ;
PRINT erase_display || fcc_null ;
PRINT shell_message ;
BREAKPOINT INTO auto_file RELOAD ;
ELSE
BREAKPOINT INTO auto_file ;
ENDIF ;
ENDIF ;
IF RECOVERED THEN
RETURN FALSE ;
ELSE
IF NOT noexit THEN
CALL reset_screen ;
IF reload THEN
clear_error_line := FALSE ;
CALL display_windows ;
ENDIF ;
ENDIF ;
RETURN TRUE ;
ENDIF ;
ENDPROC ;
>It sounds like UEDIT is somewhere in the POSIX area, would it make
>sense to use it in the 2200 world?
UEDIT is (or was) actually a relatively common 2200 editor (several of
us used it at the Unisys Airline Development/Support Center in Eagan
when I worked there, and some of us used it at Northwest Airlines).
It runs as a processor in DEMAND under OS2200.
Tim Radde and Chuck Caldarale each had slightly divergent versions of
UEDIT, and the one I maintained at NWA was initially based on Chuck's
UEDIT 4R2G, dated from the beginning of 1995.
---SNIP---
Brief Summary of UEDIT Features
* Supports the editing of multiple files or elements concurrently (each
file or element being edited is isolated in its own editing block).
* Supports "split screen" editing (two files, or two views of same file).
* Supports multiple "bookmarks" for each edited block, making it possible
to MARK places in each file you are editing and GO back to them later.
* Multiple commands may be entered at once from the home command region.
* Most processors can be "shelled" to interactively using the # prefix.
Special provision has been made for CSHELL users (! and = prefixes).
* Using the "A" option provides FULL recovery of previous editing session,
including all edited blocks, bookmarks, and locate/find strings.
* Function keys can be customized to perform almost any editor command(s).
--UNSNIP--
You can see how similar it is to FSED by its home command set:
--SNIP--
Home position commands (Page 1 of 5)
(blank) Advance one page.
+n Advance "n" lines; "+" => one page; "+H" => one half page.
-n Move back "n" lines; "-" => one page; "-H" => one half page.
n Move to the page starting with line "n".
GO Move to the page starting with a specified line number.
GOn Move to the page starting with line number stored in Bookmark n.
FIRST Move to the first page. TOP is a synonym.
LAST Move to the last page. BOTTOM is a synonym.
MARKn Mark current line to be returned to later using GOn. Value "n"
may be a letter from "A" through "E" (5 bookmarks), default = A.
SWITCH Mark current line and go to old marked line or specified line.
<n Move display window left "n" characters or columns.
>n Move display window right "n" characters or columns.
ON Turn on editor modes.
OFF Turn off editor modes.
SET Set values for editor parameters.
STATUS Display current mode and parameter settings.
Home position commands (Page 2 of 5)
OLD Begin editing an existing element.
NEW Begin editing a new (initially empty) element.
NAME Retrieve or change the file/element name of block being edited.
SAVE Save the current text.
EXIT Exit editor - save changes in active window(s).
@ADD Exit editor, save changes, @ADD the active block.
OMIT Leave editor - do not save changes.
L,LI Locate a line which contains a specified string.
LC,LCI Locate a group of lines, each containing a specified string.
F,FI Find a line which begins with a specified string.
FC,FCI Find a group of lines, each beginning with a specified string.
FN,FNI Find a line which does NOT start with a specified string.
SELECT Internally mark lines that contain a specified string (a la LC).
CAPTURE Create a new block containing lines marked by SELECT.
Home position commands (Page 3 of 5)
C,CI Replace one string with another in one or more lines.
D Delete one or more lines.
R Refresh the current page on the screen.
RESET Re-establish the screen display.
BLOCK Create a block from specific lines of the current file or element.
ADD Create a block with the text of a separate file or element.
EDIT Switch editing to another block.
NEXT/PREV Switch editing to current block + 1 (or -1) respectively.
DISPLAY Display a defined text block.
SITE @SYM a copy of the current or another block.
LNSITE Like SITE, but print the lines with line numbers.
SHOW Display a list of defined blocks and their file/element names.
IGNORE Clear the "changed" flag for a block.
REMOVE Remove a block, renumbering following blocks. Variants of this
command include REMU (remove all unnamed blocks) and REMZ
(remove all blocks with a length of zero).
Home position commands (Page 4 of 5)
HELP Display editor command descriptions.
UNHELP Remove previously loaded HELP text.
$ Execute an ECL command non-conversationally (breakpointed).
# Execute an ECL command conversationally and return.
= Execute a CSHELL command conversationally and stay in CSHELL.
! Execute a CSHELL command conversationally and return.
. Resubmit the last command line. (use HELP PERIOD for help)
PAUSE Wait for a command. Prevents terminal from timing out.
WAIT Same as PAUSE above.
DO Execute commands from a file or element.
TOC Create a block from the Table Of Contents of a program file.
COMPARE Compare lines of two blocks looking for differences.
SCROLL Start continuous scroll through block text.
SPLIT Split the window into two display windows (same as SET LINES 10).
UNSPLIT Return the editor to a single editor window (same as SET LINES).
Home position commands (Page 5 of 5)
Command prefixes may be used to change the window to which the command will
apply (A:, B:), and/or to restrict operation to either selected or unselected
lines only (S:, X:).
For more information about S: and X:, enter "SELECT".
For a description of how commands function when two windows are active (and
more information about A: and B:, enter "WINDOWS" (not Microsoft <grin>).
For a description of the use of numeric expressions in home position commands,
enter "EXPR".
For a list of commands which can be entered in the text region, enter "TEXT".
For a description of entering more than one command in the home position on a
single transmission and other details of home position commands, press XMIT.
--UNSNIP--
It also has a number of comments that operate directly in the edited
text area (type them preceded by an SOE and followed by a Xmit):
--SNIP--
These commands can be entered in the command region or the text region:
In Insert n blank lines following the text line.
IBn Insert n blank lines ahead of the text line.
Dn Delete the text line and n-1 following lines.
SB Start block definition at the text line.
EB End block definition at the text line.
EBD End block definition and delete block.
DB Delete block.
PBm Put a copy of block m following the text line.
TOP Place the text line at the top of the screen.
BOT Place the text line at the bottom of the screen.
APP Append the line to the previous line.
M Mark the line to be the target of a later GO command.
Variations of the M command are MA, MB, MC, MD, and ME.
The following commands can be entered only in the text region:
BLn Define a block of "n" lines starting at the SOE location.
SF Start a field or block at the SOE location.
EF End a field at the SOE location.
EFD End a field at the SOE location and delete it from the text.
DF Delete the field ending at the SOE location from the text.
EFE End a field at the SOE location and erase to (to spaces) in the text.
PF Insert a block as a field ahead of the SOE location.
RF Replace a field starting at the SOE location with a block.
< Make the column containing the SOE the left margin of the display.
> Make the column containing the SOE the right margin of the display.
R Refresh the line containing the SOE, and optionally following lines.
SPL Split the line into two lines at the SOE.
When text commands are entered in the text region, the position of the SOE
determines the current line if the command spans a line boundary. Unlike
other transmissions, the character under the cursor is ignored; you can type
commands in the text region without concern for the text which they overlay.
--UNSNIP--
Enough about UEDIT. :-)
The CALL macro language is an interpreted scripting language for OS2200
that is freely available on the UUSIG web site. Or was, anyway. I do
have the ZIP file saved somewhere if it isn't otherwise available, I
think, and probably CSHELL, but it used to be on a "Unisys Utilities"
collection there.
The CSHELL that I mentioned was written at Unisys Roseville for the
2200 as well, BTW, and is also coincidentally written in CALL. I can
provide documentation for that as well if you're interested, and I
think it's also freely available at the UUSIG site.
>Where is it to be found or documented? (I am at home, my manuals are
>at work and I can't remember an editor of that name).
I can send you an extensive Word document if you'd like (basically the
online UEDIT help file organized as a Word document).
noname
<andrew....@t-online.de> wrote:
>Wanting to execute ECL inside an ACOB program is an indication that the
>command should be executed immediately, not later.
Maybe you don't realize it, but I can think of at least
a couple of situations where terminating the program to
have the queued ECL processed might be useful. Lose
your tunnel vision. How can you claim to speak for the
original poster, do you him/her?
andrew williams
share? It turns out that we have a couple of versions dated December
1988 (4R1I) and February 1989 (4R1J).
rste...@visi.com (Richard Steiner) wrote in message news:<cGzG/oHpvaw...@visi.com>...
> Here in comp.sys.unisys,
--SNIP--
> UEDIT is (or was) actually a relatively common 2200 editor (several of
> us used it at the Unisys Airline Development/Support Center in Eagan
> when I worked there, and some of us used it at Northwest Airlines).
>
> It runs as a processor in DEMAND under OS2200.
>
> Tim Radde and Chuck Caldarale each had slightly divergent versions of
> UEDIT, and the one I maintained at NWA was initially based on Chuck's
> UEDIT 4R2G, dated from the beginning of 1995.
>
--SNIP--
Steve J. Martin
Andrew was just taking the original poster (Frank) at his word.
Frank said that he wanted to execute ECL _inside_ an ACOB program. He
did not say that he wished to queue ECL inside a program for execution
after the program terminates. Perhaps he meant this but, if so, he
should have said so. I don't see how we can fault Andrew for dealing
with the question based on the simple English meaning of its words.
The meaning of 'inside' is clear.
Cheers,
Steve J. Martin
Chuck Caldarale
news:995f2314.03072...@posting.google.com...
> Does anyone have a fairly new version of this editor which they could
> share? It turns out that we have a couple of versions dated December
> 1988 (4R1I) and February 1989 (4R1J).
Those are the Tim Radde versions. My version is missing a couple of his
capabilities, but has quite a few others. Haven't updated it in a while,
since the availability of CIFS on the 2200 makes it largely (but not
completely) superfluous. I'll e-mail you the ZIP file.
- Chuck
Richard Steiner
"Chuck Caldarale" <chuck.c...@unisys.com> spake unto us, saying:
>Those are the Tim Radde versions. My version is missing a couple of his
>capabilities, but has quite a few others. Haven't updated it in a while,
>since the availability of CIFS on the 2200 makes it largely (but not
>completely) superfluous. I'll e-mail you the ZIP file.
What is CIFS? Microsoft's file sharing protocol (a.k.a. "SMB")?
Chuck Caldarale
news:nqjH/oHpv2j...@visi.com...
Yes - we've implemented a CIFS server on the 2200. This allows 2200 files to
be accessed from any SMB client, which includes pretty much every desktop
platform on the planet. CIFS also provides a hierarchical file system and a
complete set of UNIX-like file system APIs (including COBOL-callable
versions). All normal OS 2200 files are directly accessible in CIFS and vice
versa.
Currently working on a CIFS client to allow 2200 programs to reach out and
scribble on someone...
- Chuck
andrew williams
rste...@visi.com (Richard Steiner) wrote in message >
Andy Wardle
the "reach out" capability for 2-3 years. So much for closed proprietary
mainframes :-)
"Chuck Caldarale" <chuck.c...@unisys.com> wrote in message
news:bfm37q$8f9$1...@si05.rsvl.unisys.com...
Richard Steiner
"Chuck Caldarale" <chuck.c...@unisys.com> spake unto us, saying:
>"Richard Steiner" <rste...@visi.com> wrote
>> "Chuck Caldarale" <chuck.c...@unisys.com> spake unto us, saying:
>>
>> What is CIFS? Microsoft's file sharing protocol (a.k.a. "SMB")?
>
>Yes - we've implemented a CIFS server on the 2200.
Hmmm. That would be tremendously useful, yes. I could use FTE or JFE
or something instead of UEDIT.
Keith Stone
> Yes - we've implemented a CIFS server on the 2200. This allows 2200 files to
> be accessed from any SMB client, which includes pretty much every desktop
> platform on the planet. CIFS also provides a hierarchical file system and a
> complete set of UNIX-like file system APIs (including COBOL-callable
> versions). All normal OS 2200 files are directly accessible in CIFS and vice
> versa.
>
> Currently working on a CIFS client to allow 2200 programs to reach out and
> scribble on someone...
Interesting. As someone that really liked using the Mac file system
because it was the only one that let me keep element/version names
intact, I'm curious how you handle mapping of
Qual*file(cycle).elt/version to //share/path/filename.
Marc Wilson
in <6bbad151.03072...@posting.google.com>::
Presumably //qual/file/cycle/elt/ver.<type>
Where <type> is SYM,REL,ABS etc?
--
Marc Wilson
___________________________________________________________________
Cleopatra Consultants Limited - IT Consultants - CoolICE Partner - MAPPER Associate
Tel: (44/0) 70-500-15051 Fax: (44/0) 870-164-0054
Mail: in...@cleopatra.co.uk Web: http://www.cleopatra.co.uk
___________________________________________________________________
MAPPER User Group mailing list: send *SUBSCRIBE to M...@cleopatra.co.uk
LX-i
//share/path/elt.version
So, WELCOME/HTML becomes WELCOME.HTML
(I think this is the way it worked - I only worked with CIFS a couple of
times, because we just recently got the OS that had it included in what
we got bought for us...)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ AIM: LXi0007 ~
~ _____ / \ | ~ E-mail: LXi...@Netscape.net ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please post if you wish to be contacted privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Frank Ney
> Andrew was just taking the original poster (Frank) at his word.
> Frank said that he wanted to execute ECL _inside_ an ACOB program. He
> did not say that he wished to queue ECL inside a program for execution
> after the program terminates.
Geez, I didn't expect a simple question and answer to turn into a
flamewar.
Yes, I wanted to execute ECL during an @XQT. I needed to cat and asg
a +1 output file, (or just asg and open extend) based on time of day.
Ken Grubb
> I wanted to execute ECL during an @XQT.
See the CALL 'ERACSF$' statement in the ASCII COBOL manual, section 18.8.1
Your ECL statement goes in data-name-1.
HTH,
Ken Grubb
Lower Paxton Twp, PA
Chuck Caldarale
news:6bbad151.03072...@posting.google.com...
>
> Interesting. As someone that really liked using the Mac file system
> because it was the only one that let me keep element/version names
> intact, I'm curious how you handle mapping of
> Qual*file(cycle).elt/version to //share/path/filename.
Sorry for the long delay in replying - had to make the annual pilgrimage to
Oshkosh, among other things. (Burt Rutan gave a great talk on affordable
manned space flight. Very, very impressive.)
In any event, to answer your question, the mapping from the API point of
view is:
/os2200/[mfd#]qual/file[(cycle)]/elt.ver[.type]
where type is only used for rel, abs, or omn. The period before ver is
omitted if ver is blank and there is no type. You may use non-ECL spellings
and component lengths from the elt level and downwards, and anywhere not in
the /os2200 hierarchy. You may also create subdirectories anywhere. From the
network, the UNC equivalent depends on where you attach a share name in the
hierarchy. If a share name were attached to the qual, the path would be:
\\host\share\file[(cycle)]\elt.ver[.type]
The package includes a complete set of UNIX/POSIX-like file system APIs (not
just the ones for the C standard), and a command line processor that accepts
UNIX or Windows commands (e.g., both ls and dir). This lot runs in
conjunction with URTS, not in place of it, so there's none of this running
in OPE or POSIX mode silliness. The forthcoming 5R1 level includes the
aformentioned client, COBOL- and PLUS-callable APIs, and a ZIP utility.
- Chuck