On Wed, 23 May 2018 13:00:22 +0000, Jousma, David wrote:
>
>>A .jar file _is_ a .zip file, but with some specified contents, such as a
>>"manifest". The JAVA "jar" command can create a file which a standard "unzip"
>>>utility can expand. It can also extract files from a standard zip file. That
>>is, it can act as a regular zip command. But a true .jar file must have the
>>.jar >extension and have the proper contents to be used by the java
>>executable.
>
>For us "dummies" though, uploading the file as-is isn’t enough. It has to be
>renamed to .jar for the supplied JCL to work correctly.
>
Why didn't the supplier, as a courtesy to the customer, deliver the file with
the needed extension and save that step?
>>Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you can
>>do a BINary download to a PC, then do a BINary upload to z/OS if you first do
>>a >"QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106".
>
>This is precisely what I am trying to avoid. I want to transmit my diags
>directly from z/OS.
>
Is there an obstacle to that? Don't the same commands work on z/OS FTP?
Or even shortcut with options on the BINARY command?
>Playing with this some more, and I think it was alrea y mentioned here is that
>AMATERSE does not allow SYSUT1 or SYSUT2 to be PATH statements either.
>
Here, the AMATERSE designers were obsessive. QSAM and BSAM handle PATH
just file. Let them do their job. In fact, UNPACK works if SYSUT1 is a
concatenation
of an empty Classic data set and a PATH.
There is, however, good reason not to support PATH for the unpacked operand.
That's what pax is for. AMATERSE should, however, allow (schematically):
pax -w | AMATERSE PACK
and:
AMATERSE UNPACK | pax -r
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
