There are a couple of emails I want to reply to. I'll try to put it into one.
> Also I would expect
> tsocmd -d "call *(asma90)"
Thank you! That does the trick. Somehow, ASMA90 was still executing without the
CALL but something got overwritten that messed up SYSIN. With the CALL it works
correctly.
> PS> Just put your sources into zFS you dinos :-)
My favorite comment! My sources are in a zFS but since I had issues with the
command, I put them back into data sets to avoid messing something up on "the
other side". After using CALL I changed all my allocations back to paths/files
;-)
> Why not use the z/OS UNIX "as" command?
Interesting! I didn't know this existed (the reason, I didn't use it).
I am going to investigate using it.
Part of the reason why I'm invoking ASMA90 using tsocmd is because it is going
to act as a blueprint for calling other compilers or preprocessors. I have
stumbled across many of these and being able to write a simple "USS wrapper"
that allows me to call them from USS helps a lot with integration. as and cob2
are two options of calling an IBM utility but not all these homegrown utilities
ship something like as or cob2.
> ... or write a Rexx wrapper to perform allocations with BPXWDYN() alloc and
> concat, then address LINKMVS ASMA90;
Intriguing. I feel like I only need this in case I want to pass data between
multiple steps. In my case, building a BMS map, I could use that to pass the
object file to the linker directly without persisting it to disk. Using my
tsocmd logic I get new allocations for each command so that wouldn't work.
Right now, tsocmd does the job for me but in case I need something more complex
I'll probably go down this route.
> Would that work alike with DSFS?
The thing with DSFS is that it simply exposes a data set as a UNIX path. If you
don't have a utility that can use native UNIX paths, it's not going to help
you. Doing PATH('/dsfs/rec/some/dataset') is obviously nonsense.
If cob2 or as or any other utility would only understand a path and we still
had the requirement to keep a file as a data set, DSFS comes in handy. A lot of
use cases in the "build" environment don't really have that requirement.
> ISHELL
Yeah, I don't bother using it. I log on using a regular SSH connection. ISHELL
and the OMVS command have always been a big no-no for me.
Cheers - David
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Paul Gilmartin
Sent: Wednesday, 5 February 2025 22:50
To: [email protected]
Subject: Re: Execute ASMA90 with tsocmd fails
CAUTION: This email originated from outside Living Mainframe. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
On Wed, 5 Feb 2025 21:38:51 +0000, Pew, Curtis G wrote:
>Probably? I haven’t had the need to start a new project of this type since
>DFSF was introduced.
>
>
I'm trying to envision make's suffix rules operating properly.
>On Feb 5, 2025, at 3:34 PM, Paul Gilmartin wrote:
>
>Would that work alike with DSFS?
>
The DSFS User's Guide ought to enumerate the commands that work properly with
data in DSFS.
--
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
