|
Hi All,
Is there a way to create a Virtual Tape on a QNTC share, I have tried in the past but been plagued by Authority issues, even though the user had full access to the share itself, able to copy files etc using the cpy cmd, It seems the issue is when using the command to create the virtual tape it uses Qsecofr to create the object and not the logged on user!
Paul Crow
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of midrange-l-request@xxxxxxxxxxxx
Sent: 16 August 2017 10:36
To: midrange-l@xxxxxxxxxxxx
Subject: MIDRANGE-L Digest, Vol 16, Issue 1295
Send MIDRANGE-L mailing list submissions to
midrange-l@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/midrange-l
or, via email, send a message with subject or body 'help' to
midrange-l-request@xxxxxxxxxxxx
You can reach the person managing the list at
midrange-l-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific than "Re: Contents of MIDRANGE-L digest..."
*** NOTE: When replying to this digest message, PLEASE remove all text unrelated to your reply and change the subject line so it is meaningful.
Today's Topics:
1. RE: access API from CLLE (Justin Taylor)
2. RE: access API from CLLE (Paul Therrien)
3. Secured txt file (Gad Miron)
4. Re: Secured txt file (Jack Woehr)
5. Re: Secured txt file (Tim Bronski)
6. Re: Secured txt file (Jonathan Wilson)
----------------------------------------------------------------------
message: 1
date: Tue, 15 Aug 2017 17:07:27 +0000
from: Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
subject: RE: access API from CLLE
Perfect, thank you!
I never would have thought to put the procedure name in quotes.
-----Original Message-----
From: Scott Klement [mailto:midrange-l@xxxxxxxxxxxxxxxx]
Sent: Monday, August 14, 2017 5:47 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: access API from CLLE
Hi Justin,
On 8/14/2017 4:57 PM, Justin Taylor wrote:
Can anyone share a sample of the access() IFS API from CLLE?
Sure, here's an example that I already had laying around... not sure what I originally wrote this for, but I think it illustrates things well enough.
PGM
DCL VAR(&RtnVar) TYPE(*INT) LEN(4)
DCL VAR(&Null) TYPE(*CHAR) LEN(1) VALUE(X'00')
DCL VAR(&SomeFile) TYPE(*CHAR) LEN(64)
DCL VAR(&Mode) TYPE(*INT) LEN(4) VALUE(0)
DCL VAR(&ErrPtr) TYPE(*PTR)
DCL VAR(&Errno) TYPE(*INT) LEN(4) +
STG(*BASED) BASPTR(&ErrPtr)
DCL VAR(&MsgNo) TYPE(*DEC) LEN(4 0)
DCL VAR(&MsgNoC) TYPE(*CHAR) LEN(4)
DCL VAR(&MsgId) TYPE(*CHAR) LEN(7)
DCL VAR(&F_OK) TYPE(*INT) LEN(4) VALUE(0)
DCL VAR(&R_OK) TYPE(*INT) LEN(4) VALUE(4)
DCL VAR(&W_OK) TYPE(*INT) LEN(4) VALUE(2)
/* DCL VAR(&X_OK) TYPE(*INT) LEN(4) VALUE(1) */
CHGVAR VAR(&SomeFile) VALUE('/qibm/ProdData/Access/Windows+
/Install/Image/SETUP.EXE' *TCAT &NULL)
/*===================================== */
/* Check for file existence */
/*===================================== */
CALLPRC PRC('access') PARM((&SomeFile) +
(&F_OK *ByVal)) +
RTNVAL(&RtnVar)
if (&RtnVar *EQ 0) do
SNDPGMMSG MSG('Exists' *bcat &SomeFile)
enddo
ELSE DO
CALLPRC PRC('__errno') RTNVAL(&ERRPTR)
CHGVAR VAR(&MSGNO) VALUE(&ERRNO)
CHGVAR VAR(&MSGNOC) VALUE(&ERRNO)
CHGVAR VAR(&MSGID) VALUE(CPE *TCAT &MSGNOC)
SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGTYPE(*DIAG)
SNDPGMMSG MSG('Error, see diagnostic message')
enddo
/*===================================== */
/* Check for read/write access */
/*===================================== */
CHGVAR VAR(&Mode) VALUE(&R_OK + &W_OK)
CALLPRC PRC('access') PARM((&SomeFile) +
(&Mode *ByVal)) +
RTNVAL(&RtnVar)
if (&RtnVar *EQ 0) do
SNDPGMMSG MSG('You have read & write access!')
enddo
ELSE DO
CALLPRC PRC('__errno') RTNVAL(&ERRPTR)
CHGVAR VAR(&MSGNO) VALUE(&ERRNO)
CHGVAR VAR(&MSGNOC) VALUE(&ERRNO)
CHGVAR VAR(&MSGID) VALUE(CPE *TCAT &MSGNOC)
SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGTYPE(*DIAG)
SNDPGMMSG MSG('Error, see diagnostic message')
enddo
ENDPGM
------------------------------
message: 2
date: Tue, 15 Aug 2017 17:12:29 -0400
from: "Paul Therrien" <paultherrien@xxxxxxxxxxxxxxxxxx>
subject: RE: access API from CLLE
Kudos and appreciation to David Gibbs and all the contributors on this site.
The below exchange came just at the right time for a program I am writing.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Justin Taylor
Sent: Tuesday, August 15, 2017 1:07 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: access API from CLLE
Perfect, thank you!
I never would have thought to put the procedure name in quotes.
-----Original Message-----
From: Scott Klement [mailto:midrange-l@xxxxxxxxxxxxxxxx]
Sent: Monday, August 14, 2017 5:47 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: access API from CLLE
Hi Justin,
On 8/14/2017 4:57 PM, Justin Taylor wrote:
Can anyone share a sample of the access() IFS API from CLLE?
Sure, here's an example that I already had laying around... not sure what I originally wrote this for, but I think it illustrates things well enough.
PGM
DCL VAR(&RtnVar) TYPE(*INT) LEN(4)
DCL VAR(&Null) TYPE(*CHAR) LEN(1) VALUE(X'00')
DCL VAR(&SomeFile) TYPE(*CHAR) LEN(64)
DCL VAR(&Mode) TYPE(*INT) LEN(4) VALUE(0)
DCL VAR(&ErrPtr) TYPE(*PTR)
DCL VAR(&Errno) TYPE(*INT) LEN(4) +
STG(*BASED) BASPTR(&ErrPtr)
DCL VAR(&MsgNo) TYPE(*DEC) LEN(4 0)
DCL VAR(&MsgNoC) TYPE(*CHAR) LEN(4)
DCL VAR(&MsgId) TYPE(*CHAR) LEN(7)
DCL VAR(&F_OK) TYPE(*INT) LEN(4) VALUE(0)
DCL VAR(&R_OK) TYPE(*INT) LEN(4) VALUE(4)
DCL VAR(&W_OK) TYPE(*INT) LEN(4) VALUE(2)
/* DCL VAR(&X_OK) TYPE(*INT) LEN(4) VALUE(1) */
CHGVAR VAR(&SomeFile) VALUE('/qibm/ProdData/Access/Windows+
/Install/Image/SETUP.EXE' *TCAT &NULL)
/*===================================== */
/* Check for file existence */
/*===================================== */
CALLPRC PRC('access') PARM((&SomeFile) +
(&F_OK *ByVal)) +
RTNVAL(&RtnVar)
if (&RtnVar *EQ 0) do
SNDPGMMSG MSG('Exists' *bcat &SomeFile)
enddo
ELSE DO
CALLPRC PRC('__errno') RTNVAL(&ERRPTR)
CHGVAR VAR(&MSGNO) VALUE(&ERRNO)
CHGVAR VAR(&MSGNOC) VALUE(&ERRNO)
CHGVAR VAR(&MSGID) VALUE(CPE *TCAT &MSGNOC)
SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGTYPE(*DIAG)
SNDPGMMSG MSG('Error, see diagnostic message')
enddo
/*===================================== */
/* Check for read/write access */
/*===================================== */
CHGVAR VAR(&Mode) VALUE(&R_OK + &W_OK)
CALLPRC PRC('access') PARM((&SomeFile) +
(&Mode *ByVal)) +
RTNVAL(&RtnVar)
if (&RtnVar *EQ 0) do
SNDPGMMSG MSG('You have read & write access!')
enddo
ELSE DO
CALLPRC PRC('__errno') RTNVAL(&ERRPTR)
CHGVAR VAR(&MSGNO) VALUE(&ERRNO)
CHGVAR VAR(&MSGNOC) VALUE(&ERRNO)
CHGVAR VAR(&MSGID) VALUE(CPE *TCAT &MSGNOC)
SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGTYPE(*DIAG)
SNDPGMMSG MSG('Error, see diagnostic message')
enddo
ENDPGM
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
------------------------------
message: 3
date: Wed, 16 Aug 2017 08:28:26 +0300
from: Gad Miron <gadmiron@xxxxxxxxx>
subject: Secured txt file
Hello pundits
Need advice with the following:
I'm asked to create on the i a "payment instructions" text file to be sent to our bank.
The actual uploading of the file to the bank is done by a special secured *PC based* software.
When testing the process someone pointed to me the need to prevent any user (i user or domain user) from changing the content of this text file.
I can create a txt file on the IFS and deny i users access to it (using
CHGAUT)
BUT when the file is copied from the IFS to the user's PC in order to send it to the bank then the access restrictions on the i are no longer valid.
I guess it is worth mentioning that we do not use SSO (Single sign on) for accessing the i
TIA
Gad
------------------------------
message: 4
date: Tue, 15 Aug 2017 23:32:03 -0600
from: Jack Woehr <jwoehr@xxxxxxxxxxxxxxxxxxxxxxxx>
subject: Re: Secured txt file
Encrypt.
On Tue, Aug 15, 2017 at 11:28 PM, Gad Miron <gadmiron@xxxxxxxxx> wrote:
Hello pundits
Need advice with the following:
I'm asked to create on the i a "payment instructions" text file to be
sent to our bank.
The actual uploading of the file to the bank is done by a special
secured *PC based* software.
When testing the process someone pointed to me the need to prevent any
user (i user or domain user) from changing the content of this text file.
I can create a txt file on the IFS and deny i users access to it
(using
CHGAUT)
BUT when the file is copied from the IFS to the user's PC in order to
send it to the bank then the access restrictions on the i are no
longer valid.
I guess it is worth mentioning that we do not use SSO (Single sign on)
for accessing the i
TIA
Gad
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
--
Absolute Performance, Inc.
12303 Airport Way, Suite 100
Broomfield, CO 80021
NON-DISCLOSURE NOTICE: This communication including any and all attachments is for the intended recipient(s) only and may contain confidential and privileged information. If you are not the intended recipient of this communication, any disclosure, copying further distribution or use of this communication is prohibited. If you received this communication in error, please contact the sender and delete/destroy all copies of this communication immediately.
------------------------------
message: 5
date: Wed, 16 Aug 2017 09:48:51 +0200
from: Tim Bronski <tim.bronski@xxxxxxxxx>
subject: Re: Secured txt file
Hi Gad,
You don't say whether confidentiality is needed as well as integrity or how the process on the PC will work. That said, a solution to detect changes would be to create a PGP detached signature file and send that with the original file to the PC. The PC process would need to perform a signature check immediately before sending to the bank. This involves no encryption so the contents of the original file aren't modified and no key or password is required on the PC end.
Tim
On 8/16/2017 7:28 AM, Gad Miron wrote:
Hello pundits
Need advice with the following:
I'm asked to create on the i a "payment instructions" text file to be
sent to our bank.
The actual uploading of the file to the bank is done by a special
secured *PC based* software.
When testing the process someone pointed to me the need to prevent any
user (i user or domain user) from changing the content of this text file.
I can create a txt file on the IFS and deny i users access to it
(using
CHGAUT)
BUT when the file is copied from the IFS to the user's PC in order to
send it to the bank then the access restrictions on the i are no
longer valid.
I guess it is worth mentioning that we do not use SSO (Single sign on)
for accessing the i
TIA
Gad
--
Need sFTP or PGP? Download your native sFTP or OpenPGP solutions here:
www.arpeggiosoftware.com
---
This email has been checked for viruses by AVG.
http://www.avg.com
------------------------------
message: 6
date: Wed, 16 Aug 2017 09:35:24 +0000
from: Jonathan Wilson <piercing_male@xxxxxxxxxxx>
subject: Re: Secured txt file
On Wed, 2017-08-16 at 08:28 +0300, Gad Miron wrote:
Hello pundits
Need advice with the following:
I'm asked to create on the i a "payment instructions" text file to be
sent to our bank.
The actual uploading of the file to the bank is done by a special
secured *PC based* software.
When testing the process someone pointed to me the need to prevent any
user (i user or domain user) from changing the content of this text file.
I can create a txt file on the IFS and deny i users access to it
(using
CHGAUT)
BUT when the file is copied from the IFS to the user's PC in order to
send it to the bank then the access restrictions on the i are no
longer valid.
I guess it is worth mentioning that we do not use SSO (Single sign on)
for accessing the i
Could you just have the requirement that the file should be loaded/transmitted from a mapped drive and/or full url? The application would load the file (which after creation would be made read only on the
i) from (for example) smb:myIserver\securefolder\thisfileisreadonly.txt?
(1)
Obviously that would require the user not to copy the file locally, edit it, and then transmit the local copy... but if there is an application involved which requires user input (via gui or command line foo) then there has to be some level of trust.
Obviously if the raw file contains some kind of checksumming then, theoretically, it would be harder to edit the file and have it pass the pc applications validation but that is down to the pc application.
It sounds very similar to the old bacs processing problem, when it was far cheaper and simpler to have a 386/486 with a dial up modem send the bacs file than having it done by the "400"... I really don't miss the days of creating a pc file transfer script which would be remotely executed by the green screen (I remember it being possible but for the life of me can't remember what it was called or how it worked) and then after working for months something would go wrong and the pc would get re-installed, or replaced, and the batch/transfer definition file would be lost.
(1) If the application remembers the url then it would just be a case of re-using a fixed file name and all the user would have to do is click the big red <send> button... assuming the pc application is clever enough to know if the content of the file has been previously sent and/or the receiving bank application is clever enough to put on hold a batch if it seems as if its a duplicate transmission.
TIA
Gad
------------------------------
Subject: Digest Footer
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) digest list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD
------------------------------
End of MIDRANGE-L Digest, Vol 16, Issue 1295
********************************************
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
